Files

T

Johan LEROY e53c7e441c feat(infra): déploie Garage par environnement, secrets par le .env, fumée S3 en CI

Reprend l'amorce de la PR 164 et l'intègre à la stack : service `garage` (dxflrs/garage v2.4.1,
`--single-node --default-bucket`) dans docker-compose.yml, garage.toml versionné sans secret,
ports sur 127.0.0.1 décalés par environnement dans provision-host.sh, garde des six clés
GARAGE_* dans le Makefile, cible Prometheus avec jeton, tests de fumée déplacés dans
tests/garage et joués par le job compose d'infra.yml contre le vrai conteneur, SSE-C compris.
Variables APP_S3_* et APP_READING_RETENTION_DAYS posées sur airflow-scheduler pour le DAG
`retention`. ADR 0019.

Closes #24

2026-09-24 10:30:04 +02:00

front

feat(deploy): URL sans port et certificats Let's Encrypt sur la VM ENI

2026-09-23 11:21:12 +02:00

garage

feat(infra): déploie Garage par environnement, secrets par le .env, fumée S3 en CI

2026-09-24 10:30:04 +02:00

proxy

fix(deploy): passe à dynv6 et rend le défi DNS-01 indépendant du fournisseur

2026-09-23 11:47:07 +02:00

terraform

fix(deploy): passe la prod sur prod.enervision-g3.dynv6.net

2026-09-23 12:35:20 +02:00

README.md

fix(deploy): passe la prod sur prod.enervision-g3.dynv6.net

2026-09-23 12:35:20 +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 dev, rec et prod (ADR 0009, ADR 0017). 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/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.

Noms et certificats (ADR 0018) : avant l'apply, la zone domaine doit exister chez dynv6 et son jeton se trouver dans <racine>/dns.token (600, proprietaire). L'apply fait alors pointer la zone, prod, rec et dev vers la machine, obtient un certificat Let's Encrypt par environnement et planifie leur renouvellement ; sans jeton, chaque environnement garde un certificat auto-signe. Le frontal SNI (infra/front) se demarre une fois depuis le dossier de la prod, make front-up.

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).