A következő cikk egy kicsit a felhő-initről és a problémáiról beszél, és arról, hogy a nyílt forráskód nem feltétlenül jelenti-e a szabadságot. Ha a cloud-init használatával szeretné konfigurálni a felhő képeket, csak görgessen lefelé a 3. pontig.

1. Mit csinál?

Gondolkozott már azon, hogy a VPS-szolgáltatók hogyan konfigurálják a virtuális gépeket, adják hozzá az SSH-kulcsokat, hozzanak létre felhasználókat és telepítsenek csomagokat minden alkalommal, amikor új virtuális gépet készít a felhőben? Nos, a legtöbb gyártó válasza felhő-init. A legtöbb operációs rendszer és disztribúció virtuális lemezképeket küld a saját operációs rendszereikkel a képbe telepítve. A telepítés nagyon minimális, és sablonként szolgálhat az operációs rendszer gyökér fájlrendszeréhez. Az operációs rendszer karbantartói szintén szívesek megadni a virtuális lemezképet a nyers lemezképektől a qcow2-ig, sőt a vmdk, a vdi és a vhd minden formátumához.

A kép egy további csomagot is előre telepített, és ez a cloud-init. A felhő-init feladata inicializálni a virtuális gép (általában egy felhőalapú tárhelyszolgáltatáson belül, például DigitalOcean, AWS vagy Azure) beszél a tárhelyszolgáltatóval adatforrás és szerezze be a konfigurációs információkat, amelyeket azután a virtuális gép konfigurálásához használ.

A konfigurációs információk tartalmazhatnak felhasználói adat mint például az SSH kulcsok, a példány hosztneve, a felhasználók és a jelszavak, valamint bármely más tetszőleges parancs, amelyet a felhasználó futtatni akar.

2. A Cloud-Init problémája

A Cloud-init nagyszerű eszköz, ha felhőfelhasználó vagy, ha virtuális gépeket vagy tárolókat forgat, és a felhőszolgáltatója szívesen kér felhő-konfigurációt, nagyon jó! A felhő-config fájl, más néven a felhasználói adatai segítségével felhasználókat adhat hozzá, tetszőleges parancsokat futtathat, csomagokat telepíthet a virtuális gép létrehozásakor. A folyamat újra és újra megismételhető anélkül, hogy unalmas parancsokat írnának újra és újra. Hamarosan megvan a virtuális gépek flottája, mindegyik azonos konfigurációval rendelkezik.

Ha azonban egy kicsit mélyebbre ás, és látja, hogyan készül a kolbász, akkor megkérdőjelezi a felhő-init néhány szempontját. Például alapértelmezés szerint az adatforrás olyan, mint egy REST végpont, és ezeket lényegében keményen kódolják magába a cloud-init csomagba. Persze, egyedül beállíthat egy adatforrást, de a folyamat nehézkes és időigényes. Az ehhez szükséges dokumentáció csak nem létezik.

A hivatalos dokumentáció nem más, mint egy felhasználói kézikönyv a meglévő felhőszolgáltatásokra támaszkodó végfelhasználók számára. Nem árulja el, hogyan állíthatja be saját felhő-init adatforrását, arra az esetre, ha Ön közelgő szállító lenne. Még a végfelhasználói dokumentáció is gyenge, és azt javasolnám az embereknek, hogy inkább a DigitalOcean kiváló oktatóanyagát használják.

A helyzetet tovább rontja, hogy az otthoni virtualizációs laboratóriumokkal és a kis VPS indítással rendelkező felhasználóknak nehéz kihasználni ezeket a könnyű felhőképeket. Nem igazán lehet elindítani a virtuális gépet ezekből a sablonokból felhő-init adatforrás vagy valamilyen hacker nélkül, amelyet nehéz automatizálni és méretezni. Más szavakkal, még akkor sem választhatja el a felhő-init figyelmen kívül hagyását, ha saját sablonjait szeretné elkészíteni.

Klasszikus systemd módon megszabadul az előre meghatározott szerepektől, és elkezd összezavarodni a hálózatépítéssel és az operációs rendszer más részeivel, ami elűzi a felhasználókat. Az Ubuntu 18-ban kerül csomagba.04 szerver ISO, aminek semmi értelme (legalábbis nekem nem).

3. Megoldás az otthoni laboratóriumok számára

Mindent félretéve, a mindennapi használat során továbbra is meg kell küzdenem a felhő-iniciálással. Van egy nagyon minimális Debian 9 telepítésem az x86_64 hardveren, amelyet KVM hipervizorként használok. Nagyon szerettem volna használni az Ubuntu és a CentOS által szállított qcow2 lemezképeket. Ezekben a lemezképekben az operációs rendszer előre van telepítve, és használatukhoz egyszerűen:

1. Másolja őket a virtuális gép virtuális merevlemez-képévé.
2. Átméretezi a gyökér fájlrendszer virtuális méretét a kívánt méretre (legalább 10 GB ajánlott). Ez nem növeli a virtuális gép fizikai méretét, de a lemezkép idővel nőhet, mivel a virtuális gép több adatot ad hozzá.
3. Konfigurálja a virtuális gépet a felhő-init használatával. A minimális követelmény a root felhasználó jelszavának vagy SSH kulcsainak beállítása, de mindent megtehetsz, amire a cloud-init képes.

A következő lépéseket követjük:

1. Töltse le kedvenc operációs rendszerének felhőképét, és mentse a / var / lib / libvirt / boot könyvtárba:

$ cd / var / lib / libvirt / boot
$ curl -O https: // felhő-képek.ubuntu.com / xenial / current / xenial-server-cloudimg-
amd64-disk1.img
$ cd / var / lib / libvirt / images

2. Hozzon létre egy üres méretű, kívánt méretű virtuális merevlemezt, és bontsa ki a letöltött qcow2 képet. Szeretem tárolni a virtuális gép merevlemezeit a / var / lib / libvirt / images / könyvtárban, kiválaszthat egy másik könyvtárat. Bármit is választ, futtassa az alábbi parancsokat ugyanabban a könyvtárban:

$ qemu-img create -f qcow2 myVM.qcow2 8G ## Hozzon létre egy merevlemezt a
virtuális lemez mérete 8 GB
$ virt-resize --expand / dev / sda1 / var / lib / libvirt / boot / xenial-server-
cloudimg-amd64-disk1.img
./ myVM.qcow2

3. Hozzon létre felhő-init fájlokat. Ezek felhasználói adatok és metaadatok fájlok:

$ vim metaadatok
példány-id: myVM
local-hostname: myVM

$ vim felhasználói adatok
# cloud-config
felhasználók:
- név: gyökér
chpasswd:
lista: |
root: myPassword
lejár: Hamis

Az egyetlen felhasználó, aki itt van, a root felhasználó. Ha nem említ egyetlen felhasználót sem, akkor az alapértelmezett felhasználó névvel ubuntu létrejön. Az alapértelmezett felhasználónév operációs rendszerenként eltér, ezért javasolom a felhasználó megadását, még akkor is, ha az igaz gyökér. A felhasználói adatfájl következő része megadja a cloud-init számára, hogy állítsa be a jelszót minden olyan felhasználó számára, akinek jelszót kíván rendelni. Ismét csak a root felhasználó jelszavát állítom be, és az is jelszavam. Ellenőrizze, hogy a kettőspont és a jelszó karakterlánc között nincs-e szóköz.

Még jobb: használhat SSH-kulcsokat ahelyett, hogy keménykódolt jelszavakat rakna körül.

$ vim felhasználói adatok
# cloud-config
felhasználók:
- név: gyökér
ssh_pwauth: Igaz
ssh_authorized_keys:
- ssh-rsa

4. Beágyazza a felhasználói és a metaadat fájlokat iso-ba.

$ genisoimage -output cidata-myVM.iso -volid cidata -joliet -rock felhasználói adatok metaadatai

Győződjön meg arról, hogy a cidata-myVM fájl.az iso a / var / lib / libvirt / images könyvtárban található

5. Lépjen a / var / lib / libvirt / images könyvtárba, és inicializálja a virtuális gépet a virt-install paranccsal: $ virt-install --import --name myVM --memory 2048 --vcpus 2 --cpu host
   --lemez myVM.qcow2, format = qcow2, bus = virtio --lemez myVM-cidata.iso, eszköz = cdrom
   --hálózati híd = virbr0, modell = virtio --os-type = linux
   --os-variáns = ubuntu16.04 - noautoconsole

   Most megpróbálhatja bejelentkezni a virtuális gépbe a virsh console myVM paranccsal, a bejelentkezéshez pedig a gyökér felhasználónévvel és a hozzá tartozó jelszóval. A konzolból való kilépéshez egyszerűen írja be a Ctrl +]

Következtetés

A legtöbb eladó által szállított felhőképek valóban hatékonyak az erőforrás-felhasználás szempontjából, és nagyon gyorsak és reagálók is. Az a tény, hogy kiindulópontként kell kezelnünk a kellemetlen felhő-init konfigurációt, csak gátolja a közösség KVM és a kapcsolódó technológiák elfogadását.

A közösség sokat tanulhat abból, ahogy a Docker elkészíti és szállítja képeit. Nagyon egyszerűen kezelhetők futó tárolókként és sablonokként, amelyeket könnyen terjeszteni és használni lehet.z