Den følgende artikel taler lidt om cloud-init og de problemer, den har, og hvordan open source ikke nødvendigvis betyder frihed. Hvis du vil bruge cloud-init til at konfigurere cloud-billeder, skal du bare rulle ned til punkt nummer 3.

1. Hvad det gør?

Har du nogensinde spekuleret på, hvordan VPS-udbydere konfigurerer dine virtuelle computere, tilføjer dine SSH-nøgler, opretter brugere og installerer pakker hver gang du spinder op til en ny VM i 'skyen'? Nå, svaret for de fleste leverandører er cloud-init. De fleste operativsystemer og distributioner sender virtuelle diskbilleder med deres respektive operativsystemer installeret i billedet. Installationen er meget minimal og kan fungere som en skabelon til operativsystemets rodfilsystem. OS-vedligeholdere er også venlige nok til at give det virtuelle diskbillede til alle de forskellige formater fra rå diskbilleder til qcow2 og endda vmdk, vdi og vhd.

Billedet har også en ekstra pakke forudinstalleret, og det er cloud-init. Det er jobbet med cloud-init til initialisere VM (typisk inden for en cloudhostingtjeneste som DigitalOcean, AWS eller Azure) taler med hostingudbyderens datakilde og få de konfigurationsoplysninger, som den derefter bruger til at konfigurere VM.

Konfigurationsoplysningerne kan omfatte brugerdata som SSH-nøgler, værtsnavn for forekomsten, brugere og adgangskoder sammen med enhver anden vilkårlig kommando, som brugeren ønsker at køre.

2. Problemet med Cloud-Init

Cloud-init er et godt værktøj, hvis du er en skybruger, hvis du spinder VM'er eller containere, og din skyudbyder er venlig nok til at bede dig om en cloud-config, det er fantastisk! Med en cloud-config-fil, alias dine brugerdata, kan du tilføje brugere, køre vilkårlige kommandoer, installere pakker lige når VM oprettes. Processen kan gentages igen og igen uden at kedelige kommandoer skrives igen og igen. Snart har du en flåde af virtuelle computere, alle med identisk konfiguration.

Men hvis du graver lidt dybere og ser, hvordan pølsen fremstilles, begynder du at stille spørgsmålstegn ved nogle af cloud-init's aspekter. For eksempel er datakilden som standard som et REST-slutpunkt, og disse er i det væsentlige hårdkodede i selve cloud-init-pakken. Sikker på, du kan oprette en datakilde helt alene, men processen er uheldig og tidskrævende. Dokumentationen til at gøre dette er alt andet end ikke-eksisterende.

Den officielle dokumentation er intet andet end en brugervejledning til slutbrugere, der er afhængige af allerede eksisterende cloudtjenester. Det fortæller dig ikke, hvordan du kan konfigurere din egen cloud-init-datakilde, hvis du er en kommende leverandør. Selv slutbrugerdokumentationen er dårlig, og jeg vil anbefale folk, der bruger DigitalOceans fremragende tutorial i stedet.

For at gøre tingene værre, har brugere med hjemmevirtualiseringslaboratorier og lille VPS-opstart det vanskeligt at drage fordel af disse lette skybilleder. Du kan ikke rigtig starte en VM fra disse skabeloner uden en cloud-init-datakilde eller noget hackery, som er vanskeligt at automatisere og skalere. Med andre ord kan du ikke engang vælge at ignorere cloud-init, medmindre du vil lave dine egne skabeloner.

På en klassisk systemd måde bryder den sig fri fra sine foruddefinerede roller, og det begynder at rode med netværk og andre dele af operativsystemet, der smider brugerne af. Det bliver samlet i Ubuntu 18.04 server ISO, der giver absolut ingen mening (i det mindste ikke for mig).

3. Løsning til hjemmelaboratorier

Hele ranting til side er jeg stadig nødt til at beskæftige mig med cloud-init i min daglige brug. Jeg har en meget minimal Debian 9-installation på x86_64-hardware, som jeg bruger som en KVM-hypervisor. Jeg ville virkelig bruge de qcow2 diskbilleder, der sendes af Ubuntu og CentOS. Disse diskbilleder har operativsystemet forudinstalleret i dem, og for at bruge dem skal du blot:

