Files

T

History

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

dynv6 sert mal un TXT _acme-challenge à la racine de la zone : l'API ne
le liste ni ne le supprime, et un seul de ses trois serveurs le renvoie.
Le défi DNS-01 de la prod échouait donc à chaque essai, alors que rec. et
dev. passaient. La prod rejoint ses voisines en sous-domaine, ce qui aligne
aussi les trois noms sur les environnements.

- provision-host.sh : hôte prod.$DOMAINE, enregistrement A prod publié.
- Makefile : --dnssleep 90, le temps que les trois serveurs de dynv6
  servent le TXT avant la validation multi-réseaux de Let's Encrypt.
- deploy.yml, ADR 0018, 10-infra.md, infra/README.md, Terraform.

2026-09-23 12:35:20 +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

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