معرفی ۸ روش ایده‌آل برای استفاده Docker در محیط عملیاتی

تهیه‌کننده مقاله : آرمان ملائی

دسته بندی: دواپس
5 دقیقه زمان مطالعه
1401/02/20
0 نظر

این روز‌ها پذیرش Docker به طور مداوم افزایش می‌یابد و بسیاری با افراد هم با آن آشنا هستند، اما  هنوز هم خیلی‌ها به بهترین شکل از روش‌های داکر استفاده نمی‌کنند.

چرا باید از روش‌های ایده آل Docker استفاده کنیم؟

در این مقاله قصد داریم ۸ روش را به شما نشان دهیم که با کمک آن‌ها می‌توانید از Docker به شیوه‌ای درست در پروژه‌های خود استفاده کنید:

  • بهبود امنیت
  • بهینه سازی اندازه تصویر

با کمک این روش ها شما می توانید از برخی از ویژگی‌های مفید Docker استفاده کرده و همچنین Dockerfiles تمیز‌‌تر و قابل نگهداری‌تری بنویسید.

برخی از ویژگی‌های مفید Docker

روش اول – استفاده از تصویر رسمی‌ و تایید شده Docker به عنوان تصویر پایه

هر زمانی که امکان داشت، از یک تصویر رسمی‌ و تایید شده Docker به عنوان تصویر پایه استفاده کنید.

فرض کنید در حال توسعه یک برنامه Node.js هستید و می‌خواهید آن را به عنوان یک تصویر Docker بسازید و اجرا کنید.

به جای گرفتن تصویر از سیستم عامل پایه و نصب node.js، npm و هر ابزار دیگری که برای برنامه خود نیاز دارید، از تصویر رسمی‌ خود برنامه استفاده کنید.

بهبودها:

پاک کننده Dockerfile

تصویر رسمی‌ و تایید شده، که در حال حاضر با بهترین شیوه‌ها ساخته شده است.

روش دوم – استفاده نسخه‌های خاص تصویر Docker

تا الان ما تصویر پایه را انتخاب کرده‌ایم، اما اکنون وقتی تصویر برنامه‌های خود را از این Dockerfile می‌سازیم، همیشه از آخرین تگ تصویر نود استفاده می‌کند.

چرا این مشکل ایجاد می‌شود؟

  • ممکن است نسخه تصویر متفاوتی را که قبلا ساخته شده است، دریافت کنید.
  • نسخه جدید تصویر ممکن است چیزهایی را خراب کند.
  • آخرین برچسب غیر قابل پیش‌بینی است و باعث رفتار غیرمنتظره‌ای شده است.

بنابراین به جای استفاده از آخرین تگ تصویر به صورت تصادفی، شما می‌توانید یک نسخه را فیکس کرده  و همان طور که دوست دارید، برنامه خود را با کمک نسخه خاصی که می‌خواهید از تصویر رسمی‌ آن استفاده کنید، گسترش دهید. قانون مهم این است: هر چه خاص‌تر، بهتر

روش بهبود :

ایجاد شفافیت برای این که بدانید دقیقا از چه نسخه‌ای از تصویر پایه استفاده می‌کنید.

روش سوم –  استفاده از تصاویر رسمی‌ با اندازه کوچک در Docker

هنگامی‌ که یک تصویر Node.js را انتخاب می‌کنید، می‌بینید که در واقع چندین تصویر رسمی‌ وجود دارد. نه تنها با شماره نسخه‌های مختلف، بلکه  توزیع‌های سیستم عامل مختلف

حالا سوال مهم این است، شما کدام را انتخاب می‌کنید و چرا این موضوع اهمیت دارد؟

 اندازه تصویر

