Het volgende artikel gaat een beetje over cloud-init en de problemen die het heeft, en hoe open source niet per se vrijheid betekent. Als u cloud-init wilt gebruiken om cloud-afbeeldingen te configureren, scrolt u gewoon naar beneden naar punt 3.

1. Wat het doet?

Heb je je ooit afgevraagd hoe VPS-providers je VM's configureren, je SSH-sleutels toevoegen, gebruikers aanmaken en pakketten installeren telkens wanneer je een nieuwe VM in de 'cloud' opstart? Welnu, het antwoord voor de meeste leveranciers is cloud-init. De meeste besturingssystemen en distributies leveren virtuele schijfkopieën met hun respectieve besturingssystemen geïnstalleerd in de afbeelding. De installatie is zeer minimaal en kan dienen als een sjabloon voor het rootbestandssysteem van het besturingssysteem. De beheerders van het besturingssysteem zijn ook zo vriendelijk om de virtuele schijfkopie te leveren voor alle verschillende formaten, van onbewerkte schijfkopieën tot qcow2 en zelfs vmdk, vdi en vhd.

De afbeelding heeft ook een extra pakket vooraf geïnstalleerd en dat is cloud-init. Het is de taak van cloud-init om initialiseren de VM (meestal binnen een cloudhostingservice zoals DigitalOcean, AWS of Azure) praat met de hostingprovider databron en krijg de configuratie-informatie die het vervolgens gebruikt om de VM te configureren.

De configuratie-informatie kan omvatten: gebruikersgegevens zoals SSH-sleutels, hostnaam van de instantie, gebruikers en wachtwoorden samen met elk ander willekeurig commando dat de gebruiker wil uitvoeren.

2. Het probleem met Cloud-Init

Cloud-init is een geweldige tool als je een cloudgebruiker bent, als je VM's of containers aan het draaien bent en je cloudprovider zo vriendelijk is om je om een ​​cloudconfiguratie te vragen, is het geweldig! Met een cloudconfiguratiebestand, oftewel uw gebruikersgegevens, kunt u gebruikers toevoegen, willekeurige opdrachten uitvoeren en pakketten installeren terwijl de VM wordt gemaakt. Het proces kan steeds opnieuw worden herhaald zonder dat vervelende commando's steeds opnieuw worden getypt. Binnenkort heb je een vloot van VM's, allemaal met identieke configuratie.

Als je echter wat dieper graaft en ziet hoe de worst wordt gemaakt, begin je enkele aspecten van cloud-init in twijfel te trekken. De gegevensbron is bijvoorbeeld standaard een REST-eindpunt en deze zijn in wezen hard gecodeerd in het cloud-init-pakket zelf. Natuurlijk kun je helemaal zelf een gegevensbron opzetten, maar het proces is omslachtig en tijdrovend. De documentatie om dit te doen is vrijwel onbestaande non.

De officiële documentatie is niets anders dan een gebruikershandleiding voor eindgebruikers die vertrouwen op reeds bestaande cloudservices. Het vertelt u niet hoe u uw eigen cloud-init-gegevensbron kunt opzetten, voor het geval u een opkomende leverancier bent. Zelfs de documentatie voor de eindgebruiker is slecht, en ik zou mensen aanraden om in plaats daarvan de uitstekende tutorial van DigitalOcean te gebruiken.

Om het nog erger te maken, vinden gebruikers met thuisvirtualisatielabs en kleine VPS-startups het moeilijk om te profiteren van die lichtgewicht cloud-images. Je kunt niet echt een VM starten met die sjablonen zonder een cloud-init-gegevensbron of een hacker die moeilijk te automatiseren en te schalen is. Met andere woorden, u kunt er niet eens voor kiezen om cloud-init te negeren, tenzij u uw eigen sjablonen wilt maken.

Op een klassieke systemd-manier breekt het los van zijn vooraf gedefinieerde rollen en begint het te knoeien met netwerken en andere delen van het besturingssysteem, waardoor gebruikers worden afgeschrikt. Het wordt gebundeld in Ubuntu 18.04 server ISO wat absoluut geen zin heeft (althans niet voor mij).

3. Tijdelijke oplossing voor thuislabs

Afgezien van al het geraas, heb ik nog steeds te maken met cloud-init in mijn dagelijks gebruik. Ik heb een zeer minimale Debian 9-installatie op x86_64-hardware, die ik gebruik als een KVM-hypervisor. Ik wilde echt de qcow2-schijfkopieën gebruiken die worden geleverd door Ubuntu en CentOS. Op deze schijfkopieën is het besturingssysteem vooraf geïnstalleerd en om ze te gebruiken, hoeft u alleen maar:

