L'article suivant parle un peu du cloud-init et des problèmes qu'il a, et comment l'open source ne signifie pas nécessairement la liberté. Si vous souhaitez utiliser le cloud-init pour configurer les images de cloud, faites défiler vers le bas vers le numéro de point 3.

1. Ce qu'il fait?

Vous avez déjà demandé comment les fournisseurs de VPs configurent vos machines virtuelles, ajoutez vos clés SSH, créent des utilisateurs et installent des packages chaque fois que vous faites tourner une nouvelle machine virtuelle dans le «cloud»? Eh bien, la réponse à la plupart des vendeurs est le cloud-init. La plupart des systèmes d'exploitation et des distributions expédient des images de disque virtuel avec leurs Os respectifs installés dans l'image. L'installation est très minime et peut servir de modèle pour le système de fichiers racine du système d'exploitation. Les responsables du système d'exploitation sont également assez gentils pour fournir l'image disque virtuelle pour tous les différents formats, des images de disque brutes à QCOW2 et même VMDK, VDI et VHD.

L'image a également un package supplémentaire préinstallé et c'est le cloud-init. C'est le travail du cloud-init à initialiser La machine virtuelle (généralement au sein d'un service d'hébergement cloud comme DigitalOcean, AWS ou Azure) parle aux fournisseurs d'hébergement la source de données et obtenir les informations de configuration qu'il utilise ensuite pour configurer la machine virtuelle.

Les informations de configuration peuvent inclure données d'utilisateur Comme les touches SSH, le nom d'hôte de l'instance, les utilisateurs et les mots de passe ainsi que toute autre commande arbitraire que l'utilisateur souhaite exécuter.

Le problème avec le cloud-init

Le cloud-init est un excellent outil si vous êtes un utilisateur de cloud, si vous faites tourner des machines virtuelles ou des conteneurs et que votre fournisseur de cloud est assez gentille pour vous demander un cloud-config, c'est génial! Avec un fichier cloud-config aka votre utilisateur, vous pouvez ajouter des utilisateurs, exécuter des commandes arbitraires, installer des packages directement lorsque la machine virtuelle est en cours de création. Le processus peut être répété encore et encore sans que les commandes fastidieuses soient tapées. Vous avez bientôt une flotte de machines virtuelles, toutes avec une configuration identique.

Cependant, si vous creusez un peu plus profondément et voyez comment la saucisse est faite, vous commencerez à remettre en question certains aspects de Cloud-Init. Par exemple, par défaut, la source de données est comme un point de terminaison de repos, et celles-ci sont essentiellement codées en dur dans le package Cloud-Init lui-même. Bien sûr, vous pouvez configurer une source de données par vous-même, mais le processus est attaché et à forte intensité de temps. La documentation pour ce faire est presque inexistante.

La documentation officielle n'est rien d'autre qu'un manuel d'utilisation pour les utilisateurs finaux qui s'appuient sur les services cloud préexistants. Il ne vous explique pas comment vous pouvez configurer votre propre survol du cloud-initial, au cas où vous êtes un prochain fournisseur. Même la documentation de l'utilisateur final est médiocre, et je recommanderais aux gens qui utilisent l'excellent tutoriel de DigitalOcean à la place.

Pour aggraver les choses, les utilisateurs avec des laboratoires de virtualisation à domicile et la petite startup VPS ont du mal à bénéficier de ces images de nuages ​​légers. Vous ne pouvez pas vraiment démarrer une machine virtuelle de ces modèles sans source de données de cloud-init ou un piratage qui est difficile à automatiser et à évoluer. En d'autres termes, vous ne pouvez même pas choisir d'ignorer le cloud-init à moins que vous ne vouliez créer vos propres modèles.

De manière classique Systemd, il se libére de ses rôles prédéfinis et commence à gâcher le réseau et d'autres parties du système d'exploitation qui jette les utilisateurs. Il est regroupé dans Ubuntu 18.04 Server ISO qui n'a absolument aucun sens (du moins pas pour moi).

Solution de contournement pour les laboratoires à domicile

Tout le diatribe mis à part, je dois encore faire face à Cloud-Init dans mon usage quotidien. J'ai une installation de Debian 9 très minimale sur le matériel x86_64, que j'utilise comme hyperviseur KVM. Je voulais vraiment utiliser les images de disque QCOW2 qui sont expédiées par Ubuntu et Centos. Ces images de disque ont le système d'exploitation préinstallé, et pour les utiliser, vous devez simplement:

