1. yuhattor

    No comment

    yuhattor
Changes in tags
Changes in body
Source | HTML | Preview
@@ -1,384 +1,385 @@
+[Microsoft Azure Tech Advent Calendar 2018](https://qiita.com/advent-calendar/2018/microsoft-azure-tech)の9日目です!
この投稿では App Service のスロットスワッピングについて、ドキュメントに載っていない細かいところを見ていきます。
#そもそもAzure App Service には
いろんな機能があります。サービスのポイントはこんな感じです。
- フルマネージドなアプリ実行環境で、非機能要件からの開放
- 従来実現が大変だった スケーリング、 スロットの用意、リモートデバッグなどが簡単に実現
- C#, Java, PHP, Python, node をはじめ、多種多様な言語対応
- コンテナアプリの実行環境として使えて非常にカンタン!
![image.png](https://qiita-image-store.s3.amazonaws.com/0/131046/99f7a3e2-37af-b9f7-739b-108584ed862d.png)
#スロットスワッピング
そんな中でも特にいけてる機能(だと思うの)が、 スロットスワッピングの機能です。
スロットとは下記のような FQDN に紐づく "子 Web App" を作って Web App の環境を追加することができる機能です。
そしてスロットスワッピングとは、いわゆる PaaS で VIP SWAP (仮想 IP スワップ) を実現するようなサービスで、主に FQDN 以外の要素を切り替えることができます。 つまり、Staging と Production 環境を URL はそのまま、中身だけ変えることができるんですね。
- merrychristmas.azurewebsites.net (親 Web App)
- merrychristmas-qa.azurewebsites.net (子 Web App)
- merrychristmas-staging.azurewebsites.net (子 Web App)
- merrychristmas-dev.azurewebsites.net (子 Web App)
このスロットスワッピングの機能を使うとBlue-Green デプロイメントというデプロイ方式が実現できたりします。
# Blue-Green デプロイメント
これは現在運用中のグリーン環境に新たに新バージョンを載せたブルー環境を構築し、切り替えることにより、ゼロダウンタイム・リリースを可能にするデプロイ方式です。
このデプロイ方式はいわゆる DevOps でよく採用されるものですが、とても効果があるので既存のオペレーションにも組み入れる事をお勧めします。
これを使うと、確認した環境をスムーズに本番に移行可能ですし、いざという時のアプリの差し戻しが可能になります。
もちろん、v1 から v2 にした時に DBスキーマとかも変えてしまっていたらもちろんスワップの際に注意が必要ですが、ちゃんとオペレーションに使えればとても大きな効果があります。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/131046/e8ffee1a-e2f8-9ec3-b3b3-0cb78a3e6c07.png)
# 実際にやってみる
ということで、この投稿では方法を紹介する
わけではありません。
詳細が知りたい方は [Azure App Service でステージング環境を設定する](https://docs.microsoft.com/ja-jp/azure/app-service/web-sites-staged-publishing)をご覧ください。
この投稿では「つまり、Staging と Production 環境を URL はそのまま、中身だけ変えることができるんですね。」と前述した部分に関して深く掘っていきます。
実際、「中身だけ変えることが〜」と書きましたが、結構色々変わるもの変わらないものがあります。
でもそれって詳しいところはあんまり共有されていないんですよね。
「スロットスワッピングは便利だし、Blue-Green がやりたいから使おう!」
と、いきなりスロットスワップ機能を使ってプロダクション環境でエラーを出す前に、このリストを確認していただければ幸いです。
# Web App の設定の引き継ぎ
そもそもスロットは新しく作ったり、スワップしたりすることができますが、「設定の引き継ぎ」が生まれる可能性が2パターンあります。
今回の投稿で注目する箇所は下記です。
- 親 Web App から新しいスロットを作成した時に引き継がれる設定、引き継がれない設定
- スロットをスワップした時に引き継がれる設定、引き継がれない設定
まず、新しいスロットを作る際にはベースにする Web App の設定を引き継ぐことができます。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/131046/801365cb-9a1b-6d61-c799-b07f6d14ba9d.png)
スロットをスワップすると、それぞれの色々な設定が引き継がれたり引き継がれなったり。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/131046/801d7edc-25ba-0a8a-b5f4-82e08fce0ef9.png)
「ちょっとまって、そういうのってドキュメントに書いてあるよね。」
はい、[こちら](https://docs.microsoft.com/ja-jp/azure/app-service/web-sites-staged-publishing
)に書いてあります。
- スワップされる設定:
- 一般設定 - フレームワーク バージョン、32/64 ビット、Web ソケットなど
- アプリ設定 (スロット固有として構成可能)
- 接続 文字列 (スロット固有として構成可能)
- ハンドラー マッピング
- 監視と診断の設定
- Web ジョブ コンテンツ
- Hybrid Connections (ハイブリッド接続)
- スワップされない設定:
- 発行エンドポイント
- カスタム ドメイン名
- SSL 証明書とバインド
- スケールの設定
- Web ジョブ スケジューラ
この公式ドキュメントについては、2018年12月段階の代表的な設定が書いてあると思ってください。
この投稿ではこれ以外に何か変わるのか見ていきます。
# メニューにそって どんどん見ていきましょう
![pict1.png](https://qiita-image-store.s3.amazonaws.com/0/131046/6c33890b-1319-5fdd-1eec-f0cba973aad7.png)
### アクセス制御 (IAM)
**スロットスワッピング** : スワップされない (2018/11確認)
- デプロイしてスロットスワップするたびに Prod 環境にアクセスできる人の権限が変わってしまったら大変ですよね。
**スロット新規作成** : 引き継がれる (2018/11 確認)
- 新しい環境を作ったら、秘匿しておきたい環境変数も他の人に見られてしまうようになったら大変です。
### タグ
**スロットスワッピング** : スワップされない (2018/11確認)
- 整理しようと思ってタグを作って、Test とかいうタグを作ったのにスワップされたらちょっといやですね。
**スロット新規作成** : 引き継がれない (2018/11確認)
- これも同じく。Env:Staging とかいうタグをつくって、-dev というスロットを作った時にそのパラメータが引き継がれたらちょっと困りますね。
### デプロイオプション:
**スロットスワッピング** : スワップされない (Document に記載)
- これが引き継がれたらこまります。
**スロット新規作成** : 引き継がれない (2018/11確認)
- 上に同じく
### デプロイセンター (プレビュー)
**スロットスワッピング** : スワップされない (Document に記載)
- デプロイオプションの項目に同じく。名前がちょっとややこしいですね。
**スロット新規作成** : 引き継がれない
- 同上
### アプリケーション設定
これは基本的にスワップ/引き継ぎが行われますが、量が多いのでスワップされないものだけ挙げます。
**スロットスワッピングでスワップされない設定** :
- 自動スワップ
- 自動スワップ スロット
**スロット新規作成時に引き継がれない設定** :
- HTTP バージョン
- ARR アフィニティ
- FTP アクセス
- 上に同じく
### 認証/承認
**スロットスワッピング** : スワップされない (2018/11 確認)
- これも環境が変わるごとに変わったらおかしなことになるので、スロットスワップされません。ちなみに、余談ですが認証の仕組みは Web App のフロントエンド(Proxy) がやるのかなと思うかもしれませんが、実は下記にある通りApp Service Worker にある easyauth.dll で行なっています。
https://docs.microsoft.com/ja-jp/azure/app-service/app-service-authentication-overview
**スロット新規作成** : 引き継がれない (2018/11 確認)
- 上に同じく
### Application Insights
**スロットスワッピング** : 引き継がれる (2018/11確認、注意)
- ポータルのこの機能で設定された AppInsights はスロット関わらずアプリ横断になるため、設定項目自体は引き継がれる、というより全体への設定になります。運用でDevとProdのログを混ぜるのは大変微妙なので、実際に開発に入ったら App Setting の環境変数を使って、スロットごとに AppInsights のキーを変えましょう。
**スロット新規作成** : 引き継がれる (2018/11確認、注意)
- 上に同じく
### マネージド サービス ID
**スロットスワッピング** : スワップされない (2018/11 確認)
- システム割り当て ID を持つアプリを作成するための設定ですが、これもスワップするたびに変化してたらおかしくなります。
**スロット新規作成** : 引き継がれない (2018/11 確認)
- 新しいスロットはステージング用途かもしれないですし、やはりこれもスワップされたら悲しいです。
### バックアップ
**スロットスワッピング** : スワップされない (2018/11 確認)
- 大抵とりたいのは Prod のバックアップだと思いますが、スワップしたら Prod のバックアップが取られないようになった。なんていったら悲劇です。
**スロット新規作成** : 引き継がれない (2018/11 確認)
- 上に同じく
### カスタム ドメイン
**スロットスワッピング** : スワップされない (Document に記載)
**スロット新規作成** : 引き継がれない (2018/11 確認)
### SSL 設定
**スロットスワッピング** : スワップされない (Document に記載)
**スロット新規作成** : [HTTPSのみ] の設定およびアップロードした公開証明書の設定**以外**は引き継がれる。(2018/11 確認)
### ネットワーク
**スロットスワッピング** : 基本的にスワップされる(2018/11 確認)
- IP 制限はスワップされる
- VNet Integration は P2S でも Preview 版でもスワップされる
- CDN 設定はスワップされない
- ハイブリッドコネクションはスワップされる
これもちょっとややこしいですが、結構重要なところです。VNet Integration はスワップされるので、環境ごとにつなぐ先を変えている場合影響が出る可能性があります。なるべくネットワーク的には Staging も Prod も近い場所に置いておいて、接続文字列で接続先を変えるようにしておいた方がいいということになります。IP 制限もスワップされるのは少し驚きかもしれません。
もしかすると、Staging / Prod の距離は心理的にもネットワーク的にも遠いものという方がも多いかもしれませんが、Azure では少なくともネットワーク的に近いことが求められます。
**スロット新規作成** : 基本的に引き継がれない(2018/11 確認)
- IP 制限は引き継がれるが優先度、レンジが変わる可能性あり (プラットフォームとして修正予定あり)
- VNet Integration は 引き継がれない
- CDN は引き継がれない
- ハイブリッドコネクションは引き継がれない
### Web ジョブ
**スロットスワッピング** : Web ジョブ コンテンツはスワップされ、Web ジョブ スケジューラはスワップされない (Document に記載)
- ここも少しややこしいですが、コンテンツ自体は /home 配下に置かれると考えると妥当な感じがすると思います。基本的には普通のアプリのスロットスワッピングと同じ考え方をすればOKです。
**スロット新規作成** : 引き継がれない (2018/11 確認)
- 上に同じく。スロットスワッピングはコンテンツまでは引き継がれないので、このような結果になります。
### MySQL In App
**スロットスワッピング** : スワップされる (2018/11 確認)
- これも InApp で /home 配下に置かれるので、アプリのコンテンツという扱いです。そもそも In App は開発テスト環境オンリーで使うためにあるので、運用には関係ない話ですね。
**スロット新規作成** : 引き継がれる (2018/11 確認)
- 引き継がれます。
### ロック
**スロットスワッピング** : スワップされない (2018/11 確認)
- スワップされた時に Prod が消せるようになって、万が一誰かが消してしまったらこれも悲劇です。
**スロット新規作成** : 子リソース独自の反映はなし (2018/11 確認)
- 親リソース自体にロックがかかっていますが、子リソースに対して新しいロックがかかることはありません。
ロックに関しては、親リソースにロックがかかっていた場合には、子リソースも削除することができません。
### パフォーマンス テスト
**スロットスワッピング** : スワップされない (2018/11 確認)
**スロット新規作成** : 引き継がれる (2018/11 確認)
### 運用環境でのテスト
**スロットスワッピング** : スワップされない (2018/11 確認)
- これは、運用環境で2環境以上使いたい時(つまりカナリアリリース環境です)に使いますが、Prod:90%, Canary:10% でロードバランシングされるように設定したのに、スワップ時にスワップされてしまってCanary90% になったら運用者は慌てること間違いなし!なので、スワップされません。
**スロット新規作成** : オンになっている場合そもそも作成できず(2018/11 確認)
### 拡張機能
**スロットスワッピング** : スワップされる (2018/11 確認)
- これも結局 /home 配下に配置されるので、スワップ対象です。
**スロット新規作成** : 引き継がれない(2018/11 確認)
- コンテンツは引き継がれないので、これも引き継がれません。
### Easy Tables
**スロットスワッピング** : スワップされる (2018/11 確認)
- コンテンツという扱いなので、スワップされます。
**スロット新規作成** : 引き継がれない(2018/11 確認)
- コンテンツという扱いなので、引き継がれません。
### Easy API
**スロットスワッピング** : スワップされる (2018/11 確認)
- 考え方は Easy Tables に同じくです。
**スロット新規作成** : 引き継がれない(2018/11 確認)
- 考え方は Easy Tables に同じくです。
### データ接続
**スロットスワッピング** : スワップされない (2018/11 確認)
**スロット新規作成** : 引き継がれる (2018/11 確認)
- データ接続に関しては引き継がれます。ちょっとこれには注意が必要ですね。
### API 定義
**スロットスワッピング** : スワップされる (2018/11 確認)
- Swagger Specification のAPI をjson で定義できますが、これもスワップされないと環境ごとに Swagger と API がマッチしないおかしなことになります。なのでちゃんとスワップされます。
**スロット新規作成** : 引き継がれる (2018/11 確認)
- 新しい環境には引き継がれるようになっています。
### CORS
**スロットスワッピング** : スワップされる (2018/11確認)
- ちゃんとスワップされます。
**スロット新規作成** : 引き継がれる (2018/11 確認)
- 引き継がれた環境ができます。
### 診断ログ
**スロットスワッピング** : スワップされない
**スロット新規作成** : 引き継がれるがアプリケーションログの設定のみ引き継がれず(2018/11 確認)
### そもそもビューの提供やリンクなので関係ないもの
- 概要
- 問題の診断と解決
- クイックスタート
- プロパティ
- ログ ストリーム
- プロセス エクスプローラー
- リソース正常性
- App Service Advisor
- 新しいサポート要求
- Automation スクリプト
- クォータ
- コンソール
- 高度なツール
- App Service Editor (プレビュー)
- リソース エクスプローラー
- アプリの複製
### Azure 全体共通 / 他のサービスの機能なので関係ないもの
- アクティビティログ
- アラート (クラシック)
### App Service Plan 共通なので関係ないもの
- スケール アップ (App Service のプラン)
- スケール アウト (App Service のプラン)
- Deployment Slot (Preview)
- デプロイスロット
- App Service プラン
- App Service プランの変更
# 注意
この投稿の検証内容の粒度はそれぞれの「メニューごとに見える範囲で」です。内部的に細かい部分が変わっている可能性がございます。運用時にはスロットでテストして確認してからお使いください。 また、今回は一つ一つ目で確認していきましたが、細かい部分が若干変わる可能性があります。詳細に関してはAzure のリソースエクスプローラーでご確認ください。また、この確認は 2018/11時点でのものですので今後急に変わる可能性がありますし、新しい機能が追加されるに伴って追加される部分もあると思います。
実際に気になる部分があった場合、この記事をあくまでも「参考」にして、今一度確認してくださるとありがたいです。
また、この投稿に誤りがございましたら、コメントいただけると幸いです。
## リソースエクスプローラとは
Azure の環境は ARM と言われる IaC 環境です。設定は基本的に全部 JSON で取得できます。
https://resources.azure.com/
<img width="1434" alt="Screen Shot 2018-12-08 at 15.55.45.png" src="https://qiita-image-store.s3.amazonaws.com/0/131046/d1fd3709-8575-5ef9-6d3f-4d62bb7dd676.png">
これで Diff をとりましょう。といっても、項目が多すぎる + GUID とかは色々違ったりするので、単純な Diff だけとってもだいぶややこしいので、誰かやってくれる人募集中です。
# 結論とまとめ
色々と長ったらしく羅列しましたが、スロットスワップといっても、引き継がれる、引き継がれない設定が結構あり注意が必要であることがわかったと思います。
下記に気をつけながら良いスロットスワップライフを送っていただければいいと思います。
- スロットスワップは便利な機能
- 色々内部的にスワップされたりされなかったりする。
- Web App の基本的な機能だけを使っている場合はそこまで考慮することなくスワップしても多分大丈夫
- Web App の様々な機能を使い倒せば使い倒すほど、スロットごとの設定で、何が変わって何が変わらないのかを考慮する必要がある。
# カンタン一覧
|項目|スワップ|新規作成|
|---|---|---|
|アクセス制御 (IAM)|スワップされない |引き継がれる |
|タグ|スワップされない |引き継がれない |
|デプロイオプション:|スワップされない |引き継がれない |
|デプロイセンター (プレビュー)|スワップされない |引き継がれない |
|アプリケーション設定|一部を除き基本的に引き継がれる|一部を除き基本的に引き継がれる|
|認証/承認|スワップされない |引き継がれない |
|Application Insights|引き継がれる |引き継がれる |
|マネージド サービス ID|スワップされない |引き継がれない |
|バックアップ|スワップされない |引き継がれない |
|カスタム ドメイン|スワップされない |引き継がれない |
|SSL 設定|スワップされない |[HTTPSのみ] の設定およびアップロードした公開証明書の設定以外は引き継がれる。|
|ネットワーク|基本的にスワップされる|基本的に引き継がれない|
|Web ジョブ|Web ジョブ コンテンツはスワップされ、Web ジョブ スケジューラはスワップされない|引き継がれない |
|MySQL In App|スワップされる |引き継がれる |
|ロック|スワップされない |子リソース独自の反映はなし |
|パフォーマンス テスト|スワップされない |引き継がれる |
|運用環境でのテスト|スワップされない |オンになっている場合そもそも作成できず|
|拡張機能|スワップされる |引き継がれない|
|Easy Tables|スワップされる |引き継がれない|
|Easy API|スワップされる |引き継がれない|
|データ接続|スワップされない |引き継がれる |
|API 定義|スワップされる |引き継がれる |
|CORS|スワップされる |引き継がれる |
|診断ログ|スワップされない|引き継がれるがアプリケーションログの設定のみ引き継がれず|
**上記を踏まえた上で、スロットスワッピングの機能を使い倒しましょう!**
**大事なことなのでもう一度・・・**
実際に気になる部分があった場合、この記事をあくまでも「参考」にして、今一度確認してくださるとありがたいです。
また、この投稿に誤りがございましたら、コメントいただけると幸いです。