کامپوز فایل و داکر کامپوز (قسمت پنجم)

داکر کامپوز ابزاریه که با استفاده از اون می‌تونیم چندین کار رو با یک دستور انجام بدیم. مثلا می‌تونیم چندین کانتینر رو به همراه نتورک‌ها و والیوم‌هایی که لازم داره بسازیم و به هم ارتباط بدیم. قبل‌تر باید داکر کامپوز رو جداگانه نصب می‌کردیم اما اخیرا امکان اینکه بتونیم کامپوز رو به صورت یه پلاگین همراه داکر کلاینت داشته باشیم هم اضافه شده و دیگه نیاز نیست که براش ابزار جداگانه‌ای نصب کنیم. یه نکته‌ی مهم اینکه اگر شما یک سرور داشته باشید بهترین گزینه برای مدیریت سرویس‌ها استفاده از docker compose هست.

خب یه مروری کنیم پست‌های قبلی رو:

• دواپس چیه و چرا لازمه؟  اینجا در مورد دواپس و ضرورت استفاده از آن صحبت کردم.

• چطور اپلیکیشن مناسب کلاد آماده کنیم؟ و اینجا توضیح دادم که چطور می‌تونیم یه اپلیکیشن مناسب کلاد توسعه بدیم.

• چه عمقی از لینوکس برای دواپس لازمه؟ و اینجا توضیح دادم که کدوم موارد لینوکس برای دواپس الزامی هست که اول سراغ اون موارد بریم.

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

• در مسیر دواپس اینبار اجزای اصلی انسیبل تو این پست اجزای انسیبل رو معرفی کردم و آنها را شرح دادم.

• در مسیر دواپس به داکر رسیدیم (قسمت اول) تو این پست داکر رو شروع کردیم و اونو معرفی کردیم.

• در مسیر دواپس اینبار: پشت داکر چه خبره؟ (قسمت دوم) توی این پست در مورد تکنولوژی هایی که داکر ازشون استفاده میکنه توضیح دادیم.

• تست نوشتن و شروع مسیر CI/CD (قسمت اول) توی این پست انواع تست رو بررسی کردیم و با ابزارهای CI/CD آشنا شدیم و یه مقایسه بین گیت‌لب و جنکینز داشتیم.

• در مسیر CI/CD گیت رو بررسی می‌کنیم (قسمت دوم) توی این پست قبل ورود به گیت‌لب نیاز بود که گیت و ورژن کنترل سیستم ها رو یه بررسی کنیم.

• در مسیر ‌CI/CD شناخت گیت‌لب (قسمت سوم) توی این پست اجزای گیت‌لب رو بررسی کردیم و با کامپوننت‌های مختلفی که داره بیشتر آشنا شدیم.

• در مسیر ‌CI/CD پایپ‌لاین و رانر گیت‌لب (قسمت چهارم) توی این پست پایپ‌لاین و رانر گیت‌لب رو بررسی کردیم.

• در مسیر CI/CD وریبل، گیت‌آپس و جمع‌بندی (قسمت پنجم) توی این پست وریبل‌های گیت‌لب رو بررسی کردیم و یه معرفی کوتاه از گیت‌آپس و آتودواپس کردیم و در انتها یه مقدار تجربه‌های خودم رو در گیت‌لب باهاتون به اشتراک گذاشتم.

• در مسیر Observability، الک (قسمت دوم) توی این پست استک قدرتمند ELK رو بررسی کردیم.

• در مسیر Observability، جمع بندی استک الک (قسمت سوم) توی این پست بقیه کامپوننت‌های استک الک رو بررسی کردیم و fluentd و fluentbit رو مقایسه کردیم و نهایتا یه معرفی هم روی opensearch داشتیم.

• در مسیر Observability، استک پرومتئوس (قسمت چهارم) توی این پست یه معرفی اولیه داشتیم روی استک پرومتئوس.

• در مسیر Observability، استک پرومتئوس (قسمت پنجم) توی این پست یه مقدار کامپوننت های استک پرومتئوس رو بیشتر بررسی کردیم.

• در مسیر Observability، استک ویکتوریا (قسمت ششم) توی این پست استک ویکتوریا رو معرفی کردیم و سعی کردیم با پرومتئوس مقایسه‌اش کنیم.

• در مسیر Observability، می‌می‌ر (قسمت هفتم) توی این پست در مورد ابزار میمیر از ابزارهای گرافانا توضیح دادیم و کاربردش رو بررسی کردیم.

• در مسیر Observability، لوکی (قسمت هشتم) توی این پست در مورد ابزار گرافانا برای مدیریت لاگ یعنی لوکی توضیح دادیم و آخرشم یه معرفی کوتاه رو graylog داشتیم.

