(NGINX LB + docker-compose) 停止 1 個服務，現在只使用另一個
我在 docker-compose 中使用 NGINX 和 2 個節點服務。
負載平衡正在工作。不知道這是否應該是這樣，但我的頁面載入到 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 進行路由。
我在 chrome 上傳入埠 80，第一個請求是通過 ping1 的頁面載入，第二個請求是 CSS 文件，它本來是 ping2，從 ping1 載入需要 18-90 秒，然後說一直在**“等待”**。
如果它是“健康的” ，我將如何解決這個問題，我會在路由到上游之前檢查它，也許是通過我手動設置的端點？
這是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 支持以下負載均衡機制（或方法）：
- 循環 - 對應用程序伺服器的請求以循環方式分發，
- 最少連接——下一個請求被分配給活動連接最少的伺服器，
- ip-hash — 一個散列函式用於確定應該為下一個請求選擇哪個伺服器（基於客戶端的 IP 地址）。
$$ … $$
當沒有特別配置負載均衡方式時，預設為round-robin。
$$ … $$
要配置 ip-hash 負載平衡，只需將 ip_hash 指令添加到伺服器（上游）組配置：
> > >
> 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 命令應該使停機時間非常短。