1. Kopier dem som din virtuelle computers virtuelle harddiskbillede.
2. Tilpas rodfilsystemets virtuelle størrelse til den ønskede størrelse (mindst 10 GB anbefales). Dette vil ikke øge den fysiske størrelse på din VM, men diskbilledet kan vokse over tid, da VM tilføjer flere data til den.
3. Konfigurer VM'erne ved hjælp af cloud-init. Det absolutte minimumskrav er at indstille rootbrugerens adgangskode eller SSH-nøgler, men du kan gøre stort set alt, hvad cloud-init er i stand til.

Følgende trin følges:

1. Download skybilledet af dit foretrukne operativsystem, og gem det i / var / lib / libvirt / boot-biblioteket:

$ cd / var / lib / libvirt / boot
$ curl -O https: // cloud-images.ubuntu.com / xenial / nuværende / xenial-server-cloudimg-
amd64-disk1.img
$ cd / var / lib / libvirt / billeder

2. Opret en tom virtuel harddisk i den ønskede størrelse, og udvid det downloadede qcow2-billede til det. Jeg kan godt lide at gemme VM-harddiske på / var / lib / libvirt / images / directory, du kan vælge en anden mappe. Uanset hvad du vælger, skal du køre nedenstående kommandoer i samme bibliotek:

$ qemu-img opret -f qcow2 myVM.qcow2 8G ## Opret en harddisk med
virtuel diskstørrelse på 8 GB
$ virt-resize - udvid / dev / sda1 / var / lib / libvirt / boot / xenial-server-
cloudimg-amd64-disk1.img
./ myVM.qcow2

3. Opret cloud-init-filer. Disse er brugerdata og metadatafiler:

$ vim metadata
instans-id: myVM
lokalt værtsnavn: myVM

$ vim brugerdata
# cloud-config
brugere:
- navn: rod
chpasswd:
liste: |
rod: myPassword
udløbe: Falsk

Den eneste bruger, jeg har her, er rodbrugeren. Hvis du ikke nævner nogen bruger, er standardbrugeren med navn ubuntu bliver skabt. Standardbrugernavnet adskiller sig fra et operativsystem til et andet, hvorfor jeg anbefaler at specificere en bruger, selvom det bare er rod. Den næste del af brugerdatafilen fortæller cloud-init at konfigurere adgangskoden til alle de brugere, du vil tildele en adgangskode. Igen indstiller jeg bare adgangskoden til bare rodbruger, og det er det myPassword. Sørg for, at der ikke er noget mellemrum mellem kolon og adgangskodestreng.

Bedre endnu, du kan bruge SSH-nøgler i stedet for at have hardkodede adgangskoder, der ligger rundt.

$ vim brugerdata
# cloud-config
brugere:
- navn: rod
ssh_pwauth: Sandt
ssh_authorized_keys:
- ssh-rsa

4. Integrer brugerdata og metadatafiler i en iso.

$ genisoimage -output cidata-myVM.iso -volid cidata -joliet -rock bruger-data metadata

Sørg for, at filen cidata-myVM.iso er beliggende i / var / lib / libvirt / images /

5. Gå til kataloget / var / lib / libvirt / images og initialiser VM med virt-install-kommandoen: $ virt-install --import --navn myVM --memory 2048 --vcpus 2 --cpu host
   --disk myVM.qcow2, format = qcow2, bus = virtio - disk myVM-cidata.iso, enhed = cdrom
   --netværksbro = virbr0, model = virtio --os-type = linux
   --os-variant = ubuntu16.04 - ingen autokonsol

   Du kan nu prøve at logge på VM ved hjælp af kommandoen virsh console myVM og bruge rodbrugernavnet og dets tilsvarende adgangskode til login. For at forlade konsollen skal du blot skrive Ctrl +]

Konklusion

Skybillederne, som de fleste leverandører sender, er virkelig effektive med hensyn til ressourceudnyttelse, og de føler sig også rigtig hurtige og lydhøre. Det faktum, at vi skal håndtere den akavede cloud-init-konfiguration som udgangspunkt, forhindrer kun samfundets vedtagelse af KVM og relaterede teknologier.

Samfundet kan lære meget af den måde, Docker bygger og sender sine billeder på. De er virkelig nemme at administrere både som kørende containere og skabeloner, der er lette at distribuere og bruge.z