Terraform sur Microsoft Azure | 1 – Introduction
Julien Corioland
Senior Software Engineer & Cloud Architect chez Microsoft
Introduction | Terraform sur Microsoft Azure
Cet article est le premier d’une série de sept, qui se concentrera sur Terraform sur Microsoft Azure.
-
- Terraform sur Microsoft Azure – Partie 1 : Introduction
- Terraform sur Microsoft Azure – Partie 3 : Gestion de l’état des déploiments
- Terraform sur Microsoft Azure – Partie 4 : Modularisation
- Terraform sur Microsoft Azure – Partie 5 : Tests d’infrastructure
- Terraform sur Microsoft Azure – Partie 6 : Intégration continue avec Azure Pipeline
- Terraform sur Microsoft Azure – Partie 7 : Déploiement continu avec Azure Pipeline
Leur objectif est de montrer comment utiliser Terraform et Microsoft Azure pour déployer l’infrastructure suivante :
Comme le montre l’illustration ci-dessus, l’infrastructure est constituée de différents composants :
- des composants principaux, comme les réseaux virtuels et les sous-réseaux
- des services d’infrastructure, comme les services Azure Kubernetes, ou tout simplement les machines virtuelles Azure
- des services de plateforme, comme Azure Database pour MySql, KeyVault, Container Registry…
- des outils communs/transverses, comme Azure Monitor et Log Analytics
Ces choix nous permettront de discuter de différents points, qui seront abordés au cours des différents articles
- comment écrire des modules Terraform pour factoriser le code de l’infrastructure
- comment gérer le déploiement d’une infrastructure présentant des composants avec des cycles de vie différents
- comment déployer seulement une partie de l’infrastructure, par exemple un environnement dupliqué ou un sous-ensemble d’un environnement
- comment revenir à une version précédente d’une application et de l’infrastructure sous-jacente
Terraform sur Microsoft Azure – Partie 1 : Introduction
Avant de nous plonger dans les détails techniques, revenons brièvement sur une notion particulièrement importante, celle d’Infrastructure as Code.
Assez souvent, les équipes de développement centralisent le code source d’une application dans un référentiel dédié (GitHub ou Azure Repos, par exemple). Cela leur permet de partager le code, de le fusionner ou de résoudre les conflits entre développeurs travaillant sur les mêmes fichiers, de procéder au versionnage, et éventuellement de revenir à une version précédente, lorsque c’est nécessaire. Cette démarche n’est cependant pas encore systématique au sein des services informatiques ou des équipes en charge de l’infrastructure.
Néanmoins, il est tout à fait possible d’appliquer le même schéma et les mêmes pratiques à votre infrastructure, simplement en la traitant comme du code. Pour être plus clair, l’ensemble des scripts, des fichiers de configuration et des templates que vous utilisez habituellement pour décrire, déployer et configurer votre infrastructure peuvent également être stockés dans un référentiel de code source, être versionnés, et avoir exactement le même cycle de vie que les applications déployées sur l’infrastructure en question.
Ce point est très important car en procédant ainsi, vous pourrez revenir à tout moment à une autre version de l’application et la redéployer sur la version de l’infrastructure qui convient, sans vous demander comment vous avez fait (ou comment a fait la personne à laquelle vous avez succédé dans l’entreprise).
Ici, le maître-mot est l’automatisation, sur laquelle repose en partie l’Infrastructure as Code (IaC), qui vous permettra de déployer votre infrastructure en continu tout en maintenant un haut niveau de qualité, via la mise en place de tests automatisés.
Il existe de nombreux outils qui peuvent vous aider à maîtriser l’Infrastructure as Code et les pratiques de déploiement continu de l’infrastructure. Peut-être avez-vous déjà utilisé des templates Azure Resource Manager (ARM), ces fichiers JSON qui permettent de décrire l’infrastructure entière en y injectant des variables et paramètres, et de la déployer dans Azure.
Terraform est un outil Open Source développé et géré par HashiCorp. L’objectif est exactement le même que celui des modèles ARM : aider à décrire l’infrastructure à l’aide du langage HCL (HashiCorp Configuration Language), plus lisible que JSON, pour la déployer dans Azure. Terraform s’accompagne d’un ensemble d’outils qui facilitent la gestion de l’état et du cycle de vie des déploiements et en font une solution un peu plus aboutie que les modèles ARM.
Par ailleurs, Terraform fonctionne non seulement avec Microsoft Azure, mais également avec une multitude d’autres fournisseurs. Cela ne veut pas dire que lorsque vous écrivez un modèle HCL pour Microsoft Azure, il fonctionnera comme par magie pour un déploiement sur n’importe quel autre cloud. Cela signifie simplement que vous pourrez utiliser le même langage et les mêmes outils pour automatiser le déploiement d’une infrastructure spécifique sur n’importe quelle plateforme compatible avec Terraform.
Sur l’auteur
Il a participé dernièrement à plusieurs projets dont l’objectif était d’aider les clients à améliorer la gestion du déploiement de leur infrastructure. Les plateformes cloud comme Microsoft Azure permettent un niveau élevé d’automatisation de ces déploiements. Il existe par ailleurs différentes options et différents outils qui permettent de déployer les différents éléments de l’infrastructure de façon automatique, reproductible et idempotente.
Aller voir la partie 2 : Les Principes de base >