정적 네트워크 구성으로 부팅 시 DHCP를 기다리는 Debian 10 cloud-init

Question

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]

Answer 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]

그런 다음 VM 생성 중에 인터페이스가 DHCP 임대를 요청한다는 사실에 놀랐습니다. ( journalctlis your friend)~ 전에cloud-init 구성은 실제로 정적 설정에 따라 인터페이스를 시작하고 구성합니다(설명된 OP와 정확히 같습니다).

약 1분 정도 후에 "신비한" dhclient는 제안(내 libvirt 네트워크에서 DHCP가 비활성화되었기 때문에 예상됨)에 대한 대기를 포기하고 백그라운드에서 계속 실행되었습니다. 그런 다음 부팅 순서가 계속 cloud-init진행되어 /etc/network/interfaces.d/50-cloud-init.cfg. 이 시점에서 인터페이스는 예상되는 고정 IP를 얻지만( ip address show이를 증명하고 IP로 핑할 수도 있음) DNS 확인이 중단된 상태로 유지됩니다. 나는 그것이 dhclient 실패의 부작용이라고 생각합니다.

/etc/network/interfaces약간의 조사 후에는 파일을 소싱하는 것 외에도 source-directory /etc/network/interfaces.d추가 디렉토리도 소싱한다는 사실이 밝혀졌습니다 /run/network/interfaces.d/. 놀랍게도 해당 디렉토리에는 모드 에서 구성되는 위치 /run에 대한 인터페이스 정의가 포함되어 있습니다 !ens3dhcp

이제 예상치 못한 DHCP 요청이 어디서 오는지 알았으니 이를 비활성화하는 것이 문제였습니다. .NET의 올바른 설정과 충돌했기 때문입니다 /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 프로세스를 중지하는 인터페이스를 중지한 다음 처음에 dhcp 모드로 설정한 인터페이스 정의 파일을 제거하고 마지막으로 설정된 내용을 적용하는 인터페이스 백업을 ens3가져옵니다. 챔피언처럼 ens3./etc/network/interfaces.d/50-cloud-init.cfg

이를 통해 초기 부팅 프로세스의 후속 cloud-init 단계에서 이제 이름으로 인터넷에 완전히 연결할 수 있게 되었습니다. packages:적절한 repo 서버 이름을 확인하려면 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을 사용하지 않았음에도 불구하고 이 문제는 너무 익숙해서 최신 릴리스에서 이 문제가 발생할 경우를 대비해 내 경험을 공유하고 싶다고 생각했습니다.

참고자료:

• https://cloudinit.readthedocs.io/en/latest/topics/network-config.html#network-configuration
• https://cloudinit.readthedocs.io/en/latest/topics/network-config-format-v2.html
• https://cloudinit.readthedocs.io/en/latest/topics/modules.html#bootcmd
• https://cloudinit.readthedocs.io/en/latest/topics/modules.html#package-update-upgrade-install
• https://cloud.debian.org/images/cloud/bullseye/latest/debian-11-genericcloud-amd64.qcow2

Answer 2

샘플 문제가 발생했습니다. 정적 네트워크 구성(NoCloud 공급자 메타데이터 ENI 또는 network-config 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므로 스크립트가 변경되거나 영향을 받을 수 있습니다.

Answer 3

나는 같은 문제를 만났습니다.

이 문제를 해결하는 더 좋은 방법은 다음과 같습니다. DHCP 시간 초과를 더 짧은 시간으로 설정하면 됩니다.

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

timeout 15;

그러면 이 이미지는 NoCloud 환경이나 DHCP 네트워크에서 올바르게 작동할 수 있습니다.

Answer 4

agittins의 답변이 가장 좋은 것 같지만 제 경우에는 debians "75-cloud-ifupdown.rules" 이후에 처리된 사용자 데이터 파일의 cloud-init "bootcmd" 명령입니다. 그래서 디스크 이미지에서 해당 데비안 스크립트를 제거해야 했습니다(먼저 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