Можно ли сделать Demo Docker, не затрагивая работоспособность контейнеров?

Можно ли сделать Docker Demo, не затрагивая работоспособность контейнеров?

Да, безусловно, можно создать демо-среду на базе Docker, которая полностью изолирована от рабочих контейнеров и не влияет на их работоспособность. Это стандартная и рекомендуемая практика в DevOps для тестирования, разработки и демонстрации функциональности. Ключевые принципы для достижения этой цели — изоляция, управление конфигурацией и сетевая сегментация.

Основные подходы для изоляции Demo-среды

1. Использование отдельных Docker Compose проектов

Каждый Docker Compose проект работает в своей изолированной среде. Имена контейнеров, сети и volumes по умолчанию изолируются с помощью префикса проекта (обычно имени директории). Это позволяет запускать демо-среду параллельно с рабочей.

# docker-compose.demo.yml
version: '3.8'
services:
  demo-app:
    image: nginx:alpine
    container_name: demo-nginx  # Явное имя для избежания конфликтов
    ports:
      - "8080:80"  # Используем порт, отличный от рабочего (например, 80 -> 8080)
    networks:
      - demo-net

networks:
  demo-net:
    driver: bridge
    name: demo-network  # Изолированная сеть

Запуск с указанием имени проекта:

docker-compose -p mydemo -f docker-compose.demo.yml up -d

2. Создание выделенных Docker сетей

Docker позволяет создавать изолированные сети, чтобы контейнеры из разных сред не могли взаимодействовать друг с другом. Это фундаментальный механизм сетевой безопасности.

# Создание отдельной сети для демо
docker network create demo-network

# Запуск контейнера в этой сети
docker run -d --name demo-container --network demo-network nginx:alpine

# Рабочие контейнеры остаются в сети по умолчанию (bridge) или своей собственной

3. Управление томами (Volumes) и bind mounts

Важно изолировать данные демо-среды от рабочих. Используйте отдельные именованные тома или проверяйте пути при использовании bind mounts.

# В docker-compose.demo.yml
services:
  demo-db:
    image: postgres:14
    volumes:
      - demo-postgres-data:/var/lib/postgresql/data  # Отдельный volume

volumes:
  demo-postgres-data:
    name: demo-postgres-data  # Уникальное имя

4. Использование разных портов хоста

Самое простое правило: никогда не используйте одни и те же порты хоста для демо и рабочих сервисов. Если рабочий Nginx слушает на порту 80, настройте демо на порт 8080, 9080 и т.д.

# Рабочий контейнер
docker run -d --name prod-nginx -p 80:80 nginx:alpine

# Демо-контейнер (использует другой порт)
docker run -d --name demo-nginx -p 8080:80 nginx:alpine

5. Применение ресурсных ограничений (Resource Limits)

Чтобы демо-среда не потребляла ресурсы, критичные для рабочих систем, установите лимиты CPU и памяти.

services:
  demo-app:
    image: my-app:demo
    deploy:
      resources:
        limits:
          cpus: '0.5'
          memory: 512M

6. Использование тегов образов (Image Tags)

Всегда используйте разные теги для демо- и production-образов. Например, myapp:demo-latest vs myapp:prod-v1.2.3. Это предотвращает случайный запуск неподготовленного кода в production.

# Dockerfile для демо
FROM alpine:3.18
...
# Сборка с тегом demo
# docker build -t myapp:demo-feature-x .

Практический пример безопасной демо-среды

Предположим, у вас есть рабочий стек app + postgres. Демо-версия может быть развернута так:

1. Создайте отдельную директорию для демо (например, /opt/demo).
2. Определите уникальные имена для всех ресурсов (контейнеры, сети, тома).
3. Используйте неконфликтующие порты (рабочий app на 3000, демо на 3005).
4. Запустите через отдельный Compose файл с явным указанием проекта.

mkdir -p /opt/demo && cd /opt/demo
cat > docker-compose.yml << 'EOF'
version: '3.8'
services:
  demo-db:
    image: postgres:14-alpine
    container_name: demo-postgres
    environment:
      POSTGRES_PASSWORD: demo_password
    networks:
      - demo-net
    volumes:
      - demo-pg-data:/var/lib/postgresql/data
  demo-web:
    build: ./webapp
    container_name: demo-webapp
    ports:
      - "3005:3000"  # Рабочее приложение использует порт 3000
    depends_on:
      - demo-db
    networks:
      - demo-net

networks:
  demo-net:
    driver: bridge

volumes:
  demo-pg-data:
EOF

# Запуск с изоляцией
docker-compose -p mydemoproject up -d

Дополнительные меры предосторожности

• Тестирование на отдельном сервере/виртуальной машине: Идеальный вариант — использовать отдельный инстанс (например, Vagrant, отдельная VM в облаке или даже docker-machine).
• Использование Docker Swarm/Kubernetes namespaces: В оркестраторах используйте разные неймспейсы (например, demo и production).
• Мониторинг ресурсов: Следите за использованием ресурсов демо-средой, чтобы она не повлияла на производительность основной системы.
• Четкие процедуры очистки: Имейте скрипты для полной остановки и удаления демо-контейнеров, сетей и volumes.

# Скрипт очистки demo
docker-compose -p mydemoproject down -v
docker network prune -f

Заключение

Создание полностью изолированной Docker демо-среды не только возможно, но и является обязательным требованием для профессиональной DevOps-практики. Главное — строго следовать принципам изоляции: отдельные проекты, сети, тома, порты и теги образов. Это гарантирует, что ваши демонстрации, тесты или разработка новых функций никоим образом не затронут стабильность и доступность рабочих контейнеров. Более того, такая изоляция упрощает управление средами и снижает операционные риски.