Il seguente articolo parla un po 'di cloud-init e dei problemi che ha e come open source non significa necessariamente la libertà. Se si desidera utilizzare Cloud-Init per configurare le immagini cloud, basta scorrere verso il basso fino al punto numero 3.

1. Cosa fa?

Mi sono mai chiesto come i provider VPS configuino le tue macchine virtuali, aggiungono i tuoi SSH-Keys, crea utenti e installa pacchetti ogni volta che si gira una nuova VM nel "cloud"? Bene, la risposta per la maggior parte dei venditori è cloud-init. La maggior parte dei sistemi operativi OS e distribuzioni spedisce le immagini del disco virtuale con i rispettivi sistemi operativi installati nell'immagine. L'installazione è molto minima e può fungere da modello per il filesystem root del sistema operativo. I manutentori del sistema operativo sono anche abbastanza gentili da fornire l'immagine del disco virtuale per tutti i vari formati dalle immagini del disco grezzo a QCOW2 e persino VMDK, VDI e VHD.

L'immagine ha anche un pacchetto extra preinstallato e questo è il cloud. È il lavoro di cloud-init a inizializzare La VM (in genere all'interno di un servizio di hosting cloud come DigitalOcean, AWS o Azure) parla con il provider di hosting fonte di dati e ottenere le informazioni di configurazione che utilizza quindi per configurare la VM.

Le informazioni sulla configurazione possono includere dati utente Come le chiavi SSH, il nome host dell'istanza, gli utenti e le password insieme a qualsiasi altro comando arbitrario che l'utente desidera eseguire.

Il problema con il cloud-init

Cloud-Init è un ottimo strumento se sei un utente cloud, se stai girando VM o contenitori e il tuo provider cloud è abbastanza gentile da chiederti un cloud-config, è fantastico! Con un file cloud-config aka i tuoi dati utente puoi aggiungere utenti, eseguire comandi arbitrari, installare pacchetti direttamente man mano che la VM viene creata. Il processo può essere ripetuto più e più volte senza comandi noiosi più e più volte. Presto hai una flotta di macchine virtuali, tutte con una configurazione identica.

Tuttavia, se scavi un po 'più a fondo e vedi come viene fatta la salsiccia, inizierai a mettere in discussione alcuni degli aspetti di Cloud-Init. Ad esempio, per impostazione predefinita, il dati dati è come un endpoint di riposo e questi sono essenzialmente codificati nel pacchetto di Init Cloud stesso. Certo, puoi impostare una bottega di dati da solo, ma il processo è intenso con il tempo. La documentazione per farlo è quasi inesistente.

La documentazione ufficiale non è altro che un manuale dell'utente per gli utenti finali che si basano sui servizi cloud preesistenti. Non ti dice come è possibile configurare la tua boxeurce cloud-init, nel caso in cui tu sia un fornitore in arrivo. Anche la documentazione dell'utente finale è scarsa e consiglierei invece le persone che usano l'eccellente tutorial di DigitalOcean.

A peggiorare le cose, gli utenti con laboratori di virtualizzazione domestica e la startup dei piccoli VP hanno difficoltà a beneficiare di quelle immagini cloud leggere. Non puoi davvero avviare una VM da quei modelli senza un dati dati iniziale o qualche hackery che è difficile da automatizzare e ridimensionare. In altre parole, non puoi nemmeno scegliere di ignorare il cloud-init a meno che tu non voglia creare i tuoi modelli.

In modo classico Systemd, si sta liberando dai suoi ruoli predefiniti e inizia a fare casino con il networking e altre parti del sistema operativo che butta via gli utenti. Viene bambolato all'interno di Ubuntu 18.04 Server ISO che non ha assolutamente senso (almeno non per me).

Soluzione alternativa per i laboratori domestici

A parte il rant, devo ancora affrontare il cloud-init nel mio uso quotidiano. Ho un'installazione Debian 9 Minimal Minimal su hardware x86_64, che uso come hypervisor KVM. Volevo davvero usare le immagini del disco QCOW2 che vengono spedite da Ubuntu e CentOS. Queste immagini del disco hanno il sistema operativo preinstallato in esse e per usarle è semplicemente necessario:

