デプロイのベストプラクティス

[アーティクル]
06/01/2023

Note

2024 年 6 月 1 日より、新しく作成されたすべての App Service アプリには、名前付け規則 <app-name>-<random-hash>.<region>.azurewebsites.net を使用して一意の既定のホスト名を生成するオプションが備わります。既存のアプリ名は変更されません。

例: myapp-ds27dh7271aah175.westus-01.azurewebsites.net

詳細については、App Service リソースの一意の既定のホスト名に関するページを参照してください。

開発チームごとに独自の要件があり、それによって、クラウドサービスで効率的なデプロイパイプラインの実装が困難になる可能性があります。この記事では、App Service へのデプロイにおける 3 つの主要なコンポーネントである、デプロイソース、ビルドパイプライン、およびデプロイメカニズムについて説明します。この記事では、特定の言語スタックのベストプラクティスとヒントについても紹介します。

デプロイコンポーネント

デプロイソース

デプロイソースは、アプリケーションコードの場所です。運用アプリの場合、デプロイソースは通常、GitHub、BitBucket、Azure Repos などのバージョン管理ソフトウェアによってホストされるリポジトリです。開発とテストのシナリオでは、デプロイソースはローカルコンピューター上のプロジェクトである可能性があります。

ビルドパイプライン

デプロイソースを決定したら、次の手順として、ビルドパイプラインを選択します。ビルドパイプラインは、デプロイソースからソースコードを読み取り、一連の手順 (コードのコンパイル、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 設計と呼ばれます。これにより、関係者は、デプロイされたブランチを簡単に評価してテストすることができます。

運用スロットに対しては継続的デプロイを有効にしないでください。代わりに、運用ブランチ (多くの場合、メイン) を非運用スロットにデプロイします。ベースブランチをリリースする準備ができたら、それを運用スロットにスワップします。運用環境にデプロイするのではなく、運用環境にスワップすると、ダウンタイムの発生が抑えられ、もう一度スワップすることで変更をロールバックすることができます。

Dev、ステージング、およびメインブランチ間のフローとそれらのデプロイ先のスロットを示す図。

コンテナーを継続的にデプロイする

Docker やその他のコンテナーレジストリのカスタムコンテナーの場合は、イメージをステージングスロットにデプロイし、運用環境にスワップしてダウンタイムを回避します。イメージをコンテナーレジストリにプッシュし、webapp でイメージタグを更新する必要があるため、オートメーションは、コードのデプロイよりも複雑になります。

スロットにデプロイするブランチごとに、ブランチへの各コミットで次を実行するようにオートメーションを設定します。

イメージをビルドしてタグ付けする。ビルドパイプラインの一部として、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、レジストリパスワードを設定します。コンテナーの CI プロセスを構築するのに役立つリンクを次に示します。

Circle CI で Azure CLI にサインインする方法

言語固有の考慮事項

Java

JAR アプリケーションのデプロイには Kudu zipdeploy/ API を使用し、WAR アプリには wardeploy/ を使用してください。 Jenkins を使用している場合、デプロイフェーズでこれらの API を直接使用できます。詳細については、こちらの記事を参照してください。

Node

既定では、Kudu は Node アプリケーションのビルドステップ (npm install) を実行します。 Azure DevOps などのビルドサービスを使用している場合、Kudu ビルドは不要です。 Kudu ビルドを無効にするには、false の値を指定して SCM_DO_BUILD_DURING_DEPLOYMENT というアプリ設定を作成します。

.NET

既定では、Kudu は .NET アプリケーションのビルドステップ (dotnet build) を実行します。 Azure DevOps などのビルドサービスを使用している場合、Kudu ビルドは不要です。 Kudu ビルドを無効にするには、false の値を指定して SCM_DO_BUILD_DURING_DEPLOYMENT というアプリ設定を作成します。

デプロイに関するその他の考慮事項

ローカルキャッシュ

Azure App Service のコンテンツは Azure Storage に保存され、コンテンツ共有として永続的な方法で表示されます。ただし、アプリによっては、高可用で実行可能な高パフォーマンスの読み取り専用コンテンツストアのみが必要になる場合があります。こうしたアプリは、ローカルキャッシュを使うことでメリットが得られます。 WordPress などのコンテンツ管理サイトには、ローカルキャッシュはお勧めしません。

ダウンタイムを防ぐために、必ずデプロイスロットと共にローカルキャッシュを使用してください。これらの機能を一緒に使用する方法については、こちらのセクションを参照してください。

CPU またはメモリの高い使用率

App Service プランで、使用可能な CPU またはメモリの 90% 以上が使用されている場合、基になる仮想マシンでのデプロイの処理に問題が発生する可能性があります。これが発生している場合は、デプロイを実行するためにインスタンス数を一時的にスケールアップしてください。デプロイが完了したら、インスタンス数を前の値に戻すことができます。

ベストプラクティスの詳細については、App Service 診断にアクセスして、リソース専用の実行可能なベストプラクティスを確認してください。

Azure portal で Web App に移動します。
左側のナビゲーションで [問題の診断と解決] を選択すると、App Service 診断が開きます。
[ベストプラクティス] ホームページタイルを選択します。
[Best Practices for Availability & Performance] (可用性とパフォーマンスのベストプラクティス) または [Best Practices for Optimal Configuration] (最適な構成のベストプラクティス) を選び、これらのベストプラクティスに関するアプリの現在の状態を確認します。

また、こちらのリンクを使用して、リソースの 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。

その他のリソース

環境変数とアプリ設定のリファレンス

次の方法で共有

デプロイのベストプラクティス

デプロイコンポーネント

デプロイソース

ビルドパイプライン

デプロイメカニズム

デプロイスロットの使用

コードを継続的にデプロイする

コンテナーを継続的にデプロイする

Azure DevOps を使用する

GitHub Actions を使用する

他のオートメーションプロバイダーを使用する

言語固有の考慮事項

Java

Node

.NET

デプロイに関するその他の考慮事項

ローカルキャッシュ

CPU またはメモリの高い使用率

その他のリソース

フィードバック

その他のリソース

次の方法で共有

デプロイのベスト プラクティス

デプロイ コンポーネント

デプロイ ソース

ビルド パイプライン

デプロイ メカニズム

デプロイ スロットの使用

コードを継続的にデプロイする

コンテナーを継続的にデプロイする

Azure DevOps を使用する

GitHub Actions を使用する

他のオートメーション プロバイダーを使用する

言語固有の考慮事項

Java

Node

.NET

デプロイに関するその他の考慮事項

ローカル キャッシュ

CPU またはメモリの高い使用率

その他のリソース

フィードバック

その他のリソース

デプロイのベストプラクティス

デプロイコンポーネント

デプロイソース

ビルドパイプライン

デプロイメカニズム

デプロイスロットの使用

他のオートメーションプロバイダーを使用する

ローカルキャッシュ