Dans la première partie de cette série de billets de blog consacrée à DevOps sur Microsoft Azure, nous avons découvert l’approche DevOps, les différentes pratiques DevOps et comment le Cloud peut agir comme catalyseur de DevOps.Dans ce billet, nous découvrirons la pratique DevOps IaC (Infrastructure as Code) et comment la mettre en œuvre en utilisant le service Azure ARM.
Gestion de la configuration dans un projet DevOps
Il y a de cela quelques années, mon équipe a été confrontée au crash d’un de nos serveurs de développement. Les responsables d’infrastructure ont pris pas moins de trois jours pour livrer de nouveaux environnements. Pour chaque environnement, il fallait réinstaller les OS et procéder à l’installation et la configuration manuelle de chaque application/service utilisée. Les environnements livrés à la fin ne correspondaient pas pour autant aux environnements précédents, car de nombreux patchs effectués manuellement et non documentés dans certains cas ont été perdus. Conséquence : le temps de déploiement des applications a été beaucoup plus long.
Dans votre quotidien de développeur ou de professionnel de l’IT, vous avez déjà été probablement confronté à une situation similaire. Vous pouvez donc évaluer l’impact sur le cout et les délais.
Voici une autre situation dont de nombreux développeurs ont déjà eu à faire face. Vous développez votre application. Vous effectuez vos tests en environnements de développement. L’application fonctionne normalement. Tout semble parfait. Une fois en environnement de production, plus rien ne marche. Ceci pour la simple raison que l’environnement de développement est très différent de l’environnement de production. Ça vous prendra du temps supplémentaire pour diagnostiquer et apporter des correctifs pour faire fonctionner l’application.
Dans un projet DevOps, les situations présentées ci-dessus sont censées ne jamais se produire. DevOps propose de bonnes pratiques de gestion de la configuration via l’automatisation. Toute mise à jour d’un environnement, toute application d’un correctif de sécurité, toute installation d’un patch, etc. doivent se faire via des scripts. Aucune intervention manuellement n’est requise. En scriptant la configuration d’un environnement, on dispose en tout temps l’historique des opérations qui ont été effectuées sur ce dernier. De plus, les scripts peuvent directement faire office de documentation. Plus besoin donc d’aller mettre à jour un quelconque document après chaque intervention.
Lorsqu’on parle de gestion de la configuration dans une démarche DevOps, cela fait référence à deux pratiques : Infrastructure as Code et Configuration as Code.
Infrastructure as Code (IaS)
IaS ou Infrastructure programmable est une approche de gestion de l’infrastructure en utilisant des scripts qui seront visionnés tout comme le code source de l’application. Le terme Infrastructure as Code peut sembler ambigu, vu que l’infrastructure fait référence aux hardwares. On peut donc penser à tort qu’il s’agit de coder son hardware. Ce qui n’est pas le cas. L’IaS est le provisionnement et la configuration des hardwares via des scripts (installation et configuration des machines virtuelles, réseaux, load balancer, etc.)
Le principe est assez simple. L’infrastructure pour exécuter une application est un ensemble de ressources : machines virtuelles, espace de stockage, gestionnaire de base de données, etc. La création et la configuration de ces ressources sont définies dans des fichiers de script. A l’exécution de ces fichiers, on obtient une infrastructure complète, prête à être utilisée pour le déploiement et l’exécution de notre application.
Le recours à des scripts va permettre de créer assez facilement autant d’environnements que besoin (dev, test, etc.), avec des états identiques. En effet, chaque fois que le script sera exécuté, le même environnement sera créé.
Deux approches sont couramment utilisées lorsque l’on a recours à l’IaC : impérative et déclarative. L’approche déclarative est centrée sur le résultat final. Les utilisateurs doivent définir l’état final du système attendu, et les scripts d’automatisation doivent atteindre ce résultat. L’approche impérative, quant à elle, est centrée sur le comment. Les scripts d’automatisation définissent comment des changements seront apportés à l’infrastructure pour atteindre un certain objectif.
Infrastructure as Code vs déploiement manuel
Le recours à l’IaS offre de nombreux avantages comparés à l’approche manuelle. Ces avantages permettent de réduire le temps de livraison et les couts. Grâce au recours à des scripts pouvant être exécutés de façon répétitive, l’équipe projet pourra ainsi se concentrer sur la résolution des problèmes métiers.
Gestion de la configuration dans le pipeline d’intégration et livraison continue
La définition et la configuration des ressources étant définies dans des fichiers de script, il devient assez aisé d’introduire ceux-ci dans un pipeline d’intégration et de livraison continue. Avant le déploiement de l’application, les scripts d’automatisation sont exécutés pour configurer et provisionner les ressources sur lesquelles l’application sera déployée.
Si vous avez besoin d’une nouvelle ressource plus tard, il suffira de modifier le script et introduire cette nouvelle ressource. Lors du déploiement, la plateforme d’intégration et livraison continue va détecter un changement dans la définition de l’infrastructure et exécutera le script qui permettra le provisionnement de la nouvelle ressource.
En procédant ainsi, votre infrastructure évoluera avec votre application, et vous disposerez en tout temps le code de l’application et le script de configuration de l’infrastructure dans l’état qu’il faut pour exécuter l’application.
Mise en place de l’IaC
Il existe sur le marché de nombreuses solutions pour aider les équipes à mettre en place des infrastructures programmables. On peut citer en autres Vagrant, Ansible, Puppet, Docker, Chef, Dell Cloud Manager, etc. Dans les prochaines parties, nous allons voir concrètement comment scripter son infrastructure en utilisant Azure Resource Manager(ARM).
Description d’ARM
Azure Resource Manager est la solution offerte par la plateforme Cloud Azure pour la création, le provisionnement, la modification et la suppression des ressources. ARM utilise une approche déclarative pour la gestion de l’infrastructure. En effet, les caractéristiques des ressources que vous souhaitez utiliser (disque dur, mémoire vive, etc.) doivent être définies dans un fichier au format JSON. ARM se chargera d’interpréter ce fichier et déployer les ressources qui correspondent dans Azure.
Pour exploiter efficacement ARM, vous devez savoir à quoi renvoient les termes Resource, Resource Group, Resource Providers et ARM Template.
- Qu'est-ce qu’une ressource ?
Sur Azure, une ressource fait référence à un item qui est disponible dans la plateforme Cloud et qui est géré par l’utilisateur. Une ressource peut être une machine virtuelle, une base de données, un compte de stockage, un load balancer, etc.
- À quoi renvoie un groupe de ressources (Resource group) ?
Le déploiement d’une application dans Azure peut nécessiter le recours à plusieurs ressources : machine virtuelle, base de données, compte de stockage, etc. L’ensemble de ces ressources représente l’infrastructure nécessaire au fonctionnement de votre application. Celle-ci doit évoluer suivant les besoins de l’application.
Pour faciliter la gestion de ces ressources, Microsoft offre les « resource group ». Il s’agit d’un conteneur pour toutes les ressources d’une solution.
En créant vos groupes de ressources, ayez à l’esprit que toutes les ressources dans le même resource group doivent avoir le même cycle de vie. De ce fait, elles sont déployées, mises à jour et supprimées ensemble.
- Resource Providers
Dans votre Resource Group, les ressources sont créées et gérées par un Resource Provider (fournisseur de ressource). Chaque Resource Provider fournit des ressources et des outils permettant d’exploiter les services d’Azure.
Les Resource Providers sont accessibles à travers une couche de gestion cohérente, pouvant être utilisée par de nombreux outils pour exploiter la plateforme Azure. Que vous utilisez Azure PowerShell, le portail Azure, Azure CLI, etc. vous aurez accès au même ensemble d’opérations.
- ARM Template
Comme je l’ai souligné plus haut, ARM utilise l’approche déclarative. Les caractéristiques des ressources qui seront déployées dans un resource group, ainsi que leurs dépendances sont définies dans des fichiers au format JSON (JavaScript Object Notation). Ces fichiers représentent les ARM templates.
Le code JSON ci-dessous est un exemple de template ARM :
| Code json : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | "resources": [ { "apiVersion": "2016-01-01", "type": "Microsoft.Storage/storageAccounts", "name": "mystorageaccount", "location": "westus", "sku": { "name": "Standard_LRS" }, "kind": "Storage", "properties": { } } ] |
Lorsque ARM reçoit un tel code, il l’interprète et transforme son contenu en des opérations REST pouvant être utilisées par chaque Resource Provider pour créer et configurer la ressource qu’il faut.
Dans la prochaine partie, nous allons créer et déployer notre infrastructure sur Azure en utilisant ARM et Visual Studio.