اقدام نادرست : اگر تصویر بر اساس یک توزیع سیستم‌ عامل کامل مانند Ubuntu یا Centos باشد، شما از قبل مجموعه‌ای از ابزارها برای تصاویر را خواهید داشت. بنابراین اندازه تصویر بزرگ‌‌تر خواهد بود، اما شما به اکثر این ابزارها در تصاویر برنامه خود نیاز ندارید.

اقدام درست : داشتن تصاویر کوچک‌‌تر به این معنی است که شما به فضای ذخیره سازی کم‌‌تری در repository تصویر و استقرار سرور نیاز دارید و همچنین می‌توانید هنگام pull یا push آن‌ها از repository، تصاویر را سریع‌‌تر انتقال دهید.

مشکل امنیتی

اقدام نادرست : با نصب تعدادی زیادی از ابزارها در داخل سیستم، شما باید حتما جنبه امنیت را نیز در نظر داشته باشید. زیرا تصاویر پایه معمولاً حاوی صدها نقطه آسیب پذیر شناخته شده هستند و به این ‌‌ترتیب شما در عمل سطح بزرگ‌‌تری برای اتک  تصویر را در برنامه ایجاد می‌کنند. به این ‌‌ترتیب شما از ابتدا مشکلات امنیتی غیرضروری را برای تصویر مشخص می‌کنید.

اقدام درست : در مقایسه با حالت قبلی، از تصاویر کوچک‌‌تر با توزیع‌های سیستم‌عامل کم‌‌تر که فقط سیستم لازم را بسته‌بندی می‌کند؛ استفاده کنید. با کمک ابزارها و کتابخانه‌ها، سطح حمله را به حداقل رسانده و مطمئن می‌شوید که تصاویر امن‌‌‌تری می‌سازید.

بنابراین بهترین روش در اینجا انتخاب یک تصویر، با یک نسخه خاص بر اساس توزیع سیستم عامل ضعیف‌‌‌تر مانند alpine است.

روش سوم -  استفاده از تصاویر رسمی‌ docker با اندازه کوچک

Alpine همه چیزهایی را که برای شروع برنامه خود در یک container مورد نیاز است، دارد، اما بسیار سبک‌‌‌تر است و برای اکثر تصاویری که در داکر‌هاب نگاه می‌کنید، یک تگ نسخه با توزیع Alpine در آن خواهید دید. که یکی از رایج ‌‌ترین و محبوب ‌‌ترین تصاویر پایه برای کانتینرهای Docker است.

روش چهارم – بهینه سازی کش برای لایه‌های تصویر هنگام ساخت یک تصویر درDocker

لایه‌های تصویر چیست و کش لایه تصویر به چه معناست؟

۱) لایه‌های تصویر چیست؟

یک تصویر Docker بر اساس یک Dockerfile ساخته شده است و در Dockerfile هر دستور یا دستورالعمل یک لایه تصویر ایجاد می‌کند:

docker و لایه‌های تصویر چیست؟

وقتی از یک تصویر پایه  node alpine مانند مثال بالا استفاده می‌کنیم، این تصویر از قبل یکسری لایه دارد، چون قبلاً با استفاده از Dockerfile ساخته شده است. به علاوه در Dockerfile ما چند دستور دیگر داریم که هر کدام یک لایه جدید به این تصویر اضافه می‌کنند.

۲) در موقع کش چه باید کرد؟

هر لایه توسط Docker ذخیره می‌شود. بنابراین وقتی تصویر خود را بازسازی می‌کنید، اگر Dockerfile شما تغییر نکرده باشد، Docker فقط از لایه‌های کش برای ساخت تصویر استفاده می‌کند.
مزایای لایه‌های تصویر کش شده:
●        ساخت سریع‌‌تر تصویر
●        pull و push سریع‌‌تر نسخه‌های جدید تصویر
اگر یک نسخه تصویری جدید از همان برنامه را pull کنیم و فرض کنیم ۲ لایه جدید، در نسخه جدید اضافه شده است. در این موقع فقط لایه‌های جدید اضافه شده، دانلود می‌شوند، بقیه قبلاً به صورت local توسط Docker ذخیره شده‌اند.

