web-dev-qa-db-ja.com

（NGINX LB + docker-compose）1つのサービスを停止し、もう1つのサービスのみを使用するようにします

Docker-2ノードサービスでNGINXを使用しています。

負荷分散が機能しています。これがどうあるべきかはわかりませんが、ページの読み込みは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

2番目の質問として、Jenkinsを使用してping2を削除し、更新してから起動し、ping1に対して同じことを行う方法を想像しようとしています。

今、私は手動でテストしていて、

docker-compose stop ping2

サービスはダウンしますが、nginxはそれを認識し、ping1を経由してルーティングするのにしばらく時間がかかります。

Chromeにポート80をロードします。最初のリクエストは、ping1を経由するページのロードです。2番目のリクエストは、ping2であるCSSファイルであり、ping1からロードするのに18〜90秒かかります。 "保留中"ずっと。

NGINXエラー

アップストリームにルーティングする前にチェックする場所でこれを修正するにはどうすればよいですか "healthy"の場合、おそらく私が手動で設定したエンドポイントを使用しますか？

これが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;
      }
  }
}
nginxload-balancingdockerdocker-composehealthcheck
1
Illinois47

私のページの読み込みはping1に行き、CSSファイルはサービスping2から読み込まれ、次のファイルはping1から読み込まれます。

これは、デフォルトの方法がラウンドロビンであるためです。

http://nginx.org/en/docs/http/load_balancing.html を参照してください。特に：

次の負荷分散メカニズム（またはメソッド）がnginxでサポートされています。

  • ラウンドロビン—アプリケーションサーバーへの要求はラウンドロビン方式で配布されます。
  • 最小接続—次の要求は、アクティブな接続の数が最も少ないサーバーに割り当てられます。
  • ip-hash —ハッシュ関数は、（クライアントのIPアドレスに基づいて）次の要求のために選択する必要があるサーバーを決定するために使用されます。

[...]

ロードバランシング方式が特に設定されていない場合、デフォルトでラウンドロビンになります。

[...]

Ip-hash負荷分散を構成するには、サーバー（アップストリーム）グループ構成にip_hashディレクティブを追加するだけです。

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

2番目の質問として、Jenkinsを使用してping2を削除し、更新してから起動し、ping1に対して同じことを行う方法を想像しようとしています。

この順序で行う必要はありません。必要なのは1つのコマンドだけです。

docker-compose up --build -d ping2

（その後、ping1について繰り返します）

イメージがビルドされるまでコンテナを停止しないと思います。ビルドされた時点で、コンテナは停止し、すぐに再作成されます。

なぜnginxが長い間ハングしているのかわかりませんが、ip_hashを使用すると、ページの途中で発生することを回避でき、上記のdocker-composeコマンドを使用すると、ダウンタイムが非常に小さくなります。

0
nafg