エンドツーエンド デプロイについて

  • 5 分

GitHub Actions ワークフローは、ニーズに合わせてさまざまに構成できる柔軟なツールです。 このユニットでは、ワークフローを使用して Azure インフラストラクチャの構成を含めてソリューション全体をデプロイする方法と、他のデプロイ操作を実行する方法について説明します。

ワークフローの数をいくつにするか

組織によっては、Azure 環境を管理するチームと環境内で実行されるコードを開発するチームが異なる場合があります。 このような状況では、複数のワークフローを作成し、それぞれをその特定領域を担当するチームが所有したくなりがちです。 たとえば、Web サイトの Azure リソースをデプロイする Bicep コードをデプロイするための 1 つのワークフローを作成し、Web サイト アプリケーションをデプロイする別のワークフローを作成することが考えられます。

この方法の場合、ワークフローをある程度柔軟に管理できる可能性がありますが、すべてを同期させておくのは困難なことがあります。たとえば、Web サイト チームが、作成中の機能を有効にするための新しい設定を Azure App Service アプリに必要としているとします。 アプリケーション デプロイ ワークフローは、インフラストラクチャ デプロイ ワークフローが正常に完了するまで実行できません。 また、インフラストラクチャ ワークフローによって作成された Azure リソースの名前などのデータをワークフロー間で送信するのが複雑になる可能性があります。

そうではなく、さまざまなチームやさまざまな人がコンポーネントを管理しているとしても、ソリューションに必要なものすべてをデプロイする 1 つのワークフローを作成する方が良い場合が多々あります。 必要な作業は、Git や GitHub などのツールを使用して調整できます。 新しい機能を追加するときは、分岐を使用して、必要な変更を Bicep ファイルに加えます。 変更を統合してリリースする準備ができると、ソリューションのビルドとデプロイに必要なすべてのステップが 1 つのワークフローによって実行されるので、さまざまなものの同期が失われる可能性が低くなります。

ヒント

ソリューションのコードのビルド中は、その動作をテストするために頻繁にデプロイすることがおそらく必要になります。 アプリケーション コードと共にインフラストラクチャをデプロイすると、ワークフローの実行速度が低下し、進行が滞ることがあります。

このような状態になったら、開発環境ではインフラストラクチャ デプロイを無効にすることを検討してください。 これはパス フィルターや再利用可能なワークフロー、そして条件を使用することで実現できます。 ただし、その他の環境では、完全なデプロイ シーケンスをそのままにしておく必要があります。

コントロール プレーンとデータ プレーン

Azure リソースの多くは、アクセスのための 2 つの異なるプレーンを備えています。 コントロール プレーンは、リソースをデプロイして構成します。 データ プレーンを使用すると、リソースの機能にアクセスできます。

Bicep ファイルを作成してデプロイする場合は、コントロール プレーンと対話します。 Azure では、コントロール プレーンは Azure Resource Manager です。 Resource Manager を使用して、各リソースの構成を定義します。

ただし、多くの場合、ワークフローではコントロール プレーンとの対話以外のことも行う必要があります。 たとえば、次のことが必要になる場合があります。

  • BLOB をストレージ アカウントにアップロードします。
  • データベース スキーマを変更します。
  • サードパーティ サービスへの API 呼び出しを行います。
  • 機械学習モデルの更新をトリガーする。
  • Web サイトを Azure App Service アプリにデプロイします。
  • ソフトウェアを仮想マシンにデプロイします。
  • DNS エントリをサードパーティ プロバイダーに登録します。

エンドツーエンド ワークフローを検討する場合は通常、Azure リソースをデプロイしてから、それらのリソースのデータ プレーンに対して一連の操作を実行する必要があります。 これらの操作は、デプロイの "ラスト マイル" と呼ばれる場合があります。コントロール プレーンを使用してほとんどのデプロイを実行し、少量の構成しか残らないためです。

Note

コントロール プレーンとデータ プレーンが明確に区分されていないリソースもあります。 これには、Azure Data Factory と Azure API Management が含まれます。 どちらのサービスも Bicep を使用することによって完全自動デプロイをサポートしていますが、特別な考慮事項が必要です。 モジュールの最後にある [概要] ページに、詳細へのリンクがあります。

データ プレーン操作を実行する方法

リソースのデータ プレーンと対話するデプロイ ワークフローの作成時は、次に示す 3 つの一般的なアプローチをどれでも使用できます。

  • Resource Manager デプロイメント スクリプト
  • ワークフロー スクリプト
  • ワークフロー アクション