1. Copiez-les comme image de disque dur virtuel de votre machine virtuelle de votre machine virtuelle.
2. Redimensionner la taille virtuelle du système de fichiers racine à la taille souhaitée (au moins 10 Go est recommandé). Cela n'augmentera pas la taille physique de votre machine virtuelle, mais l'image du disque peut croître avec le temps car la machine virtuelle y ajoute plus de données.
3. Configurez les machines virtuelles en utilisant le cloud-init. La nécessité minimale est de définir le mot de passe de l'utilisateur ou les clés de l'utilisateur racine, mais vous pouvez faire de tout ce que le cloud-Init est capable.

Les étapes suivantes sont suivies:

1. Téléchargez l'image cloud de votre système d'exploitation préféré et enregistrez-le dans le répertoire / var / lib / libvirt / boot:

$ cd / var / lib / libvirt / bott
$ curl -o https: // cloud-images.ubuntu.com / xenial / current / xenial-server-cloudImg-
AMD64-DISK1.IMG
$ cd / var / lib / libvirt / images

2. Créez un disque dur virtuel vide de la taille souhaitée et élargissez l'image QCOW2 téléchargée dedans. J'aime stocker les disques durs VM à / var / lib / libvirt / images / répertoire, vous pouvez choisir un autre répertoire. Quoi que vous choisissiez, exécutez les commandes ci-dessous dans le même répertoire:

$ qemu-iMg Create -f qcow2 myvm.QCOW2 8G ## Créez un disque dur avec
Taille du disque virtuel de 8 Go
$ ver-résize-
CloudImg-Amd64-Disk1.IMG
./ myvm.qcow2

3. Créer des fichiers Init Cloud. Ce sont des fichiers de données utilisateur et de métadonnées:

$ Vim Meta-Data
instance-id: myvm
Name local: myvm

$ Vim User-Data
# cloud-config
utilisateurs:
- nom: racine
Chpasswd:
Liste: |
Root: MyPassword
expirer: faux

Le seul utilisateur que j'ai ici est l'utilisateur racine. Si vous ne mentionnez aucun utilisateur, alors l'utilisateur par défaut avec nom ubuntu est créé. Le nom d'utilisateur par défaut, diffère d'un système d'exploitation à un autre, c'est pourquoi je recommande de spécifier un utilisateur, même si c'est juste racine. La partie suivante du fichier de données utilisateur indique au cloud-init de configurer le mot de passe pour tous les utilisateurs que vous souhaitez attribuer un mot de passe. Encore une fois, je définis simplement le mot de passe pour un user root, et c'est mon mot de passe. Assurez-vous qu'il n'y a pas d'espace entre le côlon et la chaîne de mot de passe.

Mieux encore, vous pouvez utiliser SSH-Keys au lieu d'avoir des mots de passe codés en dur à poser autour.

$ Vim User-Data
# cloud-config
utilisateurs:
- nom: racine
ssh_pwauth: vrai
ssh_authorized_keys:
- SSH-RSA

4. Intégrez les fichiers utilisateur et les métadonnées dans un ISO.

$ Genisoimage -output cidata-myvm.iso -volid cidata -joliet -rock meta-data utilisateur

Assurez-vous que le fichier cidata-myvm.ISO est situé dans / var / lib / libvirt / images /

5. Accédez au répertoire / var / lib / libvirt / images et initialisez la machine virtuelle avec la commande virgin-install:

   $ Virgin-stall --import --name myvm --memory 2048 --vcpus 2 --cpu hôte
   --disque myvm.QCOW2, format = qcow2, bus = virtio - dissk myvm-cidata.ISO, dispositif = CDROM
   --Bridge de réseau = Virbr0, modèle = Virtio --oS-Type = Linux
   --OS-Variant = Ubuntu16.04 --Noautoconsole

   Vous pouvez maintenant essayer de vous connecter à la machine virtuelle en utilisant la commandes de la console VIRSH MYVM et en utilisant le nom d'utilisateur racine et son mot de passe correspondant pour vous connecter. Pour quitter la console, tapez simplement Ctrl +]

Conclusion

Les images cloud que la plupart des fournisseurs expédiés sont vraiment efficaces en termes d'utilisation des ressources et ils se sentent également très rapides et réactifs. Le fait que nous devons faire face à la configuration maladroite du cloud-init comme point de départ ne fait que l'adoption par la communauté de KVM et de technologies connexes.

La communauté peut apprendre beaucoup de la façon dont Docker construit et expédie ses images. Ils sont vraiment faciles à gérer à la fois comme des conteneurs et des modèles qui sont faciles à distribuer et à utiliser.z