ワークフローを使用して Bicep ファイルをデプロイする
基本的なワークフローを作成できたので、Bicep ファイルをデプロイするようにワークフローを設定する準備ができました。 このユニットでは、ワークフローから Bicep コードをデプロイする方法と、デプロイ ステップを設定する方法について説明します。
注意
このユニットのコマンドは、概念を説明するために示されています。 コマンドはまだ実行しないでください。 ここで学習した内容をすぐに練習します。
コードをチェックアウトする
Bicep ファイルは Git リポジトリに格納されています。 GitHub Actions で、Git リポジトリからファイルをチェックアウトするようにワークフローに明示的に指示する必要があります。 そうしないと、ワークフローからファイルにアクセスできなくなります。 通常、このステップがジョブで最初に実行することになります。
コードをチェックアウトするには、actions/checkout@v3 アクションを使用できます。
name: MyWorkflow
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
with:
path: repo
ワークフローに uses キーワードが含まれていることに注目してください。 このキーワードは、actions/checkout という名前の事前定義されたアクションを使用することを示します。
Bicep リソースと同様に、アクションは常にバージョン管理されます。 この場合、ワークフローにはバージョン 3 が使用されるため、アクション名に @v3 が付加されます。
ワークフローにこのアクションが含まれると、リポジトリのコードがランナーのファイル システムにチェックアウトされます。 path パラメーターを使用して、ファイルが格納されるパスを指定します。
Azure に対して認証します
ご自身のコンピューターから Bicep ファイルをデプロイするときは、Azure CLI または Azure PowerShell を使用します。 コードをデプロイする前に、Azure にサインインする必要があります。 通常は、ツールによって、ブラウザーで資格情報を入力するように求められます。 資格情報の検証後、リソースをデプロイするためのアクセス許可が確認され、ツールを使用して Bicep ファイルをデプロイできるようになります。
ヒント
このモジュールでは、ワークフローで使用するワークロード ID を作成します。 「ワークロード ID を使用して Azure デプロイ ワークフローを認証する」モジュールには、ワークロード ID のさらに詳しい説明 (そのしくみや、それを作成し、ロールを割り当て、管理する方法など) があります。
ワークフローによるデプロイには、認証も必要です。 ワークフローはユーザーの操作なしで実行されるので、ワークフローによって "ワークロード ID" が使用され、Azure に対して認証されます。 GitHub と Microsoft Entra ID は連携して、資格情報を必要とせずにワークフローを安全に認証します。
ワークフローが Azure と通信する必要がある場合、ワークフロー ステップはワークロード ID を使用して Azure にサインインします。 次に、ワークフローに定義されているステップによって、ワークフローの ID が使用されます。
デプロイ ステップを実行するために必要なアクセス許可がワークロード ID に付与されているようにする必要があります。 たとえば、リソースをデプロイするリソース グループの共同作成者ロールをワークロード ID に割り当てる必要があるかもしれません。
警告
ユーザー資格情報を YAML ファイルに格納した後、az login コマンドを使用してサインインする方が簡単であるように思われるかもしれません。 この方法を使用してワークフローを認証することは避けてください。 YAML ファイル内の資格情報はクリア テキストで格納されます。 リポジトリにアクセスできるユーザーは、だれでもその資格情報を表示して使用することができます。 GitHub リポジトリへのアクセスを制限していても、誰かがリポジトリをクローンするたびに、資格情報を含む YAML ファイルがその人物のコンピューター上に作成されます。
Azure へのサインイン
ワークフローから Azure 環境に対してコマンドを実行できるようにするには、まずサインインする必要があります。 サインイン プロセスを処理する azure/login という名前のアクションがあります。 また、認証トークンを操作するためのアクセス許可をワークフローに付与する必要もあります。
name: MyWorkflow
on: [workflow_dispatch]
permissions:
id-token: write
contents: read
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
with:
path: repo
- uses: azure/login@v1
with:
client-id: ${{ secrets.AZURE_CLIENT_ID }}
tenant-id: ${{ secrets.AZURE_TENANT_ID }}
subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
azure/login アクションでは、ワークロード ID を使用するために、Microsoft Entra アプリケーション ID、Microsoft Entra テナント (ディレクトリ) ID、操作する Azure サブスクリプション ID の 3 つの情報を指定する必要があります。
このアクションが実行されると、ランナーが認証され、Azure 環境に対してステートメントを実行できるようになります。
Bicep ファイルをデプロイする
ワークフローは、Azure にサインインした後で、ワークロード ID を使用して Bicep デプロイを実行できます。 GitHub Actions で、azure/arm-deploy アクションを使用して Bicep のデプロイを開始します。
注意
GitHub Actions から Bicep ファイルをデプロイする方法は他にもあります。 たとえば、azure/CLI アクションを使用して、デプロイを実行する Azure CLI コマンドを指定することができます。 しかし、azure/arm-deploy タスクはデプロイに特化して設計されているので、このモジュールではそれを使用します。
azure/arm-deploy アクションを使用するようにステップを構成する例を次に示します。
name: MyWorkflow
on: [workflow_dispatch]
permissions:
id-token: write
contents: read
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
with:
path: repo
- uses: azure/login@v1
with:
client-id: ${{ secrets.AZURE_CLIENT_ID }}
tenant-id: ${{ secrets.AZURE_TENANT_ID }}
subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
- uses: azure/arm-deploy@v1
with:
resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
template: ./deploy/main.bicep
parameters: environmentType=Test
azure/arm-deploy アクションは、次のようないくつかのパラメーターを受け取ります。
resourceGroupName:Bicep ファイルで定義されているリソースをデプロイするリソース グループの名前です。template:リポジトリ内の Bicep ファイルのパスです。 パスはリポジトリのルートからの相対パスです。parameters:デプロイ時に指定するパラメーターの値を示します。 この例では、environmentType パラメーターの値を指定します。
前の azure/login アクションでワークフローは既に Azure にサインインしているため、azure/arm-deploy ステップは認証済みのランナー上で実行されます。
変数
多くの場合、ワークフローには、ワークフロー ファイルの複数の場所で再利用する値が含まれています。 また、これらの値をワークフロー ファイルの先頭に格納し、参照しやすくしたり、簡単に値を変更できるようにする場合もあります。 ワークフローでは、定義した変数は環境変数として表示されます。 再利用可能な値を定義するには、"変数" を使用します。
変数を作成する
変数は、ワークフロー ファイルのさまざまなレベルで作成できます。 ただし、ワークフロー ファイル全体で使用できるようにするには、ファイルの一番上、on ステートメントのすぐ下に定義します。 変数を定義するには、env パラメーターを使用します。
env:
AZURE_RESOURCEGROUP_NAME: gh-actions
AZURE_WEBAPP_NAME: webapp-gh-actions
前の例では、2 つの環境変数を指定しています。
ワークフローで変数を使用する
変数を作成したら、特別な構文を使用してワークフローの YAML ファイル内で次のように参照します。
${{ env.AZURE_RESOURCEGROUP_NAME }}
既定の環境変数
GitHub Actions には、"既定の環境変数" も使用されます。 既定の環境変数には、ワークフローで使用する定義済みの情報が含まれています。 ここでは、ワークフローに使用できる既定環境変数をいくつか紹介します。
github.sha: ワークフローの実行をトリガーした Git コミットの識別子。github.run_number: リポジトリに含まれる特定のワークフローの各実行に付けられる一意の番号。 この番号は、ワークフローの最初の実行時に 1 から始まり、新しい実行ごとに増加します。 この変数を使用して Azure デプロイに名前を付けることができます。これにより、トリガー元の特定のワークフロー実行までそのデプロイを追跡することができます。注意
GitHub Actions では、ワークフロー実行を再実行することができます。 この場合、実行番号は変わらないため、ワークフローが実行された回数をカウントするために
github.run_number変数を使用しないでください。
シークレット
場合によっては、データベース パスワードや API キーなど、ワークフローで使用するシークレット情報を格納する必要があります。 GitHub "シークレット" を使用して、資格情報または機密情報を含む情報を安全に格納します。 ワークフローはシークレットの値にアクセスできます。
シークレットは、GitHub リポジトリの設定で作成されます。 シークレットは、リポジトリ内のすべてのワークフローに使用できます。 後のモジュールでは、シークレットの使用を特定の環境へのデプロイに限定することができる "環境" について学習します。
警告
GitHub Actions の既定では、ワークフロー ログでシークレット変数の値が難読化されますが、適切なプラクティスにも従う必要があります。 ワークフロー ステップから、シークレット値にアクセスすることができます。 シークレットを安全に処理しないステップがワークフローに含まれている場合は、シークレット値がワークフロー ログに表示される可能性があります。 シークレットが誤って処理されないように、ワークフロー定義ファイルへの変更を常に慎重に確認する必要があります。
GitHub Web インターフェイスを使用してシークレットを作成できます。 ワークフローでシークレット値を参照するには、次の構文を使用します。
${{ secrets.NAME_OF_THE_SECRET }}
ワークフローの開始時には、デプロイ ステップを実行するランナーから暗号化が解除された GitHub シークレット値にアクセスできます。 GitHub Actions は、ワークフロー ログにシークレット値が表示されないように設計されています。
ヒント
Bicep のパラメーターと同じように、すべてに対して変数を作成する必要はありません。 環境によって変わる可能性があるものには変数を、秘密にしておきたいものには GitHub シークレットを作成することをお勧めします。 ワークフローには常に同じ Bicep ファイルが使用されるため、パスの変数を作成する必要はありません。
このモジュールでは、GitHub シークレットを使用して、azure/login タスクで Azure へのサインインに必要な情報 (Microsoft Entra サブスクリプションとテナント ID、ワークロード ID のアプリケーション登録 ID) を格納します。