En tant qu’équipe de plateforme chez Trendyol Tech, l’un de nos objectifs était de rendre la configuration des applications et la gestion des secrets dynamiques, fiables, sécurisées et d’être abstraites des applications. Nous utilisons les ConfigMaps et Secrets de Kubernetes depuis longtemps et ils ne répondent pas complètement à nos besoins. Par exemple, lorsque nous modifions une configuration sur une ConfigMap, nous devons redémarrer nos pods d’application pour que ce changement prenne effet. Il faut parfois plusieurs minutes pour que la modification soit répercutée sur toutes les instances d’application. Un autre problème est que les secrets Kubernetes ne sont pas suffisamment sécurisés. Nous avons besoin que nos secrets soient sécurisés et auditables.
Nos principales exigences étaient :
- Nous devrions être en mesure de modifier les configurations des applications de manière dynamique sans redémarrer les processus d’application. Lorsque nous changeons une configuration, cela doit affecter toutes les instances de l’application instantanément.
- Nos secrets d’application doivent être sécurisés et auditables. Nous voulons également fournir un contrôle d’accès aux secrets basé sur les rôles.
- Nous devons abstraire la gestion de la configuration des applications. En d’autres termes, les applications ne doivent pas savoir où et comment les secrets et les configurations sont conservés et fournis pour eux.
- Notre système de gestion des configurations et des secrets doit être hautement disponible et évolutif.
Après quelques recherches, nous sommes arrivés à 2 applications ; envconsul et consul-template.
Nous savions déjà que Vault est l’outil standard de l’industrie pour le stockage des secrets. Il répond à toutes nos exigences et possède des fonctionnalités comme les secrets dynamiques, qui pourraient nous être utiles à l’avenir. Vous pouvez également utiliser Consul comme backend de stockage pour Vault.
Consul est un outil distribué, hautement disponible et évolutif pour la découverte et la configuration de services. Dans notre cas, nous utiliserons uniquement la fonctionnalité de stockage clé-valeur de Consul pour conserver les configurations non secrètes.
Nous pourrions utiliser envconsul ou consul-template principalement pour la 3e exigence : abstraire la gestion de la configuration des applications.
Envconsul fournit un moyen de lancer un sous-processus avec des variables d’environnement peuplées à partir de Consul et Vault.
Consul-template peuple les valeurs de Consul et Vault dans le système de fichiers et maintient la synchronisation des valeurs tout en travaillant en mode démon.
Une règle d’application à douze facteurs est, stocker les configurations dans l’environnement. Mais le problème avec Envconsul (ou variables d’environnement) est que vous ne pouvez pas modifier les variables d’environnement d’un processus sans le redémarrer. Cela va à l’encontre de notre première exigence. Nous voulons être en mesure de modifier les configurations sans redémarrer les processus d’application. C’est pourquoi nous avons décidé d’aller avec consul-template.
Dans consul-template, vous pouvez utiliser un fichier modèle pour rendre les fichiers de configuration. Cela nous donne une grande flexibilité. Voici un exemple de fichier modèle;
Consul-template lit ce modèle, remplace les espaces réservés par des valeurs provenant de Consul si vous utilisez le mot clé « key » et de Vault si vous utilisez le mot clé « with secret ». Pour en savoir plus sur le langage des modèles, cliquez ici. Le fichier de sortie rendu ressemblerait à ceci;
server:
port: "8080"
toggles:
fooEnabled: true
database:
username: "username"
password: "password"