開発チームごとに独自の要件があり、それによって、クラウド サービスで効率的なデプロイ パイプラインの実装が困難になる可能性があります。 この記事では、Azure App Service へのデプロイにおける 3 つの主要な構成要素である、"デプロイ ソース"、"ビルド パイプライン"、"デプロイ メカニズム" について説明します。 この記事では、特定の言語スタックのベスト プラクティスとヒントについても紹介します。
デプロイ コンポーネント
このセクションでは、App Service にデプロイするための 3 つの主要な構成要素について説明します。
デプロイ ソース
"デプロイ ソース" は、アプリケーション コードの場所です。 運用アプリの場合、デプロイ ソースは通常、GitHub、Bitbucket、Azure Repos などのバージョン管理ソフトウェアによってホストされるリポジトリです。 Development and test のシナリオでは、デプロイ ソースはローカル コンピューター上のプロジェクトである可能性があります。
ビルド パイプライン
デプロイ ソースを決定したら、次の手順は、"ビルド パイプライン" を選択することです。 ビルド パイプラインは、デプロイ ソースからソース コードを読み取り、一連の手順を実行して、実行可能な状態でアプリケーションを取得します。
手順には、コードのコンパイル、HTML と JavaScript のミニファイ処理、テストの実行、コンポーネントのパッケージ化が含まれる可能性があります。 ビルド パイプラインによって実行される特定のコマンドは、言語スタックによって異なります。 これらの操作は、Azure Pipelines などのビルド サーバーでも、ローカルでも実行できます。
展開のメカニズム
"デプロイ メカニズム" は、ビルドしたアプリケーションを Web アプリの /home/site/wwwroot ディレクトリに配置するために使用されるアクションです。 /wwwroot ディレクトリは、Web アプリのすべてのインスタンスによって共有される、マウントされたストレージの場所です。 デプロイ メカニズムによってアプリケーションがこのディレクトリに配置されると、インスタンスは新しいファイルを同期するための通知を受け取ります。
App Service では、次のデプロイ メカニズムをサポートしています。
- Kudu エンドポイント: Kudu は、Windows App Service で個別のプロセスとして実行されるオープンソースの開発者生産性ツールです。 これは Linux App Service の 2 つ目のコンテナーとして実行されます。 Kudu は、継続的なデプロイを処理し、zipdeploy などのデプロイ用の HTTP エンドポイントを提供します。
- FTP と WebDeploy:サイトまたはユーザーの資格情報を使用して、FTP 経由または WebDeploy 経由でファイルをアップロードできます。 これらのメカニズムは、Kudu を経由しません。
Azure Pipelines、Jenkins、エディター プラグインなどのデプロイ ツールでは、これらのデプロイ メカニズムのいずれかを使用します。
デプロイ スロットの使用
新しい生産リリースをデプロイするときは、可能な限り、デプロイ スロットを使用してください。 Standard App Service プラン レベル以上を使用して、ステージング環境へのアプリのデプロイ、変更の検証、スモーク テストを行うことができます。 準備ができたら、ステージングと運用スロットをスワップします。 入れ替え操作によって、必要なワーカー インスタンスが運用規模に合わせてウォームアップされるため、ダウンタイムがなくなります。
コードを継続的にデプロイする
テスト、QA、ステージング用に指定されたブランチがプロジェクトにある場合は、それらの各ブランチをステージング スロットに継続的にデプロイする必要があります。 このアプローチは、Gitflow 設計と呼ばれます。 この設計により、関係者は、デプロイされたブランチの評価を簡単に行ってテストすることができます。
運用スロットに対しては継続的デプロイを有効にしないでください。 代わりに、運用ブランチ (多くの場合、メイン) を非運用スロットにデプロイします。 ベース ブランチをリリースする準備ができたら、それを運用スロットにスワップします。 運用環境にデプロイするのではなく、運用環境にスワップすると、ダウンタイムの発生が抑えられ、もう一度スワップすることで変更をロールバックすることができます。
コンテナーを継続的にデプロイする
Docker やその他のコンテナー レジストリのカスタム コンテナーの場合は、イメージをステージング スロットにデプロイし、運用環境にスワップしてダウンタイムを回避します。 自動化は、コードのデプロイよりも複雑です。 イメージをコンテナー レジストリにプッシュし、Web アプリのイメージ タグを更新する必要があります。
スロットにデプロイするブランチごとに、ブランチへの各コミットでこれらのタスクを実行するようにオートメーションを設定します。
- イメージをビルドしてタグ付けする。 ビルド パイプラインの一部として、git のコミット ID、タイムスタンプ、またはその他の特定可能な情報でイメージにタグを付けます。 既定の latest タグは使用しないことをお勧めします。 そうしないと、現在デプロイされているコードの追跡が困難になり、デバッグがより難しくなります。
- タグ付けされたイメージをプッシュする。 イメージがビルドされてタグ付けされると、パイプラインはイメージをコンテナー レジストリにプッシュします。 次の手順では、デプロイ スロットが、タグ付けされたイメージをコンテナー レジストリからプルします。
- デプロイ スロットを新しいイメージ タグで更新する。 このプロパティが更新されると、サイトは自動的に再起動して、新しいコンテナー イメージをプルします。
この記事には、一般的なオートメーション フレームワークの例が含まれています。
Azure DevOps を使用する
App Service には、デプロイ センターを介して、コンテナーの組み込みの継続的デリバリーがあります。 Azure portal で自分のアプリに移動します。 [デプロイ] の下で、[デプロイ センター] を選択します。 指示に従って、リポジトリとブランチを選択します。 この方法により、選択したブランチに新しいコミットがプッシュされたときに、コンテナーを自動的にビルド、タグ付け、デプロイするように DevOps のビルドとリリース パイプラインが構成されます。
GitHub Actions を使用する
GitHub Actions を使用して、コンテナーのデプロイを自動化することもできます。 ワークフロー ファイルでは、コンテナーが作成されてコミット ID でタグ付けされ、コンテナー レジストリにプッシュされて、指定した Web アプリが新しいイメージ タグで更新されます。
on:
push:
branches:
- <your-branch-name>
name: Linux_Container_Node_Workflow
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
# checkout the repo
- name: 'Checkout GitHub Action'
uses: actions/checkout@main
- uses: azure/docker-login@v1
with:
login-server: contoso.azurecr.io
username: ${{ secrets.REGISTRY_USERNAME }}
password: ${{ secrets.REGISTRY_PASSWORD }}
- run: |
docker build . -t contoso.azurecr.io/nodejssampleapp:${{ github.sha }}
docker push contoso.azurecr.io/nodejssampleapp:${{ github.sha }}
- uses: azure/webapps-deploy@v2
with:
app-name: 'node-rnc'
publish-profile: ${{ secrets.azureWebAppPublishProfile }}
images: 'contoso.azurecr.io/nodejssampleapp:${{ github.sha }}'
他のオートメーション プロバイダーを使用する
前述の手順は、CircleCI や Travis CI などの他のオートメーション ユーティリティに適用されます。 ただし、最後の手順で、新しいイメージ タグでデプロイ スロットを更新するには、Azure CLI を使用する必要があります。 オートメーション スクリプトで Azure CLI を使用するには、次のコマンドを使用してサービス プリンシパルを生成します。
az ad sp create-for-rbac --name "myServicePrincipal" --role contributor \
--scopes /subscriptions/{subscription}/resourceGroups/{resource-group} \
--sdk-auth
スクリプトで、az login --service-principal を使用し、プリンシパルの情報を指定してサインインします。 次に、az webapp config container set を使用して、コンテナー名、タグ、レジストリ URL、レジストリ パスワードを設定します。 詳細については、Circle CI で Azure CLI にサインインする方法を参照してください。
言語固有の考慮事項
Java、Node、.NET の実装では、次の考慮事項に注意してください。
ジャワ
JAR アプリケーションをデプロイするには、Kudu zipdeploy API を使用します。 WAR アプリには wardeploy を使用します。 Jenkins を使用している場合、デプロイ フェーズでこれらの API を直接使用できます。 詳細については、Jenkins を使用して Azure App Service にデプロイするを参照してください。
ノード
既定では、Kudu は Node アプリケーションのビルド ステップ (npm install) を実行します。 Azure DevOps などのビルド サービスを使用している場合、Kudu ビルドは不要です。 Kudu ビルドを無効にするには、SCM_DO_BUILD_DURING_DEPLOYMENT の値を指定して false というアプリ設定を作成します。
。網
既定では、Kudu は .NET アプリケーションのビルド ステップ (dotnet build) を実行します。 Azure DevOps などのビルド サービスを使用している場合、Kudu ビルドは不要です。 Kudu ビルドを無効にするには、SCM_DO_BUILD_DURING_DEPLOYMENT の値を指定して false というアプリ設定を作成します。
デプロイに関するその他の考慮事項
その他の考慮事項としては、ローカル キャッシュと高 CPU またはメモリがあります。
ローカル キャッシュ
Azure App Service のコンテンツは Azure Storage に保存され、コンテンツ共有として永続的な方法で表示されます。 ただし、アプリによっては、高可用で実行可能な高パフォーマンスの読み取り専用コンテンツ ストアのみが必要になる場合があります。 こうしたアプリは、ローカル キャッシュを使うことでメリットが得られます。 詳細については、「Azure App Service のローカル キャッシュの概要」を参照してください。
注
WordPress などのコンテンツ管理サイトには、ローカル キャッシュはお勧めしません。
ダウンタイムを防ぐために、必ずデプロイ スロットと共にローカル キャッシュを使用してください。 これらの機能を組み合わせて使用する方法については、ベスト プラクティスを参照してください。
高 CPU またはメモリ
App Service プランで、使用可能な CPU またはメモリが 90% を超えて使用されている場合、基になる仮想マシンでのデプロイの処理に問題が発生する可能性があります。 この状況が発生している場合は、デプロイを実行するためにインスタンス数を一時的にスケールアップしてください。 デプロイが完了したら、インスタンス数を前の値に戻すことができます。
詳細については、App Service 診断を参照して、お使いのリソースに固有の実行可能なベスト プラクティスを確認してください。
Azure portal で Web App に移動します。
左側のナビゲーションで [問題の診断と解決] を選択すると、App Service 診断が開きます。
[可用性とパフォーマンス] を選択するか、[高 CPU の分析] などの他のオプションを確認します。
これらのベスト プラクティスに関して、アプリの現在の状態を表示します。
また、こちらのリンクを使用して、リソースの App Service 診断を直接開くこともできます: https://portal.azure.com/?websitesextension_ext=asd.featurePath%3Ddetectors%2FParentAvailabilityAndPerformance#@microsoft.onmicrosoft.com/resource/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{siteName}/troubleshoot。