En tant que DevOps/SRE, vous allez surement devoir faire des choix difficiles pour votre infrastructure. Il se peut que ce choix réponde à un besoin à l'instant T, mais qu'il entraine de la dette technique sur le long terme et beaucoup de frustration. Nous avons rencontré cette problématique sur le service managé d'Azure "App Service".
Pour faire état de la situation, lorsqu'un dev doit changer une variable sur son application, nous devions déployer en prod notre code Terraform, car la définition des variables utilisées par les AppService se faisait depuis notre code. Vous noterez tout de suite que le standard de la séparation Infrastructure/Code Application n'est pas du tout respecté. La déclaration des variables d'environnement des applications des développeurs devaient se faire via notre code Terraform. Cela induisait une dépendance de la part des devs et nous devions communiquer avec eux pour prévoir les modifications de celles-ci.
Pour répondre à ce problème, nous avons effectué un Kaizen, qui est un outil de la méthodologie du Lean. Cet outil permet d'analyser une problématique et d'essayer de la résoudre par petites étapes. Cet article résume donc notre épopée à la recherche de la solution idéale. Nous parlerons des différentes étapes qui nous ont menées à la solution et des différentes solutions envisagées pour séparer la configuration des variables d'environnement sur le service managé Azure App Service.
Cela induit en général un freeze du code Terraform de notre côté de près de trois jours. Cela n'est clairement pas une option, alors que nous n'avons que deux équipes de développeurs. Alors imaginez si nous gérons une infrastructure avec une dizaine d'équipes avec chacune des besoins.
Analyser le temps à gagner :
Notre objectif était donc de réduire ces 3 jours d'attente à 0.
Maintenant que nous avons défini le potentiel d'amélioration, il est important d'étudier les méthodes actuelles et de creuser. Notre objectif dans cette prochaine étape est de connaitre sur le bout des doigts nos problèmes et nos méthodes.
La compréhension complète de notre problème nous permettra de mieux comprendre quels sont les points que nous pouvons/devons améliorer. Il est important de réaliser cette étape et de ne pas sauter directement à la première solution que nous avons trouvée. Cela nous permet de nous assurer que la solution trouvée est la plus adaptée et que nous n'allons pas perdre de temps en aval.
Flow Actuel :
Idéalement, un déploiement de l'application se fait avec sa configuration, sans opération supplémentaire. La configuration pourrait aussi se faire de manière découplée (pour révoquer un mot de passe par exemple)
Flow Idéal :
Les Ops doivent déployer deux fois les variables d'environnement : une fois pour préparer le déploiement en prod, une fois sur l'ancienne prod (devenu staging) pour permettre le rollback.
Source de chaque info dans le slot AppService :
La configuration applicative se trouve dans le code de l'infrastructure.
À ce moment-là de notre réflexion, nous nous sommes posés certaines questions pour avancer :
Ces deux questions nous ont permis de structurer notre raisonnement dans la suite de notre réflexion. Nous avons donc entrepris d'analyser ensuite quelles sont les variables d'environnement que nous exposons dans App Settings pour essayer d'en déduire des catégories.Certes, cette étape semble peu pragmatique, mais il est important de comprendre toutes les composantes de notre problème. Cela nous permettra de trouver une solution adéquate à notre problème et de pouvoir garantir que celle-ci est la plus adaptée.
À la suite de notre analyse des variables d'environnement qui sont déclarées dans App Settings, nous avons remarqué que sur les 69 variables déclarées seules 28 sont gérées par notre équipe de DevOps.
En résumé, nous avons 41 variables gérées par les Devs et 28 par les DevOps sur nos AppService dans notre AppConfig. À la suite de cette analyse, nous avons décidé de creuser les différents types de variables pour déterminer lesquels sont nécessaires et lesquels ne le sont pas.
4 types de variables d'environnement dans notre AppConfig:
Il n'y aucune corrélation entre la source/type de variable et le rôle (DEV ou DevOps).
On en conclut que ces choix ont été arbitraires jusqu'ici et qu'il n'a jamais été challengé → Nous décidons de standardiser ce choix
Nous avons donc décidé de créer un tableau de décision pour définir l'endroit adéquate d'une variable.
Cette matrice de décision a été créée:
Il semblerait que nous nous soyons éloigné du problème. Cependant, avant de trouver la solution, nous devons nous assurer que nous n'avons pas de problèmes qui pourraient remonter plus tard, ni de points d'améliorations qui pourraient être réglés rapidement.
Nous avons donc creusé les différentes variables d'environnement pour définir un nouveau standard et nous assurer que la solution sera en adéquation avec celui-ci.
Maintenant que nous avons identifié le besoin, le gain et le standard, il est temps de réfléchir à une idée pour résoudre ce problème.
Voici nos idées, qu'elles soient bonnes ou mauvaises :
La solution adoptée et que l'on va étudier est le chargement des variables d'environnements dans un docker au démarrage à partir d'un KeyVault Azure managé par les devs.
Avant de foncer tête baissée sur notre nouvelle idée, nous avons dû réfléchir à tout ce qui pouvait mal tourner. Il est important de toujours faire attention à ne pas introduire de nouveaux problèmes avec notre solution.
Sécurité :
Stabilité :
Vitesse :
On a l'idée, on connait notre nouveau standard pour les variables, et on sait sur ce quoi nous devons faire attention il est temps de valider celle-ci.
Nous avons donc testé les points suivants :
Maintenant que nous avons validé le POC et que nous avons pris en compte les différents points d'attention, il ne nous reste plus qu'à implémenter la solution. En suivant ce processus d'amélioration continue que nous avons entrepris - Kaizen - nous avons dorénavant une solution adaptée et claire pour résoudre notre problème.
Cette méthode peut s'appliquer à un ensemble de problèmes, que ce soit sur des problématiques techniques que managériales. Si vous voulez en savoir plus sur cette méthodologie je vous invite à regarder la méthodologie du Lean et le processus de Kaizen.
N'hésitez pas à nous poser des questions en commentaires !