Utiliser un workflow GitHub Actions pour déployer votre site web statique dans Stockage Azure

Article
02/19/2024

Commencez avec GitHub Actions en utilisant un workflow pour déployer un site statique sur un compte de stockage Azure. Une fois que vous avez configuré un workflow GitHub Actions, vous pouvez automatiquement déployer votre site vers Azure à partir de GitHub lorsque vous apportez des modifications au code de votre site.

Notes

Si vous utilisez Azure Static Web Apps, vous n’avez pas besoin de configurer manuellement un workflow GitHub Actions. Azure Static Web Apps crée automatiquement un workflow GitHub Actions pour vous.

Prérequis

Un abonnement Azure et un compte GitHub.

Compte Azure avec un abonnement actif. Créez un compte gratuitement.
Un référentiel GitHub avec votre code de site web statique. Si vous n’avez pas de compte GitHub, inscrivez-vous gratuitement.
Un site web statique opérationnel hébergé dans Stockage Azure. Découvrez comment héberger un site web statique dans Stockage Azure. Pour suivre cet exemple, vous devez également déployer Azure CDN.

Notes

Il est courant d’utiliser un réseau de distribution de contenu (CDN) pour réduire la latence pour vos utilisateurs dans le monde entier et pour réduire le nombre de transactions sur votre compte de stockage. Le déploiement de contenu statique dans un service de stockage informatique peut réduire la nécessité d’une instance de calcul potentiellement coûteuse. Pour plus d’informations, consultez Modèle d’hébergement de contenu statique.

Générer les informations d’identification du déploiement

Principal du service
OpenID Connect

Créez un principal de service à l’aide de la commande az ad sp create-for-rbac dans Azure CLI. Exécutez cette commande en utilisant Azure Cloud Shell dans le portail Azure ou en sélectionnant le bouton Essayer.

az ad sp create-for-rbac --name "myML" --role contributor \
                            --scopes /subscriptions/<subscription-id>/resourceGroups/<group-name> \
                            --json-auth

Le paramètre --json-auth est disponible dans les versions d’Azure CLI >= 2.51.0. Les versions antérieures à celle-ci utilisent --sdk-auth avec un avertissement de dépréciation.

Dans l’exemple ci-dessus, remplacez les espaces réservés par votre ID d’abonnement, le nom de votre groupe de ressources et le nom de votre application. La sortie correspond à un objet JSON avec les informations d’identification de l’attribution de rôle qui fournit l’accès à votre application App Service, similaire à ce qui suit. Copiez cet objet JSON pour une version ultérieure.

  {
    "clientId": "<GUID>",
    "clientSecret": "<GUID>",
    "subscriptionId": "<GUID>",
    "tenantId": "<GUID>",
    (...)
  }

OpenID Connect est une méthode d’authentification qui utilise des jetons de courte durée. La configuration d’OpenID Connect avec GitHub Actions est un processus plus complexe qui offre une sécurité renforcée.

Si vous n’avez pas d’application existante, inscrivez une nouvelle application Microsoft Entra et un principal de service pouvant accéder aux ressources.
```
az ad app create --display-name myApp
```
Cette commande affiche une sortie JSON avec un appId qui est votre client-id. Le objectId est APPLICATION-OBJECT-ID et il sera utilisé pour créer des informations d’identification fédérées avec des appels d’API Graph. Enregistrez la valeur à utiliser comme secret GitHub AZURE_CLIENT_ID ultérieurement.
Créer un principal de service. Remplacez le $appID par l’appID de votre sortie JSON. Cette commande génère une sortie JSON avec un objectId différent qui sera utilisée à l’étape suivante. Le nouveau objectId est le assignee-object-id.

Cette commande génère une sortie JSON avec un objectId différent, qui sera utilisée à l’étape suivante. Le nouveau objectId est le assignee-object-id.

copiez le appOwnerTenantId à utiliser comme secret GitHub pour AZURE_TENANT_ID ultérieurement.
```
 az ad sp create --id $appId
```
Créez une attribution de rôle par abonnement et objet. Par défaut, l’attribution de rôle est liée à votre abonnement par défaut. Remplacez $subscriptionId par votre ID d’abonnement, $resourceGroupName par le nom de votre groupe de ressources et $assigneeObjectId par le assignee-object-id généré (l’identifiant de l’objet du principal de service nouvellement créé).
```
az role assignment create --role contributor --subscription $subscriptionId --assignee-object-id  $assigneeObjectId --assignee-principal-type ServicePrincipal --scope /subscriptions/$subscriptionId/resourceGroups/$resourceGroupName
```
Exécutez la commande suivante pour créer des informations d’identification d’identité fédérée pour votre application Microsoft Entra.
- Remplacez APPLICATION-OBJECT-ID par l’objectId (généré lors de la création de l’application) pour votre application Microsoft Entra.
- Définissez une valeur pour CREDENTIAL-NAME que vous référencerez ultérieurement.
- Définissez subject. Cette valeur est définie par GitHub en fonction de votre workflow :
  - Travaux dans votre environnement GitHub Actions : repo:< Organization/Repository >:environment:< Name >
  - Pour les tâches non liées à un environnement, incluez le chemin de référence (ref path) de la branche/étiquette en fonction du chemin de référence utilisé pour déclencher le workflow : repo:< Organization/Repository >:ref:< ref path>. Par exemple, repo:n-username/ node_express:ref:refs/heads/my-branch ou repo:n-username/ node_express:ref:refs/tags/my-tag.
  - Pour les workflows déclenchés par un événement de demande de tirage (pull request) : repo:< Organization/Repository >:pull_request.
