App ServiceやWeb App for Containersによる今どきのナウいリリースについて(Blue-Greenデプロイとかカナリアリリースとか)/appservicedeploy

© SIOS Technology, Inc. All rights Reserved. App ServiceやWeb App
for Containersによる今どきのナウいリリースについて(Blue-Greenデプロイとかカナリアリリースとか) Noriyuki TAKEI 2020年11⽉25⽇

© SIOS Technology, Inc. All rights Reserved. About Me 2
BCPVUNF Noriyuki TAKEI ෢Ҫ ٓߦ Information • サイオステクノロジー株式会社 • Microsoft MVP for Azure • VS Code Meetup Organizer Favorites • Azure • Squash • Sweets blog https://tech-lab.sios.jp/ core skill Azure Kubernetes Service Cloud Native, Serverless全般 Twitter @noriyukitakei

© SIOS Technology, Inc. All rights Reserved. 今どきのナウいリリース by App
Service、Web App for Containers 3 App Service、Web App for Containersってなに︖ Azure Container RegistryにDockerイメージをアップロードするだけで、フルマネージドなプラットフォーム上にWebアプリケーションを迅速に構築、デプロイ、スケーリングすることが出来る。ほぼApp Serviceと同じ機能を持っている。 Web App for Containers 専⽤のポータルからソースコードやアーカイブをアップロードするだけで、フルマネージドなプラットフォーム上にWebアプリケーションを迅速に構築、デプロイ、スケーリングすることが出来る。 App Service 本セッションのブログのURL

Service、Web App for Containers 4 そしてApp ServiceやWeb App for Containersは、様々なデプロイ⽅法に対法しています。これらを活⽤すると無停⽌で楽ちんなデプロイが可能です︕︕ In-Placeデプロイ Blue-Greenデプロイカナリアリリース本セッションのブログのURL

Service、Web App for Containers 5 In-Placeデプロイ既存の環境に新しアプリをエイヤとデプロイする⼿法です。旧来から⽤いられている伝統的な⼿法かと思います。ただし、ダウンタイムが発⽣する可能性が⾼いです。

Service、Web App for Containers 6 Blue-Greenデプロイ現在動いている環境とは別に、新たにリリースする別の環境を⽤意して、DNSのレコード切り替え等により、旧環境から新環境にエイヤと切り替える⼿法です。ダウンタイムほぼゼロ︕︕ 旧環境と新環境の2つのリソースを⽤意しなければならないので、ちょっと費⽤がかさむ(´・ω・｀) 本セッションのブログのURL

Service、Web App for Containers 7 カナリアデプロイ現在動いている環境とは別に、新たにリリースする別の環境を⽤意して、旧環境に振られているリクエストを徐々に少しずつ新環境に割り振っていく⼿法です。少しずつ切り替えていくので、何かあった際の影響が少ない。旧環境と新環境の2つのリソースを⽤意しなければならないので、ちょっと費⽤がかさむ(´・ω・｀)

Service、Web App for Containers 8 各デプロイ⽅法のメリデリはこんな感じ。デプロイ⽅法ユーザー影響コスト切り戻し In-Placeデプロイ ☓ ◯ ☓ アプリの設計にもよるが、単なる⼊れ替えなのでサービスが停⽌することが多い。既存のサーバーに対するアプリの⼊れ替えなので、他のサーバーを⽤意しなくていい。もう⼀度同じアプリを上書きしなければいけないので、切り戻し⼤変。 Blue-Greenデプロイ ◯ ☓ ◯ 旧アプリから新アプリへの切り替えはロードバランサーや DNSの変更だけなので、ほとんど影響なし。新旧両⽅のサーバーを⽤意しなければならないので、コストがかかる。 DNSやロードバランサーを変更するだけで旧サーバーにリクエストが⾏き切り戻しできるのでラクチン。カナリアデプロイ ◯ ☓ ◯ 旧アプリから新アプリへの切り替えはロードバランサーや DNSの変更だけなので、ほとんど影響なし。新旧両⽅のサーバーを⽤意しなければならないので、コストがかかる。 DNSやロードバランサーを変更するだけで旧サーバーにリクエストが⾏き切り戻しできるのでラクチン。

Service、Web App for Containers 9 やってみよう︕︕ 本セッションのブログのURL

Service、Web App for Containers 10 Blue-Greenデプロイ実践中︕︕ すでにブラウザに「hoge」と表⽰するアプリがリリースされているとします。これを「fuga」と表⽰されるアプリにBlue-Greenデプロイでリリースします。今の状態は右図のような感じです。本セッションのブログのURL

