クイックスタート: GitHub Actions を使用した Bicep ファイルのデプロイ

[アーティクル]
09/26/2024

GitHub Actions は、ソフトウェア開発ワークフローを自動化する一連の GitHub 機能です。このクイックスタートでは、Azure Resource Manager のデプロイに GitHub Actions を使って、Bicep ファイルの Azure へのデプロイを自動化します。

GitHub Actions と Bicep ファイルの概要を簡単に示します。 GitHub Actions とプロジェクトの設定に関する詳細なステップが必要な場合は、「 Bicep と GitHub Actions を使用して Azure リソースをデプロイする」を参照してください。

前提条件

アクティブなサブスクリプションが含まれる Azure アカウント。無料でアカウントを作成できます。
GitHub アカウント。お持ちでない場合は、無料でサインアップしてください。
Bicep ファイルとワークフローファイルを保存するための GitHub リポジトリ。リポジトリを作成するには、新しいリポジトリの作成に関するページをご覧ください。

リソースグループの作成

リソースグループを作成する。このクイックスタートの後半では、Bicep ファイルをこのリソースグループにデプロイします。

CLI
PowerShell

az group create -n exampleRG -l westus

New-AzResourceGroup -Name exampleRG -Location westus

GitHub Actions は ID の下で実行されます。サービスプリンシパルを作成するには、az ad sp create-for-rbac コマンドを使用して、ID のサービスプリンシパルを作成します。前のセッションで作成したリソースグループの共同作成者ロールをサービスプリンシパルに付与し、その ID を持つ GitHub アクションがこのリソースグループにリソースを作成できるようにします。必要な最小限のアクセス権を付与することをお勧めします。

az ad sp create-for-rbac --name {app-name} --role contributor --scopes /subscriptions/{subscription-id}/resourceGroups/exampleRG --json-auth

{app-name} のプレースホルダーはアプリケーションの名前に置き換えます。 {subscription-id} は、サブスクリプション ID で置き換えてください。

出力は、次の出力のような、App Service アプリへのアクセスを提供するロールの割り当て資格情報を含む JSON オブジェクトとなります。

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

この JSON オブジェクトを後のためにコピーします。必要なのは、clientId、clientSecret、subscriptionId、tenantId の値を持つセクションだけです。最後の行の末尾に余分なコンマがないことを確認します (たとえば、前の例の tenantId 行)。そうでない場合は、無効な JSON ファイルになります。デプロイ中に、"ログインに失敗しました: コンテンツは有効な JSON オブジェクトではありません。 'auth-type' が正しいかどうかを再確認してください。"というエラーが発生します。

Open ID Connect は、有効期間の短いトークンを使用する認証方法です。 GitHub Actions を使用して OpenID Connect を設定すると、セキュリティが強化されたより複雑なプロセスになります。

既存のアプリケーションがない場合は、リソースにアクセスできる新しい Active Directory アプリケーションとサービスプリンシパルを登録します。 Active Directory アプリケーションを作成します。
```
az ad app create --display-name myApp
```
このコマンドは、appId が自分の client-id である JSON を出力します。後で AZURE_CLIENT_ID の GitHub シークレットとして使用する値を保存します。

この objectId 値は、Graph API でフェデレーション資格情報を作成するときに使用し、APPLICATION-OBJECT-ID として参照します。
サービスプリンシパルを作成する。 $appID を、JSON 出力のアプリ ID に置き換えてください。

このコマンドにより、異なる objectId を持つ JSON 出力が生成され、次のステップで使用されます。新しい objectId は assignee-object-id です。

後で AZURE_TENANT_ID の GitHub シークレットとして使用するために、appOwnerTenantId をコピーします。
```
 az ad sp create --id $appId
```
サブスクリプションとオブジェクト別に新しいロールの割り当てを作成します。既定では、このロールの割り当ては既定のサブスクリプションに紐づけられます。 $subscriptionId をサブスクリプション ID に、$resourceGroupName をリソースグループ名に、$assigneeObjectId を生成された assignee-object-id に置き換えます。 Azure CLI を使用して Azure サブスクリプションを管理する方法について説明します。
```
az role assignment create --role contributor --subscription $subscriptionId --assignee-object-id  $assigneeObjectId --assignee-principal-type ServicePrincipal --scopes /subscriptions/$subscriptionId/resourceGroups/$resourceGroupName/providers/Microsoft.Web/sites/
```
次のコマンドを実行して、Active Directory アプリケーションの新しいフェデレーション ID 資格情報を作成します。
- APPLICATION-OBJECT-ID を Active Directory アプリケーションの objectId (アプリ作成時に生成) に置き換えてください。
- 後で参照するには、CREDENTIAL-NAME の値を設定します。
- subject を設定します。この値は、ワークフローに応じて、GitHub によって定義されます。
  - GitHub Actions 環境のジョブ: repo:< Organization/Repository >:environment:< Name >
  - 環境に関連付けられていないジョブの場合は、ワークフローのトリガーに使用される ref パスに基づいて、ブランチ/タグの ref パスを含めます: repo:< Organization/Repository >:ref:< ref path>。たとえば、repo:n-username/ node_express:ref:refs/heads/my-branch または repo:n-username/ node_express:ref:refs/tags/my-tag です。
  - プル要求イベントによってトリガーされるワークフローの場合: repo:< Organization/Repository >:pull_request。