```
az ad app federated-credential create --id <APPLICATION-OBJECT-ID> --parameters credential.json
("credential.json" contains the following content)
{
    "name": "<CREDENTIAL-NAME>",
    "issuer": "https://token.actions.githubusercontent.com",
    "subject": "repo:octo-org/octo-repo:environment:Production",
    "description": "Testing",
    "audiences": [
        "api://AzureADTokenExchange"
    ]
}
```

Dans GitHub, accédez à votre dépôt.
Sélectionnez Paramètres dans le volet de navigation.
Sélectionnez Sécurité > Secrets et variables > Actions.
Sélectionnez New repository secret (Nouveau secret de dépôt).
Collez l’intégralité de la sortie JSON de la commande Azure CLI dans le champ de valeur du secret. Nommez le secret AZURE_CREDENTIALS.
Sélectionnez Ajouter un secret.

Vous devez fournir l’ID de client, l’ID de locataire et l’ID d’abonnement de votre application à l’action de connexion. Vous pouvez fournir ces valeurs directement dans le workflow ou les stocker dans des secrets GitHub et les référencer dans votre workflow. L’enregistrement des valeurs en tant que secrets GitHub est l’option la plus sécurisée.

Dans GitHub, accédez à votre dépôt.
Sélectionnez Sécurité > Secrets et variables > Actions.
Sélectionnez New repository secret (Nouveau secret de dépôt).
Créez des secrets pour AZURE_CLIENT_ID, AZURE_TENANT_ID et AZURE_SUBSCRIPTION_ID. Utilisez ces valeurs à partir de votre application Microsoft Entra pour vos secrets GitHub :

Secret GitHub Application Microsoft Entra

AZURE_CLIENT_ID ID d’application (client)

AZURE_TENANT_ID ID de l’annuaire (locataire)

AZURE_SUBSCRIPTION_ID Identifiant d’abonnement
Enregistrez chaque secret en sélectionnant Ajouter un secret.

Secret GitHub	Application Microsoft Entra
AZURE_CLIENT_ID	ID d’application (client)
AZURE_TENANT_ID	ID de l’annuaire (locataire)
AZURE_SUBSCRIPTION_ID	Identifiant d’abonnement

Ajouter votre workflow

Principal du service
OpenID Connect

Accédez à Actions pour votre référentiel GitHub.
Sélectionnez Configurer vous-même un workflow.
Supprimez tous les éléments après la section on: de votre fichier de workflow. Par exemple, votre workflow restant peut ressembler à ce qui suit.
```
name: CI

on:
    push:
        branches: [ main ]
```
Renommez votre workflow Blob storage website CI et ajoutez les actions d’extraction et de connexion. Ces actions extraient votre code de site et vous authentifient auprès d’Azure à l’aide du secret GitHub AZURE_CREDENTIALS que vous avez créé précédemment.
```
name: Blob storage website CI

on:
    push:
        branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - uses: azure/login@v1
      with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}
```
Utilisez l’action Azure CLI pour charger votre code dans le stockage de blob et vider votre point de terminaison CDN. Pour az storage blob upload-batch, remplacez l’espace réservé par le nom de votre compte de stockage. Le script est chargé dans le conteneur $web. Pour az cdn endpoint purge, remplacez les espaces réservés par le nom de votre profil CDN, le nom de votre point de terminaison CDN et votre groupe de ressources. Pour accélérer le vidage de votre CDN, vous pouvez ajouter l’option --no-wait à az cdn endpoint purge . Pour améliorer la sécurité, vous pouvez également ajouter l’option --account-key avec votre clé de compte de stockage.
```
    - name: Upload to blob storage
      uses: azure/CLI@v1
      with:
        inlineScript: |
            az storage blob upload-batch --account-name <STORAGE_ACCOUNT_NAME>  --auth-mode key -d '$web' -s .
    - name: Purge CDN endpoint
      uses: azure/CLI@v1
      with:
        inlineScript: |
           az cdn endpoint purge --content-paths  "/*" --profile-name "CDN_PROFILE_NAME" --name "CDN_ENDPOINT" --resource-group "RESOURCE_GROUP"
```

