(NGINX LB + docker-compose) Pare 1 serviço e agora use somente o outro

Question

Estou usando o NGINX dentro do docker-compose com serviços de 2 nós.

O balanceamento de carga está funcionando. Não tenho certeza se é assim que deve ser, mas o carregamento da minha página vai para ping1, depois o arquivo CSS é carregado do serviço ping2, depois o próximo arquivo do ping1 e ... Onde eu pensei que seria basicamente um carregamento de página completo do ping1 e o próximo do ping2.

Qual deles é mais padrão?

Veja 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

Como minha segunda pergunta, estou tentando imaginar como eu poderia usar o Jenkins para derrubar o ping2, atualizá-lo, depois trazê-lo para o ping1.

Agora estou apenas testando manualmente e usando

docker-compose stop ping2

O serviço cai, mas o nginx demora um pouco para perceber isso, e rotear através do ping1.

Eu carrego a porta 80 no chrome, a primeira solicitação é o carregamento da página que passa pelo ping1, e a segunda é o arquivo CSS, que seria o ping2, e leva de 18 a 90 segundos para carregar a partir do ping1, e apenas diz "Pendente" o tempo todo.

Erro NGINX

Como eu iria corrigir isso onde eu iria verificar antes de encaminhar para um upstream, se é "saudável" , talvez através de um ponto de extremidade de configuração manual por mim?

Aqui está 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;
      }
  }
}

    

Answer 1

my page load goes to ping1, then the CSS file loads from service ping2, then the next file from ping1, and... Where I thought it'd mostly be one full page load from ping1 and the next one from ping2.

Isso porque o método padrão é round-robin.

Consulte o link . Em particular:

The following load balancing mechanisms (or methods) are supported in nginx:

• round-robin — requests to the application servers are distributed in a round-robin fashion,
• least-connected — next request is assigned to the server with the least number of active connections,
• ip-hash — a hash-function is used to determine what server should be selected for the next request (based on the client’s IP address).

[...]

When the load balancing method is not specifically configured, it defaults to round-robin.

[...]

To configure ip-hash load balancing, just add the ip_hash directive to the server (upstream) group configuration:

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

     

Como minha segunda pergunta, estou tentando imaginar como eu poderia usar o Jenkins para derrubar o ping2, atualizá-lo, depois trazê-lo para o ping1.

Não há necessidade de fazer isso nessa ordem. Tudo que você precisa é de um comando:

docker-compose up --build -d ping2

(e depois repita para ping1)

Acredito que isso não irá parar o contêiner até que a imagem seja construída, e nesse ponto ele irá pará-lo e recriá-lo imediatamente.

Não sei por que o nginx está pendurado por tanto tempo, mas usar ip_hash deve evitar que isso aconteça no meio da página, e usar o comando docker-compose acima deve tornar o tempo de inatividade extremamente minúsculo.