Что использовал балансировщиком в Docker

Балансировщик нагрузки в Docker

Балансировщик нагрузки — это компонент, который распределяет входящие запросы между несколькими контейнерами приложения для обеспечения отказоустойчивости и масштабируемости. Это критически важно для production-окружения.

Основные решения для Docker

1. Docker Swarm встроенный балансировщик

Docker Swarm имеет встроенный балансировщик нагрузки, работающий на базе IPVS (IP Virtual Server):

# Инициализируем Swarm
docker swarm init

# Создаём сервис (не контейнер)
docker service create --name web-app \
  --publish 8080:8080 \
  --replicas 3 \
  myapp:latest

# Проверяем сервис
docker service ls
docker service ps web-app

Как это работает:

• Docker автоматически создаёт 3 реплики контейнера
• Встроенный Load Balancer распределяет трафик между ними
• Если контейнер упадёт, Docker создаст новый

Docker Compose с портами:

version: 3.9
services:
  app:
    image: myapp:latest
    ports:
      - "8080:8080"  # Host:Container
    deploy:
      replicas: 3  # 3 реплики
      restart_policy:
        condition: on-failure

2. Nginx как reverse proxy

Это наиболее популярное решение для production:

version: 3.9
services:
  # Несколько экземпляров приложения
  app-1:
    image: myapp:latest
    environment:
      - INSTANCE_ID=1
    networks:
      - app-network
  
  app-2:
    image: myapp:latest
    environment:
      - INSTANCE_ID=2
    networks:
      - app-network
  
  app-3:
    image: myapp:latest
    environment:
      - INSTANCE_ID=3
    networks:
      - app-network
  
  # Nginx как балансировщик
  nginx:
    image: nginx:latest
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
    networks:
      - app-network
    depends_on:
      - app-1
      - app-2
      - app-3

networks:
  app-network:
    driver: bridge

Конфигурация Nginx (nginx.conf):

upstream app_backend {
    # Round-robin — распределение по очереди
    server app-1:8080;
    server app-2:8080;
    server app-3:8080;
    
    # Проверка здоровья
    # Если сервер не отвечает 3 раза подряд, исключается
    keepalive 32;
}

server {
    listen 80;
    server_name localhost;

    location / {
        proxy_pass http://app_backend;
        
        # Заголовки прокси
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        
        # Таймауты
        proxy_connect_timeout 60s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;
        
        # Буферизация
        proxy_buffering on;
        proxy_buffer_size 128k;
        proxy_buffers 4 256k;
    }
}

3. HAProxy (High Availability Proxy)

Мощный и гибкий балансировщик нагрузки:

version: 3.9
services:
  haproxy:
    image: haproxy:latest
    ports:
      - "80:80"
      - "8404:8404"  # статистика
    volumes:
      - ./haproxy.cfg:/usr/local/etc/haproxy/haproxy.cfg:ro
    networks:
      - app-network

  app-1:
    image: myapp:latest
    networks:
      - app-network

  app-2:
    image: myapp:latest
    networks:
      - app-network

  app-3:
    image: myapp:latest
    networks:
      - app-network

networks:
  app-network:
    driver: bridge

Конфигурация HAProxy (haproxy.cfg):

global
    log stdout local0
    maxconn 4096

defaults
    log     global
    mode    http
    option  httplog
    option  dontlognull
    timeout connect 5000
    timeout client  50000
    timeout server  50000

frontend http_in
    bind *:80
    default_backend app_servers

backend app_servers
    balance roundrobin  # или leastconn, source, uri, etc
    option httpchk GET /health  # проверка здоровья
    
    server app1 app-1:8080 check
    server app2 app-2:8080 check
    server app3 app-3:8080 check

# Панель статистики
listen stats
    bind *:8404
    stats enable
    stats uri /stats
    stats refresh 5s

4. Kubernetes (для production)

Если используешь Kubernetes, там встроен ServiceLoad Balancer:

apiVersion: v1
kind: Service
metadata:
  name: app-lb
spec:
  type: LoadBalancer  # или NodePort, ClusterIP
  selector:
    app: myapp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: app
        image: myapp:latest
        ports:
        - containerPort: 8080
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 5

Алгоритмы распределения нагрузки

Round-Robin (по умолчанию):

Запрос 1 → Server 1
Запрос 2 → Server 2
Запрос 3 → Server 3
Запрос 4 → Server 1
...

Least Connections:

Запрос 1 → Server 1 (0 подключений)
Запрос 2 → Server 2 (0 подключений)
Запрос 3 → Server 3 (0 подключений)
Запрос 4 → Server 1 (минимум активных соединений)

IP Hash (сессионность):

Клиент 192.168.1.100 → всегда на Server 1
Клиент 192.168.1.101 → всегда на Server 2
(важно для сессий)

Проверка здоровья (Health Checks)

version: 3.9
services:
  app:
    image: myapp:latest
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
      interval: 10s
      timeout: 5s
      retries: 3
      start_period: 40s

Java приложение с health endpoint:

// Spring Boot
@RestController
public class HealthController {
    @GetMapping("/health")
    public ResponseEntity<Map<String, String>> health() {
        return ResponseEntity.ok(Map.of(
            "status", "UP",
            "timestamp", System.currentTimeMillis() + ""
        ));
    }
}

// Или используй Spring Actuator
@Configuration
public class ActuatorConfig {
    // Автоматически предоставляет /actuator/health
}

Практический пример с Java приложением

version: 3.9
services:
  # Java приложение
  java-app:
    build:
      context: .
      dockerfile: Dockerfile
    environment:
      - JAVA_OPTS=-Xmx512m -Xms256m
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080/actuator/health"]
      interval: 10s
      timeout: 5s
      retries: 3
    networks:
      - app-network
    deploy:
      replicas: 3

  # Nginx как балансировщик
  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
    depends_on:
      - java-app
    networks:
      - app-network

networks:
  app-network:
    driver: bridge

Dockerfile для Java приложения:

FROM eclipse-temurin:17-jre-alpine
WORKDIR /app
COPY target/app.jar app.jar
EXPOSE 8080
CMD ["java", "-jar", "app.jar"]

Масштабирование с Docker

# Docker Compose с масштабированием
docker-compose up -d --scale app=3

# Docker Swarm
docker service scale web-app=5

# Проверка
docker-compose ps
docker service ls

Мониторинг трафика

# Nginx логи в реальном времени
docker logs -f nginx-container

# HAProxy статистика
http://localhost:8404/stats

# Проверка балансировщика
for i in {1..10}; do curl http://localhost; done

Выводы

• Docker Swarm — встроенный, простой балансировщик
• Nginx — легкий и эффективный reverse proxy
• HAProxy — мощный и гибкий балансировщик
• Kubernetes — для enterprise решений
• Health checks — обязательны для reliability
• Алгоритмы распределения — выбираются в зависимости от типа приложения

Балансировщик нагрузки — неотъемлемая часть любой production системы!