アプリケーションをデプロイする際にWebAppのスワップ機能を使いたい
以下記事でも触れているが、
deployの実行のみでは明示的なイメージの再起動とプルは行いません
そのため、無理やりですがTaskとして再起動を実施しています。
※アプリケーションの瞬断が発生するので気になる方は一度デプロイスロットにデプロイ⇒スロットを再起動⇒スワップで回避できます
これを回避するためにデプロイメントスロットを採用、さらに今回はスロット側で実際のアプリの挙動を確認した上でブルーグリーンデプロイメントを実現するため、Releasesの承認機能を使って、特定のユーザーが承認アクションをしないとスワップされないようにする
ベースとなるDevOpsの設定や、WebAppについてはこちらの記事を参照
WebAppにデプロイメントスロットを作成
stagingで作成
運用スロットの「アプリケーション設定」をスロット側にも設定しておく必要がある（DevOpsでデプロイした際に運用スロットには自動で設定されている値）
現在はどちらも同じイメージで実行されている
- 運用スロット
- stagingスロット
DevOpsのReleasesを修正
Stage 1のデプロイ先をstagingスロットに変更
「Azure App Service deploy」Taskの「Deploy to Slot or App Service Environment」にチェックをいれ、スロットの情報を設定
後続の再起動Taskもstagingを先どうするように修正
Stageを追加
「Azure App Service manage」TaskでSwap Slotsを選択
承認機能の有効化
「Pre-deployment approvals」を有効化し、承認するユーザーを選択（グループを指定することも可能）
動作確認
アプリケーションを修正してコミット⇒Pipeline⇒Releasesの順で実行される
ReleasesのStage1実行後に承認プロセスが挟まり、承認者が承認するまでStage2は実行されない
この時点ではStagingスロットのみ更新されていればOK
承認者にはメールで通知が来ているので、Stagingでアプリケーションの動作を確認して問題なければ承認する
※承認コメント、却下コメントを残すことも可能
スワップが成功して環境が入れ替わっていればOK
※コンテナimageのtagを「latest」などの固定値にしてしまっているとスワップしたタイミングで両環境ともPullが実行され、同じ更新が実施されてしまうので注意
・切り戻しができなくなる
・tagを動的に変更する方法は前回の記事を参照
以上