۳) بهینه‌‌سازی cache

برای بهینه‌سازی کش، باید در نظر گرفت، هنگامی‌ که  یک لایه تغییر می‌کند، تمام لایه‌های بعدی یا پایین دستی نیز باید دوباره ایجاد شوند. به عبارت دیگر، هنگامی‌ که محتویات یک خط را در Dockerfile تغییر می‌دهید، کش تمام خطوط یا لایه‌های زیرین شکسته و باطل می‌شوند.
بنابراین در این جا قانون و بهترین اقدام این است:
دستورات خود را در Dockerfile از کم‌‌ترین تا متداول‌‌‌ترین دستورات در حال تغییر مرتب کنید تا از مزایای کش استفاده کرده و از این طریق سرعت ساخت تصویر را بهینه کنید.

روش پنجم – استفاده از فایل .dockerignore

به طور معمول وقتی یک تصویر را می‌سازیم، برای اجرای داخلی اپلیکیشن به همه چیزهایی که در پروژه است، مانند فولدرهای خود ساخته، اهداف یا فولدر ساخت یا  فایل‌های readme و … نیاز نداریم.

شاید این سوال برای شما پیش بیاید که چگونه می‌توان از قرار گرفتن چنین محتوایی در تصویر نهایی اپلیکیشن جلوگیری کرد؟

پاسخ ساده به این سوال استفاده از فایل dockerignore. است.

در حقیقت ما فقط فایل .dockerignore را ایجاد می‌کنیم و تمام فایل‌ها و پوشه‌هایی را که می‌خواهیم نادیده گرفته شوند را لیست می‌کنیم و در هنگام ساخت تصویر داکر به محتویات فایل نگاه کرده و هر چیزی را که در داخل آن مشخص شده است، نادیده می‌گیرد.

روش بهبود:

  • کاهش حجم تصویر
روش ششم داکر استفاده از ساخت‌های چند مرحله‌ای

روش ششم – استفاده از ساخت‌های چند مرحله‌ای

 فرض کنید در پروژه شما محتویاتی مانند توسعه، ابزارهای آزمایش و کتابخانه‌ها وجود دارند که در طول فرایند برای ساختن تصویر به آن‌ها نیاز دارید اما در خود تصویر نهایی برای اجرای برنامه به آن‌ها نیازی ندارید.

اگر این artifact‌ها را در تصویر نهایی خود نگه دارید، حتی اگر برای اجرای برنامه کاملاً غیر ضروری باشند، باز هم منجر به افزایش اندازه تصویر و افزایش سطح اتک می‌شود.

پس چگونه مرحله ساخت را از مرحله اجرا جدا کنیم؟

به عبارت دیگر چگونه می‌توانیم وابستگی‌های ساخت را از تصویر حذف کنیم، در حالی که هنوز آن‌ها را در حین ساخت تصویر در دسترس داریم؟

برای انجام این کار می‌توانید از روشی که به آن ساخت‌های چند مرحله‌ای می‌گویند، استفاده کنید.

ویژگی ساخت چند مرحله‌ای به شما این امکان را می‌دهد که از چندین تصویر موقت در طول فرایند ساخت استفاده کنید، اما تنها آخرین تصویر به عنوان artifact نهایی نگه دارید.

روش هفتم – استفاده حداقلی از کاربر خاص

وقتی این تصویر را ایجاد کرده و در نهایت آن را به عنوان یک کانتینر اجرا می‌کنیم، از کدام کاربر سیستم عامل برای راه اندازی اپلیکیشن در داخل استفاده می‌شود؟

به طور پیش فرض، زمانی که یک Dockerfile، یک کاربر را مشخص نمی‌کند، از یک کاربر root استفاده می‌کند. اما در واقعیت و در بیش‌‌تر مواقع دلیلی برای اجرای کانتینرهایی با امتیازات روت وجود ندارد.

