Den følgende artikkelen snakker litt om cloud-init og problemene den har, og hvordan åpen kildekode ikke nødvendigvis betyr frihet. Hvis du vil bruke sky-init til å konfigurere skybilder, er det bare å bla ned til punkt nummer 3.

1. Hva det gjør?

Har du noen gang lurt på hvordan VPS-leverandører konfigurerer virtuelle maskiner, legger til SSH-nøkler, oppretter brukere og installerer pakker hver gang du spinner opp en ny VM i 'skyen'? Svaret for de fleste leverandører er cloud-init. De fleste operativsystemer og distribusjoner sender virtuelle diskbilder med deres respektive operativsystemer installert i bildet. Installasjonen er veldig minimal og kan fungere som en mal for operativsystemets rotfilsystem. OS-vedlikeholdere er også snille nok til å gi det virtuelle diskbildet for alle de forskjellige formatene fra rå diskbilder til qcow2 og til og med vmdk, vdi og vhd.

Bildet har også en ekstra pakke forhåndsinstallert, og det er cloud-init. Det er jobben til sky-init til initialisere VM (vanligvis innenfor en cloud hosting-tjeneste som DigitalOcean, AWS eller Azure) snakker med vertsleverandørens datakilde og få konfigurasjonsinformasjonen som den deretter bruker til å konfigurere VM.

Konfigurasjonsinformasjonen kan inkludere brukerdata som SSH-nøkler, vertsnavn for forekomsten, brukere og passord sammen med andre vilkårlige kommandoer som brukeren vil kjøre.

2. Problemet med Cloud-Init

Cloud-init er et flott verktøy hvis du er en skybruker, hvis du snurrer opp virtuelle maskiner eller containere og skyleverandøren din er snill nok til å be deg om en cloud-config, det er flott! Med en cloud-config-fil som brukerdataene dine, kan du legge til brukere, kjøre vilkårlige kommandoer, installere pakker akkurat når VM blir opprettet. Prosessen kan gjentas igjen og igjen uten at kjedelige kommandoer blir skrevet om og om igjen. Snart har du en flåte med virtuelle maskiner, alle med identisk konfigurasjon.

Men hvis du graver litt dypere og ser hvordan pølsen lages, vil du begynne å stille spørsmål ved noen av sky-init-aspektene. For eksempel er datakilden som standard som et REST-sluttpunkt, og disse er egentlig hardkodet i selve skyinitpakken. Visst, du kan sette opp en datakilde alene, men prosessen er heldig og tidskrevende. Dokumentasjonen for å gjøre dette er alt annet enn fraværende.

Den offisielle dokumentasjonen er ikke annet enn en brukerhåndbok for sluttbrukere som stoler på allerede eksisterende skytjenester. Det forteller deg ikke hvordan du kan konfigurere din egen datakilde for cloud-init, i tilfelle du er en kommende leverandør. Selv sluttbrukerdokumentasjonen er dårlig, og jeg vil anbefale folk som bruker DigitalOceans utmerkede opplæring i stedet.

For å gjøre saken verre, har brukere med hjemmevirtualiseringslaboratorier og liten VPS-oppstart vanskelig å dra nytte av de lette skybildene. Du kan egentlig ikke starte en VM av disse malene uten en cloud-init datakilde eller noe hackery som er vanskelig å automatisere og skalere. Med andre ord, du kan ikke engang velge å ignorere cloud-init med mindre du vil lage dine egne maler.

På en klassisk systemd måte bryter den seg fra sine forhåndsdefinerte roller, og den begynner å rote med nettverk og andre deler av operativsystemet som kaster brukere av. Det blir samlet i Ubuntu 18.04 server ISO som gir absolutt ingen mening (i det minste ikke for meg).

3. Løsning for hjemmelaboratorier