Terminez votre workflow en ajoutant une action permettant de vous déconnecter d’Azure. Voici le workflow terminé. Le fichier apparaît dans le dossier .github/workflows de votre référentiel.

name: Blob storage website CI

on:
    push:
        branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - uses: azure/login@v1
      with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}

    - name: Upload to blob storage
      uses: azure/CLI@v1
      with:
        inlineScript: |
            az storage blob upload-batch --account-name <STORAGE_ACCOUNT_NAME> --auth-mode key -d '$web' -s .
    - name: Purge CDN endpoint
      uses: azure/CLI@v1
      with:
        inlineScript: |
           az cdn endpoint purge --content-paths  "/*" --profile-name "CDN_PROFILE_NAME" --name "CDN_ENDPOINT" --resource-group "RESOURCE_GROUP"

  # Azure logout
    - name: logout
      run: |
            az logout
      if: always()

Accédez à Actions pour votre référentiel GitHub.
Sélectionnez Configurer vous-même un workflow.
Supprimez tous les éléments après la section on: de votre fichier de workflow. Par exemple, votre workflow restant peut ressembler à ce qui suit.
```
name: CI with OpenID Connect

on:
    push:
        branches: [ main ]
```

Ajoutez une section Autorisations.

name: CI with OpenID Connect

on:
    push:
        branches: [ main ]

permissions:
      id-token: write
      contents: read

Ajoutez des actions de validation et de connexion. Ces actions extraient votre code de site et vous authentifient auprès d’Azure à l’aide des secrets GitHub que vous avez créés précédemment.

name: CI with OpenID Connect

on:
    push:
        branches: [ main ]

permissions:
      id-token: write
      contents: read

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - uses: azure/login@v1
      with:
      client-id: ${{ secrets.AZURE_CLIENT_ID }}
      tenant-id: ${{ secrets.AZURE_TENANT_ID }}
      subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

Utilisez l’action Azure CLI pour charger votre code dans le stockage de blob et vider votre point de terminaison CDN. Pour az storage blob upload-batch, remplacez l’espace réservé par le nom de votre compte de stockage. Le script est chargé dans le conteneur $web. Pour az cdn endpoint purge, remplacez les espaces réservés par le nom de votre profil CDN, le nom de votre point de terminaison CDN et votre groupe de ressources. Pour accélérer le vidage de votre CDN, vous pouvez ajouter l’option --no-wait à az cdn endpoint purge . Pour améliorer la sécurité, vous pouvez également ajouter l’option --account-key avec votre clé de compte de stockage.
```
    - name: Upload to blob storage
      uses: azure/CLI@v1
      with:
        inlineScript: |
            az storage blob upload-batch --account-name <STORAGE_ACCOUNT_NAME>  --auth-mode key -d '$web' -s .
    - name: Purge CDN endpoint
      uses: azure/CLI@v1
      with:
        inlineScript: |
           az cdn endpoint purge --content-paths  "/*" --profile-name "CDN_PROFILE_NAME" --name "CDN_ENDPOINT" --resource-group "RESOURCE_GROUP"
```

Terminez votre workflow en ajoutant une action permettant de vous déconnecter d’Azure. Voici le workflow terminé. Le fichier apparaît dans le dossier .github/workflows de votre référentiel.

name: CI with OpenID Connect

on:
    push:
        branches: [ main ]

permissions:
      id-token: write
      contents: read

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - uses: azure/login@v1
      with:
      client-id: ${{ secrets.AZURE_CLIENT_ID }}
      tenant-id: ${{ secrets.AZURE_TENANT_ID }}
      subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

    - name: Upload to blob storage
      uses: azure/CLI@v1
      with:
        inlineScript: |
            az storage blob upload-batch --account-name <STORAGE_ACCOUNT_NAME> --auth-mode key -d '$web' -s .
    - name: Purge CDN endpoint
      uses: azure/CLI@v1
      with:
        inlineScript: |
           az cdn endpoint purge --content-paths  "/*" --profile-name "CDN_PROFILE_NAME" --name "CDN_ENDPOINT" --resource-group "RESOURCE_GROUP"

  # Azure logout
    - name: logout
      run: |
            az logout
      if: always()

Vérifier votre déploiement

Accédez à Actions pour votre référentiel GitHub.
Ouvrez le premier résultat pour afficher les journaux détaillés de l’exécution de votre workflow.

Nettoyer les ressources

Lorsque votre site statique et votre référentiel GitHub ne sont plus nécessaires, nettoyez les ressources que vous avez déployées en supprimant le groupe de ressources et votre référentiel GitHub.

Étapes suivantes

En savoir plus sur Azure Static Web Apps

Partager via