Service、Web App for Containers 11 App Service(もしくはWeb App for Containers)の管理画⾯にアクセスして、左部メニューの「デプロイスロット」をクリックします。すでにbluegreentestスロットというのが出来上がっています。この名前はApp Service名とイコールです。ここに新しいスロットを追加しましょう。「+スロットの追加」をクリックします。 Blue-Greenデプロイ実践中︕︕

Service、Web App for Containers 12 Blue-Greenデプロイ実践中︕︕ 「名前」に任意の名称を⼊⼒します。「次から設定を複製」はどっちでもいいです。本セッションのブログのURL

Service、Web App for Containers 13 Blue-Greenデプロイ実践中︕︕ 以下の画⾯のように「bluegreentest-stg」というスロットが出来上がっていると思います。

Service、Web App for Containers 14 Blue-Greenデプロイ実践中︕︕ ちょうどイメージにすると、現在は以下のような状態になります。bluegreentest-stg というスロットが作成されて、その中に bluegreentestというスロット内のApp Serviceが複製されています。以下の図を⾒るとわかると思いますが、スロットはすべて同じApp Serviceプランの中に作成されます。

Service、Web App for Containers 15 Blue-Greenデプロイ実践中︕︕ ここでシステム管理者が新しいアプリをデプロイして、右図ような状態になったとします。。先程作成した新しいスロット (bluegreentest-stg)には、fugaと表⽰される新しいアプリがあります。実際にユーザーがアクセスしているのは、 bluegreentestスロットにある旧アプリです。bluegreentest-stgスロットにある新アプリにはまだリクエストが来ていないので、システム管理者は安全に新アプリをテストすることができます。

Service、Web App for Containers 16 Blue-Greenデプロイ実践中︕︕ そして、ここからがBlue-Greenデプロイの実⾏なのですが、旧アプリ (hoge)と新アプリ(fuga)を⼊れ替えます。先程のスロット⼀覧画⾯にアクセスして、「スワップ」をクリックします。

Service、Web App for Containers 17 Blue-Greenデプロイ実践中︕︕ 「ソース」にスワップ元のスロット、「ターゲット」にスワップ先のスロットを選択します。「運⽤」と表⽰されているスロットは、実際にエンドユーザーがアクセスしている本番のスロットになります。最後に「スワップ」をクリックします。しばらくすると完了します。

Service、Web App for Containers 18 Blue-Greenデプロイ実践中︕︕ ⾒た⽬にはわかりませんが、スワップされています。試しにbluegreentest のスロットにあるApp Serviceにアクセスしたら「fuga」と表⽰されるはずです。

Service、Web App for Containers 19 カナリアデプロイ実践中︕︕ 現在、先程作成したbluegreentest- stgに新アプリが適⽤済みの状態とします。エンドユーザーのアクセスは旧アプリに向いているものとします。この状態から、新アプリにだけ全体のアクセスの20%を向けるということをやっみたいと思います。

Service、Web App for Containers 20 カナリアデプロイ実践中︕︕ 現在の状態は、App Serviceのポータルで⾒ると以下のような状態です。本セッションのブログのURL

Service、Web App for Containers 21 カナリアデプロイ実践中︕︕ デプロイスロットの⼀覧画⾯で、右図のようにbluegreentest-stgのスロットの「トラフィック」を20にして「保存」をクリックします。本セッションのブログのURL

Service、Web App for Containers 22 カナリアデプロイ実践中︕︕ 以下のようなイメージの状態になりました。本セッションのブログのURL

Service、Web App for Containers 23 注意点があります︕︕ 本セッションのブログのURL

Service、Web App for Containers 24 スワップした際に引き継がれる設定とそうでない設定があります。これに注意しないと、スワップしたときに思わぬ動作をすることがあります。設定が引き継がれるタイミングは2つあります。新規にスロットを作成したときに、親のスロットから引き継がれるスロットをスワップしたときに引き継がれる本セッションのブログのURL

Service、Web App for Containers 25 以下のそれぞれのユースケースで挙動を⾒てみます。 • バックアップ • スロットを新規作成した場合 • スロットをスワップした場合 • アクセス制限 • スロットを新規作成した場合 • スロットをスワップした場合本セッションのブログのURL

Service、Web App for Containers 26 バックアップ【スロットを新規作成した場合】 App ServiceやWeb App for Containersには、その中のファイルをバックアップする機能があります。

