Déployez votre application sur Azure à l’aide de flux de travail GitHub Actions créés par Visual Studio
À partir de la version 16.11 de Visual Studio 2019, vous pouvez créer de nouveaux workflows GitHub Actions pour les projets .NET hébergés sur GitHub.com.
Prérequis
- Vous devez être connecté à votre compte GitHub dans Visual Studio.
- Un compte Azure. Si vous n’avez pas de compte Azure, activez vos avantages Azure réservés aux abonnés Visual Studio ou inscrivez-vous pour un essai gratuit.
Déployer un projet unique sur Azure avec GitHub Actions
Dans l’Explorateur de solutions, cliquez avec le bouton droit sur votre projet hébergé GitHub.com, puis choisissez Publier.
Dans l’écran suivant, sélectionnez Azure , puis choisissez Suivant.
Selon votre type de projet, vous obtenez une liste différente des services Azure à choisir. Choisissez l’un des services Azure pris en charge qui correspond à vos besoins.
À l’étape finale de l’Assistant, sélectionnez CI/CD à l’aide de flux de travail GitHub Actions (génère le fichier yml), puis choisissez Terminer.
Visual Studio génère un nouveau flux de travail GitHub Actions et vous demande de le valider et de le transmettre à GitHub.com.
Si vous effectuez cette étape à l’aide des outils Git intégrés, Visual Studio détecte l’exécution du flux de travail.
Définition des secrets GitHub
Pour que le workflow généré se déploie avec succès sur Azure, il peut avoir besoin d’accéder à un profil de publication.
Un déploiement réussi peut également nécessiter l’accès à un principal de service.
Dans tous les cas, Visual Studio tente de définir le secret GitHub pour vous avec la valeur correcte. En cas d’échec, il vous informera et vous donnera l’occasion de réessayer.
S'il ne parvient pas à définir à nouveau le secret, Visual Studio vous donne l'occasion d'accéder manuellement au secret. Vous pouvez donc effectuer le processus via la page de votre référentiel sur GitHub.com.
Déployer plusieurs projets sur Azure Container Apps avec GitHub Actions
Ces étapes sont appropriées si vous avez plusieurs projets qui utilisent des conteneurs Docker et que vous souhaitez les déployer en tant qu’application multiprojet. Vous pouvez déployer des applications multiprojets, comme celles qui mettent en œuvre des microservices, vers Azure Container Apps ou Azure Kubernetes Service (AKS). Cet article couvre les Container Apps d’Azure.
Cliquez avec le bouton droit sur le nœud GitHub Actions dans l’Explorateur de solutions, puis choisissez Nouveau workflow. L’Assistant de workflow de GitHub Actions s’affiche.
Dans l’écran cible du workflow GitHub Actions, choisissez Azure.
Pour la cible spécifique, choisissez Azure Container Apps. L’Assistant passe à l’écran Container App.
Choisissez un environnement Azure Container App existant ou sélectionnez Créer nouveau.
Lorsque vous en créez un nouveau, l’écran suivant s’affiche. À des fins de test ou de formation, il est généralement préférable de créer un nouveau groupe de ressources pour pouvoir tout supprimer plus facilement plus tard. Un environnement Container Apps est une limite sécurisée autour de groupes d’applications conteneur qui partagent le même réseau virtuel et écrivent leurs journaux dans la même destination de journalisation. Reportez-vous à Environnements Azure Container Apps. Si vous ne savez pas ce que c’est ou si vous n’en avez pas créé auparavant, créez-en un pour cette instance.
Une fois créée, la nouvelle instance Azure Container Apps s’affiche.
Choisissez Suivant pour passer à l’écran Registre. Choisissez une instance d’Azure Container Registry ou créez-en une nouvelle.
Si vous choisissez d’en créer une, cet écran s’affiche. Fournissez le groupe de ressources et la référence SKU, et choisissez si possible la même région qu’avant. Pour plus d’informations sur les références SKU pour Azure Container Registry, consultez Niveaux de service Azure Container Registry.
Une fois créé, le nouveau registre s’affiche à l’écran.
Les projets déployables dans votre solution sont affichés. Choisissez les projets que vous souhaitez déployer ensemble dans la même instance Azure Container Apps.
Cliquez sur Terminer. Vous pouvez voir les commandes émises pour créer les ressources dans Azure et configurer l’authentification. En cas d’échec, notez la ligne de commande utilisée, car vous pouvez réessayer à partir de l’interface CLI. Ne vous inquiétez pas trop si vous obtenez un échec d’autorisation à ce stade. Vous pourrez également configurer l’authentification plus tard dans Visual Studio.
Une fois l’opération terminée, l’écran de résumé s’affiche. L’écran de résumé affiche les informations d’identification, qui correspondent aux entrées créées par Visual Studio dans votre référentiel GitHub sous les secrets GitHub Actions. Vérifiez les éventuels panneaux d’avertissement jaunes. Si l’une des étapes d’authentification a échoué pendant le processus de création, vous avez la possibilité de corriger l’erreur ici en cliquant sur le lien à côté du panneau d’avertissement et en suivant quelques étapes.
Ouvrez le fichier de workflow pour vérifier ce que Visual Studio a généré. Bien que Visual Studio fasse de son mieux pour générer un workflow pour votre situation, chaque application et chaque référentiel est unique. Vous devez donc souvent modifier manuellement le fichier YML du workflow généré par Visual Studio avant qu’il ne s’exécute correctement. Pour l’ouvrir, développez le nœud GitHub Actions dans l’Explorateur de solutions, cliquez avec le bouton droit sur le workflow qui vient d’être créé, puis choisissez Modifier.
L’exemple suivant montre un fichier de workflow créé par Visual Studio pour une solution avec deux projets déployables, WebAPI et WebFrontEnd.
on:
push:
branches:
- main
env:
CONTAINER_REGISTRY_LOGIN_SERVER: registry20230810121555.azurecr.io
CONTAINER_APP_NAME: containerapp20230810121017
CONTAINER_APP_RESOURCE_GROUP_NAME: webfrontend-container-app-1234
CONTAINER_APP_CONTAINER_NAME: containerapp
jobs:
WebApi_buildImageAndDeploy:
runs-on: ubuntu-latest
steps:
- name: Checkout source code
uses: actions/checkout@v3
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v2
- name: Login to Docker registry
uses: docker/login-action@v2
with:
registry: ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }}
username: ${{ secrets.registry20230810121555_USERNAME_6891 }}
password: ${{ secrets.registry20230810121555_PASSWORD_6891 }}
- name: Build and push Docker image to Azure container registry
uses: docker/build-push-action@v4
with:
push: true
tags: ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }}/webapi:${{ github.sha }}
file: WebApi\Dockerfile
- name: Azure login
uses: azure/login@v1
with:
creds: ${{ secrets.containerapp20230810121017_SPN }}
- name: Deploy to Azure container app
uses: azure/CLI@v1
with:
inlineScript: >-
az config set extension.use_dynamic_install=yes_without_prompt
az containerapp registry set --name ${{ env.CONTAINER_APP_NAME }} --resource-group ${{ env.CONTAINER_APP_RESOURCE_GROUP_NAME }} --server ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }} --username ${{ secrets.registry20230810121555_USERNAME_2047 }} --password ${{ secrets.registry20230810121555_PASSWORD_2047 }}
az containerapp update --name ${{ env.CONTAINER_APP_NAME }} --container-name ${{ env.CONTAINER_APP_CONTAINER_NAME }} --resource-group ${{ env.CONTAINER_APP_RESOURCE_GROUP_NAME }} --image ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }}/webapi:${{ github.sha }}
- name: Azure logout
run: az logout
WebFrontEnd_buildImageAndDeploy:
runs-on: ubuntu-latest
needs: WebApi_buildImageAndDeploy
steps:
- name: Checkout source code
uses: actions/checkout@v3
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v2
- name: Login to Docker registry
uses: docker/login-action@v2
with:
registry: ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }}
username: ${{ secrets.registry20230810121555_USERNAME_2047 }}
password: ${{ secrets.registry20230810121555_PASSWORD_2047 }}
- name: Build and push Docker image to Azure container registry
uses: docker/build-push-action@v4
with:
push: true
tags: ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }}/webfrontend:${{ github.sha }}
file: WebFrontEnd\Dockerfile
- name: Azure login
uses: azure/login@v1
with:
creds: ${{ secrets.containerapp20230810121017_SPN }}
- name: Deploy to Azure container app
uses: azure/CLI@v1
with:
inlineScript: >-
az config set extension.use_dynamic_install=yes_without_prompt
az containerapp registry set --name ${{ env.CONTAINER_APP_NAME }} --resource-group ${{ env.CONTAINER_APP_RESOURCE_GROUP_NAME }} --server ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }} --username ${{ secrets.registry20230810121555_USERNAME_2047 }} --password ${{ secrets.registry20230810121555_PASSWORD_2047 }}
az containerapp update --name ${{ env.CONTAINER_APP_NAME }} --container-name ${{ env.CONTAINER_APP_CONTAINER_NAME }} --resource-group ${{ env.CONTAINER_APP_RESOURCE_GROUP_NAME }} --image ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }}/webfrontend:${{ github.sha }}
- name: Azure logout
run: az logout
La fonction principale du workflow est de se connecter aux services Azure avec l’authentification appropriée et d’exécuter les commandes pour générer et déployer l’application.
Modification et test du workflow
La procédure ci-dessus génère un fichier YML de workflow, mais vous devez normalement l’examiner et le personnaliser avant qu’il puisse être utilisé pour un déploiement. Vous devrez peut-être consulter les instructions de GitHub sur l’écriture d’actions de workflow. Le cas échéant, consultez À propos des actions personnalisées. Le fichier de workflow contient de nombreux éléments configurables, tels que les paramètres des variables d’environnement et les noms des secrets. Vous pouvez voir les références aux emplacements de vos fichiers Dockerfile, le nom de votre instance Azure Container App, la branche dans le référentiel que vous utiliserez pour déclencher les exécutions du workflow et les références aux secrets dans GitHub. Les secrets sont référencés à l’aide de la syntaxe ${{ secrets.SECRET_NAME }}. Reportez-vous à Secrets GitHub Actions.
Si vos projets ne se trouvent pas à la racine du référentiel, vous devez modifier le workflow pour spécifier le chemin d’accès pour trouver les fichiers Dockerfile. Ajoutez des variables d’environnement pour les chemins d’accès relatifs au fichier Dockerfile dans les deux projets.
DOCKER_FILEPATH_WEBAPI: docker/ComposeSample/WebApi/Dockerfile
DOCKER_FILEPATH_WEBFRONTEND: docker/ComposeSample/WebFrontend/Dockerfile
Utilisez les valeurs de ces variables d’environnement pour le paramètre file comme suit :
- name: Build and push Docker image to Azure container registry
uses: docker/build-push-action@v4
with:
push: true
tags: ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }}/webfrontend:${{ github.sha }}
file: ${{ env.DOCKER_FILEPATH_WEBFRONTEND }}
Si vous devez apporter des modifications au fichier Dockerfile, apportez et enregistrez les modifications, validez et envoyez (push) au dépôt distant. Le workflow généré par Visual Studio contient un déclencheur qui entraîne son exécution s’il est mis à jour sur une branche spécifiée. Si vous envoyez (push) à la branche working, cela devrait ressembler au code suivant :
on:
push:
branches:
- working
Pour tester les modifications, validez-les et envoyez-les à la branche du référentiel spécifiée dans le code du déclencheur. Vous n’avez pas besoin de créer une requête pull request (PR). Le workflow s’exécute tant que le déclencheur push est défini sur la bonne branche.
Sous l’onglet Actions de votre référentiel sur GitHub.com, recherchez l’exécution du workflow. Vous pouvez y accéder directement à l’aide d’un lien situé sous l’onglet de résumé GitHub Actions dans Visual Studio. Dans GitHub, vous pouvez ouvrir l’exécution du workflow pour afficher les journaux.
Résolution des problèmes
Les conseils de résolution des problèmes suivants peuvent être utiles si votre workflow ne s’exécute pas correctement.
Problème : L’étape de génération ne fonctionne pas
L’un des problèmes que vous pouvez rencontrer dans le fichier Dockerfile est que l’étape de génération ne fonctionne pas comme dans Visual Studio. Le fichier Dockerfile par défaut généré par Visual Studio pour un projet illustre ce problème. Considérez d’apporter les modifications suivantes à l’étape de génération si vous avez un fichier Dockerfile de ce type. Voici un exemple illustrant un projet situé sous docker/ComposeSample/WebApi dans un référentiel. Le chemin d’accès complet est donné, car le contexte du fichier Dockerfile dans le conteneur du build du workflow est défini sur la racine du référentiel, mais dans Visual Studio, il est défini sur le dossier au-dessus du dossier du projet. Le suffixe _build est ajouté ici pour créer le dossier du build, et au lieu de simplement copier le fichier projet, le dossier entier est copié. Par rapport au fichier Dockerfile par défaut généré par Visual Studio, la partie fichier du chemin d’accès dans le premier argument de la commande COPY a été supprimée afin de copier l’ensemble du dossier au lieu du fichier projet. Sans ces modifications, cette étape génère une erreur MSBuild.
FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /src
COPY ["docker/ComposeSample/WebApi/", "WebApi_build/"]
RUN dotnet restore "WebApi_build/WebApi.csproj"
COPY . .
WORKDIR "/src/WebApi_build"
RUN dotnet build "WebApi.csproj" -c Release -o /app/build
Problème : Informations d’authentification
Le workflow nécessite de configurer les secrets de nom d’utilisateur et de mot de passe appropriés pour l’accès à Azure. Visual Studio tente de le faire automatiquement lorsque vous créez les ressources Azure ou à partir de l’écran Actions GitHub dans l’IDE Microsoft Visual Studio. Vous pouvez vérifier les secrets dans GitHub et vous assurer qu’ils sont bien là, ou les régénérer et les ajouter à GitHub si nécessaire à l’aide de la section Paramètres du référentiel. Vérifiez l’ID des secrets par rapport à ce qui est référencé dans chaque section du workflow. Si nécessaire, vous pouvez accéder au registre de conteneurs dans le portail Azure et obtenir le nom d’utilisateur et le mot de passe du registre de conteneurs, et utiliser ces valeurs pour mettre à jour les secrets dans GitHub.
Si vous avez exécuté la commande az ad sp create-for-rbac pour configurer un principal de service et obtenir un ID client, une clé secrète client et un ID de tenant, ajoutez l’ID client et la clé secrète client comme secrets dans la section Secrets GitHub Actions pour votre référentiel GitHub. Vous pouvez fournir des informations d’identification de connexion à Azure sous la forme d’un nom d’utilisateur (ID client pour l’application) et d’un mot de passe (clé secrète client) pour l’authentification Azure Container App. Pour ce faire, remplacez l’étape Azure login par le code suivant. Utilisez vos propres noms de secrets GitHub que vous avez créés pour l’ID client et la clé secrète client, puis utilisez l’ID de tenant obtenu à partir de la sortie de la même commande.
- name: Azure login
uses: azure/CLI@v1
with:
inlineScript: |
az login --service-principal -u ${{ secrets.GITHUB_SECRETID_FOR_USERNAME }} -p ${{ secrets.GITHUB_SECRETID_FOR_PASSWORD }} --tenant {your tenant ID}
az account list
Si le fichier Dockerfile fonctionne correctement et que l’authentification est correcte, mais que vous rencontrez toujours des problèmes avec votre workflow, considérez les ressources suivantes :
Quels types de projets sont pris en charge ?
- ASP.NET Core
- ASP.NET 5 et versions ultérieures
- Azure Functions
Quels sont les services Azure pris en charge ?
- Azure Web Apps
- Azure Functions
- Gestion des API Azure
Commentaires
Bientôt disponible : Tout au long de l’année 2024, nous abandonnerons progressivement le mécanisme de retour d’information GitHub Issues pour le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez : https://aka.ms/ContentUserFeedback.
Soumettre et afficher des commentaires pour