Cloud-Init mit Flatcar Linux – Konfiguration wird beim Übergeben einer benutzerdefinierten Datei nicht angewendet?

Cloud-Init mit Flatcar Linux – Konfiguration wird beim Übergeben einer benutzerdefinierten Datei nicht angewendet?

Ich benutzeTelmatesTerraform-Anbieter fürProxmoxund versuchen,FlachwagenLinux virtuelle Maschinen mitCloud Initdurch Übergabe von Dateien überAbonnieren. Basierend auf ihrenBeispiel, ich habe die folgende Terraform-Datei erstellt:

variable "pve_user" {
}
variable "pve_password" {
}
variable "pve_host" {
}

provider "proxmox" {
  pm_tls_insecure = true
  pm_api_url      = "https://SNIP/api2/json"
  pm_user         = "SNIP"
  pm_password     = "SNIP"
  pm_parallel     = 4
}

resource "null_resource" "cloud_init_config_files" {
  connection {
    type     = "ssh"
    user     = var.pve_user
    password = var.pve_password
    host     = var.pve_host
  }

  provisioner "file" {
    source      = "./templates/cloud-config.yml"
    destination = "/var/lib/vz/snippets/cloud-config.yml"
  }
}

resource "proxmox_vm_qemu" "k8s-masters" {
  depends_on = [
    null_resource.cloud_init_config_files
  ]

  count      = 1
  name       = "VM-${count.index}"
  clone      = "VM-Template"
  full_clone = true

  target_node = "192.168.20.10"
  pool        = "VM"

  cores   = 2
  sockets = 1
  memory  = 10240

  network {
    id     = 0
    model  = "virtio"
    bridge = "vmbr0"
    tag    = 50
  }

  disk {
    id           = 0
    type         = "scsi"
    size         = 30
    storage      = "Pool"
    storage_type = "zfspool"
    backup       = true
    iothread     = true
  }

  onboot = true
  agent  = 1

  os_type         = "cloud-init"
  ssh_user        = "core"
  cicustom  = "user=local:snippets/cloud-config.yml"
  ipconfig0 = "ip=192.168.50.10/24,gw=192.168.50.1"

  sshkeys = "ssh-rsa SNIP"
  ssh_private_key = <<EOF
-----BEGIN RSA PRIVATE KEY-----
SNIP
-----END RSA PRIVATE KEY-----
EOF
}

Nach dem Ausführen terraform applywird die VM erfolgreich erstellt und Flatcar wird gebootet. Wenn Sie sich jedoch über Proxmox mit der Konsole verbinden, zeigt die VM an, dass die IP-Adresse eine über DHCP empfangene ist und nicht die, die ich angegeben habe. Darüber hinaus funktioniert der SSH-Schlüssel nicht, sodass ich keine Verbindung zur VM herstellen kann, um das Problem zu beheben.

Wenn ich die Zeile auskommentiere cicustomund mich einfach auf ipconfig0die anderen normalen Optionen verlasse, wird die VM gestartet und mein SSH-Schlüssel funktioniert tatsächlich. Die angegebene IP-Adresse wird jedoch immer noch nicht verwendet. Die VM verwendet stattdessen einfach eine von DHCP bereitgestellte. Obwohl ich auf die VM zugreifen kann, möchte ich dennoch eine benutzerdefinierte Cloud Init-Konfigurationsdatei verwenden, damit ich Zugriff auf leistungsfähigere Konfigurationsoptionen habe.

Ich habe verschiedene Kombinationen meiner cloud-config.ymlDatei ausprobiert. Darunter so einfache Dinge wie:

hostname: test

zu detaillierteren Dingen wie:

storage:
  files:
    - path: /opt/file1
      filesystem: root
      contents:
        inline: Hello, world!
      mode: 0644
      user:
        id: 500
      group:
        id: 501
passwd:
  users:
    - name: core
      ssh_authorized_keys:
        - ssh-rsa SNIP

Trotz alledem funktionieren meine SSH-Schlüssel nie, nachdem ich etwas übergeben habe cicustom, und da der Hostname nie manipuliert wird, gehe ich davon aus, dass Cloud Init die benutzerdefinierte Konfigurationsdatei überhaupt nicht empfängt. Ich habe versucht, beides zu übergebenIgnition und Container Linux Configformatierte Dateien.

