43 lines
1.7 KiB
Markdown
43 lines
1.7 KiB
Markdown
# Intégrations futures des VM
|
|
|
|
Les serveurs centraux ne sont pas encore en place. Les rôles d'intégration doivent donc rester optionnels et désactivés par défaut tant que leurs dépendances n'existent pas.
|
|
|
|
## Séparation
|
|
|
|
```text
|
|
Template Debian 13 Proxmox : socle commun minimal
|
|
Cloud-init : identité initiale du clone
|
|
Set-OPS + Ansible : configuration réelle du serveur
|
|
```
|
|
|
|
Le template ne doit pas être modifié pour chaque nouveau serveur. Les intégrations sont appliquées après clonage selon les groupes d'inventaire et les playbooks dédiés.
|
|
|
|
## Domaines prévus
|
|
|
|
```text
|
|
DNS interne : PowerDNS, résolveurs, enregistrements applicatifs
|
|
PKI interne : step-ca, ACME, confiance CA locale
|
|
Identité : LDAP, SSSD, Keycloak/OIDC selon le besoin
|
|
Supervision : Icinga2 agent ou checks distants
|
|
Métriques : Prometheus node_exporter
|
|
Visualisation : Grafana côté plateforme centrale
|
|
```
|
|
|
|
## Principes Ansible
|
|
|
|
- Chaque rôle d'intégration doit être désactivé par défaut.
|
|
- Chaque variable de rôle doit utiliser le préfixe du rôle.
|
|
- Les secrets ne doivent jamais être stockés en clair dans le dépôt.
|
|
- Un rôle ne doit pas échouer si son intégration est désactivée.
|
|
- Les playbooks applicatifs doivent être appliqués sur les clones, pas sur le template.
|
|
- Les opérations pouvant couper l'accès réseau ou SSH doivent exiger une confirmation explicite.
|
|
|
|
## Ordre logique de construction
|
|
|
|
1. DNS interne.
|
|
2. PKI interne et confiance CA.
|
|
3. Identité système et applicative.
|
|
4. Supervision et métriques.
|
|
5. Visualisation et alerting.
|
|
|
|
Cet ordre reste indicatif. Les rôles doivent rester découplés pour permettre une adoption progressive.
|