Microsoft met à disposition dans Azure DevOps un service permettant de mettre en place des pipelines de CI/CD : Azure Pipelines.
Les deux modules principaux de ce service que l’on va utiliser pour de la CI/CD sont : • Pipelines pour la CI (et aussi de la CD) • Releases pour la CD
On va ici se concentrer sur la CD sur Azure, et principalement comment faire en sorte que l’on puisse déployer automatiquement des ressources et services via Azure Resource Manager.
Tout d’abord, qu’est-ce que Azure Resource Manager (ARM) ?
Azure Resource Manager, c’est le service de déploiement et de gestion de ressources sur Azure qui sert entre autre à créer, mettre à jour, et supprimer des ressources sur Azure.
On l’a compris, si l'on veut pouvoir déployer une application web sur Azure via Azure DevOps, il faut pouvoir le connecter à Azure Resource Manager. Pour cela, il est nécessaire de créer ce que l’on appelle une Service Connection à Azure Resource Manager.
Comment créer une service connection de type Azure Resource Manager sur Azure DevOps ?
Dans le menu de paramétrage du projet puis dans la catégorie Pipelines, nous trouverons le menu de gestion des service connections.
En premier, nous sélectionnons le type de service connection que nous souhaitons créer : Azure Resource Manager
C’est à partir de ce point que l’on va avoir 2 approches possibles pour la création de la connexion.
L’approche manuelle
o Prérequis :
- Un projet Azure DevOps
- Une souscription à Azure
- Un service principal (on expliquera plus bas ce que c’est et comment le créer)
Après avoir choisi la méthode manuelle, plusieurs informations vont être requises pour continuer :
- L’Id de la souscription Azure
- Le nom de la souscription
- L’Id du service principal
- La clé du service principal (on va utiliser l’authentification via une clé générée au niveau du service principal)
- L’Id du tenant Azure AD
- Le nom que l’on veut donner à la connexion
Si vous n’avez pas de service principal, voici un rapide tutoriel expliquant de quoi il s’agit et comment en créer.
Qu’est-ce qu’un service principal ?
Un service principal, c’est une identité créée via Azure AD. La particularité de celle-ci par rapport à un compte utilisateur Azure AD, c’est qu’elle ne nécessite pas d’interaction pour s’authentifier et se gère intégralement sur Azure.
On l’utilise donc principalement pour permettre à des applications d’accéder à des ressources Azure et de s’authentifier auprès de services et/ou outils d’automatisation via assignation de rôle et clés secrètes.
Comment créer un service principal ?
Il faut au préalable avoir accès à l’administration Azure AD de votre tenant avant de pouvoir continuer ce tuto. Dans le portail Azure, chercher « App Registrations » et cliquer dessus.
Normalement on doit avoir la liste des app registrations existantes affichée, si vous avez un message indiquant que vous n’avez pas accès à ce module, vous devrez vous tourner vers votre administrateur Azure AD.
En cliquant sur « New Registration », on se retrouve sur la page de création d’un service principal. Saisissez un nom pour votre application et validez en cliquant sur « Register ».
Une fois créé, vous êtes redirigé vers le service principal en question, et trouverez dans l’encart de résumé les informations nécessaires pour authentifier l’application ou s’authentifier à celle-ci : Application (client) ID et Directory (tenant) ID.
Votre service principal est créé, mais en l’état il ne permettra pas à votre application d’accéder aux ressources Azures auxquelles vous souhaitez qu’elle accède.
Comment permettre à notre application d’accéder aux ressources Azure dont elle a besoin ?
Deux choses peuvent être nécessaires : • Sécuriser la connexion en tant que l’application que l’on vient de créer • Autoriser l’application au niveau des ressources
Etape 1 : Créer une clé secrète pour votre application
Dans le panneau de gauche, cliquez sur « Certificates & secrets » puis sur « New client Secret », remplissez le champs « Description » puis validez.
Le secret est créé et sa valeur est en clair, copiez-la pour ne pas la perdre car une fois que vous allez quitter la page elle ne sera plus visible.
Etape 2 : Assigner un rôle à l’application sur les ressources cibles
Maintenant que le service principal est créé, il faut lui assigner les permissions dont notre application a besoin sur les ressources cibles.
Dans notre cas (si l’on veut connecter notre espace de travail Azure DevOps à Azure Resource Manager pour gérer des ressources dans une souscription) il faut que le service principal associé à la service connection ait le rôle « Contributor » sur la souscription cible. Sinon, lors la vérification, la connexion entre Azure DevOps et Azure échoue.
Dans ce tuto, on va attribuer les permissions sur une souscription, ce qui fait que par héritage, le service principal aura les permissions sur toutes les ressources créées sous cette souscription.
Encore une fois, allez sur le portail Azure, mais cette fois-ci rendez vous sur la ressource sur laquelle vous voulez attribuer les permissions. Allez ensuite dans le sous-menu Access control (IAM) puis l’onglet Role assignments.
Depuis cet onglet, vous pourrez gérer les attributions de rôles pour cette ressource. On va donc cliquer sur « Add » puis « Add role assignment ».
Suivez les étapes de création en sélectionnant « Contributor » pour rôle à assigner puis cherchez le nom du service principal auquel vous voulez donner le rôle.
L’attribution devrait maintenant se retrouver dans la liste que l’on a pu voir au début.
Votre application a désormais les accès en gestion sur la ressource que vous avez choisi. Bien évidemment, l’attribution du rôle « Contributor » n’est pas systématique et il faut privilégier le principe du « least privilege » pour donner des accès. Vous savez maintenant comment créer un service principal via app registration et comment assigner des rôles sur les ressources Azure.
Une fois la vérification faite et validée, vous pouvez sauvegarder. La service connection est désormais visible depuis DevOps.
Lorsque vous irez créer des tâches Azure dans vos pipelines, la service connection sera sélectionnable et permettra de cibler des ressources créées dans les souscriptions auxquelles le service principal associé à la connexion aura le rôle « Contributor ».
L’approche automatique
o Prérequis :
- Un projet Azure DevOps
- Une souscription à Azure
Après avoir choisi la méthode automatique, Azure DevOps va automatiquement charger les souscriptions sur lesquelles le compte connecté est Contributeur. Il suffit de sélectionner celle à laquelle on veut que la service connection ait les droits de gestion. Petit détail, si on ne sélectionne pas de groupe, la service connection aura les droits sur la souscription, si on en a sélectionné un, elle n’aura les droits que sur ce groupe.
Donnez lui un nom puis validez, la service connection est désormais créée et disponible dans Azure DevOps.
On peut noter qu’à la différence de l’approche manuelle, nous n'avons pas eu besoin de renseigner d’information d’identification de service principal. En effet, l’approche automatisée va auto-générer un service principal et lui assigner automatiquement le rôle de Contributeur sur la ressource souhaitée.
Chez Atawiz, nous travaillons essentiellement avec deux souscriptions : une pour la production et une autre pour le reste. Nous privilégions donc l’approche manuelle, car celle-ci nous permet d’avoir une service connection isolée pour tout besoin de déploiement en production, et une service connection mutualisée pour tout ce qui est environnements de dev et de recette. Grâce à ce petit tuto, vous venez de faire le premier pas vers le DevOps sur Azure. Prochaine étape, créer une CI/CD pour une application simple en Angular, .NET avec une base de données SQL Server.