Ist Flatcar Linux mit Proxmox/cicustom kaputt? Wenn man bei Google nach Dingen wie "flatcar" "proxmox", "coreos" "proxmox", "container linux" "proxmox", "flatcar" "cicustom", usw. sucht, scheint man nicht viele Ergebnisse zu bekommen. Ich schätze, es gibt nicht viele Leute da draußen, die Cloud Native-Betriebssysteme mit Bare Metal verbinden? hehehe

Was jedoch herauskommt, istdieses interessante Skript. In den Zeilen 104-132 wird die Erstellung einer Flatcar/CoreOS-Vorlage für Proxmox beschrieben. Hat das also schon mal jemand gemacht? Wer weiß, ob er anschließend eine benutzerdefinierte Cloud-Init-Konfigurationsdatei übergeben hat?

Irgendwelche Ideen?

BEARBEITEN: ------------------------------------------------------------

Protokolle von der Systemd-Einheit hinzugefügt, user-configdrivewenn sie nicht übergeben werdencicustom

Aug 20 16:22:17 localhost coreos-cloudinit[831]: 2020/08/20 16:22:17 Checking availability of "cloud-drive"
Aug 20 16:22:17 localhost coreos-cloudinit[831]: 2020/08/20 16:22:17 Fetching user-data from datasource of type "cloud-drive"
Aug 20 16:22:17 localhost coreos-cloudinit[831]: 2020/08/20 16:22:17 Attempting to read from "/media/configdrive/openstack/latest/user_data"
Aug 20 16:22:17 localhost coreos-cloudinit[831]: 2020/08/20 16:22:17 line 6: warning: unrecognized key "chpasswd"
Aug 20 16:22:17 localhost coreos-cloudinit[831]: 2020/08/20 16:22:17 line 9: warning: incorrect type for "users[0]" (want struct)
Aug 20 16:22:17 localhost coreos-cloudinit[831]: 2020/08/20 16:22:17 line 10: warning: unrecognized key "package_upgrade"
Aug 20 16:22:17 localhost coreos-cloudinit[831]: 2020/08/20 16:22:17 Fetching meta-data from datasource of type "cloud-drive"
Aug 20 16:22:17 localhost coreos-cloudinit[831]: 2020/08/20 16:22:17 Attempting to read from "/media/configdrive/openstack/latest/meta_data.json"
Aug 20 16:22:17 localhost coreos-cloudinit[831]: 2020/08/20 16:22:17 Attempting to read from "/media/configdrive/openstack/content/0000"
Aug 20 16:22:17 localhost coreos-cloudinit[831]: 2020/08/20 16:22:17 Parsing user-data as cloud-config
Aug 20 16:22:17 localhost coreos-cloudinit[831]: 2020/08/20 16:22:17 Merging cloud-config from meta-data and user-data
Aug 20 16:22:17 VM-0 coreos-cloudinit[831]: 2020/08/20 16:22:17 Set hostname to VM-0
Aug 20 16:22:17 VM-0 coreos-cloudinit[831]: 2020/08/20 16:22:17 Authorized SSH keys for core user
Aug 20 16:22:17 VM-0 coreos-cloudinit[831]: 2020/08/20 16:22:17 Failed to apply cloud-config: Invalid option to manage_etc_hosts
Aug 20 16:22:17 VM-0 systemd[1]: user-configdrive.service: Main process exited, code=exited, status=1/FAILURE

BEARBEITEN 2: ----------------------------------------------------------

Der Inhalt der von der obigen Systemd-Einheit referenzierten Dateien wurde hinzugefügt.

core@VM-0 ~ $ cat /media/configdrive/openstack/latest/user_data
#cloud-config
hostname: VM-0
manage_etc_hosts: true
ssh_authorized_keys:
  - REDACTED
chpasswd:
  expire: False
users:
  - default
package_upgrade: true

Wie Sie angemerkt haben, manage_etc_hostswird es hier von Proxmox auf „true“ gesetzt.

core@VM-0 ~ $ cat /media/configdrive/openstack/content/0000
auto lo
iface lo inet loopback

        dns_nameservers 192.168.1.100
        dns_search example.com
auto eth0
iface eth0 inet static
        address 192.168.50.10
        netmask 255.255.255.0
        gateway 192.168.50.1

Dieser Abschnitt enthält die gesamte korrekte Netzwerkkonfiguration, wird jedoch vollständig von DHCP überschrieben und daher ignoriert.

core@VM-0 ~ $ cat /media/configdrive/openstack/latest/meta_data.json
{
     "uuid": "e61563c9057e9162c4e14d111fea171379170532",
     "network_config": { "content_path": "/content/0000" }
}