1. Kopieer ze als de virtuele harde schijf-image van uw VM.
2. Verklein de virtuele grootte van het rootbestandssysteem naar de gewenste grootte (minimaal 10 GB wordt aanbevolen). Dit zal de fysieke grootte van uw VM niet vergroten, maar de schijfkopie kan in de loop van de tijd groeien naarmate de VM er meer gegevens aan toevoegt.
3. Configureer de VM's met cloud-init. De absolute minimumvereiste is om het wachtwoord van de rootgebruiker of SSH-sleutels in te stellen, maar je kunt vrijwel alles doen waar cloud-init toe in staat is.

De volgende stappen worden gevolgd:

1. Download de cloud-image van je favoriete besturingssysteem en sla het op in de /var/lib/libvirt/boot directory:

$ 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. Maak een lege virtuele harde schijf van de gewenste grootte en vouw de gedownloade qcow2-afbeelding erin uit. Ik sla de VM-harde schijven graag op in /var/lib/libvirt/images/ map, je kunt een andere map kiezen. Wat je ook kiest, voer de onderstaande opdrachten uit in dezelfde map:

$ qemu-img create -f qcow2 mijnVM.qcow2 8G ## Maak een harde schijf met
virtuele schijfgrootte van 8 GB
$ virt-resize --expand /dev/sda1 /var/lib/libvirt/boot/xenial-server-
cloudimg-amd64-disk1.img
./mijnVM.qcow2

3. Cloud-init-bestanden maken. Dit zijn gebruikersgegevens en metagegevensbestanden:

$ vim-metagegevens
instantie-ID: mijnVM
local-hostname: mijnVM

$ vim gebruikersgegevens
#cloud-config
gebruikers:
- naam: wortel
chpasswd:
lijst: |
root:mijnWachtwoord
vervallen: False

De enige gebruiker die ik hier heb, is de rootgebruiker. Als u geen enkele gebruiker vermeldt, dan is de standaardgebruiker met naam ubuntu wordt gemaakt. De standaard gebruikersnaam verschilt van het ene besturingssysteem tot het andere, daarom raad ik aan om een ​​gebruiker op te geven, ook al is het maar wortel. Het volgende deel van het gebruikersgegevensbestand vertelt cloud-init om het wachtwoord te configureren voor alle gebruikers waaraan u een wachtwoord wilt toewijzen. Nogmaals, ik stel gewoon het wachtwoord in voor alleen root-gebruiker, en het is mijn wachtwoord. Zorg ervoor dat er geen spatie is tussen de dubbele punt en de wachtwoordreeks.

Beter nog, je kunt SSH-sleutels gebruiken in plaats van hardgecodeerde wachtwoorden te hebben liggen.

$ vim gebruikersgegevens
#cloud-config
gebruikers:
- naam: wortel
ssh_pwauth: True
ssh_authorized_keys:
- ssh-rsa

4. Sluit de gebruikersgegevens en metagegevensbestanden in een iso.

$ genisoimage -output cidata-myVM.iso -volid cidata -joliet -rock gebruikersgegevens meta-gegevens

Zorg ervoor dat het bestand cidata-myVM.iso bevindt zich in /var/lib/libvirt/images/

5. Ga naar de map /var/lib/libvirt/images en initialiseer de VM met het virt-install commando: $ virt-install --import --name myVM --memory 2048 --vcpus 2 --cpu host
   --schijf mijnVM.qcow2,format=qcow2,bus=virtio --disk myVM-cidata.iso,apparaat=cdrom
   --netwerk bridge=virbr0,model=virtio --os-type=linux
   --os-variant=ubuntu16.04 --noautoconsole

   Je kunt nu proberen in te loggen op de VM door het commando virsh console myVM te gebruiken en de root gebruikersnaam en het bijbehorende wachtwoord te gebruiken om in te loggen. Om de console te verlaten, typt u gewoon Ctrl+]

Conclusie

De cloudafbeeldingen die de meeste leveranciers leveren, zijn erg efficiënt in het gebruik van hulpbronnen en voelen ook erg snel en responsief aan. Het feit dat we moeten omgaan met de lastige cloud-init-configuratie als uitgangspunt, belemmert alleen de acceptatie van KVM en gerelateerde technologieën door de gemeenschap.

De community kan veel leren van de manier waarop Docker zijn afbeeldingen bouwt en verzendt. Ze zijn heel gemakkelijk te beheren, zowel als actieve containers als sjablonen die gemakkelijk te distribueren en te gebruiken zijn.z