Étude de cas
ArchitectureConception d’une architecture de cloud computing edge
Contexte
Entité publique à forts besoins de sécurité, avec des sites à équiper dans des zones contraintes : pas d’accès Internet, flux filtrés, et personne sur place pour administrer quoi que ce soit. La solution a été co-conçue avec l’équipe : de petits clusters Kubernetes capables de faire tourner des logiciels à distance, sur des VM comme sur du matériel physique, sans jamais ouvrir d’accès entrant.
Le défi
Faire tourner des applications dans des sites qu’on ne peut ni joindre en entrant ni visiter souvent : une architecture entièrement en pull, des machines qui se remettent en état seules, une télémétrie suffisante pour diagnostiquer à distance, et rien à administrer sur place. Le tout sur un socle immuable, sans aucun accès SSH.
Zones sans Internet
Pas d’accès Internet, flux filtrés au strict nécessaire : ni dépôt de paquets à joindre, ni connexion entrante, ni intervention à distance classique.
Personne sur place
Le site n’a personne pour administrer la machine. Chaque intervention doit donc se faire depuis l’extérieur, ou ne pas être nécessaire du tout.
Pull plutôt que push
Sans accès entrant, l’administration classique est impossible : c’est la machine qui vient chercher son état, pas l’opérateur qui pousse une commande.
Diagnostiquer sans voir la machine
Déboguer à distance sans shell : la télémétrie remplace la session SSH qu’on n’a pas, et elle doit être assez fine pour comprendre un incident depuis un bureau.
L’approche
01 · L’architecture
De petits clusters Kubernetes, entièrement en pull
Des clusters Kubernetes légers, sur un petit nombre de machines par site. Tout se joue en pull : la machine interroge son dépôt et applique ce qu’elle y trouve, sans qu’aucun port n’écoute depuis l’extérieur. Le site n’a pas besoin d’être joignable pour être administré.
02 · Le socle
Un système immuable, en lecture seule
Les machines tournent une image système immuable : l’état local n’est pas modifié à la main, il est remplacé à chaque mise à jour. Un redémarrage suffit à revenir à un état connu, ce qui rend la dérive impossible et la remise en route prévisible.
03 · La distance
Une télémétrie active, pour déboguer sans shell
Logs, métriques et traces remontent en continu, assez fins pour comprendre un problème sans ouvrir de session sur la machine. C’est ce qui rend l’absence d’accès SSH tenable : puisqu’on ne peut pas se connecter, on outille l’observation à la place.
04 · L’autonomie
Des machines qui se remettent en état seules
Redémarrage d’un service en échec, resynchronisation avec l’état décrit, retour à la version précédente : le site se rétablit sans intervention. La maintenance sur place se limite au matériel.
05 · Le support
Sur VM ou sur matériel physique, la même méthode
La même solution se déploie sur des VM et sur du matériel physique : ce qui change est l’image système et l’état décrit dans le dépôt, pas la procédure. Un nouveau site s’ajoute en décrivant sa cible, sans installation manuelle.
Les résultats
Zéro SSH
Les instances ne sont jamais administrées par une session : tout passe par le dépôt et par la télémétrie.
Aucune intervention sur site
Les mises à jour s’appliquent à distance, sans personne devant la machine et sans déplacement sur site.
Maintenance minimale
Le socle immuable réduit l’entretien courant : on remplace l’état au lieu de réparer la machine.
Zones contraintes couvertes
La solution tourne là où rien d’autre ne passe : pas d’Internet, flux filtrés.
VM et métal, même méthode
Un site sur VM et un site sur matériel physique se déploient avec la même méthode.
Diagnostic à distance
Un incident se diagnostique à distance, sans accès à la machine.
La stack
Socle immuable
- bootc
- Fedora
- OSTree
- systemd
Orchestration
- Kubernetes
- K3s
- ArgoCD
Administration
- GitOps (pull)
- Zéro accès SSH
- Télémétrie
Cibles
- VM
- Matériel physique