Comment nous avons rendu les déploiements plus sûrs à SEKOIA.IO

SEKOIA.IO traite près d’un milliard d’événements clients par jour. Cela représente des dizaines de milliers d’entrées de registre par seconde. Chaque événement doit être analysé rapidement et de manière fiable par notre pipeline de détection pour déceler les cybermenaces et réagir le plus rapidement possible. Vous pouvez imaginer qu’il est inenvisageable de rompre ce pipeline, ne serait-ce qu’un instant.

Déployer en toute sécurité les modifications dans ce workflow à haut débit et à faible latence est un défi majeur que nous essayons continuellement de relever.

Bien entendu, nous utilisons l’architecture des microservices : la production est assurée par un grand nombre de composants faiblement couplés. Cette approche nous permet de faire évoluer et mettre à jour facilement et indépendamment des parties de notre infrastructure. Cela implique également que nous devons fréquemment gérer un grand nombre de déploiements.

Tous nos microservices fonctionnent sous Kubernetes, idéal pour la réparation automatique et les déploiements progressifs. Kubernetes est intelligent, mais pas tant que ça. Même combiné avec tous les CI/ CD et mise en scènes du monde, on pourrait quand même déployer des services cassés. Cela a de multiples implications :

  • Les déploiements doivent être amorcés et supervisés par une personne physique (une équipe d’ingénierie de fiabilité du site dans notre cas) pour en assurer le bon déroulement.

Ces deux problèmes nuisent à la productivité et à la proactivité et peuvent créer du stress chez les responsables des déploiements.

Même avec ces dispositions, nous avons parfois rencontré des problèmes lors du déploiement de mises à jour : des services qui fonctionnaient dans l’environnement de test ont été interrompus en production lorsqu’ils ont été mis sous pression, ou n’ont tout simplement pas fonctionné en raison d’une configuration asymétrique.

Comment éviter cela ? Nous avions besoin d’un moyen de déployer en toute sécurité les mises à jour des microservices, sans avoir à craindre que cela ne déclenche un incident.

Heureusement, l’automatisation existe et peut être appliquée à presque tout.

Déploiements Canaris 🐦

Les canaris étaient utilisés dans les mines de charbon pour alerter les travailleurs des fuites de monoxyde de carbone, le « tueur silencieux ». Comme les canaris mouraient du monoxyde de carbone bien avant les travailleurs des mines, ils étaient, à l’époque, le seul moyen de détecter une fuite de gaz.

Aujourd’hui, le terme est utilisé pour décrire tout sujet de test.

Dans le domaine des opérations, les déploiements Canaris correspondent à cela : en déployant volontairement la dernière version d’un service à un nombre restreint d’utilisateurs, vous êtes en mesure de voir comment la nouvelle version fonctionne sans tout compromettre en cas de bug. Ainsi, si cette version fonctionne correctement, vous pouvez continuer à la déployer progressivement auprès d’un plus grand nombre d’utilisateurs. Si elle continue à bien fonctionner, vous avez de bonnes raisons de penser qu’elle peut remplacer l’ancienne version.

Comme Kubernetes fournit une API pour intéragir avec les déploiements, il est bien adapté à l’automatisation de ce type d’opérations.

Ransomware : Un retour en force depuis la rentrée

Solutions existantes

Comme on peut s’y attendre, il existe déjà un grand nombre de solutions différentes pour tenter de résoudre ce problème. Cependant, nous avions de strictes exigences avant d’adopter une quelconque solution :

  • Nous ne voulions pas avoir à réécrire nos piles de Kubernetes, car nous avons environs 80 microservices.

En prenant en comptes toutes ces exigences, nous avons commencé à chercher des solutions, sans grand succès. Des solutions tel que Gloo ou Flagger sont très largement basées sur HTTP, et Argo est un écosystème entier, qui nécessite des changements dans les piles de déploiement.

Nous n’avons pas pu trouver de solution simple pour les travailleurs basés sur Kafka. Après quelques jours de lecture de la documentation et d’essais sur notre environnement de test, il est devenu évident qu’aucune des solutions existantes ne répondait à nos besoins.

Aviary 🦜

Comme tout ingénieur frustré le ferait, nous avons décidé de créer notre propre solution, baptisée Aviary (parce qu’elle manipule des canaris toute la journée !).

Ce que nous voulions réaliser pouvait simplement être mis en œuvre de cette manière :

  • A l’initialisation, Aviary duplique le déploiement du service en ajoutant le suffixe -primary à son nom et met à l’échelle le déploiement initial à 0.

Deux résultats possibles sont à prévoir :

  • Si nous atteignons un point de rupture où suffisamment d’instances -canary ont été efficaces sur une période de temps, le déploiement -canary est promu -primary, et le déploiement initial reste inchangé.

Cette logique nous permet de mettre en place des déploiements canaris progressifs et une réduction automatique de la production, tout en n’apportant absolument aucun changement à notre code base existant. Notre pipeline de CI/CD reste également intact, car il interagit avec le même objet qu’avant, le déploiement initial. Aviary s’occupe du reste.

La configuration reste minimale, avec la possiblité de définir, par service :

  • Le pourcentage de points de rupture (après lequel le pourcentage d’instances de canaris réussies nous permet de déployer complètement la nouvelle version).

Il est également très interactif et permet à un opérateur d’annuler un déploiement en cours, ainsi que de se contourner pour le prochain déploiement d’un service (pour le push de hotfixes).

Conclusion

Notre solution est en production depuis quelques mois maintenant, et elle a déjà permis d’éviter de nombreux mauvais déploiements et régressions. L’absence de changement du code de base et sa très faible empreinte dans le cluster Kubernetes en font une solution très satisfaisante.

Elle ne change absolument rien aux opérations normales de SRE et à l’automatisation car elle gère de manière transparente les déploiements à grande échelle et les redémarrages des services.

Nous sommes très heureux d’avoir fait ce pas en avant, car les développeurs ont fait un pas de plus vers la possibilité de déployer eux-mêmes leurs changements, sans avoir à se soucier des problèmes non détectés qui surviendraient en production.

Bien entendu, Aviary a été réalisée de la manière la plus agnostique possible pour les entreprises et est disponible gratuitement sur notre dépôt GitHub.

Chat with our team!

Would you like to know more about our solutions? Do you want to discover our XDR and CTI products? Do you have a cyber security project in your organization? Make an appointment and meet us!

Échangez avec l’équipe

Vous souhaitez en savoir plus sur nos solutions de protection ? Vous voulez découvrir nos produits de XDR et de CTI ? Vous avez un projet de cybersécurité dans votre organisation ? Prenez rendez-vous et rencontrons-nous !