Ansible en de Pre-Container kunsten

Kubernetes Ubuntu

Voordat containerisatie het zo gemakkelijk maakte om images voor te bereiden voor virtualisatie, was het een hele kunst om aangepaste ISO-images te maken om van CD op te starten. Later werden deze images gebruikt om virtuele machines van op te starten. Met andere woorden, ISO-images waren de voorlopers van container-images.

Het is zo dat ik een paar ongelukkige botsingen heb gehad met de Windows Docker-client. Zelfs als er geen containers werden uitgevoerd, gaf de Windows-geheugenbeheerder hem zoveel mogelijk geheugen om te vertragen waar ik ook mee bezig was. Daarom heb ik de Windows Docker client van mijn machine verbannen.

Begrijp me niet verkeerd. Ik haat Docker niet, alleen de Windows-client.

Deze stap dwong me terug te gaan in de tijd. Ik begon virtuele machines rechtstreeks op Hyper-V, de Windows Hypervisor, te draaien. Het vormen van Kubernetes-clusters op Windows werd toen een vrolijke hobby voor me zoals blijkt uit mijn eerdere posts die ik hier op DZone heb gepubliceerd.

Shoemaker, Why Do You Go Barefoot?

Na urenlang dezelfde muisklikken te hebben gevolgd om virtuele machines te maken op Hyper-V Manager, realiseerde ik me dat ik ben als een schoenmaker die op blote voeten loopt: Ik bouw een DevOps-pijplijn voor een uurtarief, maar verspil tijd aan muisklikken?

Uitdaging geaccepteerd. Ik heb duckduckgo’d en gelezen dat het mogelijk is om virtuele machines te maken met PowerShell. Het duurde geen week voordat ik een script had dat een nieuwe virtuele machine aanmaakt, zoals te zien is hier. Een zusterscript kan een virtuele machine starten die is uitgeschakeld.

Een oude kunst herontdekt

Dit was geweldig, maar ik realiseerde me dat ik nog steeds muisklikken deed bij het installeren van Ubuntu. Om dit te automatiseren leek een moeilijk te kraken noot. Je moet een ISO image uitpakken, het op de een of andere manier manipuleren en het dan weer verpakken, waarbij je ervoor moet zorgen dat alles wat de computer instrueert om op te starten intact blijft.

Gelukkig vond ik een uitstekende gids over hoe je dit precies moet doen. Het proces bestaat uit drie stappen:

Uitpakken van de Ubuntu ISO boot image.
Manipuleer de inhoud:
1. Verplaats de master boot record (MBR) naar buiten.
2. Specificeer wat gebruikers normaal doen op de GUI en pas aan wat wordt geïnstalleerd en uitgevoerd tijdens de installatie. Dit wordt gedaan met behulp van een subset van Ubuntu’s Cloud-init taal. Zie hier voor de instructies die ik heb gemaakt.
3. Instructeer de bootloader (Grub, in dit geval) waar de aangepaste boot instructies te vinden en niet te wachten op input van de gebruiker. Hier is de Grub config die ik heb gekozen.
Pak alles in met een applicatie genaamd Xorriso.

Voor de tovenaars van dit oude ambacht is Xorriso hun toverstaf. Het heeft pagina’s documentatie in iets dat lijkt op een spreukenboek. Ik moet mijn handen vuil maken om het volledig te begrijpen, maar mijn huidige (en hoogstwaarschijnlijk foute) begrip is dat het Boot partities aanmaakt, de gekopieerde MBR laadt en iets doet met de Cloud-init-achtige instructies om een gewijzigde ISO image te maken.

Ansible for the Finishing Touches

Hoewel het met grote tevredenheid was dat ik Ubuntu22 kon booten vanaf PowerShell zonder enige verdere input van mij, hoe zit het de volgende keer als Ubuntu een nieuwe versie uitbrengt? Echte DevOps vereist om het proces te documenteren, niet in ASCII, maar in een script dat klaar is om uit te voeren wanneer dat nodig is. Ansible laat zijn veelzijdigheid zien, want het lukte me om dit in een middag te doen. Het geheim is om Ansible te instrueren dat het een lokale actie is. Met andere woorden, gebruik geen SSH om een machine te targeten om instructies te ontvangen, maar de Ansible Controller is ook de leerling:

YAML

- hosts: localhost
  connection: local

Het volledige spel wordt hierna gegeven en geeft een andere kijk op wat hierboven is uitgelegd:

YAML

# 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

Let op de magie van het Xorriso commando dat hier wordt gebruikt om twee images voor te bereiden: een met ondersteuning en een zonder ondersteuning voor Kubernetes.

Het enige voorbehoud is dat er een machine geïnstalleerd moet zijn met Ansible om dit spel op uit te voeren. De uitvoer van het bovenstaande spel kan worden gedownload van hier en een zeer recente versie van Ansible vooraf installeren.

Conclusie

Deze post ging retro, maar het is belangrijk om terug te gaan naar waar de dingen begonnen om te begrijpen waarom dingen zijn zoals ze zijn. Windows en containers gaan bovendien niet zo goed samen en elk onderzoek naar manieren om de dagen van ontwikkelaars beter te maken zou welkom moeten zijn.

Ik verwees naar een deel van de code, maar het volledige project kan worden bekeken op GitHub.

Source:
https://dzone.com/articles/ansible-and-the-pre-container-arts