Как поднять локальное окружение проекта с помощью Docker и Docker Compose
Что проверяют
Понимаете ли вы разницу между образом и сервисом и знаете ли типовые грабли локального окружения.
Как отвечать
Опишите структуру и порядок.
Dockerfile описывает образ приложения. Важные приёмы: многоэтапная сборка, чтобы в итоговый образ не попали инструменты сборки; сначала копируется файл зависимостей и выполняется установка, и только потом копируется код, тогда слой с зависимостями кэшируется и не пересобирается при каждой правке; файл исключений не пускает в образ виртуальное окружение, кэш и локальные настройки.
compose.yaml описывает набор сервисов и их связи:
services:
db:
image: postgres:17
environment: { POSTGRES_PASSWORD: dev }
volumes: [pgdata:/var/lib/postgresql/data]
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres"]
interval: 5s
app:
build: .
volumes: [".:/app"]
ports: ["8000:8000"]
depends_on:
db: { condition: service_healthy }
volumes: { pgdata: }Что здесь принципиально:
- проверка состояния и условие в зависимости. Обычный
depends_onждёт только запуска контейнера, а не готовности базы принимать соединения. Без проверки приложение стартует раньше и падает; - именованный том для данных базы, иначе при пересоздании контейнера данные пропадут;
- монтирование кода томом даёт горячую перезагрузку без пересборки образа. В продовой конфигурации этого быть не должно;
- сервисы видят друг друга по имени: адрес базы это
db, а неlocalhost. Это одна из самых частых ошибок при переносе настроек; - переменные из файла окружения, и сам файл не коммитится.
Команды: docker compose up -d --build, docker compose logs -f app, docker compose exec app bash для миграций и оболочки, docker compose down -v для полной очистки вместе с томами.
Где спотыкаются
Указывают localhost вместо имени сервиса.
Полагаются на depends_on без проверки готовности.
Копируют весь код до установки зависимостей и теряют кэш слоёв.
Держат данные базы без тома и удивляются их пропаже.