• در مسیر Observability، تمپو (قسمت نهم) توی این پست در مورد تریسینگ توضیح دادیم و گرافانا تمپو رو بررسی کردیم و یه معرفی کوتاه روی Jaeger داشتیم

• در مسیر Observability، گرافانا (قسمت دهم) توی این پست در مورد گرافانا و HA کردنش و همچنین یه سری از ابزارهاش مثل alloy , incident, on-call توضیح دادیم.

• آغاز مسیر کوبر (قسمت اول) تو این قدم به معرفی ابزارهای ارکستریشن پرداختیم و مدارک کوبرنتیز رو بررسی کردیم.

• کوبر سینگل ( قسمت دوم ) توی این قدم در مورد kubectl , kubeconfig توضیح دادیم و تعدادی ابزار رو معرفی کردیم که به کمک اونها میتونیم یک کوبرنتیز دمه‌دستی واسه تست‌هامون داشته باشیم.

• کامپوننت‌های کوبر ( قسمت سوم ) توی این پست کامپوننت‌های مختلف کوبرنتیز رو بررسی کردیم و اجزای نودهای مستر و ورکر رو دونه دونه بررسی کردیم و توضیح دادیم.

• پادها و مدیریت اونها در کوبرنتیز (قسمت چهارم) توی این پست در مورد پاد توی کوبرنتیز توضیح دادیم و موارد مربوط به اون رو بررسی کردیم.

• ورک‌لودهای کوبر و مدیریت منابع کوبر (قسمت پنجم) توی این پست در مورد namespaceها توی کوبر توضیح دادیم و انواع ورک‌لود کوبر رو بررسی کردیم.

• اگه لازم شد کوبر خودش گنده میشه‌! ( قسمت ششم ) توی این پست در مورد سه نوع ورک‌لود‌ مرتبط با scaling به صورت خودکار در کوبرنتیز توضیح دادیم.

• نتورک کوبر (قسمت هفتم) توی این قسمت انواع سرویس توی کوبرنتیز رو بررسی کردیم و در مورد مفاهیم اینگرس و نتورک پالیسی توضیح دادیم.

• استورج کوبرنتیز (قسمت هشتم) توی این قسمت در مورد انواع استورج توی کوبرنتیز توضیح دادیم و مفاهیم PV و PVC و Storage Class رو بررسی کردیم.

• پراب، ریکوئست و لیمیت (قسمت نهم) توی این قسمت موارد مربوط به محدود کردن منابع کانتینر توی کوبرنتیز رو بررسی کردیم و در مورد انواع ‌probe ها توی کوبرنتیز توضیح دادیم.

• پاد تو نود (قسمت دهم) توی این قسمت درمورد فرآیند انتقال پاد به نود مناسب مفاهیم پیشرفته‌تری مثل affinity و anti-affinity و taint و toleration رو بررسی کردیم.

• اولویت پاد و امنیت (قسمت یازدهم) توی این قسمت در مورد تعیین اولویت برای پادها و جنبه‌های مختلف امنیت در کوبرنتیز توضیح دادیم.

• کنترل دسترسی به کوبر (قسمت دوازدهم) توی این قسمت در مورد مراحل دسترسی به api کوبرنتیز صحبت کردیم و بعدش مفاهیمی مثل سرویس اکانت رو توضیح دادیم.

• دیزاین کلاستر (قسمت سیزدهم) توی این قسمت در مورد طراحی و دیزاین یک کلاستر و روش‌های مختلفی که داره توضیح دادیم و همچنین تفاوت روش‌های مختلف تقسیم منابع در کلاسترها را بررسی کردیم.

• مالتی تننسی در کوبر (قسمت چهاردهم) توی این قسمت چالش‌های مربوط به داشتن چند مستاجر بر روی کلاستر کوبرنتیز توضیح دادیم.

• هلم (قسمت پانزدهم) توی این قسمت پکیج منیجر معروف کوبرنتیز یعنی Helm رو بررسی کردیم و در موردش ویژگی‌ها و کاربردهاش توضیح دادیم.

• سی آر دی و اُپراتور (قسمت شانزدهم) توی این قسمت در مورد اینکه چطوری یه ریسورس کاستوم شده به کلاستر اضافه کنیم توضیح دادیم و مفهوم اُپراتور رو توی کوبر بررسی کردیم.

• نصب کلاستر با kubeadm (قسمت هفدهم) توی این قسمت قدم به قدم نحوه نصب یک کلاستر کوبرنتیز رو با استفاده از ابزار kubeadm توضیح دادیم.

• نصب کلاستر با kubespray (قسمت هجدهم) توی این قسمت نحوه نصب کلاستر با یه پروژه خیلی خوب به نام کیوب اسپری که یه انسیبل خفن برای ستاپ کلاستر رائه میده رو توضیح دادیم.

