アプリケーションと仮想マシンを構成する
アプリなどの Azure ソリューション用カスタム コードをビルドするのが一般的です。 カスタム アプリには、人による操作なしで実行される Web サイト、API、バックグラウンド アプリが含まれる場合があります。 このユニットでは、アプリをそのインフラストラクチャと共にビルドしてデプロイするワークフローを設計する方法について説明します。
アプリを構築する
多くの種類のアプリは、"コンパイル" または "ビルド" しないと使用できません。 ビルド プロセスは、アプリのソース コードを受け取り、それに対して一連のアクティビティを実行してから、デプロイ可能ファイルのセットを作成します。
ビルド プロセスでは、ソース コードがバイナリ ファイルまたは実行可能ファイルにコンパイルされます。 通常、ビルド プロセスには他のアクティビティが含まれます。これには、Web サイトのユーザーに提供される画像ファイルの圧縮、適切なコーディング プラクティスに従っていることを検証するためのコードの ''リント''、アプリの個々の部分の動作を検証する ''単体テスト'' の実行などが含まれます。 ファイルを変更できないようにするためにファイルにデジタル署名するなどのステップを実行する場合もあります。
一連のステップが何であれ、ビルド プロセスの出力はデプロイ可能成果物です。 通常、成果物はワークフロー ランナーのファイル システムに保存されます。 以降のワークフロー部分では、成果物を処理して環境全体にデプロイし、ワークフロー定義で定義した品質ゲートを進んでいく過程でテストする必要があります。
Note
"継続的インテグレーション" と "継続的デプロイ" や、CI/CD という用語をお聞きになったことがあるかもしれません。 ビルド プロセスは、ワークフローの継続的インテグレーション部分内に位置付けられます。
ワークフロー成果物
ワークフローで生成された成果物は Git リポジトリに格納されません。 これらはソース コードから派生しますがコードそのものではないので、ソース管理リポジトリに属しません。 ワークフロー ランナーのファイル システム上に作成されます。 ランナーはワークフロー ジョブごとに新しく作成されるので、ジョブとランナーとの間でファイルを共有する手段が必要となります。
"ワークフロー成果物" はファイルを GitHub Actions に格納できるようにするためのものであり、ワークフローの特定の実行に関連付けられます。 ランナーのファイル システムからファイルやフォルダーをワークフロー成果物としてアップロードするよう GitHub Actions に命令するには、actions/upload-artifact ワークフロー アクションを使用します。
- name: Upload folder as a workflow artifact
uses: actions/upload-artifact@v3
with:
name: my-artifact-name
path: ./my-folder
path プロパティは、ジョブ ランナーのファイル システム上のコンパイル済みコードまたは出力ファイルがある場所です。 この場所にある内容が成果物にアップロードされます。 1 つのファイル、複数のファイル、またはフォルダーを指定できます。
各成果物には名前があり、名前は name プロパティを使用して指定します。 成果物名は、後でワークフローで参照するために使用します。 後続のワークフロー ジョブで成果物をダウンロードできます。たとえば、Web サイトをホスト先のサーバーにデプロイするためにそれを使用できます。
すべてのワークフロー成果物をダウンロードするには、actions/download-artifact アクションを使用します。
- uses: actions/download-artifact@v3
または、特定の成果物だけをダウンロードするには、アーティファクトの名前を指定します。
- uses: actions/download-artifact@v3
with:
name: my-artifact-name
アプリをデプロイする
アプリのビルド プロセスでは、デプロイ可能成果物が生成されてアップロードされます。 ワークフロー内の後続のジョブでその成果物をデプロイします。 アプリをデプロイする方法は、アプリをホストするために使用するサービスによって異なります。
Azure App Service にデプロイする
あなたの玩具会社は、Azure App Service を使用して自社の Web サイトをホストしているとします。 Bicep を使用して App Service アプリを作成して構成できますが、アプリをデプロイする際は、コンパイル済みアプリをホスティング インフラストラクチャに乗せるためのオプションがいくつかあります。 これらのオプションは、App Service データ プレーンの一部として管理されます。
最も一般的な方法は、azure/webapps-deploy アクションを使用することです。
- uses: azure/webapps-deploy@v2
with:
app-name: my-app-service
package: my-artifact-name/website.zip
アプリを App Service にデプロイするためには、いくつかの情報を提供する必要があります。 この情報には、App Service アプリのリソース名が含まれます。その名前は、app-name プロパティを使用して指定します。 前のユニットで学習した通り、Bicep ファイルに出力を追加し、ワークフロー変数を使用してワークフローでアプリ名を伝達する必要があります。 また、package プロパティを使用して、デプロイするアプリを含む .zip ファイルを指定する必要もあります。 これは通常、ワークフロー成果物ヘのパスです。
App Service には、デプロイに使用する独自のデータ プレーン認証システムがあります。 認証プロセスは、azure/webapps-deploy アクションによって自動的に処理されます。
azure/webapps-deploy アクションには、ジョブのアクティブ Azure セッション、つまりユーザーがワークロード ID 
を使用してサインインした Azure セッションに関連付けられている ID が使用されます。 このアクションによって、デプロイに必要な資格情報が作成されてダウンロードされます
。 その後、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 サイトのアプリケーションをビルドして、それを各環境にデプロイするための新しいジョブを追加しましょう。
