Johan LEROY
0db69fd023
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.
2.3 KiB
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 officielget.k3s.io) et rapatrie le kubeconfig en local.
terraform/environments/<racine>: une racine par machine provisionnee.vm-eni: la VMeadl-2025-nantes-g3, qui porte les environnementsrecetprod(ADR 0009). Installe Docker, executescripts/provision-host.sh, enregistre le runner GitHub Actions.k3s-cible: le cluster k3s, cible a terme dedocs/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/enervisionet 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).