Esiste un modo per configurare i contenitori lxd con cloud config al momento del provisioning?


10

In particolare, con gli strumenti della CLI, non si apre.

Sto guardando come potrebbe essere un setup di sviluppo locale con lxd ma sto arrivando a mani vuote quando si tratta di configurare nuovi contenitori.

Esistono modi idiomatici (o meno) per configurare i contenitori lxd? Dovrei guardare qualcosa di più immutabile come le immagini docker?

Grazie. Qualsiasi risorsa o puntatore sarebbe apprezzato.

Risposte:


13

Quindi ci sono diversi modi per farlo, direttamente per un contenitore:

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

O ancora più breve:

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

O attraverso un profilo:

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

Come si possono usare i file .sh invece di .yml? Esiste già un tutorial su questo argomento?
Greg,

Quanto sopra è in riferimento a questa domanda: stackoverflow.com/questions/44456522
Greg

3

Un liner con cui sono andato oggi, questo lo imposta nel profilo predefinito per i nuovi contenitori:

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

Questo lo imposta in un contenitore esistente, ma attenzione che non funzionerà su contenitori già avviati poiché la roba della chiave SSH viene eseguita solo al primo avvio:

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


3

Avevo una domanda leggermente più specifica dell'OP, ma mi ci è voluto un po 'per capire cosa stavo facendo di sbagliato. Ho pensato di pubblicarlo qui per aiutare chiunque altro a rimanere perplesso in modo simile.

Volevo impostazioni di rete statiche per un contenitore Ubuntu 16.04 LXC / LXD ospitato su Ubuntu 16.04. Ho iniziato provando quello che Stéphane ha scritto ma non ha funzionato. Tutto quello che ho scoperto è stato il contenitore di tentativi DHCP predefinito con un collegamento IPv6 locale, poiché nella mia configurazione non è presente alcun DHCP.

Il mio YAML iniziale sembrava (qualcosa) simile al seguente (tratto dai documenti cloud-init ).

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

E lo stavo caricando user.user-datacome descritto sopra.

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

Fu solo quando trovai la documentazione di Stéphane nella fonte LXC / LXD che mi resi conto che dovevo caricare quel valore user.network-config.

Quindi il mio ultimo YAML sembrava (qualcosa) simile a questo.

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

Quindi ho caricato questo in user.network-configinvece.

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

Sembra che dovrò conservare due file diversi per container: uno per caricare le impostazioni di rete user.network-config; e una per le altre configurazioni da caricare a user.user-datameno che non riesca a trovare un modo per utilizzare un singolo file per tutto.


Un altro problema che ho riscontrato e che per me non era affatto ovvio era il tentativo di configurare automaticamente i componenti non di rete.

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

Il seguente YAML applicato con il comando sopra (nonostante abbia un uso corretto lxc config show CONTAINER) non ha creato nulla all'interno del mio contenitore.

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

    Foo
    Bar

    path: /etc/foo.bar

L'indizio sepolto nei formati di input dei dati utente, elemento 5: Cloud Config Data recita:

inizia con "#cloud-config"o "Content-Type: text/cloud-config" Questo contenuto è un dato "config cloud". Vedi gli esempi per un esempio commentato di formati di configurazione supportati.

Non credo che questa documentazione sia molto chiara. Non sono riuscito a far funzionare nulla utilizzando il modulo "Content-Type: text / cloud-config" ma ho trovato che se si inserisce #cloud-configla prima riga, viene analizzato lo YAML. Posso solo supporre che qualcosa non sia del tutto corretto, né la mia comprensione, né la programmazione di qualcuno. Non ha senso per me che YAML hai esplicitamente caricato come valore della chiave user.user-datadovrebbe essere usato come qualcosa di diverso dai dati di configurazione del cloud. Perché altrimenti qualcuno dovrebbe farlo se non è stato concepito per essere la configurazione nuvola, e quindi perché mai un commento (che non ha nemmeno utilizzare la sintassi baracca normale) è necessario ?

Quindi, a parte le sciocchezze, la sintassi per cui ha funzionato user.user-dataè:

#cloud-config

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

      Foo
      Bar

    path: /etc/foo.bar
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.