```
az rest --method POST --uri 'https://graph.microsoft.com/beta/applications/<APPLICATION-OBJECT-ID>/federatedIdentityCredentials' --body '{"name":"<CREDENTIAL-NAME>","issuer":"https://token.actions.githubusercontent.com","subject":"repo:organization/repository:ref:refs/heads/main","description":"Testing","audiences":["api://AzureADTokenExchange"]}'
```
Active Directory 作成アプリケーション、サービスプリンシパル、およびフェデレーション資格情報を Azure portal で作成する方法については、「Connect GitHub および Azure」を参照してください。

GitHub シークレットを構成する

サービスプリンシパル
Open ID Connect

Azure の資格情報、リソースグループ、およびサブスクリプションのシークレットを作成します。これらのシークレットは、「ワークフローの作成」セクションで使用します。

GitHub で、自分のリポジトリに移動します。
[設定] > [シークレットと変数] > [アクション] > [新しいリポジトリシークレット] の順に選択します。
Azure CLI コマンドからの JSON 出力全体をシークレットの値フィールドに貼り付けます。シークレットに AZURE_CREDENTIALS という名前を付けます。
AZURE_RG という名前の別のシークレットを作成します。リソースグループの名前をシークレットの値フィールドに追加します (exampleRG)。
AZURE_SUBSCRIPTION という名前の別のシークレットを作成します。シークレットの値フィールドにサブスクリプション ID を追加します (例: aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e)。

ログインアクションには、アプリケーションのクライアント ID、テナント ID、サブスクリプション IDを指定する必要があります。これらの値は、ワークフロー内で直接指定するか、GitHub シークレットに格納してワークフローで参照できます。 GitHub シークレットとして値を保存する方がより安全なオプションです。

GitHub リポジトリを開き、 [Settings](設定) に移動します。
[Settings](設定) > [Secrets](シークレット) > [New secret](新しいシークレット) の順に選択します。

AZURE_CLIENT_ID、AZURE_TENANT_ID、AZURE_SUBSCRIPTION_ID のシークレットを作成します。 GitHub シークレットには、Active Directory アプリケーションの次の値を使用します。

GitHub シークレット	Active Directory アプリケーション
AZURE_CLIENT_ID	アプリケーション (クライアント) ID
AZURE_TENANT_ID	ディレクトリ (テナント) ID
AZURE_SUBSCRIPTION_ID	サブスクリプション ID

[Add secret](シークレットの追加) を選択して各シークレットを保存します。

Bicep ファイルを追加する

GitHub リポジトリに Bicep ファイルを追加します。次の Bicep ファイルでは、ストレージアカウントが作成されます。

@minLength(3)
@maxLength(11)
param storagePrefix string

@allowed([
  'Standard_LRS'
  'Standard_GRS'
  'Standard_RAGRS'
  'Standard_ZRS'
  'Premium_LRS'
  'Premium_ZRS'
  'Standard_GZRS'
  'Standard_RAGZRS'
])
param storageSKU string = 'Standard_LRS'

param location string = resourceGroup().location

var uniqueStorageName = '${storagePrefix}${uniqueString(resourceGroup().id)}'

resource stg 'Microsoft.Storage/storageAccounts@2023-04-01' = {
  name: uniqueStorageName
  location: location
  sku: {
    name: storageSKU
  }
  kind: 'StorageV2'
  properties: {
    supportsHttpsTrafficOnly: true
  }
}

output storageEndpoint object = stg.properties.primaryEndpoints

Bicep ファイルでは storagePrefix と呼ばれる 1 つのパラメーターが 3 文字から 11 文字で必要です。

