Chezlepro/Set-OPS
Archived
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
This repository has been archived on 2026-06-26. You can view files and clone it, but cannot push or open issues or pull requests.
Set-OPS/README.md
Daniel Allaire 5dd3215d91 Formaliser l'identite d'ecosysteme numerique souverain 
Acter dans les docs d'autorite que Set-OPS ne se limite plus a
l'exploitation mais definit et construit l'ecosysteme numerique
souverain de Chezlepro Inc.

- AGENTS.md : nouvelle section « Mission et identite » (piliers,
  proprietes visees, nuances honnetes : pas auto-repare, defini avant
  deploiement, registres = source unique).
- README.md : section « Mission » + « Domaines prevus » rationalise en
  « Portee transverse » (retire ce que les piliers couvrent deja).
- CHANGELOG.md : entree du 2026-06-22.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-22 19:58:44 -04:00

4.7 KiB
Raw Permalink Blame History

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.