داکر برای توسعه‌دهندگان، نه فقط Ops

داکر به‌عنوان یک فناوری استقرار بازاریابی می‌شود، اما برای من بزرگ‌ترین بردش توسعه محلی است. هر توسعه‌دهنده در تیم PostgreSQL، Redis و Mailpit یکسان می‌گیرد — بدون بحث «روی سیستم من کار می‌کند»، بدون آلوده کردن لپ‌تاپتان با سرویس‌هایی که فراموششان می‌کنید.

Docker Compose برای سرویس‌های محلی

از روز اول لازم نیست کل اپتان را کانتینری کنید. با کانتینری کردن وابستگی‌ها شروع کنید:

# docker-compose.yml
services:
  postgres:
    image: postgres:16
    ports: ["5432:5432"]
    environment:
      POSTGRES_DB: myapp
      POSTGRES_USER: myapp
      POSTGRES_PASSWORD: secret
    volumes:
      - pgdata:/var/lib/postgresql/data

  redis:
    image: redis:7-alpine
    ports: ["6379:6379"]

  mailpit:
    image: axllent/mailpit
    ports: ["8025:8025", "1025:1025"]

volumes:
  pgdata:

docker compose up -d را اجرا کنید و .env لاراولتان به localhost اشاره می‌کند. Mailpit همه ایمیل‌های خروجی را با یک رابط وب روی پورت 8025 می‌گیرد — دیگر ایمیل تصادفی به کاربران واقعی حین توسعه نمی‌رود.

چرا (هنوز) خود اپ را کانتینری نکنیم؟

اجرای بومی PHP و Node روی لپ‌تاپ شما برای توسعه سریع‌تر است — hot reload، Xdebug، تغییرات آنی فایل. کانتینری کردن اپ وقتی منطقی است که محیط‌های استقرار را استاندارد می‌کنید یا توسعه‌دهندگانی را وارد می‌کنید که با راه‌اندازی محلی PHP/Node دست‌وپنجه نرم می‌کنند. با داکر فقط-سرویس شروع کنید؛ وقتی درد واقعی شد اپ را کانتینری کنید.

الگوهای مفید

• والیوم‌های نام‌دار برای پایداری پایگاه داده — docker compose down داده‌تان را پاک نمی‌کند.
• .env در compose — رازها را بیرون از فایل YAML نگه دارید.
• بررسی سلامت — قبل از اجرای مهاجرت‌ها منتظر آماده شدن پستگرس بمانید.

postgres:
  healthcheck:
    test: ["CMD-SHELL", "pg_isready -U myapp"]
    interval: 5s
    retries: 5

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

• بایند کردن پورت‌هایی که تداخل دارند. اگر از قبل پستگرس محلی دارید، پورت 5432 تداخل می‌کند. پورت میزبان را تغییر دهید.
• استفاده نکردن از والیوم. داده بدون آن‌ها هنگام ری‌استارت کانتینر ناپدید می‌شود.
• کانتینری کردن زودهنگام همه چیز. پیچیدگی بدون سود.

بهترین شیوه‌ها

• docker-compose.yml را به ریپو commit کنید — بخشی از محیط توسعه است.
• سه فرمانی را که توسعه‌دهنده‌های جدید نیاز دارند مستند کنید: docker compose up -d، مهاجرت، seed.
• ایمیج‌ها را به نسخه‌های مشخص پین کنید، نه latest.

جمع‌بندی

بهترین کاربرد داکر برای بیشتر توسعه‌دهندگان تولید نیست — یک محیط محلی یکسان است که با یک فرمان راه می‌افتد. اول سرویس‌هایتان را کانتینری کنید، اپتان را تا وقتی لازم نشده بومی نگه دارید و هرگز در compose به latest بایند نکنید. در پروژه بعدی‌تان امتحانش کنید: مستندات ورود تیمتان خیلی کوتاه‌تر می‌شود.