EXPÉRIENCE
Des problèmes concrets, à l’échelle de la production.
Expériences présentées de façon anonymisée. Les migrations décrites ont été progressives.
CASE / 01OBSERVABILITÉ
Moderniser l’observabilité en production
Faire évoluer la gestion des métriques et des logs vers une solution centralisée, légère et rapide, adaptée à des volumes importants.
CONTEXTEUne organisation exploitant environ 200 serveurs s’appuyait sur Nagios, Elastic et Prometheus, avec des connexions SSH ponctuelles pour consulter certains logs. Les différentes sources éparpillées compliquaient les investigations et l’évolution de la supervision.
INTERVENTIONGestion d'une évolution progressive vers Prometheus et Thanos, puis VictoriaMetrics pour les métriques. Pour les logs, utilisation de Vector et évolution de Loki vers Quickwit. Point central de visualisation avec Grafana et routage des alertes avec Alertmanager. Ajout d'un processus de création et de résolution d'incidents et d'un catalogue de services à l'aide d'incident.io.
- ↗Environ 600 Go de métriques conservées sur une fenêtre de deux mois à travers plusieurs clusters VictoriaMetrics.
- ↗Environ 4 To de logs provenant de Kubernetes et de conteneurs LXC traités sur une fenêtre de trois semaines.
- ↗Centralisation des tableaux de bord, des métriques et des logs afin que tout soit accessible depuis Grafana.
- ↗Des alertes routées vers les bons intervenants plutôt qu'envoyées en masse à une seule personne.
ARCHITECTURE / TRANSITION
DÉPART
- Nagios
- SSH ponctuel
- Supervision fragmentée entre Elastic et Grafana
- Logs dispersés
- Alertes envoyées à une personne
↓
DESTINATION
- 01Hôtes et services catalogués
- 02Visualisation centralisée par Grafana
- 03Cluster de monitoring
- 04Gestion d'incidents
TECHNOLOGIESPrometheusThanosVictoriaMetricsVectorLokiQuickwitGrafanaAlertmanagerincident.io
CASE / 02INGÉNIERIE DE PLATEFORME
Faire évoluer une plateforme legacy vers Kubernetes et GitOps
Remplacer progressivement une chaîne de déploiement sur mesure par une plateforme Kubernetes déclarative et reproductible.
CONTEXTEUne plateforme de production reposait sur des conteneurs LXC, des paquets Debian personnalisés et des scripts Perl complexes. Son évolution, son apprentissage et sa reproduction demandaient beaucoup de travail manuel (SSH et scripts).
INTERVENTIONContribution à une migration progressive vers Kubernetes bare metal, avec FluxCD, Helm et des pratiques GitOps. La gestion de secrets avec SOPS, les sauvegardes avec Velero et le stockage Ceph faisaient partie de l’écosystème. Expérience également avec une flotte d'environ dix clusters gérés avec Cluster API et Sveltos.
- ↗Transition graduel vers Kubernetes.
- ↗Déploiement d'un cluster de 6 nœuds dédié au monitoring centralisé de l'ensemble des serveurs.
- ↗Gestion d'environ 20 nœuds répartis à travers différents clusters.
- ↗Gestion d’une flotte d’environ dix clusters avec Cluster API et Sveltos.
- ↗Déploiement reproductible de l'infrastructure (CNI, DNS, ingress, stockage).
ARCHITECTURE / TRANSITION
DÉPART
- Conteneurs LXC
- Paquets Debian personnalisés
- Scripts Perl
- SSH
↓
TECHNOLOGIESKubernetesFluxCDArgo CDHelmCluster APISOPSVeleroCeph