Docker

Описание

Использую Docker как основной способ собирать и запускать окружение для разработки, тестирования и deploy.

Работал с:

• docker compose для многоконтейнерных приложений;
• кастомными Dockerfile для development, CI и production;
• разделением ролей по контейнерам: app, nginx, queue, websocket, postgres, redis, служебные сервисы;
• локальной разработкой через bind mounts, env-переменные, отдельные конфиги и volume;
• публикацией production-образов в registry и запуском готовых образов на сервере;
• интеграцией Docker в CI/CD и release-based deploy.

Локальная разработка

Для локальной разработки использовал Docker-окружение с несколькими сервисами.

В такой схеме настраивал:

• отдельный контейнер приложения (PHP-FPM / runtime);
• отдельный nginx как reverse proxy;
• БД и Redis;
• фоновые воркеры очередей;
• WebSocket/real-time сервисы;
• вспомогательные контейнеры для отладки.

Дополнительно:

• проброс портов для HTTP, HTTPS, Vite/frontend dev server, WebSocket, PostgreSQL, Redis;
• bind mount исходников для быстрой разработки без пересборки образа;
• разделение read-only и read-write mounts;
• named volumes для данных БД и Redis;
• healthcheck для инфраструктурных сервисов;
• синхронизация UID/GID контейнера с пользователем хоста, чтобы избежать проблем с правами на файлы;
• подготовка отдельных конфигов для CLI и FPM, включая инструменты отладки.

В работе использовал Laravel Sail как обёртку над Dockerized development workflow.

Dockerfile и сборка образов

Использовал Dockerfile под разные сценарии — dev, prod-среда.

Development image

Для локальной разработки собирал образы, в которых уже подготовлены:

• нужная версия PHP и системные зависимости;
• расширения (pgsql, redis, gd, intl, imagick, xdebug и др.);
• Composer;
• Node.js и зависимости для frontend-сборки;
• инструменты отладки и анализа.

Дополнительно настраивал:

• запуск PHP-FPM на TCP-порту внутри контейнера;
• создание runtime-пользователя;
• безопасную работу с bind-mounted git-репозиторием;
• конфиги для профилирования и xDebug.

Production image

Подготовка production-образов с упором на воспроизводимость и уменьшение runtime-слоя:

• multi-stage build;
• отдельный этап установки vendor;
• отдельный этап сборки frontend-ассетов;
• перенос в финальный образ только нужных runtime-артефактов;
• вынос production-конфигов PHP / nginx в образ;
• запуск приложения без dev-зависимостей.

Такой подход позволяет:

• сократить размер финального образа;
• сделать deploy быстрее;
• уменьшить число production-зависимостей;
• избежать сборки приложения непосредственно на сервере.

В подобных production-схемах сборка может дополнительно разделять ответственность между образами:

• PHP-FPM image собирает runtime приложения и frontend-ассеты;
• nginx image получает готовую статику и production-конфиг;
• для nginx отдельно собираются динамические brotli-модули.

Reverse Proxy и сетевой слой

Использовал nginx в Docker как внешний entrypoint для приложения.

Что настраивал:

• проксирование запросов в PHP-FPM;
• HTTPS внутри локального окружения;
• проксирование WebSocket-подключений;
• выдачу статических ассетов;
• кэширование frontend-артефактов;
• защиту служебных путей и скрытых файлов;
• подключение дополнительных модулей nginx в production-образе;
• настройка локальных сертификатов.

Очереди, фоновые процессы и real-time

Docker использовал не только для запуска web-приложения, но и для изоляции длительно живущих процессов:

• queue workers;
• WebSocket / event-broadcasting серверов;
• служебных background-процессов.

Есть опыт настройки отдельных контейнеров с собственными командами запуска, таймаутами и параметрами retry.

Такой подход удобен тем, что:

• роли процессов разделены;
• проще перезапускать только проблемный сервис;
• логи и поведение каждого процесса изолированы;
• production-схема лучше масштабируется.

CI/CD и registry

Docker использовал как базовый артефакт поставки приложения.

Типовой процесс, с которым работал:

1. CI запускает проверки и тесты.
2. Pipeline собирает production-образы приложения и nginx.
3. Образы публикуются в Docker Registry.
4. Сервер не собирает проект сам, а получает готовые образы.
5. Deploy выполняется через docker compose pull и docker compose up -d.