ИИ для Docker

🐳 Контейнеризация Laravel — пошаговый план:

Архитектура (5 контейнеров):
1. app — PHP-FPM + Laravel
2. nginx — веб-сервер
3. mysql — база данных
4. redis — кэш + сессии + очереди
5. worker — Laravel Queue worker

+ cron внутри app-контейнера (через supervisor или entrypoint)

План на 2 дня:

День 1:
• Dockerfile для PHP-FPM + расширения (pdo_mysql, redis, gd, zip)
• docker-compose с MySQL, Redis, nginx
• Миграция .env → docker-compose environment
• Тест: docker compose up → сайт работает

День 2:
• Cron + Queue worker
• Volumes для storage/ и базы
• Production-конфиг (opcache, без xdebug)
• Деплой-скрипт

Пришлите composer.json — посмотрю какие PHP-расширения нужны для Dockerfile.

📂 Storage в Docker — правильный подход:

Проблема: storage:link создаёт симлинк public/storage → storage/app/public. В Docker:
• Симлинк внутри образа — работает, но volume перезаписывает
• При пересборке — данные в storage теряются

Решение — named volume + entrypoint:

# docker-compose.yml
services:
  app:
    volumes:
      - storage:/var/www/storage  # персистентный volume
    # ...

volumes:
  storage:  # данные сохраняются между деплоями

# entrypoint.sh
#!/bin/sh
# Создать структуру storage если пустой volume
mkdir -p storage/app/public storage/framework/{cache,sessions,views} storage/logs
chmod -R 775 storage
chown -R www-data:www-data storage

# Симлинк — каждый раз при старте
php artisan storage:link --force

# Миграции
php artisan migrate --force

exec "$@"

📌 storage:link --force в entrypoint — пересоздаёт симлинк при каждом старте. Это нормально и быстро.

⚠️ Не монтируйте public/ как volume — там должны быть файлы из образа (CSS, JS). Только storage/ персистентный.

📋 Стандартизация Docker — шаблоны + чеклист:

Чеклист для code review Dockerfile:

✅ Безопасность:
• Не root: USER appuser (uid 1000)
• Конкретный тег: node:20.11-alpine, не latest
• Нет секретов в образе (API keys, пароли)
• .dockerignore исключает .git, .env, node_modules

✅ Размер:
• Alpine или slim базовый образ
• Multi-stage build (dev-зависимости не в финальном образе)
• --no-cache-dir (pip) / npm ci (не npm install)
• Объединённые RUN (меньше слоёв)

✅ Кэширование:
• COPY package*.json до COPY . .
• Зависимости ставятся до копирования кода

✅ Healthcheck:
• HEALTHCHECK в Dockerfile или docker-compose

Подготовить шаблоны для Node.js, Go, Python? Пришлите список стеков ваших сервисов.

📦 Почему размер Docker-образа важен — аргументы для команды:

Цифры (node:20 vs node:20-alpine):
• node:20 — 1.1 ГБ (Debian, 400+ пакетов)
• node:20-alpine — 180 МБ (Alpine, минимум)
• Разница: 920 МБ × 12 сервисов = 11 ГБ

Где это бьёт:

1️⃣ CI/CD: docker pull 1.1 ГБ × 12 = 13 ГБ на каждый деплой. С alpine — 2 ГБ. Деплой быстрее на 5-10 минут.

2️⃣ Registry: Docker Hub / GHCR. 12 образов × 20 тегов × 1.1 ГБ = 264 ГБ. С alpine — 43 ГБ. Меньше платить за хранилище.

3️⃣ Безопасность: node:20 содержит 400+ пакетов, каждый — потенциальная CVE. В alpine — 15 пакетов. Trivy сканирование: 50 уязвимостей vs 3.

4️⃣ Autoscaling: Kubernetes тянет образ при создании нового пода. 1.1 ГБ = 30 секунд. 180 МБ = 5 секунд. При нагрузке — разница между «успели масштабироваться» и «пользователи ждут».

