Docker Compose برای پروژه کوچک؛ کی کافیه و کی نه؟

اگه یه سرور داری، تیمت کوچیکه و سرویس هات چند دقیقه توقف موقع انتشار نسخه جدید رو تحمل می کنن، Docker Compose معمولاً کافیه و لازم نیست سراغ ابزارهای سنگین تر بری. اما اگه کارت به بیش از یه سرور، انتشار بدون قطع یا جابه جایی خودکار سرویس ها موقع خرابی رسید، وقتشه به Docker Swarm یا یه Kubernetes سبک مثل K3s فکر کنی. این نوشته یه چک لیست تصمیمه، نه سخنرانی طرفدارانه از یه ابزار. نشانه ها رو یکی یکی می گیم و هر جا Compose کافی باشه، صریح می گیم کافیه.

Docker Compose کجا کافیه؟ سه تیپ کسب و کار

بیشتر پروژه های کوچیکی که می بینیم یه VPS دارن و چند سرویس که کنار هم کار می کنن: وب سرور، برنامه، دیتابیس و شاید یه Redis. Compose برای همین مجموعه ساخته شده. همه چیز توی یه فایل نوشته می شه و با یه دستور بالا میاد. حالا ببینیم کی این ابزار برات کافیه.

تیپ اول: سایت یا فروشگاه روی یه VPS

وردپرس یا Laravel، دیتابیس و Redis روی یه سرور مجازی. ترافیک تقریباً قابل پیش بینیه و یه نفر سرور رو نگه می داره. بزرگ ترین ریسکت اینجا معمولاً یه اشتباه موقع آپدیته، نه از کار افتادن یه زیرساخت پیچیده. سادگی اینجا ارزش داره.

اگه هنوز دیتابیس رو انتخاب نکردی، قبل از نوشتن فایل Compose بخون PostgreSQL یا MySQL برای سایت و اپلیکیشن؛ کدام را انتخاب کنیم؟. عوض کردن دیتابیس وسط راه، معمولاً از بیشتر تنظیم های دیگه گرون تر تموم می شه.

تیپ دوم: استیج و ابزارهای داخلی

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

تیپ سوم: محصولی که هنوز داری امتحانش می کنی

یه API یا اپلیکیشن کوچیک که هنوز معلوم نیست بازار بهش جواب می ده یا نه. سرعت راه اندازی از تحمل خطای کامل مهم تره. چند هفته وقت گذاشتن برای زیرساخت چند سروره، قبل از اینکه اولین کاربر پولی رو داشته باشی، معمولاً سرمایه گذاری اشتباهیه.

شرط مشترک هر سه تیپ

یه شرط توی هر سه حالت هست: کل پشته با یه فایل و یه دستور بالا بیاد، و اگه سرور از بین رفت، بشه با همون فایل و آخرین بک آپ یه سرور تازه ساخت. اگه این شرط رو نداری، مشکل از Compose نیست، از بی نظمیه.

docker compose up -d

مثل آشپزخونه یه رستوران

Compose مثل کارت دستور پخت یه رستورانه که یه آشپزخونه بیشتر نداره. هر بار همون غذا رو با همون مواد درست می کنه، ولی اگه گاز آشپزخونه قطع بشه، کل رستوران تعطیله. Kubernetes بیشتر شبیه زنجیره ای از شعبه هاست: یکی بیفته، بقیه سفارش رو می گیرن. اما زنجیره هزینه مدیریت داره و هر رستوران محلی بهش نیاز نداره. سؤال درست اینه که تعطیلی یه شب برات چقدر خرج داره، نه اینکه زنجیره ای بودن بهتره یا نه.

سقف واقعی Compose روی یه سرور

Compose بد نیست. فقط یه سقف داره و بهتره قبل از رسیدن بهش بشناسیش.

نقطه شکست واحد

اگه سرور، دیسک یا دیتاسنتر مشکل پیدا کنه، همه چیز با هم از دسترس خارج می شه. تنظیم restart: unless-stopped فقط کانتینری رو که مرده، روی همون ماشین دوباره بالا میاره. سرویس رو روی ماشین دیگه ای بالا نمی بره. این دو تا رو با هم قاطی نکن، چون خیلی ها فکر می کنن restart policy یعنی «تحمل خرابی».

اگه سرور ساعت اوج فروش بیفته، Compose کاری برات نمی کنه. فقط فایلش کمکت می کنه سریع تر یه سرور جدید بسازی.

انتشار نسخه جدید و توقف کوتاه

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

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

مقیاس پذیری محدود به یه ماشین

دستور --scale تعداد نمونه های یه سرویس رو بالا می بره، ولی فقط تا ظرفیت CPU و رم همون یه سرور. جلوش هم باید پروکسی بذاری، چون دو نمونه نمی تونن یه پورت میزبان رو با هم باز کنن. پس مقیاس پذیری اینجا یعنی «بهتر استفاده کردن از یه ماشین»، نه «اضافه کردن ماشین».

سلامت سرویس بدون ناظر

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

services:
  app:
    image: myapp:1.4.2
    restart: unless-stopped
    ports:
      - "127.0.0.1:8080:8080"
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
      interval: 30s
      timeout: 5s
      retries: 3

توی این نمونه پورت فقط روی 127.0.0.1 باز می شه تا پروکسی معکوس روی همون سرور بهش برسه و از بیرون مستقیم دیده نشه. برای مانیتورینگ و اطلاع رسانی هم یه ابزار جدا لازم داری، فایل Compose این کار رو نمی کنه.

سرور ایران چیزهایی داره که توی آموزش ها نیست

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