• نصب کلاستر با rancher (قسمت نوزدهم) توی این قسمت توضیح دادیم که چطور با استفاده از ابزار RKE یک کلاستر کوبرنتیز راه‌اندازی کنیم.

توصیه می‌کنم که حتما این پست‌ها رو هم مطالعه کنید. بریم که ادامه بدیم.

تاریخچه داکر کامپوز:

ورژن اول کامندلاین داکر کامپوز تو سال ۲۰۱۴ اومد که با زبان پایتون نوشته شده بود و با دستور docker-compose اجرا میشد و بالای فایل های کامپوزش هم یک قسمت version میذاشتن که از عدد ۲.۰ تا ۳.۸ مقادیر مختلف داشت که فایل فورمت های مختلفن و اینجا میتونید بیشتر بخونید در موردش. اما از سال ۲۰۲۰ ورژن دوم داکر کامپوز معرفی شد که به زبان گولنگ هست و با دستور docker compose ازش استفاده می‌کنیم و دیگه بخش version رو بالای فایل هاش نداره و می‌تونیم نذاریمش.

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

برخی از مزایای استفاده از داکرکامپوز:

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

• در زمان ایجاد تغییر کانتینر‌ها را مجدد ایجاد نماید.

• با استفاده از متغیرهای که تعریف می‌شود می‌توان سرویس‌ را در محیط‌های مختلف پیاده‌سازی کرد.

• اطلاعات کانتینرها‌ را حسب نیاز بر روی volumeهایی که ایجاد می‌کند قرار دهد.

• داکر کامپوز می‌تواند به خوبی با سرویس‌های CI/CD ادغام شود و تمام موارد مورد نیاز را به صورت خودکار انجام دهد.

یک نکته‌ی مهم اینکه ما یک کامندلاین به عنوان docker compose و یک compose file داریم که فرمت yaml داره. همواره ما کامپوز فایل سرویس‌های خودمون رو آماده می‌کنیم که داخل آن سرویس‌ها به همراه نتورک و والیوم‌های آن‌ها و هر چیزی که لازم دارند رو قرار دادیم. به عبارتی ما تو کامپوزفایل داریم می‌گیم که سرویس‌هامون چطوری بالا میان و راه‌اندازی میشن.

داکر کامپوز برای ما کنترل کردن کل استک اپلیکیشن هامون رو راحت کرده و همینطور مدیریت سرویس ها و شبکه اونها و والیوم‌های دیسکی که نیاز دارند رو جمع کرده توی یه دونه yaml فایل. بعد از اینکه کامپوز فایلتون رو آماده کنید، یه دستور docker compose up -d میزنید و تمام سرویس‌ها و کانفیگ هایی که زدید، ایجاد میشن 🙂

نکته‌ی دیگه اینکه ما با استفاده از compose file داریم می‌ریم سمت اینکه همه چیز رو به صورت کد کنیم. با داکرفایل داریم نحوه‌ی آماده سازی ایمیج رو به صورت کد می‌کنیم و با استفاده از کامپوز فایل نحوه‌ی راه‌اندازی و اجرای کانتینرها رو داریم کد می‌کنیم. قبلا هم زیاد روی این موضوع تاکید کردم و کلا توی دواپس ما دنبال این هستیم که بریم سمت کد! دلیلش هم اینه که کد رو میشه نگهداری کرد و بهبودش داد و هی بهترش کرد.

بررسی Compose application model:

• اپلیکیشن هامون رو تحت عنوان services توی کامپوز فایل تعریف می‌کنیم، برای هر سرویس ایمیج داکری که می‌خوایم اون کانتینر از روش بالا بیاد رو مشخص می‌کنیم و کانفیگ های مختلفی که نیاز داره رو هم در ادامه اش تعریف می‌کنیم.

• سرویس‌ها با هم از طریق networks در ارتباط هستند و نتورک یه پلتفرم هست که قابلیت این رو بهمون میده که ترافیک شبکه بین کانتینرهایی که به هم متصل هستند route بشه و شبکه های داکری رو هم که نیاز داریم زیر بخش networks توی کامپوز فایل مشخص می‌کنیم و از اونها برای سرویس‌هامون استفاده می‌کنیم.

• همونطور که توی قسمت‌های قبلی هم توضیح دادم سرویس‌ها برای ذخیره و اشتراک دیتایی که می‌خوایم اونو نگه داریم از والیوم استفاده می‌کنند. زیر بخش volumes توی کامپوز فایل کانفیگ های گلوبال والیوم های داکری که می‌خوایم و اسم اونها رو مشخص می‌کنیم تا برای سرویس هایی که تعریف می‌کنیم ازشون استفاده کنیم.

• بعضی از سرویس‌ها نیاز به یک سری کانفیگ هایی دارن که به پلتفرم اونها یا runtime شون بستگی داره. برای این موارد یک بخش configs در کامپوز فایل داریم که اونجا تعریفشون می‌کنیم.

