Mises à jour sans interruption : comment Cloud-IAM maintient vos clusters Keycloak toujours disponibles

Contexte et contraintes

 

Dès sa conception, nous avons donné la priorité à l'absence d'interruption de service, aux mises à jour automatiques, aux capacités de restauration transparentes et à la simplicité globale. Ce principe est dicté par les contraintes suivantes :

1. Nous sommes un fournisseur mondial de SaaS (IAMaaS)

• Pour opérer à l'échelle mondiale, il est nécessaire d'automatiser les processus afin de minimiser les interventions manuelles.
• Pour prendre en charge le déploiement des clients dans divers environnements cloud, il faut une solution flexible et universellement applicable.

2. Nous gérons différents types d'IAM

• L'IAM orienté client (CIAM) a des exigences différentes de celles de l'IAM interne (WIAM).
• La diversité des scénarios d'utilisation exige des solutions avec un temps d'arrêt minimal. Par exemple, les plateformes VOD sont toujours opérationnelles, tandis que les entreprises utilisant l'IAM interne peuvent accepter des temps d'arrêt en dehors des heures de travail.

3. Nous proposons des clusters cogérés avec nos clients

• L'une des principales caractéristiques de Cloud-IAM est la prise en charge des extensions Keycloak personnalisées (CE).
• Nous ne gérons pas ces CE et n'avons aucune visibilité sur celles-ci, ce qui permet aux clients de les développer et de les déployer de manière indépendante.
• Un mécanisme de restauration rapide et fluide est essentiel pour les clients si une mise à niveau perturbe une extension personnalisée.

Présentation de la conception

 

À un niveau élevé, notre architecture divise chaque cluster Keycloak en deux parties distinctes :

1. Composants statless
   • Composants qui produisent les mêmes résultats quel que soit le nombre de fois où ils sont exécutés (par exemple, les binaires de l'application Keycloak ou d'autres services évolutifs horizontalement, le serveur web lui-même).
2. Composants avec état
   • Composants dont l'exécution multiple produit différents résultats (par exemple, la base de données, la configuration personnalisée ou les éléments du WAF et la configuration des équilibreurs de charge).

En séparant ces préoccupations, nous pouvons gérer chaque catégorie de composants différemment. Les sections suivantes expliquent comment cette conception se traduit en un workflow de mise à niveau pratique.

Repenser le processus d'automatisation : de la « tâche de création » à la « définition de l'état du cluster »

 

Initialement connue sous le nom de « tâche de création » (creation job), notre procédure automatisée a dépassé son champ d'application initial. Elle offre désormais les fonctionnalités suivantes :

• Déploiement d'un tout nouveau cluster Keycloak.
• Mise à niveau des clusters existants.
• Exécution d'opérations de restauration et de restauration à partir de sauvegardes.
• La duplication de clusters à des fins de reprise après sinistre.

Par conséquent, nous avons adopté le terme « tâche de définition de l'état du cluster » afin de mieux représenter sa fonction. Elle agit comme un orchestrateur central, garantissant qu'un cluster Keycloak atteint une version et un état spécifiés, qu'il s'agisse d'un nouveau déploiement, d'une mise à niveau ou d'une restauration.

Bien que le nom « tâche de création » persiste en raison de son utilisation passée, il est essentiel de comprendre que son rôle principal est de garantir que le cluster atteigne l'état final souhaité, quelle que soit la méthode employée.

Étape 1 : Provisionnement du cluster 

 

La tâche « set cluster state » utilise des scripts Terraform/Ansible pour exécuter la phase initiale de « création », qui consiste à provisionner un nouveau cluster. Ce processus comprend :

1. Provisionnement de l'infrastructure : activation des ressources cloud requises, notamment les serveurs, le réseau et les équilibreurs de charge.
2. Déploiement de Keycloak : installation de l'application « sans état » Keycloak.
3. Configuration DNS : établissement d'une nouvelle route DNS dirigée vers le cluster nouvellement provisionné.
4. Enregistrement du cluster : information du backend ou de l'orchestrateur pour gérer le cycle de vie du cluster.

Ce workflow est similaire au déploiement automatisé classique. Cependant, il est important de noter que cette même procédure s'applique non seulement aux nouveaux déploiements, mais aussi aux mises à niveau et aux restaurations.

Étape 2 : Ajout de sauvegardes au processus de création

 

Keycloak utilise Liquibase pour les migrations de bases de données, ce qui signifie que l'application elle-même gère les modifications de schéma. Il est important de noter qu'un cluster Keycloak créé avec la même sauvegarde et la même version produira le même état.

