Comment déployer en Blue Green ses Web App avec Azure DevOPS

Dans ce nouvel article, je vais vous parler de l’intégration d’un pipeline de déploiement Bleu-Green sur Azure DevOPS pour des applications Web exécutées sur Azure WebApps.

Nous allons ici exploiter les capacités de Swap sur les Slots des Web Apps pour éliminer les temps d’arrêt liés au redémarrage des applications. J’utilise ici une application SpringBoot hébergée sous la forme de conteneur, mais cela fonctionne pour d’autres types d’applications…

L’utilisation des Slots et de Azure App Service nous permets ici de nous affranchir de pas mal de complexités liées à l’infrastructure nécessaire pour pouvoir réaliser un déploiement Blue Green.

Bleu Green

Un petit peu d’explications sur ce que c’est que le Blue Green apparu en 2010 et couramment utilisé dans les processus DevOPS pour effectuer du Zero Down Time Deployment.

L’idée est simple : Déployer la nouvelle version de l’application sur un environnement à l’identique de la production, attendre que ce nouvel environnement soit « Up » puis effectuer une bascule au travers d’un routeur (généralement un reverse proxy).

Ainsi lors de la bascule, nous sommes certain que l’application qui recevra les appels aura déjà effectué ce que l’on appelle le « cold start » (démarrage à froid, où beaucoup de chargements sont effectués et où l’application n’est pas encore disponible pour traiter les appels), et que le transfert vers la nouvelle version se fera sans aucune coupure du point de vue de l’utilisateur.

Attention cela dit, effectuer un déploiement Blue Green ne peut être transparent que si certaines conditions sont remplis notamment autours du fonctionnement même de l’application :

• L’application doit être State-Less (pas de données en session),
• Les changements de base de données ne doivent pas impacter la version antérieur de l’application,
  • Parfois les changements en base de données peuvent être opérées dans d’autres processus DevOPS et ne doivent pas impacter les applications
• Les transactions en base de données sur l’application « Blue » doivent se terminer correctement durant l’opération de swap

Approche non-puriste

La méthodologie Blue-Green suppose que l’infrastructure dispose des deux environnements Blue et Green simultanément afin de pouvoir effectuer les tests de montée de version sur une instance « inactive » de la production (Blue par exemple) de faire le swap entre le Blue et Green et nous permettre de faire un rollback si jamais un utilisateur rencontre un problème (par un swap entre le Green et le Blue).

Il y a donc dans cette approche tout le temps les deux instances qui sont exécutées en même temps.

Dans cette démonstration, vous verrez que je ne suis pas une approche « puriste » de la méthodologie Blue Green dans le sens ou je souhaite bénéficier de la plateforme Azure pour provisionner mon environnement de Staging au moment du déploiement, effectuer le swap au moment opportun, puis supprimer les ressources inutiles.

Cela a un avantage en termes de facturation des ressources, puisque vous ne serez facturés que pour les ressources consommées durant l’opération de Swap (ou vous ne devrez dimensionner votre App Service que pour votre Workload, sans prendre forcement en compte les environnements de Staging).

Azure Web App Slots

Dans cet article je vais vous parler des slots de Web App pour pouvoir effectuer les déploiements avec les fonctionnalités de Swap entre slots.

Les Slots sont des emplacements d’exécution de votre application Web dédiés à un environnement séparé de celui de la production. Par défaut, lorsque vous utilisez une Web App il existe un slot nommé production, si vous utilisez un plan de service Standard Premium ou Isolé, vous avez la possibilité de créer des slots de déploiements qui vous fourniront une URL dédiée pour votre application en ligne.

Azure permet d’effectuer des opérations de Swap permettant de basculer la configuration, le contenu du système de fichier, etc…, entre vos slots.

Lorsque vous créez un slot, vous aurez la possibilité de partager une partie de la configuration avec le slot source de votre choix. Cependant, votre slot s’exécutera sur le plan de service utilisé par votre App Service et bénéficiera donc également des mêmes options de Scaling (nombre d’instances). Il vous appartient alors de le dimensionner votre App Service Plan en conséquence.

Enfin, puisque nous utilisons Azure App Service et ses slots, nous n’aurons absolument pas à nous soucier des changements sur l’infrastructure à opérer (changement du routage, ….) toutes ces opérations sont gérés par la plateforme Azure pour nous, sans aucun frais.

Azure DevOPS Release Pipeline

Comme je l’ai expliqué, je vais ici utiliser l’environnement Azure DevOPS pour réaliser ces opérations. Je ne vais pas détailler ici les opérations pour créer le pipeline de Build de notre application et vais passer directement au pipeline de Release.

Variables de déploiement

Mes actions de release nécessiteront les variables suivantes :

Agent Job Taks

Voici les différentes task qui seront utilisées pour effectuer le déploiement avec les opérations de swap que je vais vous détailler.

