Docker Compose چیست؟ اجرای چند Container با یک فایل

بیشتر اپ‌های واقعی یک فرایند تنها نیستند: frontend، API، پایگاه‌داده، و گاهی صف یا cache. با `docker run` تک‌تک می‌توانید همه را بالا بیاورید، اما تکرار فلگ‌ها، شبکه و Volume سریع شکننده می‌شود. Docker Compose این مدل را در یک فایل YAML به‌نام Compose file جمع می‌کند تا با یک فرمان مجموعهٔ سرویس‌ها ساخته و اجرا شوند.

طبق مستندات Docker، فایل Compose از Compose Specification پیروی می‌کند. شما سرویس‌ها را تعریف می‌کنید؛ CLI با `docker compose up` آن‌ها را ایجاد و شروع می‌کند. Compose جایگزین Kubernetes نیست؛ لایهٔ ساده برای تعریف و اجرای اپ چندکانتینری است — عالی برای توسعه محلی و بسیاری استقرارهای تک‌میزبان.

این مقاله مدل مفهومی (service، network، volume، config، secret، project) را می‌گوید تا بتوانید تصمیم بگیرید Compose کافی است یا وقت Orchestration فرا رسیده.

پاسخ کوتاه

Compose یعنی توصیف اعلانی چند Container به‌عنوان یک اپ: هر جزء یک service است که از یک Image با تنظیمات مشخص یک یا چندبار اجرا می‌شود؛ ارتباط از طریق network؛ دادهٔ پایدار در volume؛ تنظیمات غیرحساس در config و دادهٔ حساس در secret. پروژه (project) یک استقرار مشخص از همان فایل است و منابع را با نام پروژه گروه‌بندی و ایزوله می‌کند.

برای تیم کوچک: یک `compose.yaml` که API + DB را روی لپ‌تاپ و همان ساختار را روی یک VPS بالا می‌آورد، اغلب بزرگ‌ترین جهش نظم عملیاتی است — بدون پیچیدگی خوشه.

اگر برای بالا آوردن محیط توسعه به یک صفحهٔ ویکی با ده فرمان پراکنده نیاز دارید، Compose همان صفحه را به فایل نسخه‌پذیر تبدیل می‌کند.

مدل اپلیکیشن Compose

مستندات «Compose application model» اجزا را این‌گونه جدا می‌کند:

• Service: جزء محاسباتی؛ روی پلتفرم با اجرای همان Image و پیکربندی، یک یا چندبار پیاده می‌شود.
• Network: انتزاع مسیر IP بین Containerهای سرویس‌های متصل.
• Volume: دادهٔ پایدار به‌صورت mount سطح‌بالا.
• Config: دادهٔ پیکربندی وابسته به runtime؛ داخل Container شبیه فایل mountشده.
• Secret: شکل خاصی از پیکربندی برای دادهٔ حساس با ملاحظات امنیتی بیشتر.

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

فایل Compose و نام‌ها

مسیر پیش‌فرض `compose.yaml` (ترجیحی) یا `compose.yml` در پوشهٔ کاری است. نام‌های قدیمی `docker-compose.yaml` / `.yml` برای سازگاری پشتیبانی می‌شوند؛ اگر هر دو باشند، `compose.yaml` ارجح است. می‌توان چند فایل را ادغام کرد یا با `include` بخش‌هایی را از تیم/مخزن دیگر آورد.

نسخه‌پذیری فایل کنار کد یعنی محیط توسعه دیگر «روی ماشین ارشد تیم» نیست؛ هر کسی همان مدل را بالا می‌آورد.

yaml

services: frontend: image: example/webapp ports: - "443:8043" networks: [front-tier, back-tier] backend: image: example/database volumes: [db-data:/etc/data] networks: [back-tier] volumes: db-data: {} networks: front-tier: {} back-tier: {}