• و نهایتا بخش secrets که نوعی خاص از کانفیگ هست که دیتای حساس در اون داریم و نباید بدون در نظر گرفتن ملاحظات امنیتی اون دیتا منتشر بشه. به طور کلی کانفیگ و سکرت هم یه جورایی فایل هایی هستن که مانت میشن توی کانتینر اما با رعایت ملاحظات مربوط به خودشون.

توی مسیر پروژه کامپوز فایل باید با یکی از اسم‌های compose.yml یا compose.yaml یا docker-compose.yml یا docker-compose.yaml قرار بگیره که دو مورد آخر برای ورژن های قبل‌تر هست و اولویت اجرا با اسم compose هست.

برای اینکه کامپوز فایلتون رو کارآمدتر کنید و نگهداریش رو بهتر کنید میتونید در مورد fragments و extensions هم بخونید.

اگر تعداد سرویس‌های کامپوزتون زیاد هست برای اینکه فایل کامپوز مرتب تری داشته باشید می‌تونید سرویس‌هاتون رو توی چنتا فایل جدا کنید. سه روش برای این مورد هست که ساده ترش اینه که از فلگ f- و merge استفاده کنید و روش های Extend و Include هم هستند که میتونید بیشتر درموردشون بخونید.

در ادامه لیستی از مواردی که میتونیم توی کامپوز فایل مون اونها رو کانفیگ کنیم همراه یه توضیح کوتاه ازشون رو براتون میذارم:

• build: can be specified either as a string containing a path to the build context

• command: Override the default command

• container_name: Specify a custom container name, rather than a generated default name

• depends_on: Express dependency between services

• devices: LIST OF DEVICE MAPPINGS

• dns: Custom DNS servers. Can be a single value or a list

• image: Specify the image to start the container from

• logging: Logging configuration for the service.

• network_mode: Network mode. Use the same values as the docker client --network parameter

• Networks: Networks to join

• Pid: Sets the PID mode to the host PID mode

• Restart: no is the default restart policy, and it does not restart a container under any circumstance

• Volumes: Mount host paths or named volumes

• Secrets: Grant access to secrets on a perservice basis using the per-service

• Labels: Specify labels for the service

• Domainname: Specify a custom domain name

• external_links: Link to containers started outside this docker-compose.yml or even outside of Compose

• Links: Link to containers in another service.

• env_file: Add environment variables from a file

• environment: Add environment variables

• expose: expose ports without publishing them to the host machine

• • healthcheck: configure a check that’s run to determine whether or not containers for this service are “healthy”

• security_opt: Override the default labeling scheme for each container

• Sysctls: Kernel parameters to set in the container

• entrypoint: Override the default entrypoint

• Ports: Expose ports.

• Hostname: Specify a custom hostname

• Ulimits: Override the default ulimits for a container

• Privileged: Gives all capabilities to the container

• working_dir: The default working directory

• User: Set the default user within a container

• mac_address: Set mac address

• Driver: Specify which volume driver should be used for this volume

• driver_opts: Specify a list of options as keyvalue pairs to pass to the driver for this volume

• External: If set to true, specifies that this volume has been created outside of Compose

• Labels: Add metadata to containers using Docker labels

• Name: Set a custom name for this volume

• Driver: Specify which driver should be used for this network

• driver_opts: Specify a list of options as keyvalue pairs to pass to the driver for this network

• Internal: By default

• Labels: Add metadata to containers using Docker labels.

• External: If set to true, specifies that this network has been created outside of Compose.

• Name: Set a custom name for this network

سناریوی پیاده‌سازی سرویس‌:

معمولا این سناریو در راه‌اندازی سرویس‌ها انجام می‌شود. ابتدا داکرفایل برای ایجاد ایمیج‌ها آماده می‌شود. سپس با توجه به نیاز موجود برای راه‌اندازی سرویس و ارتباطات و عملکرد آنها با هم یک کامپوز فایل آماده می‌گردد. سپس با استفاده از دستورات داکرکامپوز و با توجه به کامپوز فایل سرویس با تمام شرایط مد نظر را‌ه‌اندازی و در اختیار قرار می‌گیرد. می‌توان برای کل سرویس و یا هر جزئی‌ از آن نیز تست نوشت و تمام موارد را تست کرد.

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

دستورالعمل‌های کامپوزفایل:

دستورالعمل ‌services:

تنها دستورالعمل‌های services, networks و volumes به صورت مسیر پیش‌فرض در کامپوزفایل می‌باشند. البته دستورالعمل‌های configs و secrets هم هستند اما آنها تنها در قسمت swarm کاربرد دارند. همانطور که می‌دونید yaml به indent دستورالعمل‌ها حساس می‌باشد از این رو در زمان ایجاد yaml file می‌بایست به موقعیت مکانی تمام دستورالعمل‌ها دقت کرد زیرا اگر در جای درستی قرار نگرفته باشن خطا میده و فایل شما اجرا نخواهد شد. در ضمن پسوند فایل می‌تواند yml. یا yaml. باشد و هر دو تای آنها درسته.

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

