گپلیش

Docker Compose برای پروژه‌های کوچک: الگویی که هر بار استفاده می‌کنم

· ۷ دقیقه مطالعه

داکر

برای پروژه‌ای که روی یک سرور اجرا می‌شود، Kubernetes زیاده‌روی است. یک فایل compose.yaml با چند سرویس، همراه با nginx روی میزبان، سال‌هاست برای من جواب داده.

فایل پایه

services:
  app:
    image: registry.example.ir/myapp:1.4.2
    restart: unless-stopped
    env_file: .env
    ports:
      - "127.0.0.1:3000:3000"
    depends_on:
      db:
        condition: service_healthy

  db:
    image: postgres:17
    restart: unless-stopped
    environment:
      POSTGRES_DB: myapp
      POSTGRES_USER: myapp
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
    secrets:
      - db_password
    volumes:
      - db_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U myapp"]
      interval: 5s
      timeout: 3s
      retries: 10

volumes:
  db_data:

secrets:
  db_password:
    file: ./secrets/db_password

چرا این‌طور نوشته شده

دستورهای روزمره

docker compose up -d
docker compose ps
docker compose logs -f app
docker compose pull && docker compose up -d
docker compose exec db psql -U myapp

up -d فقط سرویس‌هایی را دوباره می‌سازد که پیکربندی یا image آن‌ها عوض شده، پس اجرای دوباره‌اش بی‌خطر است.

لاگ‌ها دیسک را پر می‌کنند

راه‌انداز پیش‌فرض لاگ داکر هیچ سقفی ندارد. در /etc/docker/daemon.json بگذارید:

{
  "log-driver": "json-file",
  "log-opts": { "max-size": "10m", "max-file": "3" }
}

بعد systemctl restart docker. این تنظیم فقط روی کانتینرهایی که از این به بعد ساخته می‌شوند اثر دارد.