私のコンテナでresolv.confのリロードをどのようにトリガーできますか？

Question

起動時にコンテナを実行すると、systemd-resolvedがDHCPを使ってデフォルトから更新した前に、resolv.confを使用していた人がいました。これは、起動後に早すぎて起動したコンテナが何も解決できず、適切なDNS設定を使用するために再起動する必要があることを意味していました。これはrktとDockerの両方のさまざまな理由で起こっています。コンテナ内のresolv.confを更新するDockerの方法はnot compatible with the overlay filesystem driverであり、systemd-resolvedはファイルをインプレースで更新しない（むしろ一時ファイルを作成して名前を変更する）ため、rktのバインドマウントはコンテナが見るものを更新しません。

現在、私は、docker.serviceと自分のrktポッドが依存するnetwork-online.targetを遅延させるために、ハックされたsystemd.unitを使用しています。

[Unit] 
Description=Wait for DNS 

[Service] 
Type=oneshot 
RemainAfterExit=true 
ExecStart=/bin/sh -c 'while ! getent ahosts google.com >dev/null; do sleep 1; done' 

[Install] 
WantedBy=network-online.target 

しかし、これはかなり私の起動時間

# systemd-analyze blame 
     18.068s wait-for-dns.service 
     ... 

を遅延させたresolv.confが再び変更された場合、それは助けにはなりません。だから、私の問題に対してより洗練された解決策があるのか​​どうか疑問に思っていました。 Idealy私はrktとDockerの両方のコンテナでresolv.confの更新をトリガできるようにしたいと思います。

Answer 1

user defined networkでコンテナを実行し、embedded DNS serverを使用してシステムDNSにルックアップを転送します。

デフォルトのdocker0ブリッジには、従来のサポートのために残されたいくつかの特別なルールがあります。マウントされた/etc/resolv.confを使用することは、それらの遺産の1つです。

rktが同じタイプのDNSをサポートしていない場合、一般的な解決方法はUnboundのようなDNSサーバをlocal forwarding resolverに設定することです。次に、コンテナには参照する静的DNSサーバーがあります。