☰

Debian 10 cloud-init は静的ネットワーク構成で起動時に DHCP を待機します

tag-icon • tag-icon debian cloud-init
Debian 10 cloud-init は静的ネットワーク構成で起動時に DHCP を待機します

build-openstack-debian-image --release busterで作成された cloud-init イメージを使用して、Debian 10 Buster イメージ ( で作成) を実行していますcloud-localds -v --disk-format raw --filesystem iso9660 --network-config=network-config-v2.yaml seed.img user-data.yaml。

問題は、有効なネットワーク構成があり、この遅延後に適用されているにもかかわらず、DHCP を待つことによって起動が遅延されることです。

[    3.619937] cloud-init[210]: Cloud-init v. 20.2 running 'init-local' at Sun, 10 Jan 2021 10:50:20 +0000. Up 3.40 seconds.
[  OK  ] Started Initial cloud-init job (pre-networking).
[  OK  ] Reached target Network (Pre).
         Starting Raise network interfaces...
[  OK  ] Started ifup for eth0.
[     *] A start job is running for Raise network interfaces (35s / 5min 1s)

この遅延を回避するにはどうすればいいでしょうか?

必要であれば、さらに情報を提供できます。ありがとうございます。

# systemd-analyze blame
     1min 2.639s networking.service
           951ms cloud-init-local.service
           773ms cloud-init.service
           657ms cloud-final.service
           540ms cloud-config.service
           421ms dev-vda1.device
           310ms ifupdown-pre.service

私のnetwork-config-v2.yaml：

version: 2
renderer: networkd
ethernets:
  eth0:
    match:
      name: e*
    addresses:
      - private.ipv4/24
      - public.ipv4/32
      - ipv6/64
    gateway4: private.ipv4
    routes:
      - to: 0.0.0.0/0
        via: private.ipv4
    gateway6: ipv6
    nameservers:
      addresses:
        - ipv4
        - ipv6
      search: [domain.com]

答え1

@zany による素晴らしいアドバイス

私の場合、cloud-initとKVMホスト上の静的IPを使用してDebian 11汎用クラウドイメージを設定しようとしていました（dmacvicar libvirt Terraformプロバイダーを使用）

私のネットワーク設定ファイルは次のとおりです:

version: 2
ethernets:
  ens3:
    dhcp4: false
    addresses: [10.1.0.100]
    gateway4: 10.1.0.1
    nameservers:
      addresses: [10.1.0.1 1.1.1.1]
      search: [home.lab]

その後、VMの作成中にインターフェースがDHCPリースを要求していることに驚きました（これjournalctlはあなたの友達です）前にcloud-init config が実際に起動し、静的設定に従ってインターフェースを構成します (OP が説明したとおり)

1 分ほど経つと、「謎の」dhclient はオファーを待つのをあきらめ (libvirt ネットワークでは DHCP が無効になっているため、これは予想どおりでした)、バックグラウンドで実行されたままになりました。その後、ブート シーケンスが続行されてcloud-init起動し、正しい静的構成が にレンダリングされます/etc/network/interfaces.d/50-cloud-init.cfg。その時点で、インターフェイスは予想どおりの静的 IP を取得します ( がip address showそれを証明し、IP で ping することもできます)。ただし、DNS 解決は壊れたままです。これは dhclient の失敗による副作用だと思います。

調べてみると/etc/network/interfaces、ファイルはソース化に加えて、source-directory /etc/network/interfaces.d追加のディレクトリもソース化していることがわかりました/run/network/interfaces.d/。驚いたことに、そのディレクトリには、モードで構成されている/runインターフェイス定義が含まれています。ens3dhcp

予期しない DHCP 要求がどこから来ているのかがわかったので、正しい設定と競合していたため、それを無効にするだけで済みました/etc/network/interfaces.d/50-cloud-init.cfg。

残念ながら、初期の DHCP 要求の無効化は cloud-init が起動する前に行われるため、決して来ないオファーを取得しようとして dhclient が貴重な 1 分ほどを無駄にすることを防ぐ簡単な方法はありません。

しかし、私が達成できたのは、次のbootcmd:ブロックを使用してDNS解決を修正することでした。user-data

