Déployer votre application sur Azure à l’aide de flux de travail GitHub Actions créés par Visual Studio

À compter de Visual Studio 2019 version 16.11, vous pouvez créer de nouveaux flux de travail GitHub Actions pour les projets .NET hébergés sur GitHub.com.

Conditions préalables

• 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 pour les abonnés Visual Studio ou inscrivez-vous à un essai gratuit.

Déployer un projet unique sur Azure à l’aide de GitHub Actions

Dans l’Explorateur de solutions, cliquez avec le bouton droit sur votre projet hébergé GitHub.com et 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étectera l'exécution du flux de travail.

Définition des secrets GitHub

Pour que le flux de travail généré soit correctement déployé sur Azure, il peut nécessiter l’accès à 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 la possibilité d’accéder manuellement au secret. Vous pouvez donc effectuer le processus via la page de votre dépôt sur GitHub.com.

Déployer plusieurs projets sur Azure Container Apps à l’aide de 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 multiprojet telles que celles qui implémentent des microservices pour azure Container Apps ou Azure Kubernetes Service (AKS). Cet article traite d’Azure Container Apps.

1. Cliquez avec le bouton droit sur le nœud GitHub Actions dans l’Explorateur de solutions, puis choisissez nouveau flux de travail. L’Assistant de workflow de GitHub Actions s’affiche.

   

2. Dans l’écran cible du flux de travail GitHub Actions, choisissez Azure.

3. Pour la cible spécifique, choisissez Azure Container Apps. L’Assistant passe à l’écran Container App.

   Capture d’écran

4. Choisissez une application conteneur Azure existante ou choisissez Créer une nouvelle.

   capture d’écran

   Lorsque vous en créez un, vous voyez cet écran. Lors de l'exécution de tests ou d'activités d'apprentissage, il est généralement préférable de créer un nouveau groupe de ressources pour faciliter la suppression de tout 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 qui est ou n’en avez pas créé un auparavant, créez-en un pour cette instance.

   

   Une fois créée, la nouvelle instance Azure Container Apps s’affiche.

   

5. Choisissez Suivant pour passer à l’écran Registre. Choisissez un Registre de conteneurs Azure existant ou créez-en un.

   

   Si vous choisissez de en créer un, vous voyez cet écran. Fournissez le groupe de ressources, la référence SKU et choisissez la même région, le cas échéant, comme 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.

   capture d’écran

6. 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.

   

7. Choisissez 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 pouvez également configurer l’authentification ultérieurement dans Visual Studio.

8. Une fois l’opération terminée, l’écran récapitulative s’affiche. L’écran récapitulatif affiche les informations d’identification, qui correspondent aux entrées créées par Visual Studio dans votre dépôt GitHub sous les secrets GitHub Actions. Vérifiez les signes d’avertissement jaunes. Si l’une des étapes d’authentification a échoué pendant le processus de création, vous avez la possibilité de corriger cela ici en cliquant sur le lien par le signe d’avertissement et en suivant quelques étapes.

9. Ouvrez le fichier de flux de travail pour vérifier ce que Visual Studio a généré. Bien que Visual Studio fasse le meilleur pour générer un flux de travail pour votre situation, chaque application et référentiel est unique. Vous devez donc souvent modifier manuellement le fichier YML de flux de travail 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 illustre un fichier de flux de travail 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 flux de travail 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 flux de travail

La procédure ci-dessus génère un fichier YML de flux de travail, mais vous devez normalement passer en revue et le personnaliser avant de pouvoir être utilisé pour un déploiement. Vous devrez peut-être consulter les instructions de GitHub sur l’écriture d’actions de flux de travail ; consultez À propos des actions personnalisées. Le fichier de flux de travail 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 Dockerfiles, le nom de votre application conteneur Azure, la branche dans le référentiel que vous utiliserez pour déclencher les exécutions du flux de travail 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 dépôt, vous devez modifier le flux de travail pour spécifier le chemin d’accès pour rechercher les fichiers Dockerfiles. 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, apporter et enregistrer les modifications, valider et envoyer (push) au référentiel distant. Le flux de travail généré par Visual Studio contient un déclencheur qui l’entraîne à s’exécuter s’il est mis à jour sur une branche spécifiée. Si vous poussez vers la branche working, votre code devrait ressembler au code suivant :

on:
  push:
  branches:
  - working

Pour tester les modifications, validez-les et envoyez-les à la branche du dépôt spécifié dans le code du déclencheur. Vous n’avez pas besoin de créer une pull request (PR). Le workflow s’exécute tant que le déclencheur push est défini sur la bonne branche.

Dans l'onglet Actions de votre dépôt sur GitHub.com, recherchez le workflow exécuté. Vous pouvez y accéder directement à l’aide d’un lien sous l’onglet Résumé GitHub Actions dans Visual Studio. Sur GitHub, vous pouvez ouvrir l’exécution du flux de travail pour afficher les logs.

Dépannage

Les conseils de dépannage suivants peuvent être utiles si votre flux de travail 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 fonctionnera pas comme dans Visual Studio. Le fichier Dockerfile par défaut généré par Visual Studio pour un projet illustre ce problème. Tenez compte des modifications suivantes apportées à l’étape de génération si vous disposez d’un fichier Dockerfile de ce type. Voici un exemple où se trouvait un projet à docker/ComposeSample/WebApi dans un dépôt. 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 de build, et au lieu de copier simplement le fichier projet, le dossier entier est copié. Par rapport au Dockerfile par défaut généré par Visual Studio, la partie du chemin correspondant au fichier dans le premier argument de la commande COPY a été supprimée afin de copier l’ensemble du dossier au lieu du fichier du 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 flux de travail nécessite la configuration des 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 GitHub Actions dans l’IDE Microsoft Visual Studio. Vous pouvez vérifier les secrets dans GitHub et s’assurer qu’ils sont 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 locataire, ajoutez l’ID client et le secret client comme secrets dans la section Secrets GitHub Actions pour votre dépôt 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 (secret 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 locataire à 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 et que vous rencontrez toujours des problèmes avec votre flux de travail, tenez compte des ressources suivantes :

• Azure Container Apps sur GitHub
• Azure Container Apps sur Stack Overflow

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