☰

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 的偉大指點

就我而言，我嘗試在 KVM 主機上使用 cloud-init 和靜態 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]

然後令我驚訝的是，在創建虛擬機器期間，該介面正在請求 DHCP 租用（journalctl是你的朋友）前cloud-init 配置實際上會根據我的靜態設定啟動並配置介面（與所描述的 OP 完全相同）

大約一分鐘後，「神秘」的 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目錄包含一個介面定義，用於ens3在模式下配置它dhcp！

所以現在我知道意外的 dhcp 請求來自哪裡，接下來的問題是禁用它，因為它與/etc/network/interfaces.d/50-cloud-init.cfg.

不幸的是，禁用初始 dhcp 請求發生在 cloud-init 啟動之前，因此實際上沒有簡單的方法可以防止 dhclient 浪費寶貴的一分鐘左右來嘗試獲得永遠不會出現的報價。

不過，我能夠完成的是透過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 進程，然後刪除最初ens3在 dhcp 模式下設定的介面定義文件，最後將介面ens3重新啟動，這將應用設定的內容像/etc/network/interfaces.d/50-cloud-init.cfg冠軍​​一樣。

這樣，初始啟動過程中的後續 cloud-init 階段現在就可以透過名稱完全存取網路了。這對於後續階段（例如packages:阻止成功）至關重要，因為它需要 DNS 來解析 apt 儲存庫伺服器名稱。

以下是更詳細的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-template在寫入 cloud-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 腳本（首先掛載虛擬機存儲，刪除腳本，然後卸載）：

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

相關內容