• Ce que nous avons ajouté
  Nous avons amélioré notre script de création afin de permettre la restauration à partir d'une sauvegarde. Cela signifie que nous pouvons créer un clone d'un cluster Keycloak de production, avec tout le contenu de sa base de données, simplement en pointant la tâche de création vers une sauvegarde existante.

Étape 3 : Gestion des versions du déploiement

 

Lorsqu'un client crée un cluster dans Cloud-IAM (ce que nous appelons un « déploiement »), celui-ci est associé à une version majeure de Keycloak. Lors d'une mise à niveau, nous modifions simplement la version et laissons Terraform + Ansible appliquer ces modifications à l'état existant.

• Déploiements progressifs
  Régulièrement nous effectuons une mise à niveau progressive : nous lançons un nouveau nœud avec la nouvelle version, puis nous supprimons l'ancien nœud, et ainsi de suite. Cependant, certaines mises à jour de Keycloak ne prennent pas en charge les mises à niveau progressives. Dans ces cas-là, nous pouvons être amenés à arrêter l'ensemble du cluster, à le mettre à niveau, puis à le redémarrer.

Étape 4 : Mises à niveau sans interruption - Approche de reprise après sinistre

Lorsqu'une mise à jour du cluster Keycloak nécessite un arrêt complet, impliquant une interruption de service, une approche de reprise après sinistre (DR) garantit une absence d'interruption. Cette méthode implique :

1. Réplication du cluster : créer une copie identique du cluster de production à l'aide de la sauvegarde existante et de la tâche de création.
2. Mise à niveau de la copie : appliquez la nouvelle version au cluster copié, exécutez les migrations de schéma nécessaires et vérifiez la stabilité du système.
3. Commutation DNS : redirigez le trafic vers le cluster nouvellement mis à niveau. Cette action est pratiquement instantanée, ce qui garantit une interruption zéro.
4. Gestion de l'ancien cluster : mise hors service du cluster d'origine ou conservation de celui-ci en tant que système de secours facilement accessible pour une restauration immédiate si nécessaire.

En traitant Keycloak comme un système sans état et en s'appuyant sur des sauvegardes pour les données avec état, il est possible d'établir un cluster parallèle. Cela permet une commutation DNS rapide, pour des mises à jour transparentes et sans interruption de service.

Comme nous traitons Keycloak comme un système sans état et que nous nous appuyons sur des sauvegardes pour la partie avec état, nous pouvons mettre en place un deuxième cluster en parallèle. Le changement de DNS est alors instantané, ce qui évite tout temps d'arrêt.

Étape 5 : gestion des restaurations

Les restaurations sont essentiellement l'inverse du processus de mise à niveau.

1. Suppression des composants avec état problématiques

• C’est essentiel pour éviter des mises à jour partielles ou une corruption des données. Supprimez entièrement les composants stateful actuels (défaillants).

2. Restaurer à partir de la sauvegarde

• Utilisez la tâche de création avec la sauvegarde précédente pour reconstruire un cluster fonctionnel.

Pour des restaurations sans temps d'arrêt, une autre approche de reprise après sinistre (DR) peut être utilisée. Cela implique de déployer l'ancienne version parallèlement à la nouvelle, de basculer le DNS vers l'ancienne version, puis de mettre hors service la nouvelle version problématique.

 

Conclusion et points clés à retenir

1. Stateless vs. Stateful : séparer l'application de ses données et de ses éléments stateful simplifie les mises à niveau et permet des stratégies de restauration flexibles.
2. Déploiements versionnés : lier les déploiements Keycloak à un numéro de version centralise la logique de mise à niveau et maintient la cohérence.
3. Les sauvegardes sont essentielles : considérez les sauvegardes (et la possibilité de les restaurer) comme une fonctionnalité de premier ordre. Elles constituent la base de restaurations fiables et de mises à niveau sans interruption de service.
4. Approches flexibles : en fonction de la nature de la version, vous pouvez :
   • déployer progressivement les mises à jour, ou
   • effectuer un remplacement complet à l'aide d'une copie DR et d'une commutation DNS.
5. Collaboration avec les clients : autoriser les extensions personnalisées permet aux clients de contrôler leur code, mais vous devez également fournir un mécanisme de restauration robuste pour les protéger (et vous protéger) contre les incompatibilités de version.

En suivant ces principes, nous garantissons que notre plateforme IAM reste à jour, cohérente et résiliente, quelle que soit l'ampleur ou la diversité des besoins de nos clients.

‍