دستورالعمل ‌build:

با استفاده از این دستورالعمل می‌توان تنظیمات مربوط به ساخت ایمیج در زمان اجرای سرویس را داد. می‌توان مسیر و اسم داکرفایل را مشخص کرد و آپشن‌های زمان build همانند arg را در آن قرار داد و یا اینکه ایمیج با چه نامی ساخته شود. دستورالعمل‌های مهم زیر مجموعه‌ی build عبارتند از:

دستورالعمل context: مسیری که داکرفایل در آنجا قرار دارد و یا آدرس ریپوی git آن را مشخص می‌کند.

دستورالعمل dockerfile: داکرفایل اگر با نام Dockerfile داخل مسیری که اشاره شد وجود ندارد و نام دیگری دارد با این آپشن مشخص می‌کند.

دستورالعمل args: دقیقا همان arg داخل داکرفایل است که می‌توان در زمان ساخت ایمیج آن را قرار داد.

دستورالعمل labels: در زمان ساخت ایمیج به آن لیبل داده می‌شود. (از نسخه‌ی ۳.۳ به بعد)

دستورالعمل command: دستورالعمل پیش‌فرض کانتینر را جایگذاری می‌کند.

دستورالعمل ‌container_name:

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

دستورالعمل ‌depends_on:

این دستورالعمل بسیار کاربردی می‌باشد و اگر بین سرویس‌های داخل کامپوز فایل اولویت زمانی در راه‌اندازی اهمیت داشته باشد با استفاده از این دستورالعمل می‌توان سرویسی را به سرویس دیگری وابسته کرد. در تصویر زیر برای اینکه سرویس web راه‌اندازی شود نیاز است تا ابتدا سرویس db و سرویس redis راه‌اندازی شود. تازمانی که هر دو سرویس راه‌اندازی نشوند سرویس web راه‌اندازی نخواهد شد.

دستورالعمل ‌deploy:

فقط در نسخه‌ی ۳ کار می‌کند. می‌توان با استفاده از آن موارد مربوط به پیاده‌سازی سرویس را مشخص کرد. این دستورالعمل تنها در زمان استفاده از swarm و با دستورالعمل docker stack deploy قابل استفاده می‌باشد. اگر با دستور docker compose استفاده شود این قسمت به صورت کلی نادیده گرفته می‌شود. حالا بعدا در مستندی به صورت کامل swarm و نحوه‌ی کار با آن و آپشن‌های کنار آن رو توضیح می‌دهیم.

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

دستورالعمل endpoint_mode: تنها در نسخه‌ی ۳.۳ قابل استفاده است. برای زمانی که کاربر از بیرون کلاستر بخواهد به آن متصل شود کاربرد دارد. دو حالت دارد که در ادامه توضیح داده می‌شود:

• حالت vip: کلایت تنها یک ip به صورت VIP مشاهده‌ می‌کند و تمام درخواست‌های او به سمت همان IP می‌رود و کاربر اصلا متوجه نمی‌شود تعداد سرویس‌های پشت آن نخواهد شد. به صورت پیش‌فرض این روش همواره تنظیم شده است.

• حالت dnsrr: به صورت round-robin و از طریق DNS انجام می‌شود و در این روش از تک VIP استفاده نمی‌شود. در این روش به ازای هر نام تعداد زیادی IP قرار داده می‌شود و به صورت round-robin به یکی از آنها متصل می‌شود.

دستورالعمل mode: اگر به صورت global تنظیم شود به ازای هر نود در کلاستر swarm یک کانتینر ایجاد خواهد شد. به صورت پیش‌فرض replicated تنظیم شده است که به تعداد مشخصی از کانتینر دیپلوی می‌شود.

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

دستورالعمل resources: با استفاده از این دستورالعمل می‌توان منابعی که این کانتینر استفاده می‌کند را مشخص و محدودیت‌های مربوط به آن را تنظیم نمود. به مثال زیر توجه کنید.

دستورالعمل restart_policy: تنظیمات مربوط به restart کانتینر می‌باشد. این کانفیگ تنظیمات مربوط به restart را جایگزین می‌کند. در مثال زیر زمانی که موضوعی باعث fail کانتینر شود با ۵ ثانیه تاخیر ۳ بار تلاش می‌کند تا کانتینر را ران کند.

دستورالعمل ‌dns و dns_search:

با استفاده از این دستور العمل‌ها می‌توان برای کانتینر DNS تنظیم کرد. به مثال‌های زیر توجه کنید.