Alt ranting til side, jeg må fortsatt håndtere sky-init i min daglige bruk. Jeg har en veldig minimal Debian 9-installasjon på x86_64-maskinvare, som jeg bruker som en KVM-hypervisor. Jeg ønsket virkelig å bruke qcow2-diskbildene som sendes av Ubuntu og CentOS. Disse diskbildene har operativsystemet forhåndsinstallert, og for å bruke dem trenger du bare å:

1. Kopier dem som den virtuelle harddiskbildet til den virtuelle maskinen.
2. Endre størrelsen på rotfilsystemets virtuelle størrelse til ønsket størrelse (minst 10 GB anbefales). Dette vil ikke øke den fysiske størrelsen på den virtuelle maskinen, men diskbildet kan vokse over tid ettersom den virtuelle maskinen legger til mer data til den.
3. Konfigurer virtuelle maskiner ved hjelp av cloud-init. Minimumskravet er å angi root-brukerens passord eller SSH-nøkler, men du kan gjøre stort sett alt som cloud-init er i stand til.

Følgende trinn følges:

1. Last ned skybildet til ditt favoritt OS og lagre det i katalogen / var / lib / libvirt / boot:

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

2. Lag en tom virtuell harddisk av ønsket størrelse og utvid det nedlastede qcow2-bildet til det. Jeg liker å lagre VM-harddiskene i / var / lib / libvirt / images / katalog, du kan velge en annen katalog. Uansett hva du velger, kjør kommandoene nedenfor i samme katalog:

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

3. Lag sky-init-filer. Dette er brukerdata og metadatafiler:

$ vim metadata
forekomst-id: myVM
lokalt vertsnavn: myVM

$ vim brukerdata
# cloud-config
brukere:
- navn: rot
chpasswd:
liste: |
rot: myPassword
utløper: Falsk

Den eneste brukeren jeg har her er rotbrukeren. Hvis du ikke nevner noen bruker, er standardbrukeren med navn ubuntu blir opprettet. Standard brukernavn, er forskjellig fra ett operativsystem til et annet, og derfor anbefaler jeg å spesifisere en bruker, selv om det bare er rot. Den neste delen av brukerdatafilen ber cloud-init om å konfigurere passordet for alle brukerne du vil tilordne et passord. Igjen, jeg setter bare passordet for bare rotbruker, og det er det mitt passord. Forsikre deg om at det ikke er noe mellomrom mellom kolon og passordstreng.

Enda bedre, du kan bruke SSH-nøkler i stedet for å ha hardkodede passord som ligger rundt.

$ vim brukerdata
# cloud-config
brukere:
- navn: rot
ssh_pwauth: Sant
ssh_authorized_keys:
- ssh-rsa

4. Legge inn brukerdata og metadatafiler i en iso.

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

Forsikre deg om at filen cidata-myVM.iso ligger i / var / lib / libvirt / images /

5. Gå til katalogen / var / lib / libvirt / images og initialiser VM med virt-install kommando: $ virt-install --import --name myVM --memory 2048 --vcpus 2 --cpu host
   --disk myVM.qcow2, format = qcow2, buss = virtio - disk myVM-cidata.iso, enhet = cdrom
   --nettverksbro = virbr0, modell = virtio --os-type = linux
   --os-variant = ubuntu16.04 - ingen autokonsoll

   Du kan nå prøve å logge på VM ved å bruke kommandoen virsh console myVM og bruke rotbrukernavnet og dets tilhørende passord for å logge på. For å avslutte konsollen, skriv Ctrl +]

Konklusjon

Skybildene som de fleste leverandører sender, er veldig effektive når det gjelder ressursutnyttelse, og de føler seg også veldig raske og responsive. Det faktum at vi trenger å takle den vanskelige sky-init-konfigurasjonen som utgangspunkt, hindrer bare samfunnets adopsjon av KVM og relaterte teknologier.

Samfunnet kan lære mye av måten Docker bygger og sender bildene sine. De er veldig enkle å administrere både som kjørende containere og maler som er enkle å distribuere og bruke.z