アプリケーションと仮想マシンを構成する

  • 4 分

アプリなどの Azure ソリューション用カスタム コードをビルドするのが一般的です。 カスタム アプリには、人による操作なしで実行される Web サイト、API、バックグラウンド アプリが含まれる場合があります。 このユニットでは、アプリをそのインフラストラクチャと共にビルドしてデプロイするパイプラインを設計する方法を学習します。

アプリを構築する

多くの種類のアプリは、使用するためにはコンパイルまたはビルドする必要があります。 ビルド プロセスは、アプリのソース コードを受け取り、それに対して一連のアクティビティを実行してから、デプロイ可能ファイルのセットを作成します。

ビルド プロセスではソース コードがバイナリ ファイルまたは実行可能ファイルにコンパイルされますが、通常、これには以下に示すその他のアクティビティも含まれます。

  • Web サイトのユーザーに提供される画像ファイルの圧縮。
  • コードが適切なコーディング プラクティスに従っていることを確認するためのコードの "リンティング"。
  • アプリの個々のパーツの動作を検証する "単体テスト" の実行。

これらの手順に加え、ファイルの変更を防ぐためにファイルにデジタル署名するなどの手順も実行する必要があるかもしれません。

一連のステップが何であれ、ビルド プロセスの出力はデプロイ可能成果物です。 通常、成果物はパイプライン エージェントのファイル システムに保存されます。 パイプラインの後のステージでは、成果物を処理して環境全体にデプロイし、パイプライン定義で定義した品質ゲートを進んでいく過程でテストする必要があります。

Note

継続的インテグレーションと継続的デプロイや、CI と CD という用語をお聞きになったことがあるかもしれません。 ビルド プロセスは、パイプラインの継続的インテグレーション部分内に位置付けられます。

パイプライン成果物

パイプラインで生成された成果物は Git リポジトリに格納されません。 これらはソース コードから派生しますがコードそのものではないので、ソース管理リポジトリに属しません。 これらは、パイプライン エージェントのファイル システム上で作成されます。 パイプライン ジョブごとに新しいエージェントが作成されるため、ジョブとエージェントの間でファイルを共有する手段が必要になります。

パイプライン成果物はファイルを Azure Pipelines に格納できるようにするためのものであり、パイプラインの特定の実行に関連付けられます。 PublishBuildArtifacts 組み込みパイプライン タスクを使用して、エージェントのファイル システム上のファイルまたはフォルダーをパイプライン成果物として発行するよう Azure Pipelines に指示します。

- task: PublishBuildArtifacts@1
  displayName: Publish folder as a pipeline artifact
  inputs:
    artifactName: my-artifact-name
    pathToPublish: '$(Build.ArtifactStagingDirectory)/my-folder'

pathToPublish プロパティは、パイプライン エージェントのファイル システム上のコンパイル済みコードまたは出力ファイルがある場所です。 この場所にあるコンテンツは成果物として発行されます。 1 つのファイルまたはフォルダーを指定できます。

各成果物には名前があり、名前は artifactName タスク プロパティを使用して指定します。 成果物名は、後でパイプラインで参照するために使用します。 後続のパイプライン ジョブとステージで、成果物をダウンロードすることで、それを処理して、たとえば Web サイトをそれをホストするサーバーにデプロイできます。

Diagram that shows pipeline stages to build and deploy that refer to an artifact named Website.

デプロイ ジョブを使用すると、パイプライン成果物が既定で自動的にダウンロードされます。 通常のジョブを使用する場合は、DownloadBuildArtifacts タスクを使用してパイプライン成果物をダウンロードします。

- task: DownloadBuildArtifacts@0
  inputs:
    buildType: current
    downloadType: single
    artifactName: my-artifact-name
    downloadPath: '$(System.ArtifactsDirectory)'

アプリをデプロイする

アプリのビルド プロセスでは、デプロイ可能成果物が生成されて発行されます。 成果物はパイプラインの後のステージでデプロイされます。 アプリをデプロイする方法は、アプリをホストするために使用するサービスによって異なります。

Azure App Service にデプロイする

あなたの玩具会社は、Azure App Service を使用して自社の Web サイトをホストしているとします。 Bicep を使用して、App Service アプリを作成して構成できます。 しかし、アプリをデプロイする際は、コンパイル済みアプリをホスティング インフラストラクチャに配置するためのオプションがいくつかあります。 これらのオプションは、App Service データ プレーンの一部として管理されます。