dns: 8.8.8.8
dns:
  - 8.8.8.8
  - 9.9.9.9

dns_search: example.com
  dns_search:
    - dc1.example.com
      - dc2.example.com

دستورالعمل ‌entrypoint:

با استفاده از این دستورالعمل، میتوان entrypoint داخل ایمیج را در این سرویس جایگذاری می‌کند و این به جای آن اجرا می‌شود. به صورت زیر می‌توان از آن استفاده کرد.

entrypoint: /code/entrypoint.sh

entrypoint:
    - php
    -  -d   
    - zend_extension=/usr/local/lib/php/extensions/no-debug-non-zts-20100525/xdebug.so    
    -  -d    
    - memory_limit=-1   
    - vendor/bin/phpunit

دستورالعمل ‌env_file:

اضافه کردن متغیرهای محلی با استفاده از فایل که می‌تواند شامل یک متغیر و یا لیستی از آنها باشد. به مثال‌های زیر توجه کنید.

env_file: .env

env_file:
  - ./common.env
  - ./apps/web.env
  - /opt/secrets.env

در فایل‌های متغیرها، اونها رو به صورت VAR=VAL می‌بایست قرار داد. اگر از # استفاده شود به صورت comment خواهد بود و خط خالی نیز نادیده گرفته می‌شود.

# Set Rails/Rack environment
RACK_ENV=development

اگر نیاز باشد متغیری تنها در زمان build مورد استفاده قرار گیرد می‌بایست از arg استفاده کرد. اگر چند تا فایل متغیر باهم لود بشن و داخل آنها متغیر یکسان وجود داشته باشد همواره متغیرهای فایل آخر مرجع می‌باشد. یعنی آخرین مقداری که متغیر گرفته باشد معتبر است. نکته‌ی مهمی است که بهش دقت کنید.

دستورالعمل ‌environment:

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

environment:
  RACK_ENV: development
  SHOW: 'true'
  SESSION_SECRET:

environment:
  - RACK_ENV=development
  - SHOW=true
  - SESSION_SECRET

دستورالعمل ‌expose:

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

expose:
 - "3000"
 - "8000"

حواستون به تفاوت بین expose و publish باشه که این دو تا باهم متفاوت هستند. اینجا در موردشون صحبت کردیم.

دستورالعمل ‌external_links:

برای زمانی که نیاز است تا با کانتینری خارج از این docker-compose.yml ارتباط برقرار کرد استفاده می‌شود. به صورت CONTAINER:ALIAS نیز استفاده می‌شود. به مثال زیر توجه کنید.

external_links:
 - redis_1
 - project_db_1:mysql
 - project_db_1:postgresql

دستورالعمل ‌extra_hosts:

با استفاده از آن می‌توان داخل etc/hosts/ کانتینر اطلاعاتی که لازم داریم را وارد کنیم و اصطلاحا به آن host اضافه کنیم.

extra_hosts:
 - "somehost:162.242.195.82"
 - "otherhost:50.31.209.229"

دستورالعمل ‌healthcheck:

می‌توان وضعیت سلامت سرویس داخل کانتینر رو بررسی کرد که دارای ۳ تا وضعیت می‌باشد که قبلا در داکرفایل آنها را توضیح دادیم. تمام مواردی که در این دستورالعمل مورد استفاده قرار می‌گیرد دقیقا همانند داکرفایل می‌باشد با این تفاوت که در داکرفایل داخل ایمیج این موارد تنظیم می‌شد و اینجا برای خود کانتینر تنظیم میشه.

healthcheck:
  test: ["CMD", "curl", "-f", "http://localhost"]
  interval: 1m30s
  timeout: 10s
  retries: 3
  start_period: 40s

در صورتی که نیاز داشته باشید که healthcheck مربوط به ایمیج را نیز غیر فعال کنید می‌تواند از دستور زیر استفاده کنید.

healthcheck:
  disable: true

دستورالعمل ‌image:

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

دستورالعمل ‌labels:

با استفاده از آن می‌توان metadata کانتیرها را تغییر داد. گاهی با استفاده از این اطلاعات که به کانتینرها اضافه می‌شود می‌توان سرویس‌های مختلفی را دریافت کرد. برای همین این موضوع اهمیت زیادی دارد.

دستورالعمل ‌logging:

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

logging:
  driver: syslog
  options:
  syslog-address: "tcp://192.168.0.42:123"

به صورت پیش‌فرض ۳ تا درایور برای لاگ کانتیرهای داکر وجود دارد که عبارت است از:

driver: "json-file"
driver: "syslog"
driver: "none"

که درایور json-file به صورت پیش‌فرض می‌باشد و تمام آن را می‌توان در دستور docker-compose logs مشاهده کرد. یه نکته‌ی مهم اینکه این آپشن و دستورالعمل وابسته به کانفیگ مربوط به logging driver سرویس داکر شما می‌باشد و درایورهایی رو می‌توانید استفاده کنید که در آنها تعریف کرده باشید.

