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

  • 5 分

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

パイプラインの数

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

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

そうではなく、さまざまな人やさまざまなチームがコンポーネントを管理しているとしても、ソリューションに必要なものすべてをデプロイする 1 つのパイプラインを作成する方が良い場合が多々あります。 Git や Azure DevOps などのツールを使用して、作業を調整できます。 新しい機能を追加するときは、分岐を使用して、必要な変更を Bicep ファイルに加えます。 また、変更を統合してリリースする準備ができると、ソリューションのビルドとデプロイに必要なすべてのステップが 1 つのパイプラインによって実行されます。 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 によって自動的にプロビジョニングされて管理されます。

デプロイ プロセス内で基本的なスクリプトを実行する必要がある場合は、デプロイ スクリプトが適しています。 ただし、パイプラインから他の要素に簡単にアクセスできるわけではありません。

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

パイプライン タスクとパイプライン スクリプトを使用すると、柔軟性と制御が可能になります。 これらを使用すると、後に学習する "パイプライン成果物" にアクセスすることもできます。 このモジュールでは、パイプライン スクリプトとパイプライン タスクに重点を置いて説明します。 モジュールの最後にある [概要] ページに、Resource Manager デプロイ スクリプトの詳細へのリンクがあります。

出力

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

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

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

Azure Pipelines では、パイプライン変数を使用して出力の値を伝達できます。 パイプライン スクリプト内でパイプライン変数の値を設定できます。 ここに示すように、どう解釈すべきかを Azure Pipelines が理解できる特殊な形式のログ出力を使用します。

stages:
- stage: Stage1
  jobs:
  - job: Job1
    steps:
      # Set the variable's value.
      - script: |
          echo "##vso[task.setvariable variable=myVariableName;isOutput=true]VariableValue"
        name: Step1

      # Read the variable's value.
      - script:
          echo $(myVariableName)

あるジョブで変数を作成し、同じステージの別のジョブでその変数にアクセスしたい場合は、それを "マップ" する必要があります。

stages:
- stage: Stage2
  jobs:
  - job: Job2
    steps:
      # Set the variable's value.
      - script: |
          echo "##vso[task.setvariable variable=myVariableName;isOutput=true]VariableValue"
        name: Step1

  - job: Job3
    dependsOn: Job2
    variables: # Map the variable to this job.
      myVariableName: $[ dependencies.Job2.outputs['Step1.myVariableName'] ]
    steps:
      # Read the variable's value.
      - script: |
          echo $(myVariableName)

パイプライン ステージをまたいで変数にアクセスするには、以下のように、変数を "マップ" するだけでなく、別の構文を使用する必要があります。

stages:
- stage: Stage2
  jobs:
  - job: Job2
    steps:
      # Set the variable's value.
      - script: |
          echo "##vso[task.setvariable variable=myVariableName;isOutput=true]VariableValue"
        name: Step1

  - job: Job3
    dependsOn: Job2
    variables: # Map the variable to this job.
      myVariableName: $[ dependencies.Job2.outputs['Step1.myVariableName'] ]
    steps:
      # Read the variable's value.
      - script: |
          echo $(myVariableName)

- stage: Stage3
  dependsOn: Stage2
  jobs:
  - job: Job4
    variables: # Map the variable to this stage.
      myVariableName: $[ stageDependencies.Stage2.Job2.outputs['Step1.myVariableName'] ]
    steps:
      # Read the variable's value.
    - script: |
        echo $(myVariableName)

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