1. Copiali come immagine del disco rigido virtuale della tua VM.
2. Ridimensiona la dimensione virtuale del filesystem root alla dimensione desiderata (si consiglia almeno 10 GB). Ciò non aumenterà la dimensione fisica della VM ma l'immagine del disco può crescere nel tempo poiché la VM aggiunge più dati ad essa.
3. Configurare le VM utilizzando il cloud-init. Il requisito minimo indispensabile è impostare la password dell'utente root o le chiavi SSH, ma puoi fare abbastanza tutto ciò che Cloud-Init è in grado.

Vengono seguiti i seguenti passaggi:

1. Scarica l'immagine cloud del tuo sistema operativo preferito e salvala nella directory/var/lib/libvirt/boot:

$ cd/var/lib/libvirt/boot
$ curl -o https: // cloud -images.Ubuntu.com/xenial/corrente/xenial-server-cloudimg-
AMD64-Disk1.img
$ cd/var/lib/libvirt/immagini

2. Crea un disco rigido virtuale vuoto della dimensione desiderata ed espandi l'immagine QCOW2 scaricata in essa. Mi piace archiviare i dischi rigidi VM AT/var/lib/libvirt/immagini/directory, puoi scegliere una directory diversa. Qualunque cosa tu scelga, esegui i comandi seguenti nella stessa directory:

$ QEMU -IMG Crea -f Qcow2 myvm.QCOW2 8G ## Crea un hardsk con
Dimensione del disco virtuale di 8 GB
$ Virt-Resize-Expand/Dev/SDA1/Var/Lib/Libvirt/Boot/Xenial-Server-
Cloudimg-AMD64-Disk1.img
./myvm.QCOW2

3. Crea file cloud-init. Questi sono file di dati utente e meta-dati:

$ Vim Meta-Data
ID istanza: myvm
HostName locale: myvm

$ VIM USER-DATA
#Cloud-Config
utenti:
- Nome: root
chpasswd:
Elenco: |
Radice: MyPassword
scadenza: falso

L'unico utente che ho qui è l'utente root. Se non si menziona alcun utente, l'utente predefinito con il nome Ubuntu viene creato. Il nome utente predefinito, differisce da un sistema operativo all'altro, motivo per cui ti consiglio di specificare un utente, anche se è giusto radice. La parte successiva del file dei dati utente indica a Cloud-Init di configurare la password per tutti gli utenti che si desidera assegnare una password. Ancora una volta, sto solo impostando la password per l'utente solo root, e lo è la mia password. Assicurati che non ci sia spazio tra il colon e la stringa password.

Meglio ancora, puoi usare SSH-Keys invece di avere password con codice rigido.

$ VIM USER-DATA
#Cloud-Config
utenti:
- Nome: root
ssh_pwauth: vero
ssh_authorized_keys:
- SSH-RSA

4. Incorpora i file di dati utente e meta-dati in un ISO.

$ Genisoimage -Output CIDATA -MYVM.ISO -Volid Cidata -joliet -Rock -Data -Data -Data

Assicurati che il file cidata-myvm.ISO è situato in/var/lib/libvirt/immagini/

5. Vai alla directory/var/lib/libvirt/immagini e inizializza la VM con comando virt-install:

   $ virt-install --import --name myvm-memory 2048 --vcpus 2-cpu host
   --disco myvm.QCOW2, Format = QCOW2, Bus = Virtio-Disk myvm-cidata.iso, dispositivo = cdrom
   --Network Bridge = VirBr0, Model = virtio --os-type = Linux
   --os-variant = ubuntu16.04 --Noautoconsole

   Ora puoi provare a accedere alla VM utilizzando la console Virsh di comando myvm e utilizzando il nome utente root e la sua password corrispondente per accedere. Per uscire dalla console, digita semplicemente ctrl+]

Conclusione

Le immagini cloud che la maggior parte dei venditori spediscono sono davvero efficienti in termini di utilizzo delle risorse e si sentono anche molto veloci e reattive. Il fatto che dobbiamo affrontare la configurazione imbarazzante del cloud-init come punto di partenza ostacola solo l'adozione da parte della comunità di KVM e le tecnologie correlate.

La comunità può imparare molto dal modo in cui Docker costruisce e spedisce le sue immagini. Sono davvero facili da gestire sia come contenitori in esecuzione che come facili da distribuire e utilizzare.z