Назад | Перейти на главную страницу

(NGINX LB + docker-compose) Остановите 1 службу и теперь используйте только другую

Я использую NGINX внутри docker-compose с двумя службами узлов.

Балансировка нагрузки работает. Не уверен, что так и должно быть, но моя страница загружается на ping1, затем загружается файл CSS из службы ping2, затем следующий файл из ping1 и ... Где я думал, это будет загрузка одной полной страницы из ping1 и следующий из ping2.

Какой из них более стандартный?

Вот docker-compose.yml

version: "2"

services:
  ping1:
    ports:
      - "80"
    build:
      context: ./1
      dockerfile: Dockerfile
    networks:
      - front-tier

  ping2:
    build:
      context: ./1
      dockerfile: Dockerfile
    networks:
      - front-tier

  nginx:
    build: ./nginx
    ports:
        - "80:80"
    networks:
      - front-tier

networks:
  front-tier:
    driver: bridge

В качестве второго вопроса я пытаюсь представить, как я могу использовать Jenkins, чтобы отключить ping2, обновить его, затем вызвать и сделать то же самое с ping1.

Сейчас я просто тестирую вручную и использую

docker-compose stop ping2

Служба отключается, но nginx нужно время, чтобы это понять и выполнить маршрутизацию через ping1.

Я загружаю порт 80 на Chrome, первый запрос - это загрузка страницы, которая проходит через ping1, а второй - это файл CSS, который был бы ping2, и для загрузки из ping1 требуется где-то от 18 до 90 секунд, и просто говорит "В ожидании" Все время.

Ошибка NGINX

Как мне исправить это там, где я бы проверил перед маршрутизацией к восходящему потоку, если это "здоровый", может быть, через конечную точку, настроенную мной вручную?

Вот nginx.conf

events {
    worker_connections 20000;
    use epoll;
    multi_accept on;
}

http {
  upstream ping {
    server ping1:80 max_fails=1 fail_timeout=1s;
    server ping2:80 max_fails=1 fail_timeout=1s;
  }

  limit_req_zone $binary_remote_addr zone=one:10m rate=18000r/m;
  limit_conn_zone $binary_remote_addr zone=addr:10m;

  keepalive_timeout 65;
  keepalive_requests 100000;
  sendfile on;
  tcp_nopush on;
  tcp_nodelay on;

  client_body_buffer_size      128k;
  client_max_body_size         10m;
  client_header_buffer_size    1k;
  large_client_header_buffers  4 4k;
  output_buffers               1 32k;
  postpone_output              1460;

  client_header_timeout  3m;
  client_body_timeout    3m;
  send_timeout           3m;

  open_file_cache max=1000 inactive=20s;
  open_file_cache_valid 30s;
  open_file_cache_min_uses 5;
  open_file_cache_errors off;

  server {
      listen 80;

      server_tokens   off;

      gzip on;
      gzip_disable "MSIE [1-6]\.";
      gzip_comp_level 5;
      gzip_vary on;
      gzip_min_length 1000;
      gzip_proxied any;
      gzip_types text/html application/x-javascript text/css application/javascript text/javascript text/plain text/xml application/json application/vnd.ms-fontobject application/x-font-opentype application/x-font-truetype application/x-font-ttf application/xml font/eot font/opentype font/otf image/svg+xml image/vnd.microsoft.icon;
      gzip_buffers 16 8k;

      location / {
          limit_req zone=one;
          limit_conn addr 10;

          proxy_pass http://ping/;
          proxy_http_version 1.1;
          proxy_set_header   Upgrade $http_upgrade;
          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_set_header   Host                   $http_host;
          proxy_set_header   X-NginX-Proxy    true;
          proxy_set_header   Connection "";

          proxy_connect_timeout      90;
          proxy_buffer_size          4k;
          proxy_buffers              4 32k;
          proxy_busy_buffers_size    64k;
          proxy_temp_file_write_size 64k;
          proxy_temp_path            /etc/nginx/proxy_temp;

          proxy_send_timeout 600;
          proxy_read_timeout 600;
      }

      location /stats {
        stub_status on;

        allow all;
      }
  }
}

загрузка моей страницы идет на ping1, затем файл CSS загружается из службы ping2, затем следующий файл из ping1 и ... Где я думал, в основном это будет загрузка одной полной страницы из ping1 и следующей из ping2.

Это потому, что метод по умолчанию - циклический.

Видеть http://nginx.org/en/docs/http/load_balancing.html. В частности:

В nginx поддерживаются следующие механизмы (или методы) балансировки нагрузки:

  • round-robin - запросы к серверам приложений распределяются циклически,
  • наименее подключенный - следующий запрос присваивается серверу с наименьшим количеством активных подключений,
  • ip-hash - хеш-функция используется для определения того, какой сервер следует выбрать для следующего запроса (на основе IP-адреса клиента).

[...]

Если метод балансировки нагрузки специально не настроен, по умолчанию используется циклический перебор.

[...]

Чтобы настроить балансировку нагрузки ip-hash, просто добавьте директиву ip_hash в конфигурацию группы server (upstream):

upstream myapp1 {
    ip_hash;
    server srv1.example.com;
    server srv2.example.com;
    server srv3.example.com;
}

В качестве второго вопроса я пытаюсь представить, как я могу использовать Jenkins, чтобы отключить ping2, обновить его, затем вызвать и сделать то же самое с ping1.

Не нужно делать это в таком порядке. Все, что вам нужно, это одна команда:

docker-compose up --build -d ping2

(а затем повторите для ping1)

Я считаю, что это не остановит контейнер до тех пор, пока изображение не будет построено, после чего он остановит его и немедленно воссоздает.

Не знаю, почему так долго зависает nginx, но использую ip_hash следует избегать того, что происходит на середине страницы, а использование приведенной выше команды docker-compose должно сократить время простоя до минимума.