Docker Networks: Від базових концепцій до мультихост архітектури

Коли ваші мікросервіси ростуть, виникає питання: як організувати мережеву взаємодію між контейнерами? На одному хості це просто, але що робити коли сервіси розподілені між кількома серверами? У цій статті розберемо все – від bridge networks до Docker Swarm та overlay networks.

Що ви дізнаєтесь:

  • Типи Docker мереж та коли їх використовувати
  • Як організувати мережі для мікросервісної архітектури
  • Комунікація між контейнерами на різних хостах
  • Практичні приклади з реальних проєктів
  • Безпека та best practices

Час читання: 20-25 хвилин
Складність: Середній → Просунутий


Частина 1: Типи Docker мереж

1.1 Bridge Network (За замовчуванням)

Що це? Віртуальна мережа на одному хості. Контейнери можуть спілкуватися між собою через ім’я контейнера.

Приклад нашого проєкту:

Як це працює:

Комунікація:

Коли використовувати:

  • ✅ Всі сервіси на одному хості
  • ✅ Розробка та тестування
  • ✅ Невеликі проєкти

Обмеження:

  • ❌ Працює тільки на одному хості
  • ❌ Не підходить для production з кількома серверами

1.2 External Network (Спільна мережа)

Що це? Мережа створена зовні docker-compose, до якої можуть підключатися різні stack’и.

Наш випадок:

Як це працює:

Створення shared_network:

Комунікація між проєктами:

Коли використовувати:

  • ✅ Кілька docker-compose проєктів на одному хості
  • ✅ Мікросервісна архітектура
  • ✅ Розділення concerns (frontend, backend, parser тощо)

1.3 Host Network

Що це? Контейнер використовує мережу хост машини напряму. Немає ізоляції.

Коли використовувати:

  • ⚠️ Рідко! Тільки для специфічних випадків
  • Моніторинг (Prometheus, node-exporter)
  • Низька латентність (trading systems)

Недоліки:

  • ❌ Немає ізоляції
  • ❌ Конфлікти портів
  • ❌ Погана переносимість

1.4 None Network

Коли використовувати:

  • Batch jobs які не потребують мережі
  • Максимальна ізоляція

Частина 2: Expose vs Ports

Різниця (критично для безпеки!)

Що відбувається:

  • Порт 8080 доступний на localhost:8080
  • Порт 8080 доступний на server-ip:8080
  • Якщо сервер в інтернеті – порт доступний всім!

Що відбувається:

  • Порт 8080 доступний тільки іншим контейнерам
  • НЕ доступний з хост машини
  • НЕ доступний з інтернету

Наш приклад

Доступ:


Частина 3: Мультихост архітектура

Сценарій: Сервіси на різних серверах

Проблема: Bridge networks працюють тільки на одному хості!

Рішення 1: Docker Swarm + Overlay Network

Docker Swarm – вбудований оркестратор. Overlay network створює віртуальну мережу між хостами.

Ініціалізація Swarm

Створення Overlay Network

Ключові параметри:

  • --driver overlay – мультихост мережа
  • --attachable – можна підключати standalone контейнери

Docker Compose для Swarm

SERVER 1 (Laravel):

SERVER 2 (Content Parser):

Deployment

Комунікація

Як це працює:

Переваги:

  • ✅ Вбудовано в Docker
  • ✅ Автоматичний DNS
  • ✅ Encrypted комунікація
  • ✅ Service discovery

Недоліки:

  • ⚠️ Потребує Swarm mode
  • ⚠️ Складніше налаштування

Рішення 2: Weave Net

Weave створює mesh мережу між хостами без Swarm.

Рішення 3: VPN (WireGuard / Tailscale)

Найпростіше рішення – створити VPN між серверами.

Tailscale (найпростіше)

Переваги:

  • ✅ Найпростіше налаштування
  • ✅ Працює з існуючими docker-compose файлами
  • ✅ Encrypted комунікація
  • ✅ Не потребує Swarm

Недоліки:

  • ❌ Використовує IP адреси (не DNS імена)
  • ❌ Додатковий сервіс

Рішення 4: Consul + Registrator

Для складних мікросервісних архітектур.

Сервіси автоматично реєструються в Consul і можуть знаходити один одного.


Частина 4: Практичний приклад з нашого проєкту

