Docker محیط Laravel را تکرارپذیر می‌کند، اما فایل Dockerfile به‌تنهایی استقرار پایدار نمی‌سازد. در production، سؤال‌های مهم درباره processها، secret، log، health check و روش انتشار هستند. این راهنما روی همان بخش‌هایی تمرکز دارد که معمولاً بعد از اولین deploy خودشان را نشان می‌دهند.

Image کوچک، مشخص و قابل بازتولید

نسخه PHP و extensionها را pin کنید. multi-stage build اجازه می‌دهد Composer و ابزار frontend در مرحله build بمانند و image نهایی compiler و cache اضافه نداشته باشد. dependencyها با composer install --no-dev --classmap-authoritative و lock file ثابت نصب شوند.

کد و vendor باید داخل image release باشند، نه volume متغیر production. این کار rollback را ساده می‌کند: image قبلی همان چیزی است که قبلاً اجرا شده بود.

هر container یک مسئولیت عملیاتی

PHP-FPM، Nginx، queue worker و scheduler چرخه عمر و مقیاس متفاوت دارند. اجرای همه در یک process manager می‌تواند برای محیط کوچک کار کند، اما جداسازی آن‌ها کنترل restart و منابع را بهتر می‌کند. worker سنگین نباید latency درخواست وب را بالا ببرد.

تنظیمات را هنگام اجرا تزریق کنید

secret را داخل image یا repository نگذارید. APP_KEY، رمز دیتابیس و token سرویس‌ها از secret manager یا متغیر امن runtime وارد شوند. تنظیمات غیرحساس هم باید میان staging و production مشخص باشند.

config:cache عملکرد را بهتر می‌کند، اما بعد از cache نباید در کد مستقیم env() بخوانید. همه متغیرها از فایل config عبور کنند.

storage و permission را آگاهانه مدیریت کنید

فایل پایدار کاربر روی filesystem موقت container نماند؛ object storage یا volume مدیریت‌شده لازم است. فقط مسیرهایی که واقعاً نیاز دارند writable باشند. اجرای PHP با کاربر root خطر غیرضروری ایجاد می‌کند.

Health check باید آمادگی را بسنجد

پاسخ 200 از Nginx لزوماً به معنی آمادگی Laravel نیست. endpoint سلامت می‌تواند boot برنامه و وابستگی حیاتی را با timeout کوتاه بسنجد. liveness و readiness را جدا کنید: اولی می‌گوید process گیر نکرده، دومی می‌گوید می‌تواند ترافیک بگیرد.

health check سنگین که هر چند ثانیه query پیچیده اجرا کند خودش بار می‌سازد. کمترین بررسی لازم را انتخاب کنید.

Migration سازگار و انتشار بدون توقف

در rollout مدتی نسخه قدیم و جدید هم‌زمان اجرا می‌شوند. حذف ستون یا تغییر معنای آن در یک migration می‌تواند نسخه قدیم را بشکند. الگوی امن سه مرحله دارد: ستون یا ساختار جدید را اضافه کنید، داده و کد را مهاجرت دهید، سپس در release بعدی بخش قدیمی را حذف کنید.

پس از انتشار، queue worker باید graceful restart شود تا کد تازه را بگیرد. OPcache و cacheهای Laravel نیز باید در ترتیب درست آماده شوند.

Log به stdout، متریک بیرون container

container ممکن است هر لحظه جایگزین شود. log را روی disk محلی انباشته نکنید؛ stdout/stderr را جمع‌آوری و مرکزی کنید. request ID، release version و نام سرویس debugging را سریع‌تر می‌کنند. metric منابع، خطا، latency و صف باید بیرون از عمر container ذخیره شود.

Rollback را قبل از نیاز تمرین کنید

برگشت image ساده است؛ برگشت دیتابیس همیشه ساده نیست. release باید artifact مشخص، migration سازگار و runbook داشته باشد. backup بدون restore test اطمینان کاذب می‌دهد.

اگر معماری استقرار و برنامه رشد محصول را هم‌زمان طراحی می‌کنید، راهنمای معماری مقیاس‌پذیر Laravel و صفحه توسعه و استقرار Laravel ادامه مناسب این بحث‌اند.

پرسش‌های متداول

آیا Docker برای هر پروژه Laravel لازم است؟

نه. برای تیم، چند محیط و استقرار تکرارپذیر ارزش زیادی دارد؛ پروژه کوچک روی یک سرور ممکن است با راه ساده‌تر بهتر اداره شود.

Queue worker در همان container وب اجرا شود؟

بهتر است پردازش وب، worker و scheduler فرایندهای جدا باشند تا مقیاس و restart مستقل داشته باشند.