Il seguente articolo parla un po' del cloud-init e dei problemi che ha, e di come l'open source non significhi necessariamente libertà. Se vuoi usare cloud-init per configurare le immagini cloud, scorri verso il basso fino al punto 3.

1. Cosa fa?

Ti sei mai chiesto come i provider VPS configurano le tue VM, aggiungono le tue chiavi SSH, creano utenti e installano pacchetti ogni volta che avvii una nuova VM nel "cloud"? Bene, la risposta per la maggior parte dei fornitori è cloud-init. La maggior parte dei sistemi operativi e delle distribuzioni fornisce immagini di dischi virtuali con i rispettivi sistemi operativi installati nell'immagine. L'installazione è minima e può fungere da modello per il filesystem di root del sistema operativo. I manutentori del sistema operativo sono anche così gentili da fornire l'immagine del disco virtuale per tutti i vari formati dalle immagini del disco raw a qcow2 e persino vmdk, vdi e vhd.

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

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

2. Il problema con Cloud-Init

Cloud-init è un ottimo strumento se sei un utente cloud, se stai avviando VM o container e il tuo provider cloud è così gentile da chiederti una configurazione cloud, è fantastico! Con un file di configurazione cloud, ovvero i tuoi dati utente, puoi aggiungere utenti, eseguire comandi arbitrari, installare pacchetti proprio mentre viene creata la VM. Il processo può essere ripetuto più e più volte senza che vengano digitati comandi noiosi più e più volte. Presto avrai una flotta di VM, tutte con la stessa configurazione.

Tuttavia, se scavi un po 'più a fondo e vedi come viene prodotta la salsiccia, inizierai a mettere in discussione alcuni aspetti di cloud-init. Ad esempio, per impostazione predefinita, l'origine dati è come un endpoint REST e questi sono essenzialmente hardcoded nel pacchetto cloud-init stesso. Certo, puoi impostare un'origine dati da solo, ma il processo è goffo e richiede molto tempo. La documentazione per farlo è quasi inesistente.

La documentazione ufficiale non è altro che un manuale utente per gli utenti finali che si affidano a servizi cloud preesistenti. Non ti dice come puoi configurare la tua origine dati cloud-init, nel caso tu sia un fornitore imminente. Anche la documentazione per l'utente finale è scarsa e consiglierei alle persone di utilizzare invece l'eccellente tutorial di DigitalOcean.

A peggiorare le cose, gli utenti con laboratori di virtualizzazione domestici e piccole startup VPS hanno difficoltà a trarre vantaggio da quelle immagini cloud leggere. Non puoi davvero avviare una VM da quei modelli senza un'origine dati cloud-init o qualche hacker che è difficile da automatizzare e scalare. In altre parole, non puoi nemmeno scegliere di ignorare cloud-init a meno che tu non voglia creare i tuoi modelli.

In un classico modo systemd, si sta liberando dai suoi ruoli predefiniti e inizia a pasticciare con la rete e altre parti del sistema operativo che allontana gli utenti. Viene fornito in bundle all'interno di Ubuntu 18.04 server ISO che non ha assolutamente senso (almeno non per me).

3. Soluzione alternativa per i laboratori domestici

A parte gli sproloqui, devo ancora fare i conti con cloud-init nel mio uso quotidiano. Ho un'installazione Debian 9 molto minimale su hardware x86_64, che uso come hypervisor KVM. Volevo davvero usare le immagini del disco qcow2 fornite da Ubuntu e CentOS. Queste immagini disco hanno il sistema operativo preinstallato e per utilizzarle è sufficiente:

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

Si seguono 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/current/xenial-server-cloudimg-
amd64-disk1.img
$ cd /var/lib/libvirt/images

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

$ qemu-img create -f qcow2 miaVM.qcow2 8G ## Crea un disco rigido 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 di inizializzazione cloud. Questi sono file di dati utente e metadati:

$ metadati vim
id-istanza: myVM
nome host locale: myVM

$ vim user-data
#cloud-config
utenti:
- nome: radice
chpasswd:
lista: |
root:myPassword
scadono: Falso

L'unico utente che ho qui è l'utente root. Se non menzioni alcun utente, allora l'utente predefinito con nome ubuntu viene creato. Il nome utente predefinito differisce da un sistema operativo all'altro, motivo per cui consiglio di specificare un utente, anche se è solo radice. La parte successiva del file user-data dice a cloud-init di configurare la password per tutti gli utenti a cui vuoi assegnare una password. Ancora una volta, sto solo impostando la password solo per l'utente root, ed è così la mia password. Assicurati che non ci siano spazi tra i due punti e la stringa della password.

Meglio ancora, puoi usare le chiavi SSH invece di avere password hardcoded in giro.

$ vim user-data
#cloud-config
utenti:
- nome: radice
ssh_pwauth: Vero
ssh_authorized_keys:
- ssh-rsa

4. Incorpora i file di dati utente e metadati in un'iso.

$ genisoimage -output cidata-myVM.iso -volid cidata -joliet -rock metadati dati utente

Assicurati che il file cidata-myVM.iso si trova in /var/lib/libvirt/images/

5. Vai alla directory /var/lib/libvirt/images e inizializza la VM con il 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
   --bridge di rete=virbr0,model=virtio --os-type=linux
   --os-variant=ubuntu16.04 --noautoconsole

   Ora puoi provare ad accedere alla VM usando il comando virsh console myVM e usando il nome utente di root e la sua password corrispondente per accedere. Per uscire dalla console, digita semplicemente Ctrl+]

Conclusione

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

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