Leve la collision de nom entre les familles fonctionnelles de la nomenclature (infra-pki, web-frontal...) et les domaines DNS. - docs/nomenclature.yml : cle domaines -> fonctions (+ commentaires). - inventory_gui.py : domaineDe/infoDomaine -> fonctionDe/infoFonction, nomenclature.fonctions, libelles et placeholder alignes. - inventory_rules.py : docstring. Aucun role ni inventaire impacte (nomenclature lue a la planification). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|---|---|---|
| docs | ||
| filter_plugins | ||
| inventories | ||
| playbooks | ||
| roles | ||
| scripts | ||
| .gitignore | ||
| AGENTS.md | ||
| ansible.cfg | ||
| CHANGELOG.md | ||
| CLAUDE.md | ||
| LICENSE | ||
| Makefile | ||
| README.md | ||
| requirements.yml | ||
| SOLUTION.md | ||
Set-OPS — Votre artisan numérique
Dépôt Ansible central pour construire, configurer, maintenir et documenter les systèmes de Chezlepro Inc.
Mission
Set-OPS ne se limite plus à l'exploitation : il définit et construit l'écosystème numérique souverain de Chezlepro Inc. — une infrastructure interne auto-suffisante, sans dépendance SaaS, décrite en code et pilotée par des registres machine-lisibles qui font office de source unique de vérité (docs/nomenclature.yml, docs/dependances-groupes.yml, docs/bases-donnees.yml).
Piliers de l'écosystème :
- identité — machines (PKI / certificats) et utilisateurs (annuaire + SSO) ;
- confiance — autorité de certification interne (ACME) ;
- nommage et adressage — DNS interne et nomenclature dérivable ;
- données — bases relationnelles et cache, avec registre des connexions ;
- communication — relais courriel interne ;
- observabilité et supervision — métriques, journaux, tableaux de bord, supervision active ;
- applicatif — services internes (forge, etc.) et couche web.
L'état voulu est déclaratif et convergent (appliqué par les groupes Ansible), souverain par conception, mais piloté par l'opérateur (pas d'auto-remédiation : la boucle n'est pas fermée). Une grande partie est aujourd'hui définie et validée avant d'être déployée sur des VM réelles ; le template Debian 13 reste la fondation, pas la finalité.
Cadre et règles d'autorité : voir AGENTS.md (section « Mission et identité »).
Portée transverse
Au-delà des piliers ci-dessus, le dépôt couvre des préoccupations transverses, communes à toutes les VM :
- templates de VM Proxmox (la fondation) ;
- groupes de conformité et durcissement ;
- maintenance ;
- sauvegardes.
Premier chantier
Template Debian 13 Proxmox :
playbooks/modeles_vm/debian13_proxmox_preparer.yml
playbooks/modeles_vm/debian13_proxmox_verifier.yml
playbooks/modeles_vm/debian13_proxmox_nettoyer.yml
Principe
Le template contient seulement le socle commun.
Les services spécialisés seront installés ensuite sur les clones :
- NGINX ;
- PostgreSQL ;
- MariaDB ;
- Docker/Podman ;
- monitoring complet ;
- applications métier.
Exploitation courante
Un Makefile fournit les commandes d'exploitation principales.
Afficher l'aide :
make
Valider le dépôt :
make verifier
Inspecter les inventaires :
make inventaire
make hote-afficher HOTE=web-frontal-01
Ouvrir l'interface locale de gestion d'inventaire :
make inventaire-ui
Planifier une VM sans la créer ni la déployer :
make hote-planifier HOTE=obs-01 VMID=94101 GROUPES="serveurs_debian serveurs_durcis serveurs_prometheus serveurs_loki"
Ajouter une VM à l'inventaire production et l'associer aux groupes qui détermineront sa configuration :
make hote-ajouter HOTE=web-frontal-01 VMID=95301 ADRESSE_IP=10.1.15.31 GROUPES="serveurs_debian serveurs_durcis"
make hote-groupes HOTE=web-frontal-01 GROUPES="serveurs_debian serveurs_durcis"
Chaque groupe opérationnel doit avoir son playbook homonyme dans playbooks/groupes/.
La conformité normale des VM passe par ces playbooks de groupes. Les rôles de socle et de durcissement sont appliqués par serveurs_debian et serveurs_durcis, pas par des playbooks de couches séparés.
Les groupes opérationnels avec des hôtes, comme serveurs_web_frontaux ou clients_dns, sont validés contre playbooks/groupes/ par les commandes d'inventaire.
Le catalogue des services et intégrations prévus est dans docs/catalogue-services.md.
Les dépendances causales entre groupes sont dans docs/dependances-groupes.yml.
Le runbook du DNS interne initial est dans docs/dns-interne.md.
La nomenclature des noms de VM et des VMID est dans docs/nomenclature-vm.md.
Créer un clone depuis le modèle Debian 13 via l'API Proxmox :
make config
make creer-vm HOTE=web-frontal-01 VMID=95301 VLAN=15 ADRESSE_IP=10.1.15.31 PASSERELLE=10.1.15.1 GROUPES="serveurs_debian serveurs_durcis"
make deployer HOTE=web-frontal-01
Les valeurs Cloud-Init communes déjà présentes dans le modèle Proxmox sont héritées par les clones.
Préparer le golden template Debian 13 Proxmox :
make preparer-modele
make verifier-modele
Le nettoyage final du template est protégé :
make nettoyer-modele CONFIRMER=true
Déployer ou remettre en conformité une VM Debian clonée depuis le template :
make deployer HOTE=web-frontal-01
Déployer ou remettre en conformité un groupe :
make deployer-groupe GROUPE=serveurs_debian
Les déploiements de groupes ciblent automatiquement les hôtes actifs seulement.