Packer¶

Qu’est-ce que Packer ?¶

Packer est une solution d”Hasicorp qui permet de déployer et de paramétrer des images machines. Ce dernier est plutôt orienté machine virtuelle. Pour fonctionner, Packer repose sur un système de builders comprendre des configurations propres à un hyperviseur et de provisioners : des scripts à passer une fois la machine installée. Chaque builders va donc avoir besoin de paramètres spécifiques tandis que les provisioners seront identiques entre les différentes machines à OS équivalent. De mon point de vue, le plus chiant sur Packer, ce sont les machines Linux car chacune d’elle dispose de sa propre boot commande … Un enfer. Bon après, on va pas parler de preseed.

Installation¶

Packer est maintenu par HashiCorp. Le plus simple pour le télécharger, c’est de passer par apt.

wget -O- https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.lists
sudo apt update && sudo apt install packer

Configuration¶

Sécurisation¶

Utilisation¶

Présentation¶

Packer embarque quelques concepts assez particulier et pas évident de prime abord. Les blocs suivants sont les minimums nécessaires :

packer {
  required_plugins {
    qemu = {
      version = "~> 1"
      source  = "github.com/hashicorp/qemu"
    }
  }
}

source qemu "Debian" {
  # La configuratoin d'un debian en utilisatn l'hyperviseur QEMU
}
build {
  sources = [
    "source.qemu.Debian"
  ]
}

Deux posibilités :

Soit on met tout dans le même fichier. Plutôt simple, mais on perd pas mal en flexibilité et lecture je trouve.
Soit on fait différents fichiers.

Lorsque l’on voudra lancer le déploiement d’une machines, il faut d’abord initier packer pour qu’il télécharge ses plugins puis lancer le build.

ls ./
 build.pkr.hcl  qemu.pkr.hcl  variables.pkr.hcl  virtualbox.pkr.hcl
packer init ./
 Installed plugin github.com/hashicorp/qemu v1.1.0 in "/home/lucas/.config/packer/plugins/github.com/hashicorp/qemu/packer-plugin-qemu_v1.1.0_x5.0_linux_amd64"
packer build ./

La génération se fait selon ce que vous avez mis dans la source.

Installation automatique¶

Le principe de packer est de pouvoir installer sans interaction utilisateurs des systèmes. Pour cela, il utilise les outils propre à chaque OS.

Debian - Preseed¶

Preseed est la méthode de Debian pour paramétrer une machine. Honettement, c’est une horreur. “y’a rien qui est documenté, les devs ont fait des choix chelou (le partionnement en pourcent de RAM ? A quel moment ?) … C’est plutôt chiant. Mais je commence à avoir un truc assez complet à force de fouiller internet. Alors je le présenterai ici.

RedHat - KickStart¶

KickStart est la méthode de RedHat pour paramétrer une machine. Pas encore testé.

Ubuntu ??? - Ds¶

DS est l’idée (de merde) d’Ubuntu à partir de la 20.04. Le principe ? Preseed est trop merdique, on l’abandonne complètement et on passe sur une techno différente. Fausse bonne idée : en faisant ça, ils s’éloignent du côté Debian-familly, et foutent plutôt fortement la merde. Bref, nouvelle techno à apprendre.

Windows - Unattended¶

Windows a aussi sa façon de paramétrer par défaut ses machines. Plutôt bien pensé, les fichiers unattended.xml embarquent quelques failles (chiffrement réversible des mots de passes), mais dans l’absolu, c’est pas mal foutu.

guest_os_type¶

Le Guest OS Type est le plus compliqué à saisir. Il s’agit du nom de l’OS d’après l’hyperviseur. Ainsi, pour VMWare vous pouvez vous référez à cette documentation. Dans notre cas, il faut trouver Windows 10 Serveur soit windows9Server64Guest. Dans le cas d’un Hyper-V, cette variable n’est pas définie.

TroubleShooting¶

floppy_files ou secondary_iso_images ?¶

On vient de le voir la configuration peut changer entre floppy et secondary_iso. D’un point de vu pratique, le floppy_files permet d’éviter d’avoir à faire une iso et donc est plus approprié dans le cas de changements fréquents. A l’inverse, l’iso du secondary_iso assure que la configuration n’a pas été modifiée depuis la fabrication de l’image.

De plus, Hyper-V interdit l’utilisation de floppy dans les images de générations 2. on est donc forcée de faire des isos.