bootcmd:
  - cloud-init-per once down ifdown ens3
  - cloud-init-per once bugfix rm /run/network/interfaces.d/ens3
  - cloud-init-per once up ifup ens3

上記のコマンドでは、インターフェイスをダウンさせて休止状態の dhclient プロセスを停止し、最初にens3dhcp モードに設定されているインターフェイス定義ファイルを削除し、最後にインターフェイスを再びアップさせて、 like a champ でens3設定された内容を適用しています。/etc/network/interfaces.d/50-cloud-init.cfg

これにより、初期ブート プロセスのその後の cloud-init ステージは、名前でインターネットに完全にアクセスできるようになりました。これは、packages:apt リポジトリ サーバー名を解決するために DNS が機能する必要があったため、ブロックなどの後のステージが成功するために重要でした。

より詳細なuser-data抜粋は次のとおりです。

bootcmd:
  - cloud-init-per once ifdown ifdown ens3
  - cloud-init-per once bugfix rm /run/network/interfaces.d/ens3
  - cloud-init-per once ifup ifup ens3

packages:
  - qemu-guest-agent
  - locales-all

package_update: true
package_upgrade: true
package_reboot_if_required: true

runcmd:
  - [ systemctl, start, qemu-guest-agent ]

final_message: "The system is finally up, after $UPTIME seconds"

Debian10 を使用していないにもかかわらず、この問題は非常によく知られているように思われたので、新しいリリースでこの問題に遭遇した場合に備えて、私の経験を共有しようと思いました。

参考文献:

答え2

サンプルの問題が発生しました。静的ネットワーク構成 (NoCloud プロバイダー メタデータ ENI、またはネットワーク構成 v1/v2) を使用しても、DHCP クライアントが無効になりません。

/etc/network/cloud-interfaces-templatecloud-init 構成が書き込まれる前に、テンプレート ( ) からネットワーク構成が適用されているようです。

auto $INTERFACE
allow-hotplug $INTERFACE

iface $INTERFACE inet dhcp

最初の起動前にクラウド イメージを変更することで、このテンプレートが原因であるかどうかをテストできます
(たとえば、ネットワーク構成を変更すると、イメージにパッチを適用するのbootcmdが遅すぎます)。

qemu-nbd --connect=/dev/nbd0 /tmp/debian-10-genericcloud-amd64-20210208-542.qcow2
fdisk /dev/nbd0 -l
mkdir /tmp/nbd
mount /dev/nbd0p1 /tmp/nbd
sed -i 's/dhcp/manual/' /tmp/nbd/etc/network/cloud-interfaces-template
umount /tmp/nbd
rmdir /tmp/nbd
qemu-nbd --disconnect /dev/nbd0

ただし、この変更を適用する方法、または cloud-init でこのテンプレートが使用されないようにする方法をまだ見つける必要があります。

そのテンプレートは によって処理されているような/etc/network/cloud-ifupdown-helperので、スクリプトが変更されたり、影響を受けたりする可能性があります。

答え3

私も同じ問題に遭遇しました。

これを解決するより良い方法は、DHCP タイムアウトを短い時間に設定することです。

# virt-edit debian-10-generic-amd64.qcow2 /etc/dhcp/dhclient.conf

timeout 15;

その後、このイメージは NoCloud 環境または DHCP ネットワークで正しく機能します。

答え4

agittins による回答が最も良いようですが、私の場合、ユーザー データ ファイル内の cloud-init "bootcmd" コマンドは、debians "75-cloud-ifupdown.rules" の後に処理されました。そのため、ディスク イメージ内のその debian スクリプトを削除する必要がありました (最初に vm ストレージをマウントし、スクリプトを削除してからアンマウントします)。

sudo qemu-nbd --connect=/dev/nbd0 debian-11-genericcloud-arm64-backing.qcow2

sudo mount /dev/nbd0p1 /mnt

sudo rm -v /mnt/etc/udev/rules.d/75-cloud-ifupdown.rules

sudo rm -v /mnt/etc/network/cloud-ifupdown-helper

sudo rm -v /mnt/etc/network/cloud-interfaces-template

sudo umount /mnt

関連情報