Daniel Allaire 716be304c5 wiki : 10 unités restantes (Communication, Données, Observabilité, Socle & méthode)

Complète les 14 unités d'apprentissage au moule à 4 temps : Reverse-proxy,
Courriel, Bases de données, Cache, Métriques & journaux, Supervision & impact,
Virtualisation, Sécurité & durcissement, Infra as Code & idempotence,
Liaisons (bindings, avec l'analogie NetScaler). Navigation complétée.

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

2026-07-04 15:33:17 -04:00

3.9 KiB

Raw Blame History

Liaisons (bindings)

Unité d'apprentissage. Moule : ① concept → ② Set-OPS → ③ transférable → ④ à toi de jouer.

① Le concept (générique)

Un système réel n'est pas fait de pièces isolées, mais de relations : cette app utilise cette base, ce serveur fait confiance à cette AC, ce nœud envoie ses logs à ce collecteur.

Deux façons de câbler ces relations :

En dur — recopier l'adresse/le nom dans chaque config. Fragile : déplacer une pièce oblige à éditer partout, et ça casse la portabilité.
En liaisons déclaratives — on déclare « A est lié à B », et le moteur résout l'adresse concrète au bon moment. Déplacer B ? On ne touche qu'un endroit.

Analogie NetScaler (Citrix ADC) : tu bind un service à un vserver, une policy à un vserver, un monitor à un service. Tu ne codes pas des IP en dur — tu relies des entités, et l'appareil fait le reste. Les liaisons de Set-OPS, c'est exactement ce modèle.

Deux axes pour classer une liaison (indépendants) :

Niveau : app→app/base/domaine (liens) ou nœud→service de flotte (intégrations).
Modalité : requise (constitutive — sans elle, ça ne s'instancie pas) ou optionnelle (élective — un choix, l'absence est légitime).

② Comment Set-OPS le fait

Type	Où	Résolu en	Exemple
`liens`	`applications.yml`	config (host_vars, lookups)	Forgejo → sa base ; app → domaine exposé
`intégrations`	`serveurs.yml`	groupe + agent client	nœud → PKI, sauvegarde, métriques…

Les résolveurs partagés font le pont : resoudre_base (app→base) et resoudre_annuaire (app→annuaire) lisent un registre et bâtissent la connexion — le secret restant déréférencé dans le rôle, jamais en clair.

La modalité structure la robustesse : une liaison requise absente → le moteur refuse d'instancier (ex. une base sans serveur SQL). Une optionnelle absente → silence (ex. un nœud sans client_journal marche très bien).

C'est le concept de Set-OPS : tu déclares les liaisons, le moteur câble.

③ Pourquoi c'est transférable

Set-OPS	Équivalents ailleurs
liens/intégrations déclaratifs	NetScaler bindings · références de ressources Terraform
service ↔ backend	Kubernetes : Service↔Pods, Ingress↔Service
requis vs optionnel	dépendances hard vs soft (partout)

Tu as appris la relation déclarative, la résolution par un moteur, requis vs optionnel — pas un produit. C'est un modèle mental qui vaut de NetScaler à Kubernetes.

④ À toi de jouer

Lis une liaison. Ouvre instance/plan/applications.yml : une app avec expose: (liaison app→domaine), et serveurs.yml : un nœud avec integrations: (liaison nœud→service).
Vois-la se résoudre. Après make instancier, regarde l'inventaire généré : la cible est devenue une valeur concrète (FQDN, groupe) — le moteur a câblé.
Requise vs optionnelle. Compare : retirer client_journal d'un nœud → aucun problème (optionnelle). Déclarer une base sans serveur → make instancier/la validation échoue (requise). Tu sens la différence de modalité.
Casse & répare. Casse une liaison requise (ex. réfère une base à un serveur inexistant), relance l'instanciation : échec clair avant tout déploiement. Corrige : ça passe. Le moteur attrape le câblage manquant à ta place.

Pour aller plus loin (dépôt)

Conception + taxonomie (niveau × modalité) : docs/bindings-conception.md (§11).
Résolveurs : roles/resoudre_base, roles/resoudre_annuaire ; registres : instance/plan/.
Toutes les autres unités sont, au fond, des liaisons en action.

3.9 KiB Raw Blame History Unescape Escape