این موضوع در حقیقت یک مشکل امنیتی را معرفی می‌کند، زیرا هنگامی‌که کانتینر روی‌ هاست راه‌اندازی می‌شود، به طور بالقوه دسترسی روت در‌ هاست Docker خواهد داشت.

بنابراین اجرای یک برنامه در داخل کانتینر با کاربر روت یک امتیاز مضاعف بر روی‌ هاست است که کار را برای اتکر آسان‌‌‌تر می‌کند.

برای جلوگیری از این موضوع، بهترین کار این است که به سادگی یک کاربر و یک گروه اختصاصی در تصویر Docker ایجاد کنید تا برنامه را اجرا کرده و همچنین برنامه را در داخل کانتینر با همان کاربر اجرا کنید.

شما می‌توانید از دستورالعملی به نام USER با نام کاربری استفاده کرده و بعد از آن برنامه را به راحتی راه‌اندازی کنید.

نکته: برخی از تصاویر از قبل دارای یک دسته کاربر عمومی‌هستند که می‌توانید از آن استفاده کنید. بنابراین نیازی به ایجاد یک مورد جدید ندارید. برای مثال تصویر node.js قبلاً یک کاربر عمومی‌به نام node را دسته‌بندی می‌کنید و بعد به سادگی می‌توانید، از آن برای اجرای برنامه در داخل کانتینر استفاده کنید.

روش هشتم – اسکن تصاویر برای آسیب‌پذیری‌های امنیتی در Docker

در نهایت شما چگونه می‌توانید مطمئن شوید که تصویری که می‌سازید، چند آسیب‌پذیری امنیتی دارد؟

بهترین پیشنهاد به عنوان یک راه حل نهایی و ایده آل این است که پس از ساختن تصویر آن را از نظر آسیب‌پذیری‌های امنیتی با استفاده از دستور dockerscan اسکن کنید.

در پس‌زمینه Docker در واقع از سرویسی به نام snyk برای اسکن آسیب‌پذیری تصاویر بهره می‌برد و برای اسکن از پایگاه داده‌ای  آسیب پذیری‌ها استفاده می‌کند که به صورت مدام بروزرسانی می‌شود.

نمونه خروجی دستور اسکن docker به شکل زیر است:

خودکار کردن اسکن در Docker

علاوه بر اسکن دستی تصاویر با دستور docker scan در یک CLI، شما می‌توانید Docker Hub را برای اسکن خودکار تصاویر زمانی که به repository،push می‌شوند، پیکربندی کنید. همچنین شما می‌توانید در هنگام ساخت تصاویر Docker آن‌ها را در پایپ‌لاین‌های CI/CD خود ادغام کنید.

جمع بندی

در این مقاله به ۸ تا از بهترین روش‌هایی که امروزه می‌توانید برای ساخت تصاویر Docker کم‌‌‌تر و ایمن‌‌‌تر استفاده کنید، اشاره کردیم. امیدواریم این روش‌ها برای بعضی از شما کاربردی باشند. البته روش‌های بسیار بیش‌‌تری در رابطه با Docker وجود دارد اما به نظر می‌رسد که استفاده از روش‌های اشاره شده در این مقاله بتوانند نتایج بسیار مثبتی هنگام استفاده از Docker در تولید محصول برای شما داشته باشد. اگر این مقاله برای شما جالب بوده است یا روش‌هایی دیگری را می‌شناسید، که می‌توانند نتایج بهتری در پی داشته باشند، خوشحال خواهیم شد تا آن‌ها را در کامنت را به ما به اشتراک بگذارید.

منبع: https://dev.to/techworld_with_nana/top-8-docker-best-practices-for-using-docker-in-production-1m39

مشاهده فرصت‌های شغلی در آسا مشاهده فرصت‌های شغلی در آسا