Архітектура

Laravel .env

Content Parser docker-compose.yml

Чому parser-network окремо?

Причини:

  1. Безпека – Laravel не має прямого доступу до БД Parser’а
  2. Ізоляція – кожен сервіс контролює свою БД
  3. Separation of concerns – чітке розділення відповідальності

Комунікація:


Частина 5: Безпека

5.1 Ports vs Expose

5.2 Nginx як Reverse Proxy

Nginx конфіг:

Тепер API доступний через Nginx, але порт 8080 закритий ззовні!

5.3 Firewall правила

5.4 Encrypted Communication

Docker Swarm (автоматично)

Manual TLS


Частина 6: Troubleshooting

Проблема 1: Контейнери не бачать один одного

Рішення:

Проблема 2: “network not found”

Проблема 3: “address already in use”

Проблема 4: Swarm overlay не працює

Проблема 5: Повільна комунікація між хостами


Частина 7: Best Practices

7.1 Naming Conventions

7.2 Network Segmentation

7.3 Use Labels

7.4 Monitoring

7.5 Documentation

Завжди документуйте вашу мережеву архітектуру:


Частина 8: Скрипт для управління

Створимо bash скрипт для зручного управління мережами:

Використання:


Частина 9: Real-World Scenarios

Scenario 1: Microservices на одному хості

Переваги:

  • Тільки API Gateway доступний ззовні
  • Всі інші сервіси захищені
  • Проста архітектура

Scenario 2: Hybrid – частина на хості, частина в cloud

Налаштування з SSH тунелем:

Налаштування з Tailscale:

Scenario 3: Multi-region deployment

Docker Swarm з constraints:

Позначити ноди:

Scenario 4: Development → Staging → Production

Запуск:


Частина 10: Performance Optimization

10.1 MTU Settings

Коли змінювати MTU:

  • VPN з’єднання (зменшити на 50-100)
  • Jumbo frames (збільшити до 9000)
  • Cloud providers (AWS, GCP мають рекомендації)

10.2 DNS Caching

10.3 Connection Pooling

10.4 Load Balancing


Частина 11: Monitoring & Debugging

11.1 Network Traffic

11.2 Prometheus Metrics

11.3 Grafana Dashboard

Метрики для моніторингу:

  • Network throughput (MB/s)
  • Latency між контейнерами
  • Packet loss
  • Connection count
  • DNS resolution time

11.4 Logging

Централізований logging:


Частина 12: Security Deep Dive

12.1 Network Policies (з Kubernetes)

Якщо використовуєте Kubernetes замість Docker Compose:

12.2 Docker Security Scanner

12.3 Secrets Management

12.4 Read-only Root Filesystem


Частина 13: Migration Strategies

З bridge на overlay

Zero-downtime migration


Частина 14: Advanced Topics

14.1 IPAM (IP Address Management)

14.2 IPv6 Support

14.3 MacVLAN Networks

Контейнери отримують IP з фізичної мережі:

Use cases:

  • Legacy додатки що очікують physical network
  • Network monitoring tools
  • DHCP servers в контейнерах

14.4 Custom DNS


Частина 15: Checklist для Production

Pre-deployment Checklist


Висновки

Що ми навчились

  1. Bridge Networks – для single-host розробки
  2. External Networks – для комунікації між docker-compose стеками
  3. Overlay Networks – для мультихост продакшн
  4. Expose vs Ports – критично для безпеки
  5. Network Segmentation – для ізоляції сервісів

Рекомендації

Для Development:

Для Production:

Ключові принципи

  1. Least Privilege – мінімально необхідний доступ
  2. Defense in Depth – кілька рівнів безпеки
  3. Separation of Concerns – чітке розділення мереж
  4. Monitor Everything – якщо не моніторите, не контролюєте
  5. Document Always – майбутній ви подякує

Корисні ресурси


Бонус: Quick Reference Commands


Що далі?

У наступних постах у цьому розділі:

  1. Kubernetes Networking – для enterprise scale
  2. Service Mesh (Istio, Linkerd) – для складних мікросервісів
  3. eBPF – для network observability
  4. Cilium – modern networking для Kubernetes

Happy Networking! 🚀


Якщо у вас є питання або доповнення – пишіть в коментарях!

Опубліковано в Docker

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *