Docker Compose فقط ابزار توسعه نیست؛ می‌تواند چند سرویس production را روی یک host تعریف و اجرا کند. اما «اجرا شدن با docker compose up -d» به معنی آماده بودن برای production نیست. اگر همان host از دست برود، Compose به‌تنهایی سرویس را به node دیگری منتقل نمی‌کند و بدون طراحی جداگانه، Backup، rollback و rollout بی‌قطعی هم فراهم نمی‌شود.
پاسخ سریع: برای سرویس‌های تک‌سروری با نیاز دسترس‌پذیری متناسب، تیم کوچک و عملیات کنترل‌شده، Compose گزینه منطقی است؛ اگر image نسخه‌دار، health، storage پایدار، secret، backup، monitoring و روش بازیابی دارید. اگر تحمل خرابی host، scheduling چند node یا rollout پیچیده لازم است، باید معماری و ابزار دیگری را ارزیابی کنید. Kubernetes پاسخ خودکار هر پروژه نیست.
Compose دقیقاً چه کاری می‌کند؟
Compose با فایل YAML سرویس‌ها، network، volume، config و رابطه شروع را تعریف می‌کند و lifecycle آن‌ها را روی Docker Engine هماهنگ می‌سازد. ابزار مناسبی برای stack چندسرویسی است؛ جایگزین پلتفرم کامل orchestration چند host، سامانه backup یا سامانه alert نیست. فایل Compose «منبع تعریف» است، اما وضعیت داده و image منتشرشده نیز بخشی از release واقعی هستند.
چه سناریویی برای Compose مناسب است؟
یک برنامه و worker و proxy روی VPS یا سرور اختصاصی، با رشد قابل‌پیش‌بینی و RTO/RPO مشخص، می‌تواند با Compose به‌خوبی اداره شود. شرط مهم این است که تیم بتواند خرابی host، خطای image، پرشدن disk و شکست دیتابیس را تشخیص و بازیابی کند. انتخاب ساده‌تر زمانی خوب است که محدودیت‌هایش شناخته و پذیرفته شده باشد.
چه زمانی کافی نیست؟
اگر قرارداد خدمت اجازه از دست رفتن یک host را نمی‌دهد، replicaها باید روی hostهای مستقل و پشت load balancer مناسب باشند. Compose روی یک host چنین تضمینی نمی‌دهد. همچنین deployment تدریجی چند replica، rescheduling خودکار، service discovery چند node و autoscaling گسترده از مسئولیت‌های معمول Compose نیستند. حتی با orchestrator بزرگ‌تر نیز داده stateful و failover باید طراحی شود.
Image را در سرور production نسازید مگر ضرورت روشن باشد
در pipeline بهتر است image با dependency قفل‌شده ساخته، تست، scan و در registry منتشر شود؛ staging و production همان digest را اجرا کنند. این کار مشخص می‌کند کدام artifact deploy شده است. اگر در هر host جدا build می‌کنید، تفاوت زمان دانلود dependency و context می‌تواند خروجی را تغییر دهد. راهنمای Dockerfile production برای طراحی artifact کمک می‌کند.
فایل تولیدی و فایل توسعه
تنظیمات hot reload، bind mount کل source، debug port و رمز آزمایشی نباید بی‌توجه وارد production شوند. می‌توانید فایل پایه مشترک و override تولیدی داشته باشید، اما خروجی نهایی config را پیش از اجرا بازبینی کنید. اجرای docker compose config ساختار ادغام‌شده را نشان می‌دهد؛ مراقب باشید خروجی آن ممکن است مقدار متغیرهای حساس را آشکار کند و نباید در log عمومی ذخیره شود.
State و Volume
داده دیتابیس، upload و فایل موردنیاز برنامه را در volume یا storage مناسب نگه دارید. volume معادل backup نیست؛ باید نسخه پشتیبان سازگار با سرویس، نسخه خارج از همان host و Restore Test داشته باشید. قبل از تغییر image یا schema، سازگاری migration و امکان rollback را روشن کنید. دستورهای حذف volume یا prune عمومی بدون تشخیص target می‌توانند داده را از دسترس خارج کنند؛ در runbook تولیدی جای اقدام عجولانه ندارند.
Secret و دسترسی
رمز دیتابیس و کلید API را در repository یا image قرار ندهید. متغیر محیطی ساده ممکن است از طریق inspect، فرایند یا log دسترس‌پذیر باشد؛ فایل secret با مجوز محدود یا secret manager متناسب، چرخش و کنترل دسترسی را طراحی کنید. کاربر service، دسترسی Docker daemon، mount host و network داخلی را حداقلی کنید. عضویت در گروه docker معمولاً دسترسی بسیار قدرتمند به host می‌دهد و نباید به همه اپراتورها داده شود.
Network و Port
فقط reverse proxy یا سرویس واقعاً عمومی را روی host publish کنید. دیتابیس و cache معمولاً در network داخلی قابل‌دسترس‌اند. تفاوت expose و ports را در config بررسی کنید؛ انتشار ناخواسته پورت می‌تواند سرویس داخلی را در اینترنت نمایان کند. TLS، hostname و headerهای proxy را جداگانه آزمون کنید. localhost داخل container همان host یا container دیگر نیست.
Healthcheck، dependency و ترتیب شروع
ترتیب start شدن سرویس‌ها، آمادگی آن‌ها را ثابت نمی‌کند. healthcheck باید readiness مناسب را بسنجد و برنامه در برابر دیر آماده‌شدن دیتابیس retry کنترل‌شده داشته باشد. شرط سلامت در dependency می‌تواند startup را بهتر مدیریت کند، ولی اگر سرویس پس از شروع خراب شود، جای monitoring و recovery را نمی‌گیرد. restart policy را با log و alert تکمیل کنید تا crash loop پنهان نشود.
Deployment و زمان قطعی
هنگام به‌روزرسانی یک سرویس، Compose ممکن است container قبلی را متوقف و نمونه جدید را ایجاد کند؛ این به‌خودی‌خود zero downtime نیست. برای تحمل‌نکردن قطعی، مسیر blue/green یا دو stack جدا با proxy و health gate طراحی کنید. دیتابیس و migration باید با نسخه قدیم و جدید در دوره گذار سازگار باشند. صرف داشتن دو replica روی یک host نیز خرابی همان host را پوشش نمی‌دهد.
Rollback واقعی
بازگشت به digest قبلی فقط بخش کد را برمی‌گرداند. اگر migration schema تخریبی، داده جدید ناسازگار یا تغییر config رخ داده باشد، rollback ساده ممکن است شکست بخورد. پیش از release، مسیر برگشت app، config و data را بنویسید و در staging تمرین کنید. backup تازه پیش از migration لازم است، اما restore دیتابیس ممکن است داده تراکنش‌های پس از release را از دست بدهد؛ RPO را با کسب‌وکار هماهنگ کنید.
Log، metric و ظرفیت host
خروجی log بدون rotation، imageهای قدیمی، volume و backup می‌توانند disk را پر کنند. CPU، memory pressure، OOM، inode، I/O، restart count و latency سرویس را کنار تجربه کاربر ببینید. راهنمای مانیتورینگ سرور نشان می‌دهد چرا running بودن container برای سالم بودن خرید یا ورود کافی نیست. ظرفیت host را با رشد داده و ترافیک واقعی بسنجید.
امنیت و نگهداری Engine
Docker Engine و base image باید patch شوند؛ patch image به container در حال اجرا خودکار منتقل نمی‌شود. image تازه را بسازید و با تست deploy کنید. دسترسی SSH و Docker socket را محدود، eventهای امنیتی را log و credentialها را دوره‌ای بازبینی کنید. اسکن image کمک می‌کند، ولی جای hardening host و برنامه را نمی‌گیرد.
اگر مدیر سرور و توسعه‌دهنده افراد متفاوت‌اند، مسئولیت patch Engine، ساخت image، تغییر Compose و بازگردانی داده را صریح تقسیم کنید. ابهام مالکیت معمولاً در زمان incident خودش را نشان می‌دهد.
چک‌لیست قبل از اولین استقرار
- RTO و RPO و تحمل خرابی host را مشخص کنید.
- image آزمایش‌شده و digest ثبت‌شده داشته باشید.
- پورت‌ها و network داخلی را بازبینی کنید.
- secret و مجوز volume را آزمون کنید.
- healthcheck و restart همراه alert تعریف کنید.
- backup، نسخه خارج host و restore test انجام دهید.
- migration و rollback را در staging تمرین کنید.
- مسیر deploy، owner و runbook incident را ثبت کنید.
اشتباه‌های رایج در تصمیم
- رد کردن Compose فقط چون «مخصوص توسعه» تصور می‌شود
- انتخاب آن برای نیاز قطعی high availability چند host
- تصور اینکه
up -dیعنی سلامت برنامه - ساخت image با tag شناور روی سرور زنده
- نبود backup مستقل برای volume
- استفاده از
down -vدر runbook عادی - انتشار تصادفی دیتابیس و cache روی host
چه زمانی معماری را ارتقا دهیم؟
اگر ترافیک و SLO به چند host، rollout تدریجی و failover نیاز پیدا کرده، نخست failure mode و ظرفیت تیم را ثبت کنید؛ بعد میان orchestrator، سرویس مدیریت‌شده یا معماری ساده‌تر مقایسه کنید. راهنمای انتخاب Docker کمک می‌کند ابزار را با نیاز واقعی بسنجید. برای طراحی و آزمون استقرار تک‌سروری یا مسیر رشد، سرویس داکرایز اپلیکیشن می‌تواند قرارداد deploy، داده و بازیابی را یکپارچه کند.
پرسش‌های متداول
آیا Compose به‌تنهایی high availability می‌دهد؟
خیر؛ در مدل تکhost، خرابی همان host همه سرویس‌ها را متأثر می‌کند. چند host و داده failover معماری جدا می‌خواهد.
آیا برای production حتماً Kubernetes لازم است؟
خیر؛ نیاز عملیاتی، SLO و توان تیم معیار هستند. پیچیدگی بیشتر همیشه ارزش بیشتر نیست.
آیا volume بعد از recreate باقی می‌ماند؟
volume مستقل معمولاً از container جداست، اما lifecycle دقیق به تعریف و فرمان‌های اجرا بستگی دارد؛ backup را جایگزین این فرض نکنید.
آیا Compose zero downtime دارد؟
نه به‌صورت خودکار؛ برای آن باید چند نسخه هم‌زمان، health gate، proxy و سازگاری داده طراحی شود.