patch-nginxコンテナはnginxプロセス内でpatch-backendのIPアドレスを誤って確認しましたが、nginxコマンドラインで手動で確認したときには確認されませんでした。
Podmanコンテナ内でnginxをエージェントとして実行していますが、インターネット検索ではこの問題がDockerにも存在し、解決策がないことがわかりました。
nginxログには次のものが表示されます。
2023/07/12 19:33:52 [error] 24#24: *52 connect() failed (113: No route to host) while connecting to upstream, client: 10.89.0.119, server: patches.lan, request: "GET /api/auth HTTP/1.1", upstream: "https://10.89.0.117:9000/api/auth", host: "10.10.25.131", referrer: "https://10.10.25.131/"
10.89.0.119 - - [12/Jul/2023:19:33:52 +0000]
"GET /api/auth HTTP/1.1" 502 559
"https://10.10.25.131/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36"
Certificate: "-"
Client Key: "-"
アップストリームホストが10.89.0.117であることがわかります。 nginx設定を確認しようとしました。 -proxy_pass は以下を指しますpatches-backend
。
events {
worker_connections 1024;
}
http {
include /etc/nginx/mime.types;
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
log_format custom '
$remote_addr - $remote_user [$time_local]
"$request" $status $body_bytes_sent
"$http_referer" "$http_user_agent"
Certificate: "$ssl_client_cert"
Client Key: "$ssl_client_raw_cert"
';
server {
listen 80;
listen [::]:80;
server_name patches.lan 10.10.25.131 ;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
listen [::]:443 ssl;
server_name patches.lan 10.10.25.131 ;
access_log /var/log/nginx/access.log custom;
# Client-facing certificate and key
ssl_certificate /patches/server_certs/patches.lan.crt;
ssl_certificate_key /patches/server_certs/patches.lan.key;
# Disable client certificate request
ssl_verify_client optional_no_ca;
location /api {
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header Host $http_host;
# Set X-SSL-CERT header with client certificate
proxy_set_header X-SSL-CERT $ssl_client_escaped_cert;
proxy_pass https://patches-backend:9000;
}
location / {
proxy_set_header Host $http_host;
# Set X-SSL-CERT header with client certificate
proxy_set_header X-SSL-CERT $ssl_client_escaped_cert;
proxy_pass http://patches-frontend:3000;
}
}
すべてがそうしなければなりません。 nginxコンテナからバックエンドまでDNS名のカールを確認しました。
root@87c91993cab5:/# curl patches-backend:9000
curl: (52) Empty reply from server
これはそうすべきです。しかし、確認してみるとpodman inspect patches-backend
次のようになります。
...SNIP...
"Networks": {
"host-bridge-net": {
"EndpointID": "",
"Gateway": "10.89.0.1",
"IPAddress": "10.89.0.120",
"IPPrefixLen": 24,
"IPv6Gateway": "",
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"MacAddress": "3e:c9:de:23:44:a6",
"NetworkID": "host-bridge-net",
"DriverOpts": null,
"IPAMConfig": null,
"Links": null,
"Aliases": [
"e9485d2c8cf7"
]
}
}
...SNIP...
patch-backend は明らかに 10.89.0.120 ですが、nginx の文脈でどういうわけかそのホスト名を10.89.0.117
ネットワークのどこにも存在しないホスト名で解決します (ログに見られるように)。
私はこれがどのように起こったのか分からない。 nginx設定にはIPの代わりにホスト名があるため、どこかにハードコーディングされたIPではなく、上記のようにコマンドラインで解決するとpatches-backend
nginxコンテナが正しく解決されます。しかし、nginxプロセスは存在しないIPアドレスを取得しました。私のコンテナにはIP 117はありません。
# Reverse search 10.89.0.117 (the wrong IP) across all containers
[grant@patches2 opt]$ podman inspect -f '{{.Name}}' $(podman ps -a -q --format='{{.ID}}') | xargs -I {} sh -c 'podman inspect -f "{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}" {} | grep -w 10.89.0.117 && echo Container: {}'
# Reverse search 10.89.0.120 (the correct IP) across all containers
[grant@patches2 opt]$ podman inspect -f '{{.Name}}' $(podman ps -a -q --format='{{.ID}}') | xargs -I {} sh -c 'podman inspect -f "{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}" {} | grep -w 10.89.0.120 && echo Container: {}'
10.89.0.120
Container: patches-backend
どのようにこれが起こるか想像することはできませんし、簡単な例として再現することもできません。 nginxには追加の設定が適用されないことに注目する価値があります。これが唯一の構成です。
答え1
簡単に答えると、nginx
ほとんどの場合、構成がロードされている間にnginx
DNS解決がキャッシュされ、再起動すると、DNSキャッシュがフラッシュされ、新しいIPアドレスを取得するか、TTLが期限切れになるまで待つことができます。
一つあるhttps://serverfault.comは良い答えを提供しますより良い説明とヒントを使用すると、DNSリゾルバーとnginx
変数を使用して各要求に対して新しい検索を実行できます。