Packer - Automatiser dine template builds

Enhver administrator af et virtuelt miljø har på et tidspunkt stået overfor enten et massivt tidsspilde for at installere og opdatere Windows Server eller Linux på en ny virtuel maskine eller bruge et image som der ikke er blevet holdt opdateret, muligvis grundet mangel på tid til at gøre det i.

Introducing:

Hvad er Packer?

Packer er et værktøj fra HashiCorp (firmaet bag Vagrant og Terraform) som gør det muligt at bygge images til VMer udfra en specifikation skrevet af den enkelte administrator eller udvikler. Packer kan bygge disse images på en bred rækkevidde af platforme, bl.a.: VMware (ESXi, Fusion, Workstation), QEMU/KVM (igennem libvirt), OpenStack platforme og Amazon EC2.

I denne artikel tager vi udgangspunkt i at miljøet der benyttes er en VMware Workstation klient på en Windows computer, med det ultimative mål at uploade det producerede image til VMware vCloud Director.

Måden Packer arbejder på er såmænd ved at starte enten med en ISO fil eller en eksisterende virtuel maskine som den vil tage en kopi af og arbejde videre med.

I vores eksempel vil vi bygge en template med Ubuntu 16.04 som først bliver installeret fra en ISO og derefter tilpasset til vores krav.

Packer kan hentes fra hjemmesiden https://packer.io til Windows, Linux, OS X, FreeBSD og OpenBSD.

Packer bygger baseret på en template som er skrevet i forvejen. En template kan hedde hvad som helst, så i teorien kunne du sagtens have flere Packer templates og scripts i en folder. Templates er skrevet i ren JSON, som burde være let læseligt og nemt at forstå. For enkelthed foreslår vi at holde en template og dets underfoldere og scripts i en folder, så man ikke roder.

Det første vi definerer i vores template er vores 'builder'. En builder er den process der vil bygge vores image. Da det i vores tilfælde er VMware og vi ønsker at bygge fra en ISO fil hedder vores builder 'vmware-iso'. I 'builder' definitionen tilføjer vi også alle de øvrige argumenter som skal bruges til et build:

{
  "builders": [
    {
      "type": "vmware-iso",
      "guest_os_type": "ubuntu-64",
      "vm_name": "ubuntu-1604",
      "iso_url": "http://archive.ubuntu.com/ubuntu/dists/xenial/main/installer-amd64/current/images/netboot/mini.iso",
      "iso_checksum": "902731a64bf54a057ba266a32de5fbcc4c494fcf",
      "iso_checksum_type": "sha1",
      "boot_command": "<tab><wait><bs><bs><bs><bs><bs><bs><bs><bs><bs><bs><bs><bs><bs><bs><bs><bs><bs><bs><bs><bs><bs><bs><bs><bs><bs><bs><bs><bs><bs><bs><bs><bs><bs><bs><bs><bs><bs><bs><bs><bs><bs><bs>/linux initrd=/initrd.gz auto=true noapic=true fb=false hostname=localhost locale=en_US keyboard-configuration/modelcode=SKIP preseed/url=http://{{ .HTTPIP }}:{{ .HTTPPort }}/preseed.cfg<enter>",
      "boot_wait": "60s",
      "disk_size": "8192",
      "http_directory": "http",
      "ssh_username": "root",
      "ssh_password": "packerbuild",
      "ssh_wait_timeout": "3600s",
      "shutdown_command": "shutdown -P now",
    }
  ],

Lad mig forklare de mindre åbenlyse argumenter i den ovenstående template:

• boot_wait: boot_wait er en simpel timer for hvor lang tid der skal gå fra maskinen er startet til at Packer forsøger at sende boot_command.
• boot_command: Når boot_wait's tid er udløbet går vi ud fra at vi er i en form for menu. boot_command er, som man nok kan regne ud, en række taster der bliver sendt, enten via VNC eller en anden form for konsol til VMen for at få den til at installere med preseed, eksempelvis. I en Windows installation kan vi lade boot_command stå tom, da man i stedet ville lave en virtuel floppy disk med et script som Windows selv finder og installerer efter.
• ssh_* settings: Da Packer også efter installationen vil udføre scripts på VMen er det vigtigt at den har muligheden for at logge ind på maskinen efter setup er klaret. Vi definerer en bruger i preseedet til dette formål.
• shutdown_command: Defineret her er den kommando som Packer vil bruge når den er færdig med at konfigurere maskinen. I et build af en Windows maskine kunne det være en fordel at definere 'sysprep' som sin shutdown_command.
• http_directory: I tilfælde af at vi har et preseed eller anden fil som vi ønsker at loade kan man starte en lille intern HTTP server hvor en fil, som for eksempel preseed.cfg eller ks.cfg (i Linux) kan hentes fra. Denne server virker dog kun under boot og bliver lukket når Packer forbinder til maskinen efter setup er gennemført. Ønsker vi i vores boot_command at bruge denne server kan vi gøre det som vist, med variablen: http://{{ .HTTPIP }}:{{ .HTTPPort }}/<filnavn>

Med den del af vores template på plads, sørg herefter for at have to foldere:

• http: Dette er det førnævnte http_directory som defineret i vores template.
• scripts: Denne folder kunne i virkeligheden hedde hvad som helst, men navnet er i dette tilfælde selv-dokumenterende. I denne folder kan scripts som Packer skal køre når maskinen er genstartet efter installation fra ISO filen. (Fortvivl ikke over manglende scripts, i bunden af artiklen findes et link til vores scripts og template som du blot kan kopiere.)

Dette leder os godt ind i den næste del af vores template: Vores 'provisioner':

En provisioner er den service der køres for at eksekvere scripts på maskinen til at fuldende dens opsætning. I vores tilfælde har Packer SSH adgang til den nye maskine, så vi bruger 'shell' provisioneren. I dokumentationen findes der en liste over tilgængelige provisioners.

Så tilføj efter 'builders' i vores template:

  "provisioners": [
    {
      "type": "shell",
      "scripts": [
        "scripts/base.sh",
        "scripts/cleanup.sh",
        "scripts/zerodisk.sh"
      ]
    }
  ],

Efter Packer har indtastet boot_command vil den efterfølgende blot vente på at SSH bliver tilgængelig på den VM den har lavet. Når SSH er tilgængelig vil den logge ind og eksekvere disse scripts i den skrevne rækkefølge. Scriptsne bliver udført af den shell der er præsenteret til Packer efter login over SSH/WinRM. I vores tilfælde er dette Bash, så når vi skriver vores scripts skal vi blot være opmærksom på dette. Det er vigtigt at alle scripts ikke venter på noget input, da vi ikke har mulighed for at kigge ind i det Packer laver på VMen. Hvis en kommando venter på input el. lign. vil Packer eventuelt lave et timeout og afbryde sit build.

Til sidst har vi i Packer en mulighed for at tilføje en 'post-processor', som kan udføre en specifik handling når maskinen er bygget færdig. Det kan være ting som at putte den nye VM ind i vSphere som en template, importere som en template i AWS eller en af de mange andre funktioner.

Da shell-local står til at blive udfaset som post-processor benytter vi os i stedet for af et batch script som bliver kørt efter Packer, som pakker filen sammen til en .ova via VMware's ovftool.

Når alt er i template filen og alle de korrekte filer er placeret i http og scripts folderne kan du fra kommandolinjen køre 'packer validate template.json' (Erstat template.json med din templates' filnavn). Dette får Packer til at gennemgå templaten for at lede efter syntaksfejl eller mulige mangler. (f.eks scripts der ikke findes eller lign.)

Siger Packer at templaten er valid kan du så derefter køre 'packer build template.json', som vil starte processen beskrevet i template filen. Packer laver den virtuelle maskine med de specs defineret i filen og, hvis defineret, går igennem den proces som templaten skal følge efter den er blevet bygget.

Når alt dette er færdigt står du så tilbage med et færdigt image. Denne proces kan så automatisk køres hver dag, hver uge, eller hvornår end det nu er nødvendigt for at sørge for at der altid er et friskt image klar til brug.

Som lovet kan filerne tilhørende denne post findes på Github hvor vi også i fremtiden vil tilføje flere af vores templates.

Hos Rackhosting benytter vi os af Packer til regelmæssigt at bygge nye templates til brug i både vores interne, managed VMer, men også til templates der bliver uploadet til vores vCloud Director og gjort tilgængelig for self-service kunder.

Interesseret? På vores produktsider på www.rackhosting.dk kan du læse mere om vores ydelser i denne Cloud-verden, både som VMware Virtual Center løsning, Cloud Server løsning og Virtual Private Server / VPS hosting! Vi tilbyder sågar også dedikerede servere, colocation, office 365 backup, remote backup og meget mere!