Provisioners

Un provisioner exécute une action sur la VM temporaire de build, entre sa création par le source et la publication de l’image. Plusieurs provisioners s’enchaînent dans l’ordre où ils sont déclarés.

---

Provisioners courants

Provisioner	Rôle
shell	Exécute un script ou des commandes inline sur la machine cible (via le communicator SSH/WinRM)
shell-local	Exécute une commande sur la machine qui lance packer build (pas sur la VM temporaire)
file	Copie un fichier/dossier local vers la VM temporaire
ansible	Exécute un playbook Ansible contre la VM temporaire
powershell	Équivalent shell pour Windows
windows-restart	Redémarre la VM Windows temporaire et attend qu’elle soit de nouveau joignable

---

Exemple — enchaînement typique

build {
  sources = ["source.googlecompute.app"]
 
  provisioner "shell" {
    script = "scripts/install-app.sh"
  }
 
  provisioner "file" {
    source      = "config/"
    destination = "/tmp/config"
  }
 
  provisioner "shell" {
    inline = [
      "sudo mv /tmp/config/* /etc/app/",
      "sudo systemctl enable app.service",
    ]
  }
}

L’ordre compte : ici, l’application est installée, puis sa configuration copiée, puis déplacée et le service activé — le tout figé dans l’image plutôt que rejoué à chaque boot par un startup_script Terraform.

---

Le communicator

Le builder établit une connexion (SSH par défaut sur Linux, WinRM sur Windows) appelée communicator, utilisée par tous les provisioners pour agir sur la VM temporaire. Ses paramètres (ssh_username, ssh_timeout…) sont définis dans le bloc source, pas dans les provisioners.

---

Provisioner ansible — remplacer une suite de shell par un playbook

packer {
  required_plugins {
    ansible = {
      source  = "github.com/hashicorp/ansible"
      version = ">= 1.1.0"
    }
  }
}
 
build {
  sources = ["source.googlecompute.postgresql_health_agent"]
 
  provisioner "ansible" {
    playbook_file = "${path.root}/ansible/playbook.yml"
    user          = "packer"
  }
}

Comme googlecompute, ansible est un plugin à déclarer dans required_plugins. Il appelle ansible-playbook en interne : Packer génère un inventaire éphémère pointant vers la seule VM temporaire, et y injecte les paramètres de connexion SSH (user) — aucune configuration réseau à écrire à la main. Le playbook lui-même (roles, tasks, templates) est un sujet à part entière, voir Synthèse Ansible.

Intérêt par rapport à plusieurs shell empilés : idempotence des modules Ansible, organisation en rôles réutilisables, et rendu de fichiers de config via Jinja2 plutôt que des sed/heredoc dans un script.

---

En relation avec

• Anatomie d’un template Packer — où s’insèrent les provisioners dans build
• Builders — crée la VM sur laquelle les provisioners s’exécutent
• Post-processors — étape suivante, après les provisioners
• Synthèse Ansible — détail du provisioner ansible
• Packer — image pré-construite vs startup-script