Azure Developer CLI を使用して Azure App Service デプロイ スロットにデプロイする

Azure Developer CLI (azd) では、App Service でホストされているアプリの Azure App Service デプロイ スロットがサポートされています。 インフラストラクチャ内でスロットを定義し、コードを特定のスロットにデプロイすることができます。リリースを昇格する準備ができたら、スロットをスワップすることができます。

この方法は、カスタム デプロイ スクリプトを追加せずに、ステージング、ブルーグリーン デプロイ、スモーク テスト、ロールバックに使用します。

前提条件

• Azure App Service にサービスをデプロイする azd プロジェクト。
• Bicep で App Service リソースを定義するコードとしてのインフラストラクチャ。
• Standard (S1) レベル以上の App Service プラン。 Free レベル、Shared レベル、Basic レベルでは、デプロイ スロットはサポートされていません。

Bicep でデプロイ スロットを定義する

通常どおり運用サイトを定義し、ターゲットにするスロットごとに Microsoft.Web/sites/slots リソース azd 追加します。

resource appServicePlan 'Microsoft.Web/serverfarms@2021-03-01' = {
  name: 'my-appservice-plan'
  location: resourceGroup().location
  sku: {
    name: 'S1'
    tier: 'Standard'
  }
}

resource webApp 'Microsoft.Web/sites@2021-03-01' = {
  name: 'my-appservice'
  location: resourceGroup().location
  kind: 'app'
  properties: {
    serverFarmId: appServicePlan.id
  }
}

resource stagingSlot 'Microsoft.Web/sites/slots@2021-03-01' = {
  name: '${webApp.name}/staging'
  location: webApp.location
  properties: {}
}

Azure Verified Modules (AVM) を使用する場合は、同じデプロイで Web アプリとデプロイ スロット モジュールを定義し、スロット モジュールにアプリ名を渡します。

azd を使用してスロットにデプロイする

azd upまたはazd provisionを実行し、通常どおりazd deployします。

azd up

最初のデプロイでは、 azd は、運用サイトとインフラストラクチャで定義されているすべてのスロットにデプロイされます。 この最初のデプロイでは、メイン アプリとすべてのスロットで同じベースラインが確立されます。

最初のデプロイの後、 azd deploy スロットが存在する場合のデプロイ ターゲットの選択方法を変更します。 azd では、スロットが使用可能な場合、運用アプリへの直接デプロイは続行されません。 代わりに、スロットにデプロイし、リリースを検証してから、運用環境にスワップします。

azd がデプロイ ターゲットを選択する方法

デプロイ スロットがある App Service に対して azd deploy 実行すると、メイン アプリのデプロイ履歴を確認し、使用可能なスロットを評価することでターゲットが選択されます。

動作は次のように動作します。

• 以前のデプロイが存在しない場合、 azd はメイン アプリとすべてのスロットにデプロイされます。
• 以前のデプロイが存在し、スロットが存在しない場合、 azd はメイン アプリにのみデプロイされます。
• 以前のデプロイが存在し、スロットが 1 つだけ存在する場合、 azd はそのスロットにのみデプロイされます。
• 以前のデプロイが存在し、2 つ以上のスロットが存在する場合、 azd は環境変数で指定されたスロットを使用するか、1 つ選択するように求められます。

環境変数を含むスロットを選択する

最初のデプロイ後にサービスに 2 つ以上のスロットがある場合は、デプロイするサービスの環境変数を設定することで、対話型プロンプトをスキップできます。

次の形式を使用します。

AZD_DEPLOY_<SERVICE_NAME>_SLOT_NAME

大文字を使用し、ハイフンをアンダースコアに置き換えて、 azure.yaml のサービス名から変数名を作成します。

たとえば、サービスに my-api という名前が付けられている場合は、 AZD_DEPLOY_MY_API_SLOT_NAMEを使用します。

azd env set AZD_DEPLOY_MY_API_SLOT_NAME staging
azd deploy my-api

この値は、azdを使用してazd env set環境に格納することも、azd deployを実行する前に CI システムに直接定義することもできます。

サービスにスロットが 1 つだけ存在する場合、 azd は環境変数を無視します。可能なデプロイ ターゲットは 1 つだけなのでです。

サービスに 2 つ以上のスロットがあり、環境変数が設定されていない場合は、 azd スロットを選択するように求められます。

スロット検出をバイパスしてメイン アプリにデプロイする

