Ansible et les arts du pré-conteneur

Avant que la conteneurisation ne facilite la préparation d’images pour la virtualisation, c’était tout un art de préparer des images ISO personnalisées pour démarrer à partir d’un CD. Plus tard, ces images ont été utilisées pour démarrer les machines virtuelles. En d’autres termes, les images ISO étaient les précurseurs des images de conteneurs.

C’est ainsi que j’ai eu quelques démêlés malheureux avec le client Windows Docker. Même lorsqu’il n’exécutait aucun conteneur, le gestionnaire de mémoire de Windows lui remettait autant de mémoire que possible en ralentissant ce à quoi j’étais occupé. J’ai donc banni le client Windows Docker de ma machine.

Ne vous méprenez pas. Je ne déteste pas Docker – seulement son client Windows.

Cette étape m’a obligé à revenir en arrière. J’ai commencé à exécuter des machines virtuelles directement sur Hyper-V, l’hyperviseur de Windows. Former des clusters Kubernetes sur Windows est alors devenu un heureux passe-temps pour moi comme en témoignent mes anciens billets publiés ici sur DZone.

Cordonnier, pourquoi vas-tu pieds nus?

Après avoir suivi les mêmes clics de souris pour créer des machines virtuelles sur Hyper-V Manager pendant de nombreuses heures, j’ai réalisé que je suis comme un cordonnier qui va pieds nus : Je construis un pipeline DevOps pour un taux horaire, mais je perds du temps sur des clics de souris ?

Défi relevé. J’ai fait un duckduckgo et j’ai lu qu’il était possible de créer des machines virtuelles en utilisant PowerShell. Il n’a pas fallu une semaine pour avoir un script qui crée une nouvelle machine virtuelle comme on peut le voir ici. Un script apparenté peut démarrer une machine virtuelle éteinte.

Un vieil art redécouvert

C’était génial, mais je me suis rendu compte que je faisais encore des clics de souris lors de l’installation d’Ubuntu. L’automatisation de cette opération semblait plus difficile à mettre en œuvre. Il faut décompresser une image ISO, la manipuler d’une manière ou d’une autre, puis l’emballer à nouveau en prenant soin de laisser intact tout ce qui indique à un ordinateur comment démarrer.

Heureusement, j’ai trouvé un excellent guide sur la façon de procéder. Le processus consiste en trois étapes :

1. Déballez l’image de démarrage ISO d’Ubuntu.
2. Manipuler le contenu :
   1. Déplacer le master boot record (MBR) vers l’extérieur.
   2. Spécifier ce que les utilisateurs font normalement sur l’interface graphique et personnaliser ce qui est installé et exécuté pendant l’installation. Cela se fait à l’aide d’un sous-ensemble du langage Cloud-init d’Ubuntu. Voir ici pour les instructions que j’ai créées.
   3. Instruire le chargeur de démarrage (Grub, dans ce cas) où trouver les instructions de démarrage personnalisées et de ne pas attendre l’entrée de l’utilisateur. Voici la configuration de Grub que j’ai choisie.
3. Ensemblez le tout à l’aide d’une application appelée Xorriso.

Pour les magiciens de cet ancien métier, Xorriso sert de baguette magique. Il contient des pages de documentation qui ressemblent à un livre de sorts. Je vais devoir me salir les mains pour bien comprendre, mais ma compréhension actuelle (et très probablement erronée) est qu’il crée des partitions de démarrage, charge le MBR copié, et fait quelque chose avec les instructions de type Cloud-init pour créer une image ISO modifiée.

Ansible for the Finishing Touches

Même si c’est avec une grande satisfaction que j’ai réussi à démarrer Ubuntu22 à partir de PowerShell sans aucune autre intervention de ma part, qu’en sera-t-il la prochaine fois qu’Ubuntu sortira une nouvelle version ? Le véritable DevOps exige de documenter le processus non pas en ASCII, mais dans un script prêt à être exécuté en cas de besoin. Ansible montre sa polyvalence en me permettant de faire cela en une après-midi. Le secret consiste à indiquer à Ansible qu’il s’agit d’une action locale. En d’autres termes, n’utilisez pas SSH pour cibler une machine afin de recevoir des instructions, mais le contrôleur Ansible est également l’étudiant:

- hosts: localhost
  connection: local

Le jeu complet est donné à la suite et fournit une autre vue de ce qui a été expliqué ci-dessus:

# stamp_images.yml

- hosts: localhost
  connection: local
  become: true
  vars_prompt:
    - name: "base_iso_location"
      prompt: "Enter the path to the base image"
      private: no
      default: /tmp/ubuntu-22.04.4-live-server-amd64.iso

  tasks:
    - name: Install 7Zip
      ansible.builtin.apt:
        name: p7zip-full
        state: present

    - name: Install Xorriso
      ansible.builtin.apt:
        name: xorriso
        state: present

    - name: Unpack ISO
      ansible.builtin.command: 
        cmd: "7z -y x {{ base_iso_location }} -o/tmp/source-files"

    - name: Copy boot partitions
      ansible.builtin.copy:
        src: /tmp/source-files/[BOOT]/
        dest: /tmp/BOOT
  
    - name: Delete working boot partitions
      ansible.builtin.file:
        path:  /tmp/source-files/[BOOT]
        state: absent
  
    - name: Copy files for Ubuntu Bare
      ansible.builtin.copy:
        src: bare/source-files/bare_ubuntu
        dest: /tmp/source-files/

    - name: Copy boot config for Ubuntu bare
      ansible.builtin.copy:
        src: bare/source-files/boot/grub/grub.cfg
        dest: /tmp/source-files/boot/grub/grub.cfg

    - name: Stamp bare image
      ansible.builtin.command: 
        cmd: xorriso -as mkisofs -r   -V 'Ubuntu 22.04 LTS AUTO (EFIBIOS)'   -o ../ubuntu-22.04-wormhole-autoinstall-bare_V5_1.iso   --grub2-mbr ../BOOT/1-Boot-NoEmul.img -partition_offset 16   --mbr-force-bootable   -append_partition 2 28732ac11ff8d211ba4b00a0c93ec93b ../BOOT/2-Boot-NoEmul.img   -appended_part_as_gpt   -iso_mbr_part_type a2a0d0ebe5b9334487c068b6b72699c7   -c '/boot.catalog'   -b '/boot/grub/i386-pc/eltorito.img'     -no-emul-boot -boot-load-size 4 -boot-info-table --grub2-boot-info   -eltorito-alt-boot   -e '--interval:appended_partition_2:::'   -no-emul-boot .
        chdir: /tmp/source-files

    - name: Copy files for Ubuntu Atomika
      ansible.builtin.copy:
        src: atomika/source-files/atomika_ubuntu
        dest: /tmp/source-files/

    - name: Copy boot config for Ubuntu Atomika
      ansible.builtin.copy:
        src: atomika/source-files/boot/grub/grub.cfg
        dest: /tmp/source-files/boot/grub/grub.cfg

    - name: Stamp Atomika image
      ansible.builtin.command:
        cmd: xorriso -as mkisofs -r   -V 'Ubuntu 22.04 LTS AUTO (EFIBIOS)'   -o ../ubuntu-22.04-wormhole-autoinstall-atomika_V5_1.iso   --grub2-mbr ../BOOT/1-Boot-NoEmul.img -partition_offset 16   --mbr-force-bootable -append_partition 2 28732ac11ff8d211ba4b00a0c93ec93b ../BOOT/2-Boot-NoEmul.img   -appended_part_as_gpt   -iso_mbr_part_type a2a0d0ebe5b9334487c068b6b72699c7   -c '/boot.catalog'   -b '/boot/grub/i386-pc/eltorito.img'     -no-emul-boot -boot-load-size 4 -boot-info-table --grub2-boot-info   -eltorito-alt-boot   -e '--interval:appended_partition_2:::'   -no-emul-boot .
        chdir: /tmp/source-files        

Notez la magie de la commande Xorriso utilisée ici pour préparer deux images : une avec support et une sans support pour Kubernetes.

La seule mise en garde est d’avoir une machine installée avec Ansible pour exécuter cette pièce. La sortie de la pièce ci-dessus peut être téléchargée à partir de ici et préinstaller une version très récente d’Ansible.

Conclusion

Ce billet est devenu rétro, mais il est important de revenir sur le point de départ pour comprendre pourquoi les choses sont ce qu’elles sont. Windows et les conteneurs, en outre, ne font pas bon ménage et toute recherche sur les moyens d’améliorer les journées des développeurs devrait être accueillie favorablement.

J’ai fait référence à une partie du code, mais le projet complet peut être consulté sur GitHub.