Docker Compose و پروژه‌های چندسرویسی

پیش‌نیازهای این آموزش

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

آموزش مرحله‌به‌مرحله

1. در ساخت اپلیکیشن، Compose را انتخاب کنید یا پروژه دارای فایل Compose را آپلود کنید.
2. فایل را در ویرایشگر وارد کنید و بررسی پروژه را اجرا کنید.
3. سرویس‌های وب، دیتابیس، دیسک و متغیرهای تشخیص‌داده‌شده را جداگانه مرور کنید.
4. همه مقادیر اجباری را در فرم کامل کنید و هزینه مجموع منابع را ببینید.
5. پس از تأیید، وضعیت هر سرویس و ارتباط برنامه با دیتابیس را بررسی کنید.

services:
  web:
    image: nginx:alpine
    ports:
      - "8080:80"

توضیحات تکمیلی

مسیر کامل واردکردن Compose

1. در بخش روش ساخت، «روش‌های دیگر» را باز کنید.
2. Compose Editor را انتخاب و محتوای compose.yaml را Paste کنید.
3. نتیجه تحلیل سرویس‌ها، دیتابیس‌ها، دیسک‌ها، پورت‌ها و متغیرها را مرور کنید.
4. هزینه کل پروژه و اثر هر منبع را پیش از تأیید نهایی بررسی کنید.

Compose را وارد کنید

فایل compose.yaml را همراه سورس آپلود کنید یا متن Compose را مستقیماً در ویرایشگر صفحه ساخت بچسبانید. پاستا services، build، image، environment، env_file، ports، healthcheck، volumes، configs و وابستگی‌های سرویس‌ها را بررسی می‌کند.

پیش‌نمایش معماری را مرور کنید

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

دیتابیس را مدیریت‌شده کنید

PostgreSQL، MySQL، MongoDB و Redis شناسایی‌شده به‌صورت پیش‌فرض به دیتابیس مدیریت‌شده تبدیل می‌شوند. نسخه، پلن، حجم دیسک و قیمت هر نمونه پیش از پرداخت نمایش داده می‌شود. اگر به کانتینر خام نیاز دارید، تبدیل خودکار را برای همان سرویس خاموش کنید.

چند دیسک بسازید

هر named volume به یک دیسک پایدار قابل‌ویرایش تبدیل می‌شود. اندازه، کلاس ذخیره‌سازی و mount path هر دیسک را جدا تعیین کنید. bind mountهای حاوی فایل پیکربندی به ConfigMap تبدیل می‌شوند و مسیرهای داده به PVC می‌روند.

Secret و متغیرها

مقادیر env و env_file در بررسی پروژه نمایش داده می‌شوند اما Secretهای حساس را بهتر است در بخش متغیرهای محیطی وارد کنید. مقدار Secret در لاگ یا صفحه پروژه دوباره نمایش داده نمی‌شود و فقط نام کلید قابل مشاهده است.

پورت عمومی را مشخص کنید

پاستا سرویس وب اصلی را از ports و healthcheck پیشنهاد می‌دهد. فقط سرویس‌هایی که باید از اینترنت دیده شوند دامنه و Ingress می‌گیرند؛ دیتابیس‌ها و سرویس‌های داخلی فقط در شبکه خصوصی پروژه در دسترس‌اند.

اتصال امن دیتابیس در استقرار Synapse

فایل‌های تنظیمات داخل پوشهٔ متصل به سرویس، با حفظ مسیر زیرپوشه و نگهداری امن، همراه دیسک پایدار منتقل می‌شوند. در ایمیج رسمی Synapse، اتصال PostgreSQL داخل homeserver.yaml نیز به دیتابیس مدیریت‌شده منتقل می‌شود و دسترسی لازم به پوشهٔ داده فراهم می‌شود.

دیتابیس تازهٔ Synapse با encoding برابر UTF8 و مرتب‌سازی و نوع نویسهٔ C ساخته می‌شود. داده و تنظیم دیتابیس‌های موجود تغییر نمی‌کند. تلاش دوباره، استقرار سورس جدید و بازگشت نسخه، اتصال مجاز و معتبر قبلی را حفظ می‌کنند؛ تغییر رمز نیز در تنظیمات اتصال اعمال می‌شود. اتصال خارجی شما خودکار بازنویسی نمی‌شود.

آیا متغیرهای اتصال هنگام ساخت نسخهٔ جدید در دسترس‌اند؟

