Utiliser un workflow GitHub Actions pour déployer votre site web statique dans Stockage Azure
Article
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.
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
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.
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.
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
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"
]
}
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.
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.
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.
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.
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.
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.
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.