Set-OPS-Public/wiki/Rôle-serveur_ops.md

Rôle serveur_ops

Généré par scripts/fiche_role.py depuis les meta/ de ce rôle. Ne pas éditer à la main : corriger la déclaration, puis régénérer.

Pour qui : celui qui doit agir sur ce rôle et veut savoir, avant de toucher quoi que ce soit, qui lui parle, ce qu'il rend, et ce qu'il coûte.

graph LR
  R["<b>ops</b>"]
  E0["admin"] -->|"8090 · clair"| R
  E1["edge"] -->|"8090 · clair"| R
  R -.->|"sonde « runner »"| ICINGA[["Icinga"]]
  R -.->|"sonde « console-ops »"| ICINGA[["Icinga"]]

Qui lui parle

port	depuis	chiffrement	pourquoi
8090	edge, admin	clair	Console d'exploitation servie par l'edge (TLS terminé à l'edge), et joignable depuis le plan d'administration là où il n'y a pas d'edge. Le GUI lui-même reste sur la boucle locale : c'est nginx qui authentifie devant.

Ce qu'il rend à la supervision

sonde	TTL	ce qu'elle voit
runner	5400 s	Le poste d'exploitation peut-il encore agir ? Deux choses : ses depots sont-ils PROPRES et sur leur branche (une modification locale fait diverger le runner du depot que tout le monde lit), et Ansible repond-il dans son venv.
console-ops	5400 s	La console d'exploitation repond-elle, et son vestibule tient-il ? Un GUI mort derriere un nginx vivant rend une page d'erreur a qui sait deja entrer ; un vestibule tombe rend la fabric entiere a qui trouve l'URL. Le second ne fait echouer personne — c'est pourquoi il faut le mesurer.

Ce qu'il expose en séries

Aucun exportateur déclaré — voir docs/conception/metriques-conception.md.

Ce qu'il coûte, et qui entre

• Empreinte : 2 cœur(s), 2048 Mo, 20 Go.
• Authentification : sans-auth-humaine — Le poste d'exploitation n'expose aucune interface : il n'est ni serveur web ni service reseau, et rien ne s'y connecte. On y entre par SSH sur l'hote, comme sur n'importe quelle machine de la flotte, puis l'on devient l'utilisateur d'exploitation. Il n'y a donc rien a federer, et rien a fermer.