BEARBEITEN 3: ----------------------------------------------------------

Mein Versuch einer benutzerdefinierten Cloud-Init-Datei wurde hinzugefügt

manage_etc_hosts: false
hostname: "test"
ssh_authorized_keys:
  - REDACTED

BEARBEITEN 4: ----------------------------------------------------------

ich folgtedieser Leitfadenum im Grunde dasselbe direkt mit qemu zu erreichen, anstatt Proxmox zu verwenden. Mit:

Das cloud-config.ign:

{
  "ignition": { "version": "2.2.0" },
  "passwd": {
    "users": [
      {
        "name": "core",
        "sshAuthorizedKeys": [
          "REDACTED"
        ]
      }
    ]
  },
  "storage": {
    "files": [{
      "filesystem": "root",
      "path": "/etc/hostname",
      "mode": 420,
      "contents": { "source": "data:,test" }
    }]
  }
}

Oder dieses cloud-config.yml:

hostname: test
passwd:
  users:
    - name: tj
      ssh_authorized_keys:
        - REDACTED

beide führen zum selben Ergebnis: Eine nicht verbindbare virtuelle Maschine, die mit dem Hostnamen hochfährt localhost.

  • Hiersind die Protokolle, die mit erstellt wurden cloud-config.ign.
  • Hiersind die Protokolle, die mit erstellt wurden cloud-config.yml.

BEARBEITEN 5: ----------------------------------------------------------

Diese Protokolle werden erstellt, user-configdrive.servicewenn der Provider von Telmate mit einer Flatcar-Vorlage verwendet wird.

Aug 21 21:41:50 localhost coreos-cloudinit[795]: 2020/08/21 21:41:50 Checking availability of "cloud-drive"
Aug 21 21:41:50 localhost coreos-cloudinit[795]: 2020/08/21 21:41:50 Fetching user-data from datasource of type "cloud-drive"
Aug 21 21:41:50 localhost coreos-cloudinit[795]: 2020/08/21 21:41:50 Attempting to read from "/media/configdrive/openstack/latest/user_data"
Aug 21 21:41:50 localhost coreos-cloudinit[795]: 2020/08/21 21:41:50 Fetching meta-data from datasource of type "cloud-drive"
Aug 21 21:41:50 localhost coreos-cloudinit[795]: 2020/08/21 21:41:50 Attempting to read from "/media/configdrive/openstack/latest/meta_data.json"
Aug 21 21:41:50 localhost coreos-cloudinit[795]: 2020/08/21 21:41:50 Attempting to read from "/media/configdrive/openstack/content/0000"
Aug 21 21:41:50 localhost coreos-cloudinit[795]: Detected an Ignition config. Exiting...
Aug 21 21:41:50 localhost systemd[1]: Started Load cloud-config from /media/configdrive.

BEARBEITEN 6: ----------------------------------------------------------

Hierist das gesamte Systemd-Journal aus der ersten Ausgabe nach der Verwendung cloud-config.ignin EDIT 4 mit dem Provider von Telmate.

BEARBEITEN 7: ----------------------------------------------------------

Diese qmBefehle erzeugen eine funktionierende Flatcar-VM mit cicustom.

qm create 101 --name test --cores 2 --memory 2048 --net0 "virtio,bridge=vmbr0"

qm set 101 --net0 "virtio,bridge=vmbr0,tag=50"

qm importdisk 101 /mnt/RAIDPool_Templates/template/iso/flatcar_production_qemu_image.img FlashPool

qm set 101 --scsihw virtio-scsi-pci --scsi0 FlashPool:vm-101-disk-0 --ide2 FlashPool:cloudinit --boot c --bootdisk scsi0 --serial0 /dev/tty0 --ipconfig0 ip=dhcp --citype configdrive2

qm set 101 --cicustom user=RAIDPool_Templates:snippets/user-data.yml

qm start 101
ssh -i ~/.ssh/sol.milkyway.kubernetes [email protected]

Benutzerdaten.yml:

#cloud-config
hostname: test
manage_etc_hosts: true
ssh_authorized_keys:
  - ssh-rsa REDACTED
chpasswd:
  expire: False
users:
  - default
package_upgrade: true

Die Weitergabe desselben user-data.ymlinnerhalb cicustomder proxmox_vm_qemuRessource scheint jedoch nicht zu funktionieren.

verwandte Informationen