Files

T

Johan LEROY 0db69fd023 feat(infra): Terraform provisionne la VM, GitHub Actions continue de déployer

Le seul Terraform du dépôt installait un cluster k3s que rien ne consomme, et
sa racine ne passait même pas `terraform init` : depuis Terraform 1.x, un
provisioner `destroy` impose que tout le bloc `connection` ne lise que `self`,
et celui du module k3s lisait `var.*`. Il est corrigé en batissant la connexion
sur `triggers`, où ne figurent que l'adresse, le port, l'utilisateur et le
chemin de la clé : jamais la clé ni un mot de passe.

`environments/vm-eni` provisionne la machine qui porte la recette et la
production : Docker et le plugin Compose, `scripts/provision-host.sh`, puis
l'enregistrement du runner. Rien n'y construit d'image ni ne lance de
conteneur, et un `apply` n'interrompt pas la stack qui tourne. Le déploiement
continu ne bouge pas : `deploy.yml` reste le seul chemin de livraison.

`environments/dev` devient `k3s-cible`, parce qu'il provisionnait un cluster et
pas un environnement applicatif, et que `rec` et `prod` vivent sur la même
machine. `environments/prod`, dossier vide, disparaît.

`infra.yml` formate et valide chaque racine à chaque push : c'est l'absence
d'un tel job qui a laissé ce Terraform cassé sans que rien ne le dise. La
boucle parcourt `environments/*`, une racine ajoutée est couverte sans y
toucher.

ADR 0010 pour la frontière entre provisionnement et livraison, et la doc
d'architecture alignée dessus.

2026-09-22 11:27:21 +02:00

proxy

Merge branch 'main' into dev

2026-09-22 09:03:17 +02:00

terraform

feat(infra): Terraform provisionne la VM, GitHub Actions continue de déployer

2026-09-22 11:27:21 +02:00

README.md

feat(infra): Terraform provisionne la VM, GitHub Actions continue de déployer

2026-09-22 11:27:21 +02:00

README.md

Infrastructure

Provisionnement Terraform des machines on-premise. Terraform prepare la machine, GitHub Actions deploie l'application : voir l'ADR 0010. Rien ici ne construit d'image ni ne lance de conteneur.

terraform/modules : modules reutilisables.
- k3s : installe un cluster k3s single-node sur une machine distante via SSH (script officiel get.k3s.io) et rapatrie le kubeconfig en local.
terraform/environments/<racine> : une racine par machine provisionnee.
- vm-eni : la VM eadl-2025-nantes-g3, qui porte les environnements rec et prod (ADR 0009). Installe Docker, execute scripts/provision-host.sh, enregistre le runner GitHub Actions.
- k3s-cible : le cluster k3s, cible a terme de docs/architecture/10-infra.md. Jamais applique.

Usage (environments/vm-eni)

cd infra/terraform/environments/vm-eni
cp terraform.tfvars.example terraform.tfvars
terraform init
terraform apply

terraform.tfvars est ignore par git. Trois valeurs sont a renseigner avant l'apply :

proprietaire : l'utilisateur qui possede /srv/enervision et fait tourner le runner. Il doit deja exister sur la machine.
runner_version : a epingler depuis https://github.com/actions/runner/releases.
runner_token : jeton d'enregistrement, valable une heure et pour une seule inscription. Parametres du depot, Actions, Runners, New self-hosted runner. Seul un administrateur du depot peut le creer.

Apres l'apply, la machine porte /srv/enervision/rec et /srv/enervision/prod, chacun avec son .env et son certificat. Le premier demarrage reste manuel, make stack-up dans chaque dossier ; les suivants sont joues par le runner a chaque push sur dev et sur main.

Retirer le runner se fait a la main, depuis les parametres du depot : terraform destroy ne le desinscrit pas.

Usage (environments/k3s-cible)

cd infra/terraform/environments/k3s-cible
cp terraform.tfvars.example terraform.tfvars   # renseigner ssh_host / ssh_private_key_path
terraform init
terraform apply

Le kubeconfig est ecrit localement au chemin defini par kubeconfig_output_path (par defaut ./kubeconfig, ignore par git).