nginxコンテナネットワークDNSが無効なIPアドレスで解決されます。

nginxコンテナネットワークDNSが無効なIPアドレスで解決されます。

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-backendnginxコンテナが正しく解決されます。しかし、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ほとんどの場合、構成がロードされている間にnginxDNS解決がキャッシュされ、再起動すると、DNSキャッシュがフラッシュされ、新しいIPアドレスを取得するか、TTLが期限切れになるまで待つことができます。

一つあるhttps://serverfault.comは良い答えを提供しますより良い説明とヒントを使用すると、DNSリゾルバーとnginx変数を使用して各要求に対して新しい検索を実行できます。

関連情報