Packer, vSphere, et UbuntuServer

Packer, vSphere, et UbuntuServer

Avec du VSCode & DevContainer~

Hop là ! Après quelques « petits » articles pour recommencer en douceur, on s’attaque désormais à quelque chose de bien plus sympatoche ! Nous allons voir ici comment déployer un template UbuntuServer 24.04 sur un cluster vSphere via Packer, avec comme subtilité d’utiliser Packer via un DevContainer dans VSCode, grâce à Docker Desktop 🕺🏻

Alors bien sûr disclaimer: il n’est clairement pas obligatoire d’utiliser un DevContainer pour utiliser Packer et déployer des templates sur vSphere ou autre, mais étant donné que j’ai découvert cette manière de faire récemment, je me suis dit que ce serait sympa de vous en parler ici.

Alors commençons dans l’ordre !

I) Le lab en question

Étant donné que je suis toujours entrain de remettre à niveau mon environnement de lab, ici j’utiliserai encore mon bon vieux VMware Workstation, avec :

  • Une VM Windows 10, avec Visual Studio Code et Docker Desktop d’installé ;
  • Un cluster vSphere fonctionnel, avec VCSA installé (VCSA en 192.168.0.130) ;

Et c’est plus ou moins tout.

II) Devcontainer, ça sert à quoi au juste ?

Alors vous connaissez sûrement cette technologie appelée Remote Containers puisque ça date tout de même de 2019-2020… mais un p’tit résumé s’impose pour les non-connaisseurs.

Sur Visual Studio Code, l’éditeur/IDE de chez ‘Crosoft, on peut installer des thèmes et des extensions.

Parmi ces fameuses extensions, l’une permet quelque chose de plutôt cool : monter des dossiers dans un conteneur et donc créer un environnement parfait pour développer ! Elle s’appelle donc Dev Containers, cf la doc ici -> https://code.visualstudio.com/docs/devcontainers/containers

https://code.visualstudio.com/docs

Ici par exemple, dans l’exemple avec Packer, j’ai décidé de créer mon projet dans un dossier, jusque là rien de foufou.

La magie arrive ici: j’utilise un fichier devcontainer.json pour setuper mon environnement VSCode –avec par exemple des extensions, des variables, et autre– et j’exécute ensuite un Dockerfile ou Docker-Compose pour créer mon conteneur et lui aussi le setuper ! Paquets de base, shell personnalisé, montage particuliers…

Cela permet d’avoir un environnement portable et surtout maîtrisé. Par exemple, si vous êtes un DevOps bossant avec Azure, vous aurez sûrement entendu parler du Azure Rover. Et bien c’est exactement ça ! Un devcontainer avec un Dockerfile pour setup le tout, et avoir de base une toolbox sans avoir besoin de tout setuper à la main…

Le fameux Rover, avec son conteneur et ses extensions vsCode installées par défaut !

SCREEN_02

III) Et du coup pour ton fameux Packer et vSphere ?

Et bien j’ai fait la même approche ! Alors certes le tout est clairement perfectible, le but était de jouer/s’approprier la techno, mais le résultat est fonctionnel donc je vais vous le partager.

Pour les plus pressés, le projet est dispo’ sur mon humble repo’ Github: https://github.com/IT-Anthony/UbuntuServer2404-packer-vsphere8

Pour les autres, on va décortiquer ça ensemble !

IV) Création du folder .devcontainer

C’est dans ce premier dossier que tout va se passer : on va y créer notre devcontainer.json ainsi que notre Dockerfile :

Ici on va donc renseigner qu’on va utiliser un fichier Dockerfile, on va passer en argument la version de Packer, histoire de ne l’éditer qu’ici si elle venait à changer, puis on renseigne un utilisateur autre que root, ici ce sera donc vscode.

Ensuite, on monte le .ssh en read-only, afin de pouvoir utiliser nos clefs SSH, et enfin on se permet l’ajout de quelques extensions pour faciliter le développement de tout ça 🤗.

Ici c’est notre fameux Dockerfile ! Je suis parti d’une base Alpine (et oui, ‘pour ça que j’ai sorti un article dessus y’a quelques jours héhé), et pour résumer :

  • On passe la version de Packer en argument, car on va la ré-utiliser ici ;
  • On installe quelques packages par défaut, notamment cdrkit qui est obligatoire pour ensuite monter nos fichiers Cloud-Init via CD/Floppy ;
  • On créer un répertoire de travail ;
  • On installe Packer, classique ;
  • On installe ZSH/Oh-my-ZSH, parce que pourquoi pas ;
  • On rajoute notre utilisateur vscode, et on lui donne les bonnes permissions ;
  • On change le thème de Oh-my-ZSH (parce que pourquoi pas…) ;
  • Et enfin on installe le plugin vSphere-ISO pour Packer ;

Rien de très foufou, mais ça fait le boulot !

V) Configuration niveau Packer files

Le fichier principal est donc ubuntu-2404-vsphere.pkr.hcl, c’est ici que l’on renseigne toutes les informations et les variables. Je vais volontairement ne pas trop m’étayer ici, car le fichier est globalement bien documenté (enfin je pense ?).

Initialement, et comme j’avait fait à l’époque pour Windows Server 2019, je comptais utiliser le serveur web de Packer… sauf que là petit souci ; on est à l’intérieur d’un conteneur, rappelez-vous ! Du coup Packer démarrait sur une IP en 172.16.0.0/16… pas si grave que ça en soit, on peut rajouter un argument -p 0.0.0.0:3000 à notre fichier .devcontainer, et rajouter une variable http_ip dans notre fichier HCL pour que Packer utilise un port bien spécifique et réaliser du port-forwarding avec notre hôte.

J’ai testé, et it works ! Mais bon, tout de même un peu moins user-friendly, et étant donné que vSphere-ISO permet de monter des floppys (enfin, des CDs) autant en profiter.

Sinon rien de très spécifique à dire… le template créé n’a qu’un seul disque, de 50Gb. A terme je pourrai éventuellement proposer une configuration multi-disques, mais pas mal casse-tête niveau Cloud-Init/Curtin… 🙄

VI) Le fichier Cloud-Init

Là aussi rien de très transcendant ! On installe quelques paquets de base, on configure les locales, le clavier (en Français-Belgique, à noter !), et on créer deux utilisateurs. Un administrator qui sera donc l’admin par défaut, et on en profite aussi pour créer un user ansible et y coller sa clef publique. Les deux ont les droits sudo, en passwordless.

VI) Conclusion

Et bien je pense avoir déjà tout décrit… il y a un folder scripts avec un bash permettant de clean un peu le tout une fois l’installation terminée, et les fichiers de variables ont le radical auto, permettant donc de ne pas devoir les spécifier lors du build via Packer. C’est-à-dire qu’un simple :

packer build .

Et il prendra automatiquement le fichier variables et secret. J’ai aussi anticipé un peu et rajouté un fichier .gitlab-ci.yml, car je compte prochainement essayer de me créer une p’tite pipeline pour m’amuser.

Et oui, là aussi l’article traitant de l’install’ de Gitlab n’était pas pour rien 🤫.

Sur ce, j’espère comme d’habitude vous avoir appris quelques bricoles, et vous souhaite une bonne journée/soirée ! Tchô !

Laisser un commentaire