Följande artikel talar lite om moln-init och de problem den har, och hur öppen källkod inte nödvändigtvis betyder frihet. Om du vill använda moln-init för att konfigurera molnbilder, bläddrar du bara ner till punkt nummer 3.

1. Vad den gör?

Har du någonsin undrat hur VPS-leverantörer konfigurerar dina virtuella datorer, lägger till dina SSH-nycklar, skapar användare och installerar paket varje gång du snurrar upp en ny virtuell dator i "molnet"? Svaret för de flesta leverantörer är cloud-init. De flesta operativsystem och distributioner skickar virtuella diskbilder med respektive operativsystem installerade i bilden. Installationen är mycket minimal och kan fungera som en mall för operativsystemets rotfilsystem. OS-underhållarna är också snälla för att tillhandahålla den virtuella skivavbildningen för alla olika format från rå skivbilder till qcow2 och till och med vmdk, vdi och vhd.

Bilden har också ett extra paket förinstallerat och det är molninit. Det är jobbet för moln-init till initialisera VM (vanligtvis inom en molntjänst som DigitalOcean, AWS eller Azure) pratar med värdleverantörens datakälla och få konfigurationsinformationen som den sedan använder för att konfigurera den virtuella datorn.

Konfigurationsinformationen kan inkludera användardata som SSH-nycklar, värdnamn för instansen, användare och lösenord tillsammans med alla andra godtyckliga kommandon som användaren vill köra.

2. Problemet med Cloud-Init

Cloud-init är ett bra verktyg om du är molnanvändare, om du snurrar upp virtuella datorer eller behållare och din molnleverantör är snäll nog att be dig om en molnkonfiguration, det är fantastiskt! Med en molnkonfigurationsfil aka din användardata kan du lägga till användare, köra godtyckliga kommandon, installera paket direkt när den virtuella datorn skapas. Processen kan upprepas om och om igen utan att tråkiga kommandon skrivs om och om igen. Snart har du en maskinpark, alla med identisk konfiguration.

Men om du gräver lite djupare och ser hur korven görs kommer du att börja ifrågasätta några av moln-init aspekter. Till exempel är datakällan som en REST-slutpunkt som standard och dessa är i huvudsak hårdkodade i själva moln-init-paketet. Visst, du kan ställa in en datakälla helt själv, men processen är lycklig och tidskrävande. Dokumentationen för att göra detta är nästan obefintlig.

Den officiella dokumentationen är inget annat än en användarmanual för slutanvändare som förlitar sig på redan befintliga molntjänster. Det berättar inte för dig hur du kan konfigurera din egen moln-init-datakälla, om du är en kommande leverantör. Till och med slutanvändardokumentationen är dålig, och jag skulle rekommendera människor som använder DigitalOceans utmärkta handledning istället.

För att göra saken värre har användare med hemvirtualiseringslaboratorier och liten VPS-start svårt att dra nytta av de lätta molnbilderna. Du kan inte riktigt starta en virtuell dator av dessa mallar utan en moln-init-datakälla eller något hackery som är svårt att automatisera och skala. Med andra ord kan du inte ens välja att ignorera moln-init om du inte vill skapa dina egna mallar.

På ett klassiskt systemd-sätt bryter det sig loss från sina fördefinierade roller och det börjar röra med nätverk och andra delar av operativsystemet som kastar bort användare. Det buntas i Ubuntu 18.04-server-ISO vilket inte ger någon mening (åtminstone inte för mig).

3. Lösning för hemlaboratorier

Bortsett från att jag rantar åt sidan måste jag fortfarande hantera moln-init i min vardagliga användning. Jag har en mycket minimal installation av Debian 9 på hårdvara x86_64, som jag använder som en KVM-hypervisor. Jag ville verkligen använda qcow2 diskbilder som levereras av Ubuntu och CentOS. Dessa diskbilder har operativsystemet förinstallerat i dem, och för att använda dem behöver du helt enkelt:

1. Kopiera dem som din virtuella virtuella hårddiskavbildning.
2. Ändra storlek på rotfilsystemets virtuella storlek till önskad storlek (minst 10 GB rekommenderas). Detta ökar inte den fysiska storleken på din virtuella dator men skivavbildningen kan växa över tiden eftersom den virtuella datorn lägger till mer data till den.
3. Konfigurera virtuella datorer med moln-init. Det minsta kravet är att ställa in root-användarens lösenord eller SSH-nycklar, men du kan göra allt som moln-init kan.

Följande steg följs:

1. Ladda ner molnbilden för ditt favorit OS och spara den i katalogen / var / lib / libvirt / boot:

$ cd / var / lib / libvirt / boot
$ curl -O https: // molnbilder.ubuntu.com / xenial / current / xenial-server-cloudimg-
amd64-disk1.img
$ cd / var / lib / libvirt / images

2. Skapa en tom virtuell hårddisk av önskad storlek och expandera den nedladdade qcow2-bilden till den. Jag gillar att lagra VM-hårddiskarna i / var / lib / libvirt / images / katalog, du kan välja en annan katalog. Oavsett vad du väljer kör du kommandona nedan i samma katalog:

$ qemu-img skapa -f qcow2 myVM.qcow2 8G ## Skapa en hårddisk med
virtuell diskstorlek på 8 GB
$ virt-resize - expand / dev / sda1 / var / lib / libvirt / boot / xenial-server-
cloudimg-amd64-disk1.img
./ myVM.qcow2

3. Skapa moln-init-filer. Dessa är användardata- och metadatafiler:

$ vim metadata
instans-id: myVM
lokalt värdnamn: myVM

$ vim användardata
# cloud-config
användare:
- namn: root
chpasswd:
lista: |
root: myPassword
upphör: Falskt

Den enda användaren jag har här är rotanvändaren. Om du inte nämner någon användare är standardanvändaren med namn ubuntu blir skapad. Standard användarnamnet skiljer sig från ett operativsystem till ett annat, varför jag rekommenderar att du anger en användare, även om det bara är rot. Nästa del av användardatafilen ber cloud-init att konfigurera lösenordet för alla användare du vill tilldela ett lösenord. Återigen ställer jag bara in lösenordet för bara root-användare, och det är det mitt lösenord. Se till att det inte finns något utrymme mellan kolon och lösenordsträng.

Bättre än, du kan använda SSH-nycklar istället för att ha hårdkodade lösenord som ligger runt.

$ vim användardata
# cloud-config
användare:
- namn: root
ssh_pwauth: Sant
ssh_authorized_keys:
- ssh-rsa

4. Bädda in användardata och metadatafiler i en iso.

$ genisoimage -output cidata-myVM.iso -volid cidata -joliet -rock användardata metadata

Se till att filen cidata-myVM.iso ligger i / var / lib / libvirt / images /

5. Gå till katalogen / var / lib / libvirt / images och initialisera den virtuella datorn med virt-install-kommandot: $ virt-install --import --name myVM --memory 2048 --vcpus 2 --cpu host
   --disk myVM.qcow2, format = qcow2, bus = virtio - disk myVM-cidata.iso, enhet = cdrom
   --nätverksbro = virbr0, modell = virtio --os-type = linux
   --os-variant = ubuntu16.04 - ingen autokonsol

   Du kan nu försöka logga in på den virtuella datorn med kommandot virsh console myVM och använda root-användarnamnet och dess motsvarande lösenord för att logga in. För att lämna konsolen, skriv helt enkelt Ctrl +]

Slutsats

Molnbilderna som de flesta leverantörer levererar är verkligen effektiva när det gäller resursutnyttjande och de känns också riktigt snabba och lyhörda. Det faktum att vi måste hantera den obekväma moln-init-konfigurationen som utgångspunkt hindrar bara samhällets antagande av KVM och relaterad teknik.

Gemenskapen kan lära sig mycket av hur Docker bygger och skickar sina bilder. De är väldigt enkla att hantera både som körcontainrar och mallar som är lätta att distribuera och använda.z