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

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

アプリをビルドする

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

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

• Web サイトのユーザーに提供されるイメージ ファイルを圧縮する。
• コードをリンティングして、適切なコーディングプラクティスに従っていることを確認します。
• アプリの個々の部分の動作を検証する 単体テスト を実行する。

これらの手順に加えて、ファイルのデジタル署名などの手順を実行して、ファイルを変更できないようにすることもできます。

一連の手順に関係なく、ビルド プロセスの出力はデプロイ可能な 成果物です。 通常、成果物はパイプライン エージェントのファイル システムに保存されます。 パイプラインの後のステージでは、成果物を使用して環境を通じてデプロイし、パイプライン定義で定義した品質ゲートを通じてそれをテストする必要があります。

パイプライン成果物

パイプラインで生成された成果物は、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 サイトをデプロイするなどして操作できるようにします。

デプロイ ジョブを使用すると、パイプライン成果物は既定で自動的にダウンロードされます。 通常のジョブを使用する場合は、 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 タスクは、認証プロセスを自動的に処理します。

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 サイトのアプリケーションをビルドして各環境にデプロイする新しいジョブを追加します。