دستورالعمل ‌network_mode:

برای مشخص کردن شبکه کانتینر مورد استفاده قرار می‌گیرد. برای زمانی کاربرد دارد که شما بخواهید از modeهای مختلفی به عنوان مثال host و یا none استفاده نمایید.

دستورالعمل ‌networks:

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

دستورالعمل aliases: با استفاده از آن برای کانتیرها aliase تعریف می‌شود و می‌توان داخل آن network کانتینر را علاوه بر اسم و id آن با این aliase نیز صدا کرد.

دستورالعمل ipv4_address, ipv6_address: با استفاده از آن می‌توان ip به هر کانتیر اختصاص داد.

version: '3'
services:
  some-service:
      networks:
         some-network:
             aliases:
                - alias1
                - alias3
             ipv4_address: 172.16.238.10
             ipv6_address: 2001:3984:3989::

دستورالعمل ‌pid:

می‌توان pid داخل کانیتر را با host یکی کرد که برای این کار از این دستورالعمل استفاده می‌شود.

دستورالعمل ports:

که با استفاده از آن می‌توان پورت‌ها رو از داخل کانتیر به هاست publish کرد. به صورت اختصار به صورت HOST:CONTAINER استفاده می‌شود. برای مثال پورت ۸۰ کانتیر به پورت ۸۰۸۰ هاست مپ می‌شود.

ports: 
   - "8080:80"

می‌توان تنها پورت کانتیر را قرار داد که آنگاه سرویس داکر آن را بر روی یکی از رندم پورت‌های هاست مپ می‌کند. و می‌توان به صورت اختصاصی مشخص کرد که این پورت بر روی کدام پورت و ip سروس هاست bind شود و یا اینکه در چه پروتکلی قرار داشته باشد. در مثال‌های زیر تمام موارد آورده شده است.

ports:
 - "3000"
 - "3000-3005"
 - "8000:8000"
 - "9090-9091:8080-8081"
 - "49100:22"
 - "127.0.0.1:8001:8001"
 - "127.0.0.1:5000-5010:5000-5010"
  - "6060:6060/udp"

اما به گونه‌ای دیگر نیز پورت را تعریف کرد که دارای توضیحات زیاد و روش طولانی آن می‌باشد. در مثال زیر پورت ۸۰ داخل کانتینر را به پورت ۸۰۸۰ داخل هاست مپ می‌کند. این نوع فرمت در نسخه ۳.۲ به بعد می‌باشد.

ports:
  - target: 80
    published: 8080
    protocol: tcp
    mode: host

دستورالعمل ‌restart:

این دستورالعمل برای سیاست restart کانتینر مورد استفاده قرار می‌گیرد و به صورت پیشفرض برای همه‌ی کانتینرها no می‌باشد. این دستورالعمل تنها در زمان استفاده غیر swarm کاربرد دارد. اگر از آپشن always استفاده شود همواره بعد از هر اتفاقی حتی اگر کانفیگ کانتینر مشکل داشته باشد مدام تلاش می‌کند که آن را استارت کند. آپشن on-failure برای زمانی است که به دلیل خطایی کانتینر استاپ شده باشد که آن را مجدد استارت می‌کند. آپشن unless-stopped که بسیار شبیه always می‌باشد اما اگر کانتیر به صورت دستی stop شود بعد از restart سرویس داکر کانتیر را استارت نمی‌کند اما در always این کار را انجام می‌دهد.

دستورالعمل ‌sysctls:

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

sysctls:
  net.core.somaxconn: 1024
  net.ipv4.tcp_syncookies: 0
sysctls:
  - net.core.somaxconn=1024
  - net.ipv4.tcp_syncookies=0

دستورالعمل ‌ulimits:

با استفاده از آن آپشن‌های مربوط به limit.conf را می‌توان در کانتیر تغییر داد و اجازه استفاده بیشتر و بهینه‌تر از منابع سیستم‌عامل را به آن داد.

ulimits:
  nproc: 65535
  nofile:
    soft: 20000
    hard: 40000

دستورالعمل ‌volumes:

به دو روش یکی قرار دادن بر روی مسیری از دایرکتوری هاست و دیگری ایجاد والیوم با استفاده از درایورهای مختلف می‌توان داده‌های کانتینر را بر روی هاست ذخیره کرد. در استفاده از والیوم نیز می‌توان به صورت مختصر یعنی HOST:CONTAINER استفاده کرد یا به صورت طولانی‌تر تمام هر قسمت را توضیح داد. در مثال زیر چند نمونه از استفاده‌ی مختصر آن آورده شده است.

