Azure Pipelines を使用してリリース パイプラインを計画する
- 6 分
このセクションでは、Andy と Mara と共に、Azure Pipelines で実行される基本的な CD パイプラインを計画します。
完了したら、チームの他のメンバーにデモを行います。 パイプラインは POC として機能し、Tim と Amita からさらに学習し、フィードバックを受け取るにつれて、改善と拡張を行います。
基本的な CD パイプラインの部分は何ですか?
基本的な CD パイプラインには、プロセスを実行し、少なくとも 1 つのステージまたはデプロイ フェーズを取得するトリガーが含まれています。 ステージは ジョブで構成されます。 ジョブは、アプリケーションをビルド、テスト、またはデプロイする方法を定義する一連の手順です。
Andy: ビルド成果物は既にあります。 これは、既存のビルド パイプラインによって作成される .zip ファイルです。 しかし、
ライブ環境にデプロイするにはどうすればよいですか?
パイプラインステージとは何ですか?
ステージは、独立して実行でき、さまざまなメカニズムによってトリガーされるパイプラインの一部です。 メカニズムは、前のステージの成功、スケジュール、または手動トリガーである可能性があります。 これらのメカニズムの詳細については、次のモジュールで学習します。
マラ: アプリをビルドするステージと、テストを実行する別のステージを用意できます。
マラ: パイプラインのビルド ステージ のタスクは既に定義されています。 デプロイ ステージ
は、環境にビルドをデプロイするタスクを含め、同様の場合があります。
問題は、成果物をデプロイする必要がある場所です。
環境とは
環境 という用語 を使用して、アプリケーションまたはサービスが実行されている場所を参照している可能性があります。 たとえば、エンド ユーザーが アプリケーションにアクセス する運用環境が考えられます。
この例に従って、運用環境は次のようになります。
- 物理マシンまたは仮想マシン (VM)。
- Kubernetes などのコンテナー化された環境。
- Azure App Service などのマネージド サービス。
- Azure Functions などのサーバーレス環境。
成果物は環境にデプロイされます。 Azure Pipelines を使用すると、オンプレミスでもクラウドでも、ほぼすべての種類の環境に簡単にデプロイできます。
Azure Pipelines では、環境という用語には 2 つ目の意味があります。 ここでは、環境とは、Kubernetes クラスター、App Service インスタンス、仮想マシンなど、デプロイ環境を抽象的に表したものです。
Azure Pipelines 環境では、変更元を特定するのに役立つデプロイ履歴が記録されます。 Azure Pipelines 環境を使用すると、セキュリティ チェックと、パイプラインのあるステージから別のステージへの成果物の昇格方法を制御する方法を定義することもできます。 環境が含むものは、アーティファクトで実行したいことによって異なります。 アーティファクトをテストする環境は、エンド ユーザー用に成果物をデプロイする環境とは異なる方法で定義されている可能性があります。
Azure Pipelines 環境を定義する 1 つの方法は、YAML ファイルを使用することです。 YAML ファイルには、成果物をデプロイする Azure Pipelines 環境を指定する environment
セクションが含まれています。
リリース パイプラインを計画するときは、アプリケーションまたはサービスを実行する場所を決定する必要があります。 聞いて、アンディとマラが何を決めたかを見てみましょう。
アンディ: 大まかに言えば、どのような種類の環境が必要ですか? オンプレミスまたはクラウドにデプロイしますか?
マラ: ラボで VM を作成するように Tim に依頼できますが、常にハードウェアが不足しています。 クラウドを使用すれば、すぐに簡単に POC を設定できます。
アンディ: 賛成です;ただし、考慮すべきクラウド オプションは非常に多く、Azure Pipelines を使用して任意のクラウドにデプロイできます。 どれを試す必要がありますか?
マラ: ゲームを開発するチームは、Azure を使用してバックエンド システムの一部をホストします。 彼らはすぐにそれを設定し、それを好きのように見えます。 クラウド用に Azure を使用する必要があると思います。
アンディ: さて、それは理にかなっています! しかし、Azure には非常に多くのコンピューティング オプションが用意されています。 どれを選ぶべきですか?
Andy はホワイトボードに次のオプションを一覧表示します。
- 仮想マシン
- Containers
- Azure App Service
- サーバーレス コンピューティング
注
これらの各コンピューティング オプションの詳細については、このモジュールの最後に説明します。
マラ: 私はコンテナーとサーバーレスコンピューティングが今普及していることを知っている。 VM と比較すると、どちらもリソースの観点から見ると軽量です。 また、置き換えやスケールアウトも簡単です。どちらも面白いですが、2つの新しい技術を同時に学ぶことに緊張しています。 パイプラインの構築だけに集中したいと思います。
アンディ: 私はあなたと一緒です。 それにより、選択肢として残るのは VM または App Service です。 特定の環境へのフル アクセスを必要とする基幹業務アプリをクラウドに移行する場合、VM の方が適していると思います。 重要なことは何もしていません。
マラ: 残るはApp Serviceです。私ならそれを選びます。 Azure DevOps と連携するように設計されており、利点があります。 Webアプリ用のサービスとしてのプラットフォーム (PaaS) 環境であるため、私たちの負担を大幅に軽減します。 インフラストラクチャについて心配する必要はありません。 また、セキュリティ機能も備え、負荷分散と自動スケーリングを実行できます。
アンディ: App Service は、必要なもののように聞こえます。 App Service を使用しましょう。 とにかく概念実証だけを作成しています。 後で何かを試したい場合は、いつでもコンピューティング オプションを変更できます。
Azure Pipelines はデプロイ手順をどのように実行しますか?
アプリケーションをデプロイするには、まず Azure Pipelines がターゲット環境で認証を行う必要があります。 Azure Pipelines には、さまざまな認証メカニズムが用意されています。 使用するものは、デプロイ先のターゲット環境によって異なります。 これらのメカニズムの詳細については、このモジュールの最後に説明します。
Andy:ビルド成果物があり、パイプラインのステージでビルドとデプロイを行うことがわかっています。 デプロイのターゲット環境も定義しました。 それが App Service です。 私の質問は、Azure Pipelines が App Service でどのように認証されるかです。 私はこれが Tim の懸念事項の 1 つになることを知っています。 プロセスがセキュリティで保護されていることを確認する必要があります。
少し調査した後、Andy と Mara は、Azure Pipelines が App Service にデプロイできるようにする一般的な手順を思い付きます。
- パイプライン構成でターゲットデプロイ環境を指定します。
- Azure Pipelines がその環境へのアクセスを認証する方法を提供します。
- Azure Pipelines タスクを使用して、ビルド成果物をその環境にデプロイします。
マラ: 調査によると、ターゲット環境を指定し、それに対するアクセスを認証するための サービス接続 を作成する必要があります。 サービス接続を定義すると、すべてのタスクで使用できるようになります。 次に、組み込みのタスク DownloadPipelineArtifact@2 を使用して、ビルド成果物をパイプライン エージェントにダウンロードし、 アプリケーション を Azure App Service にデプロイAzureWebApp@1する必要があります。
ジョブと戦略とは何ですか?
既存のビルド パイプラインでは、ビルド エージェント、パイプライン変数、およびソフトウェアのビルドに必要なタスクを定義します。
パイプラインのデプロイ部分には、これらの同じ要素が含まれています。 通常、デプロイ構成では、1 つ以上のジョブ、パイプライン環境、および戦略も定義されます。 前にパイプライン環境について学習しました。
このモジュールの後半で実行する構成の例を次に示します。 この構成により、 Space Game Web サイトが Azure App Service にデプロイされます。
- stage: 'DeployDev'
displayName: 'Deploy to dev environment'
dependsOn: Build
jobs:
- deployment: Deploy
pool:
vmImage: 'ubuntu-20.04'
environment: dev
variables:
- group: 'Release Pipeline'
strategy:
runOnce:
deploy:
steps:
- download: current
artifact: drop
- task: AzureWebApp@1
displayName: 'Azure App Service Deploy: website'
inputs:
azureSubscription: 'Resource Manager - Tailspin - Space Game'
appName: '$(WebAppName)'
package: '$(Pipeline.Workspace)/drop/$(buildConfiguration)/*.zip'
仕事
ジョブとは、1 つの単位として順番に実行される一連のステップ (タスク) です。 各パイプライン ステージには、そのステージで job
キーワードが使用されていない場合でも、既定で 1 つのジョブがあります。
ジョブは、エージェント プール、コンテナー、または Azure DevOps サーバー上で直接実行できます。 ここで示すサンプル ジョブは、Microsoft がホストする Ubuntu エージェントで実行されます。
各ジョブを実行する条件を指定できます。 ここで示すジョブの例では、条件は定義されていません。 既定では、ジョブが他のジョブに依存していない場合、または依存しているすべてのジョブが正常に完了した場合に実行されます。
ジョブは、並列または順番に実行することもできます。 既存のビルド パイプラインを例として使用すると、並列ジョブを使用して、Windows、Linux、および macOS エージェントでソフトウェアを同時にビルドできます。
デプロイ ジョブは、展開ステージで重要な役割を果たす特殊な種類のジョブです。 デプロイ ジョブは、Azure Pipelines のデプロイの状態を記録し、監査証跡を提供します。 デプロイ ジョブは、デプロイ戦略を定義するのにも役立ちます。これについては、後で説明します。
戦略
戦略では、アプリケーションのロールアウト方法を定義します。今後のモジュールでは、ブルーグリーンやカナリアなどの戦略について詳しく学習します。 ここでは、 runOnce 戦略を使用して、パイプラインから Space Game パッケージをダウンロードし、それを Azure App Service にデプロイします。
Azure Pipelines は Azure にどのように接続しますか?
仮想マシンや App Service などの Azure リソースにアプリをデプロイするには、 サービス接続が必要です。 サービス接続は、次の 2 つの方法のいずれかを使用して、Azure サブスクリプションへの安全なアクセスを提供します。
- サービス プリンシパルの認証
- Azure リソースのマネージド ID
これらのセキュリティ モデルの詳細については、このモジュールの最後にありますが、簡単に説明します。
- サービス プリンシパルは、Azure リソースにアクセスできる制限付きロールを持つ ID です。 サービス プリンシパルは、ユーザーに代わって自動化されたタスクを実行できるサービス アカウントと考えてください。
- Azure リソースのマネージド ID は、サービス プリンシパルの操作プロセスを簡略化する Microsoft Entra ID の機能です。 マネージド ID は Microsoft Entra テナントに存在するため、Azure インフラストラクチャは自動的にサービスを認証し、アカウントを管理できます。
マネージド ID を使用すると、サービス プリンシパルを操作するプロセスが簡略化されます。ただし、このモジュールでは、サービス 接続によって Azure リソースが自動的に検出され、適切なサービス プリンシパル ロールが割り当てられるため、サービス プリンシパル認証を使用します。
計画
Andy と Mara は開始する準備ができています。 彼らは次のことをします:
- 既存の Azure Pipelines ビルド構成に基づいて構築します。
- 成果物を作成するビルド ステージを定義します。
- App Service に成果物をデプロイするデプロイ ステージを定義します。
アンディ: この図面は正しいですか? Azure Pipelines を使用して Azure App Service にデプロイします
。 これを行うには、ビルド成果物
をデプロイ ステージ
への入力として受け取ります。 デプロイ ステージのタスクは、成果物
をダウンロードし、サービス接続を使用して App Service
に成果物をデプロイします。
Mara:そういうことですね。 始めましょう。