最も一般的な方法は、AzureRmWebAppDeployment Azure Pipelines タスクを使用することです。

- task: AzureRmWebAppDeployment@4
  inputs:
    azureSubscription: MyServiceConnection
    ResourceGroupName: MyResourceGroup
    WebAppName: my-app-service
    Package: '$(Pipeline.Workspace)/my-artifact-name/website.zip'

アプリを App Service にデプロイするためには、いくつかの情報を提供する必要があります。 この情報には、App Service アプリのリソース グループ名とリソース名が含まれます。これらの名前は、ResourceGroupName 入力と WebAppName 入力を使用して指定します。 前のユニットで学習した通り、Bicep ファイルに出力を追加し、パイプライン変数を使用してパイプラインでアプリ名を伝達する必要があります。 また、Package 入力 (通常はパイプライン成果物へのパス) を使用して、デプロイするアプリで .zip ファイルを指定する必要があります。

App Service には、デプロイに使用する独自のデータ プレーン認証システムがあります。 AzureRmWebAppDeployment タスクは、認証プロセスを自動的に処理します。

Diagram that shows the credential exchange process.

AzureRmWebAppDeployment タスクは、サービス接続に関連付けられているサービス プリンシパルを使用して、デプロイに必要な資格情報を自動的に作成してダウンロードします。 その後、App Service データ プレーン API と通信するときに、デプロイ資格情報を使用します。

App Service には、デプロイ スロットを含め、デプロイ関連の機能もいくつか用意されています。 スロットは、新しいバージョンのアプリをダウンタイムなしで安全にデプロイするのに役立ちます。 また、それらを使用すれば、新しいバージョンのアプリケーションを準備してウォームアップしたうえで、そのアプリケーションに運用トラフィックを送ることも可能です。 このモジュールではスロットを使用しませんが、モジュールの最後にある [概要] ページに、スロットに関する詳細へのリンクがあります。

他の Azure サービスにアプリをデプロイする

Azure には、それぞれに独自のデプロイ方法があるアプリをホストするためのさまざまなオプションがほかにも用意されています。

Azure Functions は App Service 上に構築され、前に説明したのと同様のデプロイ プロセスを使用します。

仮想マシンにデプロイする場合は通常、仮想マシン インスタンスに接続してアプリをインストールする必要があります。 多くの場合、仮想マシンへのデプロイを調整するには、Chef、Puppet、Ansible などの特別なツールを使用する必要があります。

Kubernetes または Azure Kubernetes Service (AKS) を使用する場合は、ソリューションのビルドとデプロイに若干異なる方法を使用することになります。 アプリがビルドされると、パイプラインがコンテナー イメージを作成してコンテナー レジストリに発行し、ここから Kubernetes クラスターが読み取ります。 コンテナー レジストリがコンパイル済みアプリケーションを保持するので、一般にパイプライン成果物は使用しません。

このモジュールでは、Azure App Service に焦点を当てて、関連するパイプラインの概念を説明します。 モジュールの最後にある [概要] ページに、他のホスティング サービスへのデプロイに関する詳細情報へのリンクがあります。

パイプラインでアプリをテストする

前のモジュールでは、パイプラインから自動テストを実行することの価値と重要性について学習しました。 アプリをデプロイするときは、アプリのコードを呼び出すいくつかのテストをパイプラインで実行することをお勧めします。 このようなテストを行うと、アプリ エラーやデプロイ エラーのためにダウンタイムが発生するリスクが低くなります。 より高度なシナリオでは、API の呼び出しや代理トランザクションの送信と監視など、アプリに対して一連のテスト ケースを実行することもできます。

多くのアプリは、正常性チェック エンドポイントを実装します。 正常性チェック エンドポイントは、要求を受信すると、Web サイトに対して一連のチェックを実行します。たとえば、アプリ環境からデータベースとネットワーク サービスにアクセスできることを確認します。 サイトから返される応答は、アプリが正常であるかどうかを示します。 開発者は、アプリの要件に合わせて独自の正常性チェックを作成し、カスタマイズすることができます。 アプリに正常性チェック エンドポイントがあれば、多くの場合はそれをデプロイ ステージの完了後にパイプラインから監視するのが合理的です。

デプロイ パイプライン

次の演習では、以下のようにデプロイ パイプラインを更新して、Web サイトのアプリケーションをビルドして、それを各環境にデプロイするための新しいジョブを追加します。

Diagram that shows the revised pipeline, including a new build stage and an application deployment step.