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

```mermaid
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/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.