Archived

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.

Daniel Allaire 8f6de3ebe2 Construire l'ecosysteme de services et outiller l'inventaire

Registres (source unique):
- docs/nomenclature.yml: domaines, VMID, plan d'adressage 10.1.0.0/16 segmente.
- docs/bases-donnees.yml: bases applicatives (1 appli -> 1 base -> 1 owner -> 1 DSN).

Roles de service:
- Reseau/edge/PKI/mail: nginx, step_ca, sendmail.
- Donnees/identite: postgresql (consommateur du registre BD), redis, openldap, keycloak.
- Observabilite: prometheus, loki, grafana.
- Supervision: icinga (coeur; Icinga Web 2 differe). Forge: forgejo.

Integrations clientes:
- clients_metriques, clients_journaux, clients_pki, clients_ldap, clients_smtp.

Inventaire et outillage:
- make inventaire-ui: refonte (cartes, theme sombre, onglets, vue Chaine VM->groupes->
  playbooks->roles), saisie du provisioning, auto-proposition depuis la nomenclature,
  deploiement securise (verifier/deployer, jeton anti-CSRF, verrou, mot de passe vault),
  robustesse reseau (connexions fermees, favicon).
- Makefile: cible verifier-deploiement; detection d'un group_vars de production chiffre.
- Scission serveurs_web -> serveurs_web_frontaux/dorsaux; migration de l'adressage vers
  10.1.x; retrait des hotes de test; planification des hotes; requirements.yml.

Chaque role valide en --syntax-check et ansible-lint (profil production).
Secrets references depuis Ansible Vault (jamais en clair); roles non testes live.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-06-22 18:06:11 -04:00

2 KiB

Raw Permalink Blame History

DNS interne Chezlepro

Le service DNS interne est la premiere capacite de plateforme.

Groupes

serveurs_powerdns -> service DNS central PowerDNS Authoritative
clients_dns       -> integration cliente DNS

clients_dns depend de serveurs_powerdns dans docs/dependances-groupes.yml.

Zone initiale

La zone initiale est :

chezlepro.internal

Elle est definie dans :

inventories/production/group_vars/serveurs_powerdns.yml

Enregistrement automatique

Le role serveurs_powerdns genere la zone a partir de l'inventaire.

Les hotes qui remplissent ces conditions sont ajoutes automatiquement :

hote dans hotes_actifs
ansible_host defini

Exemple :

web-frontal-01 ansible_host=10.1.15.31
-> web-frontal-01.chezlepro.internal A 10.1.15.31

Les enregistrements additionnels explicites sont dans serveurs_powerdns_records.

Backend PowerDNS

Le premier jalon utilise le backend BIND de PowerDNS.

Raison :

pas de dependance prematuree a PostgreSQL ;
zone lisible et generee par Ansible ;
idempotence simple ;
bon point de depart pour la supervision.

Quand serveurs_postgresql sera stable, il sera possible de migrer vers un backend SQL si le besoin operationnel le justifie.

Clients DNS

Le role clients_dns valide :

qu'un serveur serveurs_powerdns actif existe ;
que la zone repond a une requete SOA ;
que le nom de l'hote existe dans la zone.

La modification du resolver local est protegee :

clients_dns_apply: true
clients_dns_confirm: true

Sans ces deux variables, le role valide les prerequis mais ne modifie pas /etc/resolv.conf.

Cette protection est volontaire : une mauvaise configuration DNS peut couper la resolution de noms.

Surveillance a prevoir

Les premiers checks utiles :

service pdns actif ;
port UDP/TCP 53 disponible ;
SOA de chezlepro.internal resoluble ;
enregistrement ns1.chezlepro.internal resoluble ;
enregistrements des hotes actifs presents ;
serial de zone attendu ;
latence de resolution.

2 KiB Raw Permalink Blame History