مقاله 07 / Docker
Docker Compose در محیط عملیاتی؛ چک‌لیست استقرار قابل نگهداری
مشخصات پیشنهادی انتشار
- عنوان سئو
- Docker Compose در محیط عملیاتی؛ چک‌لیست | نگهبان وب
- توضیح متا
- پیش از استقرار Docker Compose در production، شبکه، داده ماندگار، healthcheck، منابع و لاگ را بررسی کنید؛ چک‌لیست تحویل و بازیابی را بخوانید.
- مسیر پیشنهادی
- /blog/docker-compose-production
- عبارت اصلی
- Docker Compose در محیط عملیاتی
- تصویر
- docker-compose-production.webp
- یادداشت انتشار
- تصویر را در CMS بارگذاری و تاریخ واقعی انتشار و URL تصویر را ثبت کنید.
Docker Compose برای تعریف چند سرویس مرتبط، شبکه‌ها و فضای ذخیره‌سازی آن‌ها کاربرد دارد. استفاده از آن در محیط عملیاتی ممکن است برای پروژه‌ای با اندازه و نیاز مناسب انتخاب معقولی باشد. اما انتقال مستقیم فایل توسعه به production، بدون بازبینی دسترسی و داده، می‌تواند اختلال یا افشای ناخواسته ایجاد کند.
پرسش اصلی این نیست که فایل Compose اجرا می‌شود یا نه. باید بدانید داده کجا می‌ماند، سرویس چه زمانی آماده است، منابع چگونه محدود می‌شوند و اگر میزبان از دست رفت چگونه بازمی‌گردید. این راهنما برای روشن کردن همین تصمیم‌هاست.
در محیط توسعه معمولاً کد از میزبان mount می‌شود، حالت debug فعال است و پورت‌های بیشتری منتشر می‌شوند. این تنظیمات را برای production جدا بررسی کنید. برنامه باید با تنظیمات مشخص و بدون وابستگی اتفاقی به پوشه‌های لپ‌تاپ توسعه‌دهنده اجرا شود.
برای imageها نسخه قابل ردیابی انتخاب کنید. استفاده بی‌برنامه از latest باعث می‌شود اجرای مجدد، نسخه‌ای متفاوت از انتظار بیاورد. شناسه image منتشرشده و commit مرتبط را در گزارش انتشار بنویسید و نسخه قبلی لازم برای بازگشت را نگه دارید.
شبکه داخلی با انتشار پورت فرق دارد
سرویس‌های داخل شبکه مشترک می‌توانند بدون انتشار عمومی همه پورت‌ها با هم ارتباط داشته باشند. دیتابیس یا کش معمولاً نباید صرفاً برای اتصال برنامه به آن‌ها در اینترنت باز شوند. هر ports را با این سؤال بررسی کنید: «کدام مصرف‌کننده بیرونی به آن نیاز دارد؟»
اگر Nginx هم داخل کانتینر باشد، localhost مقصد برنامه دیگر نیست؛ به خود همان کانتینر اشاره دارد. نام سرویس و پورت داخلی در شبکه مشترک اهمیت دارند. محدودیت دسترسی شبکه را از بیرون و داخل، متناسب با معماری آزمایش کنید.
داده ماندگار را از کانتینر جدا کنید
داده مهم نباید فقط داخل لایه نوشتنی کانتینر بماند. volume یا محل ذخیره مناسب تعریف کنید و مالکیت، مجوز، ظرفیت و روش بکاپ آن را بنویسید. ماندگاری volume به‌خودی‌خود حفاظت در برابر خرابی میزبان یا حذف اشتباه ایجاد نمی‌کند.
برای دیتابیس، روش پشتیبان‌گیری سازگار با همان موتور را انتخاب کنید. کپی تصادفی فایل‌های یک دیتابیس در حال کار لزوماً نسخه قابل بازیابی تولید نمی‌کند. پیش از هر دستور حذف یا پاک‌سازی، دقیقاً مشخص کنید چه volume و داده‌ای تحت تأثیر است.
healthcheck چه چیزی را می‌سنجد؟
آزمون سلامت باید معنای روشنی داشته باشد و با ابزار موجود داخل image اجرا شود. پاسخ یک endpoint ساده می‌تواند برای زنده بودن کافی باشد، ولی لزوماً آماده بودن برای کار اصلی را ثابت نمی‌کند. آزمون بسیار سنگین هم ممکن است خودش بار نامناسب تولید کند.
وضعیت unhealthy به‌تنهایی در Docker Compose معمولی، الزاماً سبب restart خودکار کانتینر نمی‌شود. سیاست restart نیز جای طراحی تشخیص و واکنش را نمی‌گیرد. اگر سرویس برای کار به دیتابیس وابسته است، رفتار retry و خطای قابل فهم را در خود برنامه هم طراحی کنید.
منابع و لاگ‌ها را محدود و قابل مشاهده نگه دارید
مصرف حافظه و CPU سرویس‌ها را اندازه بگیرید و محدودیت متناسب تعیین کنید. محدودیت بیش از حد می‌تواند برنامه را وارد چرخه شکست کند؛ نبود محدودیت هم ممکن است کل میزبان را درگیر کند. تنظیمات اعمال‌شده را در محیط واقعی بررسی کنید.
برای لاگ‌ها دوره نگهداری و چرخش تعریف کنید. خروجی بی‌وقفه یک سرویس خطادار می‌تواند دیسک را پر کند. اطلاعات حساس را در لاگ ننویسید و برای بررسی رخداد، زمان و شناسه درخواست مناسب نگه دارید. مانیتورینگ باید حجم لاگ و فضای میزبان را هم ببیند.
secrets و دسترسی فرایند را بررسی کنید
فایل محیطی را وارد مخزن نکنید و مجوز آن را محدود کنید. قابلیت secrets در Compose به‌تنهایی معادل یک سامانه کامل مدیریت راز نیست؛ منبع راز و دسترسی به آن همچنان اهمیت دارد. اگر برنامه امکان اجرا با کاربر غیر root دارد، این حالت را با مجوز فایل‌های لازم آزمایش کنید.
از دسترسی privileged و mount کردن socket داکر برای سرویس‌های غیرضروری پرهیز کنید. چنین دسترسی‌هایی می‌توانند مرز کنترل را بسیار گسترده کنند. هر استثنا باید کاربرد مشخص و محدودیت قابل توضیح داشته باشد.
چک‌لیست تحویل production
| موضوع | شواهد لازم برای تحویل |
|---|---|
| نسخه | image مشخص و ارتباط آن با commit |
| داده | محل ذخیره، بکاپ و آزمون restore |
| شبکه | پورت‌های لازم و نتیجه بررسی دسترسی |
| سلامت | معنای healthcheck و روش واکنش |
| عملیات | روش انتشار، لاگ، پایش و بازگشت |
Compose روی یک میزبان، دسترس‌پذیری بالای چندمیزبانه ایجاد نمی‌کند. اگر از دست رفتن یک ماشین قابل تحمل نیست، معماری باید جدا بازبینی شود. بزرگ‌تر کردن ابزار قبل از روشن شدن نیاز، فقط نگهداری را پیچیده‌تر می‌کند.
پرسش‌های رایج
آیا Docker Compose فقط برای توسعه است؟
خیر. مستندات Docker کاربرد production را پوشش می‌دهد؛ تناسب آن با نیاز دسترس‌پذیری و عملیات پروژه باید بررسی شود.
آیا restart policy جای بکاپ را می‌گیرد؟
خیر. restart مربوط به اجرای فرایند است؛ حفاظت و بازیابی داده مسئله دیگری است.
برای تبدیل استقرار فعلی به یک مسیر مستند، درخواست Docker و کانتینرسازی ثبت کنید.
