Johan LEROY
10cc408b03
Infra / Formatage et validation Terraform (push) Successful in 50s
Troisième projet Compose sur la VM ENI, /srv/enervision/dev, alimenté par workflow_dispatch de n'importe quelle branche autre que dev et main (https://dev.enervision.local:9443). La recette suit toujours dev, la production main. - deploy.yml : routage main -> prod, dev -> rec, autre -> dev ; groupe de concurrence par environnement et non plus par branche. - provision-host.sh : prépare le dossier dev (ports 9443, 5435, 8027, 8084) ; passe safe.directory à git, faute de quoi un second passage en root, celui de terraform apply, échoue sur les clones déjà remis au runner. - ADR 0017, 10-infra.md, 50-cicd.md, infra/README.md à jour.
55 lines
2.4 KiB
Markdown
55 lines
2.4 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 `dev`, `rec` et `prod`
|
|
([ADR 0009](../docs/adr/0009-deux-environnements-compose-sur-la-vm-eni.md),
|
|
[ADR 0017](../docs/adr/0017-environnement-dev-a-la-demande.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/dev`, `/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`, et a chaque lancement manuel d'une autre branche pour `dev`.
|
|
|
|
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).
|