مثال مستندات: frontend به شبکهٔ بیرونی و داخلی وصل است؛ backend فقط به شبکهٔ داخلی و Volume پایدار. این همان جداسازی منطقی است که در صحبت معماری می‌گویید ولی با `docker run` دستی فراموش می‌شود.

CLI روزمره

• `docker compose up` — ایجاد و شروع سرویس‌ها.
• `docker compose down` — توقف و حذف منابع اجرا.
• `docker compose ps` — وضعیت سرویس‌ها.
• `docker compose logs` — مشاهدهٔ خروجی برای دیباگ.

این چهار فرمان چرخهٔ عمر محلی را پوشش می‌دهند. فلگ‌های جزئی را وقتی درد واقعی داشتید یاد بگیرید؛ اول مدل را درست کنید.

Compose در برابر Docker خام و در برابر Kubernetes

Kubernetes صریحاً می‌گوید CI را دیکته نمی‌کند و PaaS کامل نیست؛ Compose هم ادعای خوشهٔ تولیدی بزرگ ندارد. مرز را با درد بکشید: اگر یک میزبان و چند Container کافی است، Compose را تمام‌شده فرض کنید تا درد مقیاس بیاید.

Secret و Config در عمل

Specification بین config و secret فرق می‌گذارد چون دادهٔ حساس مسیر پلتفرمی متفاوتی می‌طلبد. حتی در توسعه محلی، عادت نکنید رمز را داخل Image یا در فایل commit‌شدهٔ عمومی بگذارید. از متغیر محیطی فایل‌نشده در Git، یا secretهای خارجی، استفاده کنید — همان خط قرمز مقالات Secret.

الگوی خوب برای تیم کوچک

1. یک `compose.yaml` برای توسعه با سرویس‌های ضروری.
2. Image اپ از Dockerfile همان مخزن؛ DB از Image رسمی نسخه‌قفل‌شده.
3. Volume برای دادهٔ DB؛ کد اپ یا bind mount در dev یا rebuild سریع.
4. فایل override محلی برای پورت‌ها بدون commit اسرار.
5. روی سرور تک‌میزبان: همان مدل با Imageهای digets‌قفل از Registry.

Staging و Production را با نام پروژه یا فایل‌های جدا و Secret جدا نگه دارید. Compose راحتی می‌آورد نه مجوز یکی‌کردن محیط‌ها.

اشتباه‌های رایج

• فرض اینکه Compose همان Kubernetes روی لپ‌تاپ است.
• یک فایل غول‌آسا با بیست سرویس که کسی جرئت تغییرش را ندارد.
• نگه داشتن دادهٔ Production فقط داخل Container بدون Volume پشتیبان.
• استفاده از `latest` برای همهٔ Imageها در فایل مشترک تیم.
• اجرای Compose به‌عنوان تنها لایهٔ امنیتی شبکه بدون فایروال میزبان.

جمع‌بندی برای تصمیم

Docker Compose مدل اعلانی اپ چندکانتینری است: سرویس، شبکه، Volume، config و secret در YAML، اجرا با CLI. بهترین نقطهٔ شروع بعد از فهم Image/Container برای تیم‌هایی است که چند جزء دارند و هنوز خوشه لازم ندارند.

اگر محیط محلی‌تان هنوز «نصب دستی Postgres و Redis» است، این هفته یک `compose.yaml` مینیمال بنویسید و `up` را به README اضافه کنید. همان فایل زبان مشترک onboarding می‌شود.

منابع و مراجع

• Docker Docs — How Compose works (application model) — https://docs.docker.com/compose/intro/compose-application-model/
• Docker Docs — Docker Compose overview — https://docs.docker.com/compose/
• Docker Docs — What is Docker? (mentions Compose client) — https://docs.docker.com/get-started/docker-overview/

برای واحدهای Image/Container مقالات ۱۰۵ و ۱۰۷ و برای مقایسه با Kubernetes مقالهٔ ۱۱۱ را ببینید.