terraform-proxmox-serveur-ubuntu/CICD.md

CI/CD — dépôt terraform-proxmox-serveur-ubuntu-24-04

La chaîne s'arrête à la création du serveur. Ansible n'est pas déclenché par la CI : il est joué depuis Semaphore, indépendamment.

Répartition

Étape	Outil	Déclencheur
fmt, validate, plan	Gitea Actions	pull request et push sur main
apply	Gitea Actions	lancement manuel, action=apply
destroy	Gitea Actions	lancement manuel, confirmation littérale DETRUIRE
Configuration applicative	Semaphore	manuel, après la fin de cloud-init

Préalables

1. OpenBao

Une clé est à ajouter au secret existant secret/proxmox : le dépôt du snippet cloud-init passe par SSH, le mot de passe du nœud est donc nécessaire.

bao kv patch secret/proxmox ssh_password='<mot de passe root du nœud pve>'

Le secret doit finir par contenir : api_url, api_token, node_name, ssh_password. L'adresse du nœud est déduite de api_url, il n'y a rien d'autre à saisir.

Politique et AppRole dédiés au projet, en lecture seule sur les deux secrets utiles :

bao policy write terraform-proxmox-ubuntu - <<'POLICY'
path "secret/data/proxmox"     { capabilities = ["read"] }
path "secret/metadata/proxmox" { capabilities = ["read"] }
path "secret/data/aws"         { capabilities = ["read"] }
path "secret/metadata/aws"     { capabilities = ["read"] }
POLICY

bao write auth/approle/role/terraform-proxmox-ubuntu \
    token_policies=terraform-proxmox-ubuntu token_ttl=1h token_max_ttl=4h

bao read  auth/approle/role/terraform-proxmox-ubuntu/role-id
bao write -f auth/approle/role/terraform-proxmox-ubuntu/secret-id

Si vous préférez ne pas multiplier les rôles, le couple role_id / secret_id déjà utilisé par le dépôt Debian convient tel quel : la politique y donne accès aux deux mêmes secrets, secret/proxmox et secret/aws.

2. Secrets et variables Gitea

Gitea ne détient que de quoi ouvrir OpenBao.

Secrets du dépôt (Paramètres → Actions → Secrets) :

Nom	Valeur
OPENBAO_ROLE_ID	sortie de role-id
OPENBAO_SECRET_ID	sortie de secret-id

Aucune variable de dépôt n'est nécessaire. L'adresse d'OpenBao a une valeur par défaut dans scripts/openbao-env.sh, et le backend S3 est écrit en dur dans state.tf : ni le bucket ni la région ne sont des secrets.

La clé d'état, backend/terraform-proxmox-serveur-ubuntu-24-04/terraform.tfstate, est différente de celle des autres projets. Deux dépôts partageant la même clé écraseraient mutuellement leur état.

3. Bit d'exécution du script

Le piège déjà rencontré sur proxmox-create-vm : le transfert depuis Windows perd le bit d'exécution, et le job échoue sur un « Permission denied ».

git update-index --chmod=+x scripts/openbao-env.sh
git commit -m "Rendre openbao-env.sh executable"

Le fichier .gitattributes livré fige les fins de ligne en LF, pour la même raison.

4. Clé publique

Chaque fichier vms/<nom>.tfvars est versionné et référence les clés publiques : vérifier le ssh-ed25519 AAAA... d'exemple avant le premier apply. Sans quoi la VM sera créée avec une clé inutilisable et il faudra la recréer — cloud-init ne rejoue rien.

Fonctionnement des workflows

scripts/openbao-env.sh s'authentifie en AppRole, lit les deux secrets et pousse dans l'environnement du job : TF_VAR_pve_endpoint, TF_VAR_pve_api_token, TF_VAR_pve_node, TF_VAR_pve_node_address, TF_VAR_pve_ssh_password, AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY. Chaque valeur sensible est passée en ::add-mask:: avant d'être exportée : elle apparaît en *** si un outil l'affiche.

Le script s'arrête avec un message explicite quand une clé manque dans OpenBao, plutôt que de laisser Terraform échouer sur une authentification vide.

deploy.yml calcule toujours un plan, et ne l'applique que si action=apply — c'est le plan enregistré qui est appliqué, pas un second calcul. À la fin, l'inventaire Ansible est publié en artefact (inventaire-ansible), utile surtout comme trace : l'adresse étant fixe, Semaphore peut se contenter d'un inventaire statique.

Côté Semaphore

La configuration Semaphore est décrite dans le dépôt qu'elle concerne : ansible/CICD.md.

Enchaînement d'un test complet

1. deploy.yml avec action=apply — environ 3 minutes.
2. Attendre la fin de cloud-init : ssh [email protected] 'cloud-init status --wait'.
3. Lancer le modèle Semaphore site.yml — 10 à 20 minutes.
4. Déposer les exports d'Enclume, relancer le modèle --tags clapi.
5. Pour repartir propre : destroy.yml avec la confirmation DETRUIRE, puis reprendre à l'étape 1.Aucune variable de dépôt n'est nécessaire : l'adresse d'OpenBao a une valeur par défaut dans scripts/openbao-env.sh, et le backend S3 est écrit en dur dans state.tf. Ni le bucket ni la région ne sont des secrets.

La clé d'état, backend/terraform-proxmox-serveur-ubuntu-24-04/terraform.tfstate, est différente de celle des autres projets : deux dépôts partageant la même clé écraseraient mutuellement leur état.