Partager via


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

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.

Cliquez avec le bouton droit sur > Publier

Dans l’écran suivant, sélectionnez Azure , puis choisissez Suivant.

Sélectionnez Azure

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.

sélectionnez le service Azure approprié pour votre projet

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

CI/CD à l'aide des workflows GitHub Actions (génère un fichier yml)

Visual Studio génère un nouveau flux de travail GitHub Actions et vous demande de le valider et de le transmettre à GitHub.com.

Valider et faire un Push

Si vous effectuez cette étape à l’aide des outils Git intégrés, Visual Studio détecte l’exécution du flux de travail.

Le flux de travail est en cours d'exécution

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 secret GitHub

Un déploiement réussi peut également nécessiter l’accès à un principal de service.

deux secrets GitHub

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.

secret GitHub manquant

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éfinir le secret GitHub manquant

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.

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

    Capture d'écran du menu du nœud GitHub Actions.

  2. Dans l’écran cible du workflow GitHub Actions, choisissez Azure.

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

    Capture d'écran montrant les Azure Container Apps existants.

  4. Choisissez un environnement Azure Container App existant ou sélectionnez Créer nouveau.

    Capture d'écran montrant les concepts d'Azure Container Apps.

    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.

    Capture d'écran montrant la création d'une nouvelle instance Azure Container Apps.

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

    Capture d'écran montrant l'instance Azure Container Apps nouvellement créée.

  5. Choisissez Suivant pour passer à l’écran Registre. Choisissez une instance d’Azure Container Registry ou créez-en une nouvelle.

    Capture d'écran de l'écran Azure Container Registry.

    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.

    Capture d'écran montrant un nouveau Azure Container Registry qui vient d'être créé.

    Une fois créé, le nouveau registre s’affiche à l’écran.

    Capture d'écran montrant la création d'un nouveau Azure Container Registry.

  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.

    Capture d'écran montrant le choix des projets à déployer.

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

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

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