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.
53 lines
2.3 KiB
Markdown
53 lines
2.3 KiB
Markdown
# Infrastructure
|
|
|
|
Provisionnement Terraform des machines on-premise. Terraform prepare la machine, GitHub Actions
|
|
deploie l'application : voir l'[ADR 0010](../docs/adr/0010-terraform-provisionne-github-actions-deploie.md).
|
|
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](../docs/adr/0009-deux-environnements-compose-sur-la-vm-eni.md)). 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)
|
|
|
|
```bash
|
|
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)
|
|
|
|
```bash
|
|
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).
|