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

  • 5 分

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

パイプラインの数

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

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

代わりに、多くの場合、異なるユーザーまたは異なるチームがコンポーネントを管理する場合でも、ソリューションに必要なすべてのものをデプロイする単一のパイプラインを作成することをお勧めします。 Git や Azure DevOps などのツールを使用して、作業を調整できます。 新しい機能を追加するときは、分岐を使用して、必要な変更を Bicep ファイルに加えます。 また、変更を統合してリリースする準備ができたら、ソリューションのビルドとデプロイに必要なすべての手順が 1 つのパイプラインによって実行されます。 1 つのパイプラインを使用すると、同期から抜け出す可能性が低くなります。

ヒント

ソリューションのコードをビルドする場合は、そのしくみをテストできるように、頻繁にデプロイする必要があります。 アプリケーション コードと共にインフラストラクチャをデプロイすると、パイプラインの実行速度が遅くなり、進行状況が阻害される場合があります。

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

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

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

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

ただし、パイプラインでは、多くの場合、単にコントロール プレーンとやり取りする以上のことを行う必要があります。 たとえば、他のタスクを実行する必要がある場合があります。

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

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

注

コントロール プレーンとデータ プレーンが明確に区分されていないリソースもあります。 これには、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 コードをデプロイし、デプロイの一部としてリソースに対してさまざまなアクションを実行するマルチステージ パイプラインを作成できます。