Périmètre
infrastructure/ gère staging et rien d’autre. Aucune commande n’accepte d’argument de stage, il
n’y a pas de racine prod ni test. Un futur stage prod clonera la composition staging finie avec son
propre state, ses credentials, ses domaines, son sizing et sa propriété des secrets.
OpenTofu possède le VPC, Postgres, Redis, les buckets, le registry, l’IAM, les entrées Secret
Manager, le domaine TEM, les containers, les domaines custom, le token Cockpit et les
enregistrements Route 53 optionnels. La CI possède l’image : les ressources container portent
ignore_changes = [image].
L’offre payante TEM (Essential ou Scale) est un prérequis externe au niveau projet : le provider
ne l’expose qu’en data source. Elle survit à un destroy de la stack applicative.
Contrat de sûreté
- Ne jamais lire, afficher, éditer ou commiter
.envrc,terraform.tfvars,.terraform/, le state, un plan sauvegardé, ou une valeur de secret. - Les plans sauvegardés contiennent des secrets en clair :
make clean-plansaprès usage. - Ne jamais appliquer si le chiffrement du state n’est pas vérifié. Les applies foundation, core, normal et destroy passent tous par le gate lecture-seule versioning/SSE du bucket de state.
- Postgres n’est public que pour la CIDR fixe du migration runner.
0.0.0.0/0et::/0sont rejetés. - Route 53 utilise
TF_VAR_route53_aws_access_key/TF_VAR_route53_aws_secret_key. LesAWS_*ambiants appartiennent au backend S3-compatible du state et ne doivent jamais être réutilisés pour Route 53. - Rotation de credential : ajouter une génération dans la map retenue, la sélectionner comme active,
appliquer, basculer et vérifier les consommateurs, puis supprimer l’ancienne dans un apply revu
séparé. Jamais
tofu taint. - DNS/TLS, activation de l’utilisateur runtime de la base, création de ressource payante, opération de state, révocation de credential et suppression de ressource exigent chacun leur propre approbation humaine.
Workflow quotidien
make help liste tout. Autres cibles utiles : make fmt, make fmt-check, make validate,
make verify-stage (readiness, isolation CORS par audience, frontière de stockage, spoofing de
rate-limit).
Credentials locaux
Deux paires distinctes, chargées par direnv depuis un.envrc ignoré par git :
Le projet
kare-state est volontairement isolé du projet applicatif : le bucket
kare-staging-opentofu-state et son historique survivent à la destruction de la stack.
Bootstrap d’un stage neuf
1
Identités
make bootstrap-stage-apply dans l’organisation staging, make bootstrap-state-apply dans celle
qui contient kare-state. Fusionner les snippets de credentials générés dans le .envrc ignoré,
compléter les entrées staging, puis make init.2
Foundation : le registry seul
make foundation-plan → make foundation-show → make foundation-apply.3
Seed des images
Depuis un checkout propre et revu, avec
HEROUI_AUTH_TOKEN et le
NEXT_SERVER_ACTIONS_ENCRYPTION_KEY de l’environment : make seed-images. Il construit et pousse
des images boot-only API, Backoffice, Audit et Kare pour le SHA exact. Il crée un alias
staging-latest manquant, mais ne déplace jamais un alias existant.4
TEM
Confirmer qu’une offre Scaleway TEM Essential ou Scale est active sur le projet du stage.
5
Core : la stack sans domaines
make core-plan → make core-show → make core-apply. Crée la stack et le domaine TEM sans
domaines custom ni validation TEM, parce que le DNS manuel survivant pointe encore sur l’ancienne stack.6
DNS, à la main
Lire les outputs
api_cname_records, frontend_cname_records, tem_dns_records. Le propriétaire
DNS met à jour exactement les six CNAME staging et crée les enregistrements SPF, DKIM, MX et DMARC
dans Route 53. Vérifier la propagation publique de chaque valeur émise.7
Plan complet
make plan → make show-plan → make apply. Avec le DNS déjà correct, ce plan crée les six
domaines custom Scaleway et leurs certificats TLS, et valide le domaine d’envoi TEM.8
Chiffrement des buckets
Avec approbation séparée :
make storage-apply, puis make storage-status pour prouver
versioning et SSE-ONE sur les buckets applicatifs neufs.9
GitHub + premier déploiement
make sync-secrets, configurer l’Environment GitHub staging, puis lancer un déploiement all.10
Premier opérateur
Sur la base vide :
make bootstrap-bo-admin EMAIL=<operateur>@akord-securite.fr. Le helper lit
l’URL publique de la base et le CA directement depuis Scaleway, jamais un .env applicatif, et
affiche le mot de passe initial une seule fois en local.11
Données réelles
Se connecter au Backoffice, créer l’organisation et l’utilisateur staging par le flux produit,
synchroniser les credentials E2E dédiés.
STAGING_AUTO_DEPLOY_ENABLED reste false jusqu’à ce
que tout le flux soit sain.Topologie staging actuelle
512 MB de RAM sur l’API meurt en « heap out of memory » au démarrage (416 MB RSS au repos) : ne
descends pas la limite.
Destruction
Il n’y a pas de commande de destroy directe. « Repartir de zéro » détruit la stack applicative gérée, pas son plan de contrôle : le projet Scaleway staging, le projetkare-state, le bucket de state et son historique, les identités de
bootstrap, la zone et les enregistrements Route 53, les environments GitHub et les projets Sentry
sont préservés.
Avant destruction : STAGING_AUTO_DEPLOY_ENABLED=false, make backup-postgres BACKUP_DIR=<chemin sûr>
avec dump et checksum conservés hors repo, inventaire des objets retenus et des images du registry.
Redis est éphémère et n’est pas une source de sauvegarde. make destroy-data-status puis, seulement
après une approbation de perte de données séparée, make destroy-data-purge — sa liste blanche codée
en dur ne peut toucher que uploads, exports et assets, jamais le bucket de state.