ファイルは、リポジトリ内のどこに置いてもかまいません。次のセクションのワークフローサンプルでは、Bicep ファイル名が main.bicep であり、リポジトリのルートに保存されていることを想定しています。

ワークフローを作成する

ワークフローでは、トリガーされた場合に実行するステップを定義します。これは、お使いのリポジトリの /.github/workflows/ パスの YAML (.yml) ファイルです。ワークフローファイルの拡張子には、 .yml または .yaml を指定できます。

ワークフローを作成するには、次の手順を実行します。

GitHub リポジトリの上部のメニューで、 [Actions](アクション) を選択します。
[New workflow](新しいワークフロー) を選択します。
[Set up a workflow yourself](ワークフローを自分でセットアップする) を選択します。
main.yml 以外の別の名前を使用する場合は、ワークフローファイルの名前を変更します。例: deployBicepFile.yml。

.yml ファイルの内容を次のコードに置き換えます。

サービスプリンシパル
OpenID Connect

name: Deploy Bicep file
on: [push]
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:

    - name: Checkout code
      uses: actions/checkout@main

    - name: Log into Azure
      uses: azure/login@v1
      with:
        creds: ${{ secrets.AZURE_CREDENTIALS }}

    - name: Deploy Bicep file
      uses: azure/arm-deploy@v1
      with:
        subscriptionId: ${{ secrets.AZURE_SUBSCRIPTION }}
        resourceGroupName: ${{ secrets.AZURE_RG }}
        template: ./main.bicep
        parameters: 'storagePrefix=mystore storageSKU=Standard_LRS'
        failOnStdErr: false

mystore を独自のストレージアカウント名プレフィックスに置き換えます。

注意

代わりに、ARM デプロイアクション (例: .azuredeploy.parameters.json) に JSON 形式のパラメーターファイルを指定できます。

ワークフローファイルの最初のセクションには次のものが含まれます。

name:ワークフローの名前。
on: ワークフローをトリガーする GitHub イベントの名前。ワークフローは、メインブランチにプッシュイベントがある場合にトリガーされます。

on: [push]
name: Azure ARM
permissions:
  id-token: write
  contents: read
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:

      # Checkout code
    - uses: actions/checkout@main

      # Log into Azure
    - uses: azure/login@v1
      with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

      # Deploy Bicep file
    - name: deploy
      uses: azure/arm-deploy@v1
      with:
        subscriptionId: ${{ secrets.AZURE_SUBSCRIPTION }}
        resourceGroupName: ${{ secrets.AZURE_RG }}
        template: ./main.bicep
        parameters: 'storagePrefix=mystore storageSKU=Standard_LRS'
        failOnStdErr: false

[変更点のコミット] を選択します。
[Commit directly to the main branch](メインブランチに直接コミットする) を選択します。
[Commit new file](新しいファイルをコミットする) (または [Commit changes](変更をコミットする) ) を選択します。

ワークフローファイルまたは Bicep ファイルのいずれかを更新すると、ワークフローがトリガーされます。変更をコミットすると、ワークフローがすぐに開始されます。

ワークフローの状態を確認する

[Actions]$アクション$ タブを選択します。Create deployBicepFile.yml ワークフローが一覧表示されます。ワークフローの実行には 1 から 2 分かかります。
ワークフローを選択して開き、Status が Success であることを確認します。

リソースをクリーンアップする

リソースグループとリポジトリが不要になったら、リソースグループと GitHub リポジトリを削除して、デプロイしたリソースをクリーンアップします。

CLI
PowerShell

az group delete --name exampleRG

Remove-AzResourceGroup -Name exampleRG

次のステップ

Bicep ファイルの構造と構文

次の方法で共有

クイックスタート: GitHub Actions を使用した Bicep ファイルのデプロイ

前提条件

リソースグループの作成

デプロイ資格情報を生成する

GitHub シークレットを構成する

Bicep ファイルを追加する

ワークフローを作成する

ワークフローの状態を確認する

リソースをクリーンアップする

次のステップ

フィードバック

その他のリソース

次の方法で共有

クイックスタート: GitHub Actions を使用した Bicep ファイルのデプロイ

前提条件

リソース グループの作成

デプロイ資格情報を生成する

GitHub シークレットを構成する

Bicep ファイルを追加する

ワークフローを作成する

ワークフローの状態を確認する

リソースをクリーンアップする

次のステップ

フィードバック

その他のリソース

リソースグループの作成