Service、Web App for Containers 27 バックアップ【スロットを新規作成した場合】ではスロットを作成してみます。その際、忘れずに「次から設定を複製」で複製元のスロットを選択して下さい。本セッションのブログのURL

Service、Web App for Containers 28 バックアップ【スロットを新規作成した場合】複製したスロットを⾒てみます。複製されていませんね。バックアップを取りたいのはだいたい運⽤スロットのみだと思うので、妥当な動作かなと思います。

Service、Web App for Containers 29 バックアップ【スロットを新規作成した場合】今の状態をイメージにすると、こんな感じですね。本セッションのブログのURL

Service、Web App for Containers 30 バックアップ【スロットをスワップした場合】では、先程の状態からスワップして⾒てみましょう。まずは運⽤スロットから。なるほど、スワップしても運⽤スロットの設定は変わらないですね。

Service、Web App for Containers 31 バックアップ【スロットをスワップした場合】次はステージングスロットです。ステージングスロットも変わらずバックアップされない設定になっていますね。

Service、Web App for Containers 32 バックアップ【スロットをスワップした場合】つまりイメージにすると右図のような感じなのですが、たしかにスワップしたときにバックアップの設定もスワップされてしまうと、今までバックアップを取っていた運⽤スロットがスワップ後にバックアップ取られなくなったとかなると、もう⼤騒ぎです(汗) 本セッションのブログのURL

Service、Web App for Containers 33 アクセス制限【スロットを新規作成した場合】 App ServiceやWeb App for Containersには、IPアドレスでアクセス制限をできます。右図のような制限を設定していた場合に、スロットを新規作成した場合を⾒ていきましょう。スロットの新規作成⽅法は先程と同じ⼿順です。

Service、Web App for Containers 34 アクセス制限【スロットを新規作成した場合】今のイメージはこんな感じです。本セッションのブログのURL

Service、Web App for Containers 35 アクセス制限【スロットを新規作成した場合】ではスロットを新規作成して、複製されたスロットを⾒てみましょう。まずは運⽤スロットからですが、設定が複製されています。

Service、Web App for Containers 36 アクセス制限【スロットを新規作成した場合】つまりこういう今の状態は右図のとおりとなっています。

Service、Web App for Containers 37 アクセス制限【スロットをスワップした場合】次はスロットをスワップした場合です。両⽅のスロットとも同じ設定が⼊っていて、この状態でスワップしても差がわからないので、運⽤スロットの設定を削除して以下のような状態にしてみます。

Service、Web App for Containers 38 アクセス制限【スロットをスワップした場合】ではスロットをスワップしてみて、運⽤スロットの⽅から⾒てみましょう。うん、アクセス制限設定なしですね。

Service、Web App for Containers 39 アクセス制限【スロットをスワップした場合】ステージングスロットは先程と変わらずアクセス制限設定ありです。

Service、Web App for Containers 40 アクセス制限【スロットをスワップした場合】つまり変わらずこういう状態です。そらそうですよね。例えば、ステージングスロットのみに施していたアクセス制限が運⽤スロットに反映されてしまったら、いきなりアクセスできなくなるユーザーがたくさん出て⼤騒ぎになります。本セッションのブログのURL

Service、Web App for Containers 41 まとめますと以下です。スワップするときは何が引き継がれて何が引き継がれないのか⼗分注意する。スワップされる設定の詳細については以下の公式ドキュメントにて︕︕ https://docs.microsoft.com/ja-jp/azure/app-service/deploy-staging-slots#which-settings- are-swapped

© SIOS Technology, Inc. All rights Reserved. 最後に︕︕ 42 本セッションの
ブログのURL App ServiceやWeb App for Containersによる⾊んなリリース⽅法(Blue-Greenデプロイやカナリアリリース) https://tech-lab.sios.jp/archives/22822 App ServiceやWeb App for ContainersでのカスタムドメインのSSL https://tech-lab.sios.jp/archives/23123 Azure App ServiceのVNet統合 https://tech-lab.sios.jp/archives/22563 関連ブログ

App ServiceやWeb App for Containersによる今どきのナウいリリースについて(Blue-Greenデプロイとかカナリアリリースとか)/appservicedeploy

App ServiceやWeb App for Containersによる今どきのナウいリリースについて(Blue-Greenデプロイとかカナリアリリースとか)/appservicedeploy

More Decks by Noriyuki TAKEI

Other Decks in Technology

Featured

Transcript