Configurer le stockage et les bases de données
Souvent, une partie de votre processus de déploiement requiert que vous vous connectiez aux bases de données ou aux services de stockage. Cette connexion peut être nécessaire pour appliquer un schéma de base de données, ajouter des données de référence à une table de base de données ou charger des objets blob. Dans cette unité, vous découvrirez comment étendre votre workflow pour travailler avec des services de données et de stockage.
Configurer vos bases de données à partir d’un workflow
De nombreuses bases de données ont des schémas, qui représentent la structure des données contenues dans la base de données. Il est souvent recommandé d’appliquer un schéma à votre base de données à partir de votre workflow de déploiement. Cette pratique permet de garantir que tous les éléments dont votre solution a besoin sont déployés ensemble. Cela garantit également, en cas de problème lors de l’application du schéma, que votre workflow affichera une erreur, ce qui vous permettra de résoudre le problème et de redéployer.
Lorsque vous utilisez Azure SQL, vous devez appliquer des schémas de base de données en vous connectant au serveur de base de données et en exécutant des commandes à l’aide de scripts SQL. Ces commandes sont des opérations de plan de données. Votre workflow doit s’authentifier auprès du serveur de base de données, puis exécuter les scripts. GitHub Actions fournit l’action azure/sql-action qui peut se connecter à un serveur de base de données Azure SQL et exécuter des commandes.
Il n’est pas nécessaire de configurer d’autres services de données et de stockage à l’aide d’une API de plan de données. Par exemple, lorsque vous utilisez Azure Cosmos DB, vous stockez vos données dans un conteneur. Vous pouvez configurer vos conteneurs à l’aide du plan de contrôle, directement à partir de votre fichier Bicep. De même, vous pouvez déployer et gérer la plupart des aspects des conteneurs d’objets blob de Stockage Azure dans Bicep. Dans l’exercice suivant, vous verrez un exemple illustrant la façon de créer un conteneur d’objets blob à partir de Bicep.
Ajout de données
De nombreuses solutions nécessitent l’ajout de données de référence à leurs bases de données ou comptes de stockage avant de fonctionner. Il peut être judicieux d’ajouter ces données aux workflows. De cette manière, une fois que le workflow s’exécute, votre environnement est entièrement configuré et prêt à être utilisé.
Il est également utile de disposer d’exemples de données dans vos bases de données, en particulier pour les environnements hors production. Les exemples de données aident les testeurs et autres personnes qui utilisent ces environnements à pouvoir tester immédiatement votre solution. Ces données peuvent inclure des exemples de produits ou des éléments tels que des faux comptes d’utilisateur. En règle générale, vous ne souhaitez pas ajouter ces données à votre environnement de production.
L’approche que vous utilisez pour ajouter des données dépend du service que vous utilisez. Par exemple :
- Pour ajouter des données à une base de données Azure SQL, vous devez exécuter un script, comme pour configurer un schéma.
- Lorsque vous devez insérer des données dans Azure Cosmos DB, vous devez accéder à son API de plan de données, ce qui peut vous obliger à écrire du code de script personnalisé.
- Pour charger des objets blob dans un conteneur d’objets blob de Stockage Azure, vous pouvez utiliser divers outils à partir des scripts de workflow, notamment l’application de ligne de commande AzCopy, Azure PowerShell ou Azure CLI. Chacun de ces outils comprend comment s’authentifier auprès du Stockage Azure en votre nom et comment se connecter à l’API de plan de données pour charger des objets blob.
Idempotence
L’une des caractéristiques des workflows de déploiement et de l’infrastructure en tant que code est que vous devriez être en mesure de redéployer de façon répétée sans effets secondaires indésirables. Par exemple, quand vous redéployez un fichier Bicep que vous avez déjà déployé, Azure Resource Manager compare le fichier que vous avez envoyé à l’état existant de vos ressources Azure. En l’absence de modifications, Resource Manager ne fait rien. La capacité à réexécuter une opération de façon répétée est appelée idempotence. Une bonne pratique consiste à vous assurer que vos scripts et autres étapes de workflow sont idempotents.
L’idempotence est particulièrement importante lorsque vous interagissez avec des services de données, car ils conservent l’état. Imaginez que vous insériez un exemple d’utilisateur dans une table de base de données à partir de votre workflow. Si vous n’êtes pas vigilant, un nouvel exemple d’utilisateur est créé, chaque fois que vous exécutez votre workflow. Ce résultat n’est probablement pas celui que vous voulez.
Lorsque vous appliquez des schémas à une base de données Azure SQL, vous pouvez utiliser un package de données, également appelé fichier DACPAC, pour déployer votre schéma. Votre workflow génère un fichier DACPAC à partir du code source et crée un artefact de workflow, comme avec une application. Ensuite, le travail de déploiement dans votre workflow publie le fichier DACPAC dans la base de données :
Lorsqu’un fichier DACPAC est déployé, il se comporte de manière idempotente en comparant l’état cible de votre base de données à l’état défini dans le package. Dans de nombreux cas, cela signifie que vous n’avez pas besoin d’écrire des scripts qui suivent le principe de l’idempotence, car les outils le gèrent pour vous. Certains outils pour Azure Cosmos DB et le stockage Azure se comportent également correctement.
Toutefois, lorsque vous créez des exemples de données dans une base de données Azure SQL ou un autre service de stockage qui ne fonctionne pas automatiquement de manière idempotente, une bonne pratique consiste à écrire votre script afin qu’il crée des données seulement si elles n’existent pas déjà.
Il est également important de considérer si vous pouvez être amené à restaurer les déploiements, par exemple en réexécutant une version antérieure d’un workflow de déploiement. La restauration à vos données peut s’avérer compliquée. Réfléchissez donc attentivement à la manière dont votre solution fonctionnera si vous devez autoriser les restaurations.
Sécurité du réseau
Parfois, vous pouvez appliquer des restrictions réseau à certaines de vos ressources Azure. Ces restrictions peuvent appliquer des règles sur les demandes adressées au plan de données d’une ressource, par exemple :
- Ce serveur de base de données est accessible uniquement à partir d’une liste spécifiée d’adresses IP.
- Ce compte de stockage est accessible uniquement à partir de ressources déployées au sein d’un réseau virtuel spécifique.
Les restrictions réseau sont courantes avec les bases de données, car il n’est pas nécessaire d’utiliser Internet pour se connecter à un serveur de base de données.
Toutefois, en raison des restrictions réseau, vos workflows de déploiement peuvent avoir des difficultés à fonctionner avec les plans de données de vos ressources. Quand vous utilisez un exécuteur hébergé par GitHub, son adresse IP n’est pas facilement connue à l’avance et peut être affectée à partir d’un grand pool d’adresses IP. En outre, les exécuteurs hébergés par GitHub ne peuvent pas être connectés à vos propres réseaux virtuels.
Certaines actions qui vous aident à effectuer des opérations de plan de données peuvent contourner ces problèmes. Par exemple, l’action azure/sql-action :
Quand vous utilisez l’action azure/sql-action pour utiliser une base de données ou un serveur logique Azure SQL, elle utilise votre identité de charge de travail
pour se connecter au plan de contrôle pour le serveur logique Azure SQL. Elle met à jour le pare-feu pour permettre à l’exécuteur d’accéder au serveur à partir de son adresse IP
. Ensuite, elle peut soumettre avec succès le fichier ou le script DACPAC à exécuter
. L’action supprime ensuite automatiquement la règle de pare-feu, une fois terminée.
Dans d’autres situations, il n’est pas possible de créer des exceptions de ce type. Dans ce cas, envisagez d’utiliser un exécuteur auto-hébergé, qui s’exécute sur une machine virtuelle ou une autre ressource de calcul que vous contrôlez. Vous pouvez ensuite configurer cet exécuteur selon vos besoins. Il peut utiliser une adresse IP connue ou il peut se connecter à votre propre réseau virtuel. Nous n’aborderons pas les exécuteurs auto-hébergés dans ce module, mais nous vous proposons des liens vers des informations supplémentaires dans la page Résumé du module.
Votre workflow de déploiement
Dans l’exercice suivant, vous allez mettre à jour votre workflow de déploiement pour ajouter de nouveaux travaux afin de créer les composants de base de données de votre site web, déployer la base de données et ajouter des valeurs initiales :