بررسی نسخهٔ جدید، متغیرهای فعلی پروژه و اتصال دیتابیس‌های متصل را در نظر می‌گیرد. اتصال اولیهٔ PostgreSQL و MySQL همراه پروژه، متغیرهای DB_HOST، DB_PORT، DB_NAME، DB_DATABASE، DB_USER و DB_PASSWORD را نیز فراهم می‌کند. برای الزام صریح متغیرها در پروژهٔ سورسی، requiredEnv را در paasta.json مشخص کنید. متغیرهای الزامی بدون مقدار، پیش از شروع ساخت بررسی می‌شوند. فایل نمونهٔ .env در استقرار مجدد، متغیر حذف‌شده را دوباره وارد نمی‌کند.

نتیجه را چگونه بررسی کنید؟

سرویس عمومی از آدرس پروژه پاسخ می‌دهد و وابستگی‌های داخلی آن در دسترس‌اند؛ ساخت موفق یک سرویس به‌تنهایی کافی نیست.

اگر به مشکل خوردید

• از مسیر فایل‌های نسبی و وجود پوشه‌های build داخل منبع مطمئن شوید.
• رمزها را داخل Compose ننویسید؛ نام متغیر را ارجاع دهید و مقدار را در فرم امن ثبت کنید.

آموزش‌های مرتبط

• تنظیمات اجرا
• دیتابیس‌ها
• فضای ذخیره‌سازی
• رفع خطا

SQL Server و اتصال دات‌نت

ایمیج رسمی SQL Server در Compose به‌صورت سرویس مستقل اجرا می‌شود و به MySQL تبدیل نمی‌شود. خود SQL Server حداقل ۲ گیگابایت حافظه لازم دارد؛ حافظهٔ سایر سرویس‌ها نیز باید در پلن جا شود. پاستا این حداقل را بررسی می‌کند و حافظهٔ لازم را در محدودهٔ منابع همان پلن اختصاص می‌دهد. ارتقای پلن هزینه را تغییر می‌دهد.

در متغیرهای ConnectionStrings__DefaultConnection، نام سرویس در بخش Server یا Data Source به آدرس داخلی تبدیل می‌شود؛ اطلاعات ورود حفظ می‌شوند. پس از تغییر تنظیمات، استقرار مجدد لازم است.

تعیین سهم RAM و CPU هر سرویس

در هر سرویس از cpus و mem_limit یا deploy.resources.limits.cpus و deploy.resources.limits.memory استفاده کنید. CPU برحسب هسته است؛ 0.5 یعنی نیم هسته. حافظه را مانند 512M یا 1G وارد کنید؛ مقدار به مگابایت کامل رو به بالا گرد می‌شود و حداقل آن ۸ مگابایت است. اگر هر دو شکل تنظیم را بنویسید، مقدارها باید یکسان باشند. تنظیمات deploy.resources.reservations در تخصیص منابع پاستا اعمال نمی‌شوند.

services:
  web:
    image: nginx:alpine
    ports: ["8080:80"]
    cpus: "0.5"
    mem_limit: 512M
  worker:
    image: alpine:3.22
    command: ["sleep", "infinity"]
    deploy:
      resources:
        limits:
          cpus: "1.5"
          memory: 1536M

این مثال مجموعاً ۲ هسته CPU و ۲۰۴۸ مگابایت RAM نیاز دارد. مجموع سهم سرویس‌های برنامه باید در سقف پلن جا شود. هرکدام از CPU یا RAM که مشخص نشده باشد، از باقی منابع به‌صورت خودکار سهم می‌گیرد؛ سرویس اصلی دو سهم و هر سرویس دیگر یک سهم دارد. برای هر سرویس بدون مقدار، حداقل یک هزارم هسته و ۸ مگابایت RAM لازم است. اگر همه مقدارها مشخص باشند، باقی منابع تخصیص داده نمی‌شود. پروژه‌های بدون این تنظیمات همان تقسیم خودکار قبلی را دارند. پلن کوچک‌تر ناسازگار با نسخه فعال یا در حال استقرار پیش از پرداخت رد می‌شود. منابع دیتابیس مدیریت‌شده با پلن جدا تعیین می‌شوند و ظرفیت و هزینه هر نمونه پروژه نیز طبق پلن محاسبه می‌شود.

مراحل یک‌بارهٔ Compose

سرویس بدون پورت و بدون وابستگی با restart: "no" در هر استقرار یک‌بار اجرا می‌شود. سرویس‌های برنامه پس از پایان موفق آن شروع می‌شوند و پایان موفق، خرابی برنامه حساب نمی‌شود. هر مرحله حداکثر ۱۵ دقیقه فرصت دارد. شکست آن همراه گزارش در تاریخچهٔ استقرار ثبت می‌شود و فرمان خودکار تکرار نمی‌شود. دیسک‌های تعریف‌شدهٔ همان پروژه در دسترس این مرحله هستند.