packer build image-wordpress.pkr.hcl suivi de terraform apply : ces deux commandes, exécutées dans cet ordre précis, résument l’assemblage mis en place pour garantir que chaque nouveau serveur WordPress provisionné, qu’il s’agisse d’un environnement de test ou de production, parte d’une base rigoureusement identique.
Ce billet décrit l’architecture de ce pipeline, pensé pour des équipes qui veulent des serveurs reproductibles entre environnements, sans dépendre d’un serveur configuré manuellement au fil du temps par accumulation de correctifs successifs. La configuration applicative post-déploiement, gérée par un outil distinct, reste hors du périmètre décrit ici.
Le problème que ce pipeline résout
Un serveur configuré manuellement, puis maintenu par petites modifications successives au fil des mois, finit toujours par diverger de sa documentation initiale, si tant est qu’une documentation ait été tenue à jour. Reproduire ce même serveur à l’identique, pour un environnement de test ou en cas de sinistre nécessitant une reconstruction complète, devient alors un exercice incertain, dépendant de la mémoire de la personne qui l’a configuré.
Packer répond à ce problème en figeant, à un instant donné, une image système complète et versionnée, construite à partir d’un fichier de définition explicite plutôt que d’une suite de manipulations manuelles non tracées.
Rôle de Packer : construire l’image de base
Le fichier de définition Packer décrit, de façon déclarative, les paquets système à installer, les versions de PHP et de MySQL retenues, et les réglages de base communs à tous les serveurs du parc. Cette image est reconstruite à chaque évolution du socle logiciel, avec un identifiant de version explicite permettant de savoir précisément quelle image est déployée sur quel serveur.
source "amazon-ebs" "wordpress-base" {
ami_name = "wordpress-base-{{timestamp}}"
instance_type = "t3.small"
region = "eu-west-3"
source_ami_filter {
filters = {
name = "debian-12-amd64-*"
}
owners = ["136693071363"]
}
}
build {
sources = ["source.amazon-ebs.wordpress-base"]
provisioner "shell" {
script = "provision-base.sh"
}
}
Le script provision-base.sh installe les paquets communs (nginx, PHP-FPM, les extensions PHP requises par WordPress) sans configurer les particularités propres à un site donné, cette étape restant du ressort de l’outil de configuration applicative exécuté après le déploiement de l’instance.
Rôle de Terraform : déployer l’image de façon reproductible
Une fois l’image Packer construite et versionnée, Terraform prend le relais pour déployer une nouvelle instance à partir de cette image précise, en référençant son identifiant plutôt qu’un nom générique susceptible de correspondre à plusieurs versions au fil du temps.
data "aws_ami" "wordpress_base" {
most_recent = true
owners = ["self"]
filter {
name = "name"
values = ["wordpress-base-*"]
}
}
resource "aws_instance" "serveur_wordpress" {
ami = data.aws_ami.wordpress_base.id
instance_type = "t3.small"
tags = {
Name = "wordpress-prod-01"
}
}
Schéma général du pipeline
Fichier de définition Packer (versionné dans Git)
|
v
Construction d'une image système figée
|
v
Fichier de définition Terraform (versionné dans Git)
|
v
Déploiement d'une instance à partir de l'image
|
v
Outil de configuration applicative (hors de ce pipeline)
Ce que cette séparation apporte concrètement
- Un environnement de test peut être reconstruit à l’identique de la production en réutilisant exactement la même image Packer, éliminant les écarts de comportement liés à une divergence de version de paquet système.
- Une reconstruction après sinistre repart d’une image connue et versionnée, plutôt que d’un serveur reconfiguré manuellement dans l’urgence, sous pression et avec un risque d’oubli plus élevé.
- Chaque évolution du socle logiciel commun est tracée dans l’historique Git du fichier de définition Packer, offrant une traçabilité que ne permet pas une configuration accumulée manuellement au fil du temps.
Séparer la construction de l’image du déploiement de l’instance clarifie la responsabilité de chaque outil : l’un fige un socle reproductible, l’autre déploie ce socle de façon prévisible.
Pour aller plus loin
Ce pipeline ne couvre volontairement que le socle système commun à l’ensemble du parc. La configuration propre à chaque site WordPress (réglages spécifiques du pool PHP-FPM, certificats TLS du domaine concerné, configuration de la base de données du client) reste gérée par un outil de configuration distinct, exécuté une fois l’instance provisionnée par ce pipeline Packer et Terraform.