Les tâches nécessitent l’utilisation d’un Service Principal pour pouvoir effectuer les opérations sur Azure, mais cette partie là n’est pas détaillée.

Certaines tâches n’existent pas réellement dans les playbook de Azure Devops, j’ai donc utilisé la tâche Azure CLI fournie par Azure DevOPS me permettant d’exécuter mes propres scripts (PowerShell, PowerShell Core ou même Shell) en bénéficiant de la CLI Azure (c.f : azure-pipelines-tasks/Readme.md at master · microsoft/azure-pipelines-tasks (github.com)).

Create Staging Slot

La première étape de notre déploiement sera de provisionner un nouvel environnement à la copie de la production. J’utilise ici la tâche Azure CLI, disponible sur Azure Devops par défaut .

Voici le contenu du script pour effectuer la création de ce nouveau Slot.

$slot = az webapp deployment slot create --name $(webapp-name) --resource-group $(resourcegroup-name) --slot $(slot-name) --configuration-source $(webapp-name) | ConvertFrom-Json

N.B : Dans mon cas, mes applications utilisent des chaines de connexion qui sont stockées dans un KeyVault Azure, il m’est donc nécessaire d’ajouter une identité managée à mon application ainsi qu’une Policy permettant à cette identité d’accéder aux secrets dont elle a besoin :

$identity=az webapp identity assign --name $slot.repositorySiteName --resource-group $slot.resourceGroup --slot $slot.name| ConvertFrom-Json
az keyvault set-policy --name $(keyvault-name)  --resource-group  $(keyvault-resourcegroup)  --object-id $identity.principalId --secret-permissions Get

Azure App Service Deploy

Cette partie concerne le déploiement de notre application sur notre slot nouvellement créé.

L’interface de Azure Devops, va normalement nous aider dans la sélection de nos ressources à déployer (avec des select box). Or dans notre cas, nos ressources ne sont pas créées lors de la définition du pipeline nous allons donc devoir les positionner à la main, j’utilise donc les varibles d’environnement de notre pipeline (que nous avons auparavant définis).

Wait for WebApp Health

Voila une partie intéressante, il s’agit de se donner la possibilité de vérifier le bon état de santé de notre application Web avant d’effectuer l’opération de Swap.

Dans mon cas, j’ai une application développée avec Spring Boot offrant un endpoint de management Actuator, fournissant par exemple le endpoint /management/health.

Il s’agit alors du paramètre que j’ai fournit à Azure pour mesurer l’état de santé de mon application dans Azure Monitor.

Puisque Azure Monitor est configuré sur mes App Service (ainsi que mon slot qui a copié la configuration de l’application parente), je vais pouvoir me baser sur les résultats de Azure Monitor pour vérifier l’état de santé de la ressource directement .

Voici donc le script utilisé pour cette tâche :

$slot = az webapp show --name $(webapp-name) --resource-group $(resourcegroup-name) --slot $(slot-name) | ConvertFrom-Json

$iteration = 0
$sleepDuration = 30

do {
    Start-Sleep $sleepDuration
    $iteration++

    $monitor = az monitor metrics list --resource $slot.id --metric "HealthCheckStatus" --interval 5m | ConvertFrom-Json
    $current = $monitor.value.timeseries.data[$monitor.value.timeseries.data.Count - 1].average

    Write-Host "After $($sleepDuration*$iteration)sec, currentAverrage: $current"

} until ($monitor.value.timeseries.data[$monitor.value.timeseries.data.Count - 1].average -eq 100.0)

Cette tâche effectue donc une boucle de check toutes les 30 sec, vérifie l’état de santé de la ressource via Azure Monitor sur les 5 dernières minutes et sort si l’application est considérée comme UP.

Swap Slots

Voilà l’opération attendue, il s’agit de la tâche Azure App Service Management fournie également par Azure DevOPS par défaut qui permet de réaliser l’opération :

Remove Staging Slot

Enfin comme, je vous l’avais annoncé, si toutes les opérations se passent bien, nous allons maintenant pouvoir supprimer notre slot une fois l’opération de swap réalisée.

Voici le script utilisé ici :

az webapp deployment slot delete --name $(webapp-name) --resource-group $(resourcegroup-name) --slot $(slot-name)

Notez également que cette tâche peut-être déclenchée, ,comme toutes les autres, selon certaines condition de votre pipeline :

Cela permet par exemple de s’assurer que dans tous les cas la suppression de l’environnement de staging soit supprimé etc…

Conclusions

L’utilisation des Slots sur les App Service est assez simple et gratuite (si on a le plan de service au bon tier et correctement dimensionné). L’opération de swap est bien transparente pour les utilisateurs mais prend néanmoins quelques minutes pour s’opérer sur la plateforme.

Il faudra cependant porter une attention particulière au Health Check qui se base sur un Endpoint qui ne donne que l’information du warmup de l’application. Il vous appartient de vérifier que votre application est dans un bon état de santé avant de réaliser le Swap (tests exhaustif des composants de votre application, …).