"Resource Manager デプロイ スクリプト" は、Bicep ファイル内で定義されます。 このデプロイ スクリプトでは Bash スクリプトまたは PowerShell スクリプトを実行し、Azure CLI コマンドと Azure PowerShell コマンドレットと対話できます。 Azure に対する認証に使用するデプロイ スクリプトのマネージド ID を作成すると、デプロイ スクリプトを実行するために必要なその他のリソースが Azure によって自動的にプロビジョニングされて管理されます。

デプロイ スクリプトは、デプロイ プロセス内で基本的なスクリプトを実行する必要がある場合に適していますが、ワークフローから他の要素に簡単にアクセスできるようにはなりません。

デプロイ ワークフロー内から独自のロジックを実行することもできます。 GitHub Actions は、実行する必要のある一般的なことのための "アクション" の豊富なエコシステムを提供します。 ニーズを満たすアクションが見つからない場合は、"スクリプト" を使用して独自の Bash コードまたは PowerShell コードを実行できます。 ワークフロー アクションとワークフロー スクリプトは、ワークフローのランナーから実行されます。 多くの場合、使用しているサービスのデータ プレーンに対してアクションまたはスクリプトを認証する必要があります。その方法はサービスによって異なります。

ワークフロー アクションとワークフロー スクリプトを使用すると、柔軟性と制御が可能になります。 これらを使用すると、"ワークフロー成果物" (もう少し後で説明) にアクセスすることもできます。 このモジュールでは、ワークフロー アクションについて重点的に取り上げます。 モジュールの最後にある [概要] ページに、Resource Manager デプロイ スクリプトの詳細へのリンクがあります。

出力

ワークフローは通常、Bicep ファイルをデプロイすることによって Azure リソースを作成、構成します。 ワークフローの後続の部分は、それらのリソースのデータ プレーンと対話します。 リソースと対話できるようになるために、ワークフロー アクションとワークフロー ステップは、作成された Azure リソースに関する情報を必要とします。

たとえば、ストレージ アカウントをデプロイする Bicep ファイルがあるとします。 ワークフローでストレージ アカウントをデプロイし、次にストレージ アカウント内の BLOB コンテナーにいくつかの BLOB をアップロードする必要があります。 BLOB をアップロードするワークフロー タスクでは、接続先のストレージ アカウントの名前と、ファイルのアップロード先の BLOB コンテナーの名前を知る必要があります。

Bicep ファイルで Azure リソースの名前を決定するようにすることをお勧めします。 パラメーター、変数、または式を使用して、ストレージ アカウントと BLOB コンテナーの名前を作成できます。 その後 Bicep ファイルは、各リソースの名前を提供する出力を公開できます。 ワークフローのその後のステップでは、出力の値を読み取ることができます。 そうすることで、環境間で変わる可能性がある名前などの情報をワークフロー定義でハードコードしたり、Bicep ファイルで定義されているルールにパイプライン定義が基づいたりする必要がありません。

GitHub Actions では、"ワークフロー変数" を使用して出力の値を伝達できます。 azure/arm-deploy アクションでは、Bicep デプロイ出力ごとの変数が自動的に作成されます。 スクリプトから手動でワークフロー変数を作成することもできます。 モジュールの最後にある [概要] ページに、詳細へのリンクがあります。

別のジョブで作成された変数にアクセスするときは、その変数を公開して、それを読み取るジョブからアクセスできるようにする必要があります。 たとえば、Bicep ファイルをデプロイするジョブを作成し、その appServiceAppName 出力をワークフローに伝達する必要があるとします。 appServiceAppName ワークフロー変数を、deploy ステップによって作成された appServiceAppName 出力変数の値に設定する必要がある場合、outputs キーワードを使用してその旨を指定します。

job1:
  runs-on: ubuntu-latest
  outputs:
    appServiceAppName: ${{ steps.deploy.outputs.appServiceAppName }}
  steps:
  - uses: actions/checkout@v3
  - uses: azure/login@v1
    name: Sign in to Azure
    with:
      client-id: ${{ secrets.AZURE_CLIENT_ID }}
      tenant-id: ${{ secrets.AZURE_TENANT_ID }}
      subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
  - uses: azure/arm-deploy@v1
    id: deploy
    name: Deploy Bicep file
    with:
      failOnStdErr: false
      deploymentName: ${{ github.run_number }}
      resourceGroupName: Playground1
      template: ./deploy/main.bicep

その後、後続のジョブで needs キーワードを追加し、変数の作成元となったジョブへの依存関係を明示的に作成したら、公開された変数の名前を使用してそれを参照します。

job2:
  needs: job1
  runs-on: ubuntu-latest
  steps:
  - run: |
      echo "${{needs.job1.outputs.appServiceAppName}}"

Bicep 出力とワークフロー変数を使用すると、Bicep コードをデプロイした後にデプロイの一環としてリソースに対してさまざまなアクションを実行するワークフローを作成できます。