Infrastructure OpenTofu
Décrivez votre infrastructure en code ou dessinez-la, faites calculer le plan, validez-le, puis appliquez-le : chaque étape est une étape de workflow, avec son historique.
Piles versionnées
Une pile est un ensemble de fichiers .tf versionné dans Serveurs › Infrastructure, avec un état par environnement. Pour protéger le serveur d'exécution, sont refusés : les fonctions de lecture de fichiers et local-exec, les modules, les blocs backend et cloud, les fournisseurs local et external. Seuls les fournisseurs autorisés s'installent : aws, azurerm, google, kubernetes, helm, random, null, time, tls, dns, cloudflare, digitalocean, hcloud, ovh, scaleway, alicloud.
Plan, validation, application
- Plan d'infrastructure calcule le plan sur l'état de la pile dans l'environnement de l'exécution, puis le conserve chiffré. Les créations, modifications, remplacements et suppressions sont présentés avant validation.
- Appliquer l'infrastructure attend la décision sans occuper de worker. Valider ou rejeter demande le rôle propriétaire ou administrateur, et la clé de l'environnement s'il est protégé. La validation porte sur ce plan précis : tout nouveau plan exige une nouvelle décision.
- L'application se fait sous verrou (une seule à la fois par pile et environnement), seulement si l'état n'a pas changé depuis le plan. Le plan enregistré est appliqué tel quel : rien n'est recalculé en silence.
À savoir. Une interruption pendant l'application rend le résultat indéterminé, et rien n'est réappliqué automatiquement. L'état produit est enregistré, même en cas d'échec partiel.
Schéma visuel
Le bloc Provisionner l'infrastructure (visuel) contient un schéma dessiné sur un canevas, pour un fournisseur : glissez les ressources, imbriquez-les (réseau › sous-réseau › ressource) et reliez-les (sécurité vers la ressource protégée, répartiteur vers les serveurs, calcul vers la base). L'Architecte IA peut proposer le schéma à partir d'une demande écrite ; rien n'est appliqué au canevas sans votre accord. Le code est généré, puis le plan, la validation et l'application se suivent dans la même étape.
| Fournisseur | Ressources | Identifiants |
|---|---|---|
| AWS | VPC, sous-réseaux publics ou privés, passerelles Internet et NAT, table de routage, groupe de sécurité, ALB, EC2, ECS, EKS, RDS, S3 | AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY |
| Azure | Réseau virtuel, sous-réseaux, groupe de sécurité réseau, Application Gateway v2, machine virtuelle Linux, AKS, PostgreSQL flexible, compte de stockage | ARM_CLIENT_ID, ARM_CLIENT_SECRET, ARM_TENANT_ID, ARM_SUBSCRIPTION_ID |
| Google Cloud | Réseau VPC, sous-réseaux, règle de pare-feu, répartiteur réseau TCP, Compute Engine, GKE, Cloud SQL, Cloud Storage | GOOGLE_CREDENTIALS (clé JSON d'un compte de service) |
| Alibaba Cloud | VPC, vSwitch, passerelle NAT avec IP élastique, groupe de sécurité, répartiteur SLB, instance ECS, ACK Pro, ApsaraDB RDS pour PostgreSQL, compartiment OSS | ALICLOUD_ACCESS_KEY, ALICLOUD_SECRET_KEY |
Réglages sûrs par défaut
- Stockage jamais public : S3 bloqué, compte Azure sans accès public, Cloud Storage et OSS avec accès public empêché.
- Bases sur réseau privé uniquement : RDS en sous-réseaux privés, PostgreSQL Azure en sous-réseau délégué, Cloud SQL et ApsaraDB sans adresse publique.
- Machines accessibles par clé SSH seulement ; suppression protégée en production pour les ressources critiques.
- États et plans chiffrés au repos ; le déverrouillage forcé est réservé aux administrateurs et journalisé.