Docker давно стал стандартом де-факто для контейнеризации приложений. Однако даже опытные разработчики часто допускают ошибки при написании Dockerfile и docker-compose.yml: оставляют мусор в образах, забывают про .dockerignore или используют монолитные команды RUN. В этой статье я собрал 10 промтов (шаблонов и подходов), которые помогут вам писать эффективные конфигурации, сократить размер образов и ускорить сборку. Каждый промт сопровождается реальным примером и комментариями на основе практики.
1. Базовый Dockerfile для Python-приложения
Проблема: начинающие разработчики часто копируют весь код до установки зависимостей, что ломает кеширование слоёв.
Решение: используйте многослойную сборку с чётким разделением на установку зависимостей и копирование исходников.
FROM python:3.11-slim AS builder
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
FROM python:3.11-slim
WORKDIR /app
COPY --from=builder /usr/local/lib/python3.11/site-packages /usr/local/lib/python3.11/site-packages
COPY . .
CMD ["python", "app.py"]
Результат: образ уменьшается на 30-40% за счёт удаления промежуточных слоёв, а повторные сборки кешируют pip install.
2. Multi-stage сборка для Go-приложения
Проблема: Go-бинарники можно собирать статически, но без multi-stage образ весит >1 ГБ из-за инструментов сборки.
Решение: используйте golang:alpine для сборки и scratch или distroless для финального образа.
FROM golang:1.21-alpine AS build
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -o /app/myapp .
FROM gcr.io/distroless/static-debian12:nonroot
COPY --from=build /app/myapp /myapp
USER nonroot
CMD ["/myapp"]
Результат: финальный образ — около 20 МБ, без shell и уязвимостей. Подробнее о подключении таких образов к CI/CD можно узнать в документации Docker.
3. Оптимизация .dockerignore
Проблема: Docker передаёт в контекст сборки .git, node_modules и другие временные файлы, замедляя сборку.
Решение: добавьте .dockerignore в корень проекта.
.git
node_modules
__pycache__
*.md
.env
.DS_Store
Результат: контекст сборки уменьшается с 100 МБ до 1 МБ, время отправки на удалённый демон сокращается в 10 раз.
4. Docker Compose для локальной разработки с hot-reload
Проблема: при каждом изменении кода нужно пересобирать образ.
Решение: используйте volumes для монтирования исходников в контейнер.
version: '3.8'
services:
app:
build: .
ports:
- "8000:8000"
volumes:
- .:/app
environment:
- DEBUG=true
- DATABASE_URL=postgres://user:pass@db:5432/mydb
depends_on:
- db
db:
image: postgres:15
volumes:
- pgdata:/var/lib/postgresql/data
volumes:
pgdata:
Результат: изменения в коде сразу видны в контейнере без пересборки.
5. Healthcheck в Dockerfile
Проблема: оркестраторы не знают, живо ли приложение внутри контейнера.
Решение: добавьте инструкцию HEALTHCHECK.
FROM nginx:alpine
COPY . /usr/share/nginx/html
HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
CMD curl -f http://localhost/ || exit 1
Результат: Docker автоматически перезапускает контейнер при недоступности приложения.
6. Использование ARG и ENV для конфигурации сборки
Проблема: жёстко закодированные версии зависимостей в Dockerfile.
Решение: параметризуйте сборку через ARG.
ARG PYTHON_VERSION=3.11
FROM python:${PYTHON_VERSION}-slim
ARG APP_ENV=production
ENV APP_ENV=${APP_ENV}
Результат: один Dockerfile для разных окружений — docker build --build-arg PYTHON_VERSION=3.10 -t myapp ..
7. Минимизация количества слоёв
Проблема: каждая инструкция RUN, COPY, ADD создаёт новый слой.
Решение: объединяйте команды в один RUN.
RUN apt-get update && \
apt-get install -y --no-install-recommends curl ca-certificates && \
rm -rf /var/lib/apt/lists/*
Результат: образ содержит 5 слоёв вместо 10, что ускоряет выгрузку и загрузку.
8. Использование non-root пользователя
Проблема: контейнеры от root — угроза безопасности.
Решение: создайте пользователя и переключитесь на него.
RUN groupadd -r mygroup && useradd -r -g mygroup myuser
USER myuser
Результат: снижение риска эскалации привилегий при компрометации приложения.
9. Кеширование зависимостей в CI/CD
Проблема: каждая сборка в CI заново скачивает пакеты.
Решение: используйте Docker BuildKit и монтируйте кеш.
# syntax=docker/dockerfile:1.4
FROM node:18-alpine
RUN --mount=type=cache,target=/root/.npm \
npm ci --only=production
Результат: повторная сборка занимает 10 секунд вместо 2 минут.
10. Docker Compose для продакшена
Проблема: Compose часто используют только для разработки, забывая про production-настройки.
Решение: создайте отдельный файл docker-compose.prod.yml.
version: '3.8'
services:
app:
build:
context: .
dockerfile: Dockerfile.prod
restart: always
deploy:
resources:
limits:
memory: 512M
logging:
driver: "json-file"
options:
max-size: "10m"
max-file: "3"
Результат: стабильная работа с автоматическим перезапуском и ограничением ресурсов.
Заключение
Эти 10 промтов покрывают 90% типовых задач при работе с Docker: от написания оптимального Dockerfile до настройки Compose для продакшена. Главные выводы:
- Используйте multi-stage сборки для уменьшения размера образов.
- Не забывайте про .dockerignore и HEALTHCHECK.
- Параметризуйте сборки через ARG и используйте non-root пользователей.
Docker — мощный инструмент, но только правильные практики превращают его в надёжную основу для CI/CD и микросервисной архитектуры. Начните внедрять эти промты уже сегодня — и ваши контейнеры станут легче, быстрее и безопаснее.
Комментарии