volumes:
  # Just specify a path and let the Engine create a volume
    - /var/lib/mysql
  # Specify an absolute path mapping
    - /opt/data:/var/lib/mysql
  # Path on the host, relative to the Compose file
    - ./cache:/tmp/cache
  # User-relative path
    - ~/configs:/etc/configs/:ro
  # Named volume
   - datavolume:/var/lib/mysql

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

دستورالعمل domainname:

می‌توان با استفاده از آن domainname را برای کانتینر تعریف کرد.

دستورالعمل hostname:

با استفاده از آن hostname برای کانتینر تعریف می‌کنیم.

دستورالعمل privileged:

اگر در کانتینر نیاز به سطح دسترسی بیشتری هستیم آن را با privileged اجرا خواهیم کرد. این موضوع نکته‌ی امنیتی دارد و بهتر است که استفاده نشود.

دستورالعمل user:

کاربر کانتینر در زمان اجرا را مشخص می‌کند.

دستورالعمل working_dir:

دایرکتوری کاری کانتینر را مشخص می‌کند.

دستورالعمل Volume configuration reference:

والیومی که در قسمت بالاتر توضیح داده شد مربوط به قسمت سرویس می‌باشد اما این قسمت برای تعریف والیوم می‌باشد. این قسمت هم ردیف قسمت سرویس در کامپوز فایل قرار داده می‌شود. این دستورالعمل شامل چند زیرمجموعه می‌باشد که عبارتند از:

دستورالعمل driver: با استفاده از آن می‌توانیم درایور مربوط به والیوم را مشخص کنیم. به صورت پیش‌فرض درایور local استفاده می‌شود.

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

دستورالعمل external: اگر این آپشن true باشد یعنی والیوم بیرون از کامپوز فایل تعریف می‌شود و وجود خواهد داشت و باید از آن استفاده کند. معمولا این آپشن مواقعی که از stack استفاده می‌شود کاربرد دارد.

دستورالعمل labels: با استفاده از آن می‌توان metadata والیوم‌ها را تغییر داد.

دستورالعمل name: برای کانتینر اسم انتخاب کرد. (از نسخه‌ی ۳.۴ به بعد)

دستورالعمل Network configuration reference:

قبلا درباره network که زیرمجموعه سرویس بود صحبت کردیم. این قسمت هم ردیف سرویس در کامپوز فایل بوده و برای معرفی شبکه‌ی مورد استفاده کاربرد دارد. این دستورالعمل چندین زیرمجموعه دارد که در ادامه به آنها اشاره می‌شود:

دستورالعمل driver: با استفاده از آن درایور شبکه مورد نظر را مشخص می‌کند که به صورت پیش‌فرض bridge می‌باشد.

دستورالعمل driver_opts: با استفاده از آن می‌توانیم آپشن‌های مربوط به درایور را مشخص کنیم که این موارد به صورت key-value تنظیم می‌گردد.

دستورالعمل attachable: می‌توان یک کانتینر را به شبکه‌ی overlay متصل کرد.

دستورالعمل enable_ipv6: نسخه‌ی ipv6 را برای این شبکه فعال می‌کند.

دستورالعمل ipam: برای اینکه بتوان درایور ipam را تغییر داد از آن استفاده می‌شود. به عنوان مثال می‌توان subnet و .. را تغییر داد و آنها را کانفیگ کرد.

دستورالعمل internal: به صورت پیش‌فرض تنظیم شده است. به معنای اینکه شبکه داخل کامپوزفایل ایجاد می شود و داخل آن استفاده می‌شود.

دستورالعمل external: به معنای آن می‌باشد که این شبکه بیرون از کامپوز فایل تعریف شده است و می‌بایست قبل از اجرای کامپوز فایل آن را ایجاد نمایید.

دستورالعمل labels: با استفاده از آن می‌توان metadata مربوط به شبکه را کامل‌تر کرد.

دستورالعمل name: برای شبکه‌ای که ساخته می‌شود اسم انتخاب می‌کند.

نحوه‌ی استفاده از متغیرها در خود کانفیگ فایل:

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

$VARIABLE
${VARIABLE}

تمام این متغیرها و مقادیر آنها در یک env. فایل باید باشد تا در کامپوز فایل مورد استفاده قرار گیرد.

برخی از موارد دیگه همانند configs و secrets باقیمانده است که آنها را در زمانی که می‌خواهیم از swarm استفاده کنیم توضیح خواهیم داد.

مراقب خودتون باشید. 🌹🐳🌹

خوبه که داکرمی رو تو جاهای مختلف فالو کنید. پذیرای نظرات شما هستیم.

🫀 Follow DockerMe 🫀

🔔 Follow YouTube 🔔

📣 Follow Instagram 📣

🖇 Follow LinkedIn DockerMe🖇

🔎 Follow Linkedin Ahmad Rafiee 🔎

🕊 Follow Twitter 🕊