دریافت ایمیج. روی سرورهای داخل ایران، دریافت ایمیج از Docker Hub و بعضی بسته ها به خاطر محدودیت روی IP های ایران ممکنه جواب نده. یه راه رایج اینه که ایمیج ها رو روی سیستم توسعه بسازی و با SSH به سرور منتقل کنی:

docker save myapp:1.4.2 | gzip | ssh user@server "gunzip | docker load"

اگه این کار رو هر بار دستی انجام بدی، زود خسته می شی و یه روز یادت می ره. استقرار خودکار سایت با CI/CD؛ از push تا سرور بدون دست کاری نشون می ده چطور این مسیر رو خودکار کنی.

فایروال. Docker معمولاً قوانین فایروال ufw رو دور می زنه. یعنی پورتی که توی Compose باز کردی، ممکنه با وجود قانون ufw از بیرون در دسترس باشه. اگه مثلاً می خوای فقط CDN به سرور برسه، قانون ها رو هم توی ufw بذار و هم توی زنجیره DOCKER-USER. اگه فقط به ufw اکتفا کنی، فکر می کنی پورت ها بسته ست، ولی نیست.

هیچ کدوم از این دو مورد به خود Compose مربوط نیستن، به شرایط ایران و رفتار Docker مربوطن. ولی تصمیم «Compose کافیه» رو عوض می کنن: اگه کسی رو نداری که این جزئیات رو نگه داره، حتی ساده ترین راه هم ریسک داره.

نشانه هایی که یعنی Compose دیگه جواب نمی ده

این ها نشانه های واقعین. اگه دو سه تاشون رو داری، جدی بگیر.

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

نشانه های دروغین

چند چیز هست که خیلی ها فکر می کنن دلیله، ولی نیست. «تعداد کانتینرها زیاد شده» به تنهایی دلیل نیست، ده تا کانتینر روی یه سرور قوی کاملاً مشکلی نداره. «همه Kubernetes دارن» هم دلیل نیست. این ها رو با ترس از عقب موندن قاطی نکن. معیار، هزینه قطعی و ریسک خطای دستیه.

کدوم گزینه برای کی؟

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

یه نکته درباره دیتابیس: توی Swarm یا K3s، دیتابیس رو یا باید به یه نود ثابت بچسبونی یا ذخیره سازی مشترک درست کنی. اگه این بخش رو سرسری بگیری، مهاجرتی که برای بالا بردن پایداری انجام دادی، خودش ریسک تازه ای می شه. خیلی ها اول وب سرور و برنامه رو منتقل می کنن و دیتابیس رو روی یه سرور جدا نگه می دارن. این هم راه معقولیه.

اگه مطمئن نیستی کدوم ردیف مال توئه، قبل از هر مهاجرتی یه مشاوره و معماری می تونه یه ساعت وقت رو از ماه ها کار اشتباه نجات بده.

قبل از مهاجرت، با Compose چقدر می شه جلو رفت؟

خیلی وقت ها قبل از رفتن سراغ ابزار سنگین، می شه ریسک رو با چند کار ساده کم کرد:

1. فایل Compose رو توی گیت نگه دار و تنظیمات حساس رو جدا بذار تا بازسازی سرور فقط یه کلون و یه دستور باشه.
2. داده دیتابیس رو روی volume بذار و بک آپ بگیر. مهم تر از بک آپ گرفتن، یه بار واقعاً بازیابی کردنشه. بک آپی که تست نشده، فقط یه امیده.
3. یه سرور دوم کم هزینه آماده نگه دار که اگه اولی از دست رفت، با همون فایل و بک آپ بالا بیاد. بازیابی دستیه، ولی ساعت ها کوتاه تر از ساختن از صفره.
4. مانیتورینگ و اطلاع رسانی بذار که قبل از مشتری، خودت بفهمی سرویس افتاده.
5. انتشار رو خودکار کن تا اشتباه دستی از معادله بیرون بره.

اگه این پنج تا رو داری و هنوز قطعی برات گرونه، دلیل واقعی داری برای رفتن سراغ گزینه بعدی. اگه نداری، معمولاً مشکل جای دیگه ست و مهاجرت فقط پیچیدگی اضافه می کنه.

سوالات متداول

آیا Docker Compose برای محیط production مناسبه؟

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

فرق Compose با Swarm و K3s چیه؟

Compose سرویس ها رو روی یه ماشین مدیریت می کنه. Swarm و K3s می تونن چند ماشین رو یکی کنن، سرویس ها رو بینشون جابه جا کنن و انتشار تدریجی بدن. در عوض، یادگیری و نگهداری شون سنگین تره و K3s بیشتر از Swarm تجربه می خواد.

با Compose می شه انتشار بدون قطع داشت؟

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

روی سرور ایران، ایمیج ها رو چطور بگیرم؟

اگه دریافت از Docker Hub ممکن نبود، ایمیج رو روی سیستم توسعه بساز و با SSH به سرور منتقل کن، مثل همون docker save و docker load که بالا اومد. بعد از اینکه این مسیر جا افتاد، بهتره توی یه فرایند خودکار قرارش بدی.

سه تا سوال برای تصمیم آخر

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

اگه جواب این سه تا «ضرر کم، مشکلی نداره، کسی نیست» بود، Compose رو نگه دار و بک آپ هات رو محکم کن. اگه جواب ها برعکس بود، وقتشه دنبال راهکار سنگین تر بگردی، ولی با یه برنامه مشخص و نه از روی عجله. اگه خواستی این مسیر رو با یه تیم باتجربه جلو ببری، می تونی روی DevOps ما حساب کنی.