シナリオによっては、スロットが存在する場合でも、メインの App Service アプリに直接デプロイ azd 必要があります。 例えば次が挙げられます。

• CI パイプラインでは、既存のスロットはそのままにしたまま、メイン アプリを更新する必要があります。
• 不適切なスロット状態から復旧しており、運用サイトを直接再デプロイする必要があります。
• 新しいスロットを設定する前に、メインアプリのベースラインを再設定しています。

スロット検出をバイパスするには、サービスに次の環境変数を設定します。

AZD_DEPLOY_<SERVICE_NAME>_IGNORE_SLOTS

大文字を使用し、ハイフンをアンダースコアに置き換えて、 azure.yaml のサービス名から変数名を作成します。 スロットの検出をスキップしてメイン アプリにデプロイするには、値を true に設定します。

たとえば、サービスに my-api という名前が付けられている場合は、 AZD_DEPLOY_MY_API_IGNORE_SLOTSを使用します。

azd env set AZD_DEPLOY_MY_API_IGNORE_SLOTS true
azd deploy my-api

AZD_DEPLOY_<SERVICE_NAME>_IGNORE_SLOTSが true に設定されている場合、azdはメイン アプリにデプロイされ、同じサービスのAZD_DEPLOY_<SERVICE_NAME>_SLOT_NAME値は無視されます。 変数の設定を解除するか、 false に設定して、スロット対応の既定の動作に戻ります。

CI と非インターアクティブな動作

azd deploy --no-promptを実行するか CI からデプロイする場合、スロットの選択は使用可能なスロットの数によって動作が異なります。

2 つ以上のスロットがある App Service のデプロイを自動化する場合は、AZD_DEPLOY_<SERVICE_NAME>_SLOT_NAMEを実行する前にパイプライン環境でazd deployを設定します。 スロットが存在する場合に CI からメインへの直接デプロイを強制するには、代わりに AZD_DEPLOY_<SERVICE_NAME>_IGNORE_SLOTS を true に設定します。

Azure App Service デプロイ スロットをスワップする

検証後にスロットをスワップするには、 azure.appservice 拡張機能を使用します。 拡張機能がまだインストールされていない場合は、 azd コマンドを初めて実行するときにインストールするように求められます。

対話型エクスペリエンスを実行します。

azd appservice swap

非運用スロットが 1 つだけ存在する場合、 azd はプロンプトをスキップし、運用環境と直接スワップします。

自動化の場合は、ソース スロットと宛先スロットを明示的に指定します。 @mainを使用してプロダクションスロットを参照します。

azd appservice swap --src staging --dst @main
azd appservice swap --src @main --dst staging
azd appservice swap --service myapi --src staging --dst @main

一般的なリリース フローをサポートするには、次のパターンを使用します。

• --src staging --dst @mainを使用して、検証済みのステージングデプロイを運用環境に昇格させます。
• --src @main --dst stagingによって実稼働環境をステージング スロットに戻してロールバックします。
• azdを使用して、マルチサービス --service プロジェクト内の特定の App Service ベースのサービスをターゲットにします。

スワップは、スロットの構成後に運用環境を更新するための目的のパスです。 azd deployを使用してスロットを更新し、azd appservice swapを使用してそのスロットを運用環境に昇格させます。

推奨されるデプロイ スロットのワークフロー

1. Bicep テンプレートで 1 つ以上の App Service デプロイ スロットを定義します。
2. azd provisionまたはazd upを使用して App Service リソースをプロビジョニングします。
3. 最初のデプロイで、メイン アプリとすべてのスロットでベースラインを確立します。
4. 2 つ以上のスロットがある場合に AZD_DEPLOY_<SERVICE_NAME>_SLOT_NAME を設定するか、プロンプトが表示されたらスロットを選択して、後でアプリケーションの更新をステージング スロットにデプロイします。 スロットが存在する場合に CI からメインへの直接デプロイを強制するには、代わりに AZD_DEPLOY_<SERVICE_NAME>_IGNORE_SLOTS を true に設定します。
5. 段階的なデプロイを検証します。
6. azd appservice swap --src <slot> --dst @mainを実行してリリースを推進します。
7. 必要に応じて、リバース スワップを実行してロールバックします。

関連するコンテンツ

• Azure Developer CLI コマンドの概要
• Azure Developer CLI リファレンス
• Azure App Service でステージング環境を設定する
• azd を使用して Azure App Service デプロイ スロットにデプロイする
• Azure Developer CLI (azd): Azure App Service スロットをスワップする 1 つのコマンド