App Service にデプロイする

  • 3 分

開発チームごとに独自の要件があり、それによって、クラウド サービスで効率的なデプロイ パイプラインの実装が困難になる可能性があります。 App Service では、自動デプロイと手動デプロイの両方がサポートされます。

自動化されたデプロイ

自動デプロイ、または継続的デプロイは、エンド ユーザーへの影響を最小限に抑えつつ、短期間かつ反復的なパターンで新機能とバグ修正を提供するために使用されるプロセスです。

Azure では、複数のソースから直接、自動デプロイをサポートします。 次のオプションを使用できます。

  • Azure DevOps Services: Azure DevOps Services にコードをプッシュし、クラウドでコードをビルドし、テストを実行し、コードからリリースを生成し、最後にコードを Azure Web アプリにプッシュできます。
  • GitHub: Azure では、GitHub から直接、自動デプロイをサポートします。 自動デプロイのために GitHub リポジトリを Azure に接続すると、GitHub 上の運用ブランチにプッシュするすべての変更が自動的にデプロイされます。
  • Bitbucket: GitHub との類似性により、Bitbucket を使用して自動デプロイを構成できます。

手動デプロイ

手動でコードを Azure にプッシュするために使用できるいくつかのオプションがあります。

  • Git:App Service Web アプリには、リモート リポジトリとして追加できる Git URL があります。 リモート リポジトリにプッシュすると、アプリがデプロイされます。
  • CLI: webapp up はアプリをパッケージ化し、デプロイする az コマンドライン インターフェイスの機能です。 他のデプロイ方法とは異なり、az webapp up では、まだ作成していない場合、新しい App Service Web アプリが自動的に作成されます。
  • Zip デプロイ: curl または同様の HTTP ユーティリティを使用し、アプリケーション ファイルの ZIP を App Service に送信します。
  • FTP/S:FTP または FTPS は、App Service を含む、さまざまなホスティング環境にコードをプッシュする従来の方法です。

デプロイ スロットの使用

新しい運用ビルドをデプロイするときは、可能な限り、デプロイ スロットを使用してください。 Standard App Service 以上のプラン レベルを使用する場合は、ステージング環境にアプリをデプロイし、ステージング スロットと運用スロットをスワップすることができます。 スワップ操作によって、必要なワーカー インスタンスが運用規模に合わせてウォームアップされるため、ダウンタイムがなくなります。

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

テスト、QA、ステージング用に指定されたブランチがプロジェクトにある場合は、それらの各ブランチをステージング スロットに継続的にデプロイする必要があります。 これにより、関係者は、デプロイされたブランチを簡単に評価してテストすることができます。

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

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

  • イメージをビルドしてタグ付けする:ビルド パイプラインの一部として、Git コミット ID、タイムスタンプ、またはその他の識別可能な情報を使用してイメージにタグ付けします。 既定の "latest" タグは使用しないことをお勧めします。 そうしないと、現在デプロイされているコードの追跡が困難になり、デバッグがはるかに難しくなります。
  • タグ付けされたイメージをプッシュする:イメージがビルドされてタグ付けされると、パイプラインによってコイメージがコンテナー レジストリにプッシュされます。 次の手順では、デプロイ スロットが、タグ付けされたイメージをコンテナー レジストリからプルします。
  • デプロイ スロットを新しいイメージ タグで更新する:このプロパティが更新されると、サイトは自動的に再起動して、新しいコンテナー イメージをプルします。