Когда alpine НЕ подходит:
• Нативные зависимости (sharp, canvas) — нужно доставлять build-tools
• glibc-зависимые пакеты — alpine использует musl
• В этих случаях: node:20-slim (~200 МБ, Debian-based)

Правило для команды: alpine по умолчанию, slim если alpine ломает зависимости, full никогда.

🐳 Единое dev-окружение для 3 ОС:

Принцип: код на хосте (IDE, git), всё остальное — в контейнерах. Hot reload через volume mounts.

Структура:

project/
├── docker-compose.yml
├── docker-compose.override.yml  # dev-специфичное (volumes, ports)
├── frontend/
│   ├── Dockerfile
│   └── Dockerfile.dev
├── backend/
│   ├── Dockerfile
│   └── Dockerfile.dev
└── .env.example  # скопировать в .env

docker-compose.yml:

services:
  frontend:
    build: { context: ./frontend, dockerfile: Dockerfile.dev }
    volumes: [./frontend:/app, /app/node_modules, /app/.next]
    ports: ["3000:3000"]
    environment: { NEXT_PUBLIC_API_URL: http://localhost:8000 }

  backend:
    build: { context: ./backend, dockerfile: Dockerfile.dev }
    volumes: [./backend:/app]
    ports: ["8000:8000"]
    environment:
      DATABASE_URL: postgresql://postgres:localdev@db:5432/myapp
      REDIS_URL: redis://redis:6379/0
      CELERY_BROKER_URL: redis://redis:6379/1
    depends_on:
      db: { condition: service_healthy }
    command: python manage.py runserver 0.0.0.0:8000

  celery:
    build: { context: ./backend, dockerfile: Dockerfile.dev }
    volumes: [./backend:/app]
    command: celery -A config worker -l info --autoreload
    environment:
      DATABASE_URL: postgresql://postgres:localdev@db:5432/myapp
      REDIS_URL: redis://redis:6379/0
      CELERY_BROKER_URL: redis://redis:6379/1
    depends_on: [redis, db]

  db:
    image: postgres:16-alpine
    environment: { POSTGRES_DB: myapp, POSTGRES_PASSWORD: localdev }
    volumes: [pgdata:/var/lib/postgresql/data]
    ports: ["5432:5432"]
    healthcheck:
      test: ["CMD-SHELL", "pg_isready"]
      interval: 3s
      retries: 5

  redis:
    image: redis:7-alpine

volumes:
  pgdata:

📌 Нюансы кроссплатформенности:
• /app/node_modules — анонимный volume, чтобы Mac/Windows node_modules не попали в Linux-контейнер
• File watching на Mac/Windows: добавьте WATCHPACK_POLLING=true для Next.js, --reload для Django
• Не забудьте .env.example → .env в README

🐌 Hot reload на Mac — проблема с file system events:

Причина: Docker Desktop на Mac использует VirtioFS/gRPC FUSE для монтирования хост-файлов в контейнер. Файловые события (inotify) доставляются с задержкой 3-10 сек.

Решения (от простого к сложному):

1️⃣ Polling mode (сразу работает):

# docker-compose.override.yml (только для Mac)
services:
  frontend:
    environment:
      WATCHPACK_POLLING: "true"  # Next.js
      CHOKIDAR_USEPOLLING: "true"  # CRA/Vite

• Минус: CPU +5-10%, но задержка < 1 сек

2️⃣ Docker Desktop → Settings → General:
• Включите VirtioFS (вместо gRPC FUSE) — быстрее в 2-3 раза
• macOS Ventura+: VirtioFS уже по умолчанию

3️⃣ Sync вместо bind mount (Docker Desktop 4.27+):

services:
  frontend:
    develop:
      watch:
        - action: sync
          path: ./frontend/src
          target: /app/src

• docker compose watch вместо docker compose up
• Мгновенная синхронизация без overhead монтирования

Рекомендация: начните с варианта 1 (одна строка), если не устроит — попробуйте вариант 3.