Set-OPS/README.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/serveurs.yml`, `docs/applications.yml`, `docs/bases-donnees.yml`, `docs/domaines.yml`, `docs/nomenclature.yml`, `docs/dependances-groupes.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é »).

## Le plan : on édite, l'inventaire se génère

`Set-OPS` se pilote par un **plan**, pas par l'édition directe de l'inventaire.
`inventories/production/hosts.yml` est **généré** depuis le plan — **ne pas l'éditer à la main**.

```
éditer le PLAN  →  make instancier (revoir le diff)  →  make instancier-appliquer  →  make deployer
```

- **Plan** : `docs/serveurs.yml` (les VM), `docs/applications.yml` (les services et leurs liens), `docs/bases-donnees.yml`, `docs/domaines.yml`, dérivés via `docs/nomenclature.yml`.
- **GUI** (`make inventaire-ui`) : vues **Serveurs** et **Applications** pour éditer, puis « Appliquer le plan » ; la vue **Inventaire** est en lecture seule.
- VMID / IP / VLAN sont **dérivés** de la `fonction` ; les groupes d'une VM sont dérivés des applications qui y tournent.

Guide complet : **`docs/plan-et-generation.md`**.

## 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 :

```text
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 :

```bash
make
```

Valider le dépôt :

```bash
make verifier
```

Inspecter les inventaires :

```bash
make inventaire
make hote-afficher HOTE=web-frontal-01
```

Ouvrir l'interface locale de gestion d'inventaire :

```bash
make inventaire-ui
```

Planifier une VM passe désormais par le **plan**, pas par l'édition de l'inventaire :

1. déclarer la VM dans `docs/serveurs.yml` (vue **Serveurs** du GUI, ou `make serveurs`) — `fonction`, `etat`, placement ; VMID/IP/VLAN sont dérivés ;
2. déclarer les services qui y tournent dans `docs/applications.yml` (vue **Applications**) ;
3. régénérer l'inventaire :

```bash
make instancier             # génère + diff sémantique (que va-t-il changer ?)
make instancier-appliquer   # régénère inventories/production/hosts.yml
```

Les anciennes commandes `make hote-planifier` / `hote-ajouter` / `hote-groupes` éditaient l'inventaire **directement** ; elles sont **supplantées** par le plan (l'inventaire est généré, ne pas l'éditer à la main).

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 `serveur_debian` et `serveur_durci`, pas par des playbooks de couches séparés.

Les groupes opérationnels avec des hôtes, comme `serveur_web_frontal` ou `client_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 :

```bash
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="serveur_debian serveur_durci"
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 :

```bash
make preparer-modele
make verifier-modele
```

Le nettoyage final du template est protégé :

```bash
make nettoyer-modele CONFIRMER=true
```

Déployer ou remettre en conformité une VM Debian clonée depuis le template :

```bash
make deployer HOTE=web-frontal-01
```

Déployer ou remettre en conformité un groupe :

```bash
make deployer-groupe GROUPE=serveur_debian
```

Les déploiements de groupes ciblent automatiquement les hôtes actifs seulement.