Johan LEROY
dbcd5c4240
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.
2.9 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.
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/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).