Le site portait trois services sur les sept du modele `origine`. Sa forge servait LE
GENOME EN CLAIR et aucune de ses machines n'avait de certificat — donc aucun chiffrement
est-ouest, ce que la doctrine zero-confiance interdit. site-pki-01 (step-ca) et
site-dns-01 (PowerDNS + resolveur colocalises) rejoignent les trois autres.
Quatre defauts que le site a fait tomber, chacun invisible chez un tenant :
- DNS bloque par notre propre default-deny. Un tenant a son resolveur DANS son reseau
et ne traverse jamais la frontiere ; le site interroge la sienne. La regle est derivee
de `site.dns_amorcage`, destination declaree, jamais `any`.
- serveur_cache_site n'installe rien : il marque un cache et lit les variables de
serveur_artefacts. Les defauts d'un role ne sont en portee que dans le play qui
l'inclut — une dependance de role regle l'ordre ET la portee.
- resoudre_idp partait meme avec OIDC desactive, et exigeait un plan. La resolution
suit desormais l'usage.
- le plancher /etc/hosts etait VIDE : `hotes_actifs` n'existait pas dans l'inventaire
du site. Un role qui reussit en n'ecrivant rien est la pire forme d'echec.
Une machine du site peut desormais se configurer (`variables:`), appliquee en dernier :
ce qu'une machine declare d'elle-meme prime sur ce que le site declare pour toutes.
Verifie et non suppose : systemd disait `active` mais rien n'ecoutait sur 443 — step-ca
sert sur 8443. La zone souveraine resout et la recursion marche, mesurees sur la machine.
42 preuves vertes, ansible-lint profil production.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
19 lines
1,007 B
YAML
19 lines
1,007 B
YAML
---
|
|
# CE RÔLE EN EXIGE UN AUTRE, ET C'EST À ANSIBLE DE LE SAVOIR.
|
|
#
|
|
# `serveur_cache_site` n'installe rien : il MARQUE un cache comme racine de la chaîne et
|
|
# vérifie qu'il n'a pas d'amont. Pour cela il lit les variables de `serveur_artefacts`,
|
|
# qui pose apt-cacher-ng.
|
|
#
|
|
# Or les valeurs par défaut d'un rôle ne sont en portée que DANS LE PLAY QUI L'INCLUT.
|
|
# Déclarer les deux rôles sur la machine ne suffisait donc pas : chaque groupe est appliqué
|
|
# par son propre playbook, et le marqueur ne voyait jamais `serveur_artefacts_port`.
|
|
#
|
|
# Une dépendance de rôle règle les deux choses d'un coup : Ansible applique l'installateur
|
|
# AVANT le marqueur, dans le MÊME play, donc ses variables sont en portée. Et l'ordre
|
|
# cesse de dépendre de la façon dont on lance le déploiement.
|
|
#
|
|
# Chez patient 0 les deux vivaient sur le même hôte et étaient appliqués ensemble : la
|
|
# dépendance existait déjà, elle n'était simplement écrite nulle part.
|
|
dependencies:
|
|
- role: serveur_artefacts
|