Docker в продакшене: ошибки и уроки при миграции 15 сервисов

Мы отключили автоматическое управление файрволом со стороны Docker-демона, добавив параметр в конфигурацию:

# /etc/docker/daemon.json
{
  "iptables": false,
  "ip-forward": true,
  "userland-proxy": false
}

Затем создали собственный набор правил iptables, которые корректно обрабатывают и трафик контейнеров, и хостовые правила безопасности:

# Разрешаем forward между контейнерами
iptables -A FORWARD -i docker0 -o docker0 -j ACCEPT
iptables -A FORWARD -i docker0 ! -o docker0 -j ACCEPT
iptables -A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

# NAT для выходящего трафика контейнеров
iptables -t nat -A POSTROUTING -s 172.18.0.0/16 ! -o docker0 -j MASQUERADE

# Проброс конкретных портов
iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 172.18.0.5:8080
iptables -A FORWARD -p tcp -d 172.18.0.5 --dport 8080 -j ACCEPT

Цепочка DOCKER-USER, которую Docker предлагает для кастомных правил, на практике оказалась недостаточно гибкой — она не позволяет контролировать NAT-таблицу и не поддерживает сложные сценарии маршрутизации.

Для критичных по производительности сервисов мы применили network_mode: host, что устраняет весь overhead от bridge-сети:

# docker-compose.yml для высоконагруженного API
services:
  api-gateway:
    image: registry.internal/api-gateway:1.4.2
    network_mode: host
    environment:
      - BIND_PORT=8080
      - METRICS_PORT=9090

Для остальных сервисов мы создали кастомные сети с непересекающимися подсетями:

# daemon.json — переопределяем дефолтную подсеть
{
  "default-address-pools": [
    {
      "base": "10.200.0.0/16",
      "size": 24
    }
  ],
  "bip": "10.200.0.1/24"
}

Важный нюанс: параметр bip игнорируется docker-compose, если сеть создаётся явно. Поэтому для compose-файлов мы прописывали подсети вручную:

networks:
  backend:
    driver: bridge
    ipam:
      config:
        - subnet: 10.201.0.0/24
  frontend:
    driver: bridge
    ipam:
      config:
        - subnet: 10.202.0.0/24

После оптимизации сети и переключения критичных сервисов на host-режим потери производительности сократились до менее 1%.

Наша команда внедрила многоуровневую систему защиты:

1. Непривилегированные контейнеры. Каждый Dockerfile мы переписали с явным указанием пользователя:

FROM python:3.11-slim
RUN groupadd -r appuser && useradd -r -g appuser -d /app appuser
WORKDIR /app
COPY --chown=appuser:appuser . .
USER appuser
CMD ["python", "main.py"]

2. Ограничение capabilities. В docker-compose мы явно ограничили привилегии каждого контейнера:

services:
  payment-api:
    image: registry.internal/payment-api:2.1.0
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE
    security_opt:
      - no-new-privileges:true
    read_only: true
    tmpfs:
      - /tmp

3. Контроль доступа к Docker socket. Мы убрали прямой доступ к socket и внедрили Portainer с RBAC для управления контейнерами.

4. Использование --mount вместо -v. Флаг -v автоматически создаёт каталоги с правами root, а --mount требует существования целевого каталога, что позволяет контролировать права.

5. Приватный registry. Мы развернули Harbor как приватный registry с автоматическим сканированием образов на уязвимости через Trivy.

Мы перевели все контейнеры на драйвер journald, который поддерживает команду docker logs и интегрируется с системным журналом:

# /etc/docker/daemon.json
{
  "log-driver": "journald",
  "log-opts": {
    "tag": "docker/{{.Name}}/{{.ID}}"
  }
}

Для сбора логов и отправки в ELK-стек мы настроили Promtail:

# promtail-config.yml
scrape_configs:
  - job_name: docker
    journal:
      json: true
      max_age: 12h
      labels:
        job: docker
    relabel_configs:
      - source_labels: ['__journal_container_name']
        target_label: 'container'
      - source_labels: ['__journal_container_tag']
        target_label: 'tag'
    pipeline_stages:
      - json:
          expressions:
            level: level
            msg: message
      - labels:
          level:

Также мы установили лимиты на уровне daemon.json как страховку от переполнения:

{
  "log-opts": {
    "max-size": "50m",
    "max-file": "5"
  }
}

После внедрения объём дискового пространства под логи сократился с непредсказуемого до стабильных 2-3 ГБ на хост.

Мы использовали формат compose 2.4 с явными health-check условиями:

version: '2.4'
services:
  postgres:
    image: postgres:16-alpine
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app -d appdb"]
      interval: 5s
      timeout: 3s
      retries: 10
      start_period: 15s

  redis:
    image: redis:7-alpine
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 5s
      timeout: 3s
      retries: 5

  api:
    image: registry.internal/api:1.2.0
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_healthy

Для продакшен-среды мы дополнительно обернули запуск каждого сервиса в systemd unit, что обеспечило автоматический перезапуск, корректное завершение и интеграцию с системным мониторингом:

[Unit]
Description=Payment API Container
After=docker.service postgresql-container.service
Requires=docker.service

[Service]
Type=simple
Restart=always
RestartSec=10
ExecStartPre=-/usr/bin/docker rm -f payment-api
ExecStart=/usr/bin/docker run --name payment-api \
  --network backend \
  -p 8080:8080 \
  registry.internal/payment-api:latest
ExecStop=/usr/bin/docker stop -t 30 payment-api

[Install]
WantedBy=multi-user.target

Мы разработали и внедрили несколько практик:

• Единая версия Docker на всех серверах с синхронными обновлениями через Ansible
• Внешнее хранение данных — все stateful-сервисы используют именованные volumes с бэкапами, а критичные данные хранятся на внешних NFS-шарах
• Registry с версионированием — каждый образ тегируется хэшем коммита и семантической версией, тег latest запрещён в продакшене

# Ansible playbook для синхронизации версий Docker
- name: Ensure consistent Docker version
  hosts: docker_hosts
  tasks:
    - name: Pin Docker version
      apt:
        name: docker-ce=5:24.0.7-1~ubuntu.22.04~jammy
        state: present
        allow_downgrade: yes
    - name: Verify storage driver
      command: docker info --format '{{.Driver}}'
      register: storage_driver
    - name: Assert overlay2
      assert:
        that: storage_driver.stdout == 'overlay2'
        msg: "Storage driver must be overlay2"