Gibt es eine Möglichkeit, lxd-Container zur Bereitstellungszeit mit Cloud-Konfiguration zu konfigurieren?

Insbesondere mit den CLI-Tools - nicht Openstack.

Ich schaue mir an, wie ein lokales Entwickler-Setup mit lxd aussehen könnte, aber ich bin leer, wenn es darum geht, neue Container zu konfigurieren.

Gibt es idiomatische (oder andere) Möglichkeiten, lxd-Container zu konfigurieren? Sollte ich etwas Unveränderlicheres wie Docker-Bilder betrachten?

Vielen Dank. Alle Ressourcen oder Hinweise wäre dankbar.

Es gibt also mehrere Möglichkeiten, dies entweder direkt für einen Container zu tun:

lxc init ubuntu: CONTAINER
lxc config set CONTAINER user.user-data - < cloud-init-config.yml
lxc start CONTAINER

Oder noch kürzer:

lxc launch ubuntu: CONTAINER --config=user.user-data="$(cat cloud-init-config.yml)"

Oder über ein Profil:

lxc profile create dev
lxc profile set dev user.user-data - < cloud-init-config.yml
lxc launch ubuntu: CONTAINER -p default -p dev

Ein Liner, mit dem ich heute gefahren bin, setzt diesen in das Standardprofil für neue Container:

echo -e "#cloud-config\nssh_authorized_keys:\n - $(cat ~/.ssh/id_rsa.pub)" | lxc profile set default user.user-data -

Dieser setzt es in einen vorhandenen Container, aber Vorsicht, es funktioniert nicht bei Containern, die bereits gestartet wurden, da der SSH-Schlüssel nur beim ersten Start ausgeführt wird:

echo -e "#cloud-config\nssh_authorized_keys:\n - $(cat ~/.ssh/id_rsa.pub)" | lxc config set CONTAINER_NAME user.user-data -

Ich hatte eine etwas spezifischere Frage als das OP, aber es dauerte eine Weile, bis ich herausgefunden hatte, was ich falsch gemacht hatte. Ich dachte, ich würde es hier posten, um allen anderen zu helfen, ähnlich ratlos zu werden.

Ich wollte statische Netzwerkeinstellungen für einen LXC / LXD Ubuntu 16.04-Container, der auf Ubuntu 16.04 gehostet wird. Ich habe zunächst versucht, was Stéphane geschrieben hat, aber es hat nicht funktioniert. Am Ende hatte ich nur den Standardcontainer für DHCP-Versuche mit einer lokalen IPv6-Verbindung, da in meiner Konfiguration kein DHCP bereitgestellt wird.

Meine anfängliche YAML sah (so) wie folgt aus (entnommen aus den Cloud-Init- Dokumenten).

network:
  version: 1
  config:
    - type: physical
      name: eth0
      subnets:
        - type: static
          address: 192.168.23.14/27
          gateway: 192.168.23.1
          dns_nameservers:
            - 192.168.23.2
            - 8.8.8.8
          dns_search:
            - exemplary.maas

Und ich habe dies user.user-datawie oben beschrieben geladen.

lxc config set CONTAINER user.user-data - < CONTAINER.cloud-init-config.yml

Erst als ich Stéphanes Dokumentation in der LXC / LXD-Quelle fand , wurde mir klar, dass ich diesen Wert laden musste user.network-config.

Mein letztes YAML sah also so aus.

version: 1
config:
  - type: physical
    name: eth0
    subnets:
      - type: static
        address: 192.168.23.14/27
        gateway: 192.168.23.1
        dns_nameservers:
          - 192.168.23.2
          - 8.8.8.8
        dns_search:
          - exemplary.maas

Dann habe ich dies user.network-configstattdessen geladen .

lxc config set CONTAINER user.network-config - < CONTAINER.network-config.yaml

Es scheint, als müsste ich zwei verschiedene Dateien pro Container aufbewahren: eine, in die die Netzwerkeinstellungen geladen werden können user.network-config; und eine für die andere Konfiguration, in die geladen werden user.user-datakann, es sei denn, ich kann einen Weg finden, eine einzelne Datei für alles zu verwenden.

Ein weiteres Problem, das mir überhaupt nicht klar war, war der Versuch, Nicht-Netzwerkkomponenten automatisch zu konfigurieren.

lxc config set CONTAINER user.user-data - < CONTAINER.user-data.yaml

Die folgende YAML, die mit dem obigen Befehl angewendet wurde (obwohl sie korrekt verwendet wurde lxc config show CONTAINER), hat nichts in meinem Container erstellt.

write_files:
  - content: |
    # My new /etc/foo.bar file

    Foo
    Bar

    path: /etc/foo.bar

Der in Benutzerdaten-Eingabeformaten, Punkt 5: Cloud-Konfigurationsdaten, vergrabene Hinweis lautet:

beginnt mit "#cloud-config"oder "Content-Type: text/cloud-config" Dieser Inhalt ist "Cloud-Konfigurations" -Daten. In den Beispielen finden Sie ein kommentiertes Beispiel für unterstützte Konfigurationsformate.

Ich glaube nicht, dass diese Dokumentation sehr klar ist. Ich konnte mit dem Formular "Inhaltstyp: Text / Cloud-Konfiguration" nichts zum Laufen bringen, aber ich habe #cloud-configfestgestellt, dass die YAML analysiert wird , wenn Sie in die erste Zeile setzen . Ich kann nur annehmen, dass etwas nicht ganz stimmt, weder mein Verständnis noch die Programmierung von jemandem. Für mich macht es keinen Sinn, dass YAML, das Sie explizit als Wert des Schlüssels geladen haben user.user-data, als etwas anderes als Cloud-Konfigurationsdaten verwendet werden sollte. Warum sollte das sonst jemand tun, wenn es sich nicht um eine Cloud-Konfiguration handeln sollte, und warum sollte daher ein Kommentar (der nicht einmal die normale Shebang-Syntax verwendet) erforderlich sein ?

Abgesehen vom Unsinn ist die Syntax, für die funktioniert hat, user.user-dataalso:

#cloud-config

write_files:
  - content: |
      # My new /etc/foo.bar file

      Foo
      Bar

    path: /etc/foo.bar