Updated: 2020/02/05
このハンズオンでは、Azure DevOps と Azure Web App を使い、Microsoft が提供している DevOps プロセスを一貫して体験いただきます。
- 準備
- Azure Web App を Azure にプロビジョ二ング
- Azure DevOps のプロジェクトを作成
- Azure Pipelines にビルドパイプラインを作成
- Azure Pipelines にリリースパイプラインを追加し、基本的な CI/CD を実現する
- Azure Pipelines のリリースパイプラインに Staging 環境へのデプロイプロセスを追加
- Azure Repository からコードを変更し、コミットをトリガーに CI/CD が走り出すことを確認
- Azure Web App の機能で遊ぶ
お客様に高い価値を提供するためには、新しいテクノロジーやエンドユーザーのフィードバックを迅速にサービスに反映し続け、 それと同時に、サービス品質を高水準に保ち続ける必要があります。そのためには開発からデリバリまでのプロセスを自動化し 継続的に価値が提供できる環境を作らなくてはなりません。 このハンズオンでは Azure における 開発からリリースまでのプロセス最適化をご体験いただけます。
- Azure Subscription
- 当ハンズオン資料 https://github.com/yuhattor/DevOpsHandson
- Azure Portal https://portal.azure.com
- Azure DevOps https://dev.azure.com/
この章では Azure App Service をまずデプロイします。
-
Azure Portal (https://portal.azure.com) にアクセスします。
-
ホームページに App Service があるので、作成していきます。
-
追加/Add ボタンから 新しい App Service を追加します。
-
リソースグループを追加します。リソースグループの名前は任意の名前で良いですが、同一サブスクリプションの中でかぶらないようにします。当ハンズオン では、例として XX の値を置いておりますが、XX はご自身の ID や ニックネームなどで置き換えてください。
-
Web App の名前を定義します。また、デプロイモデルは コード/Code を選びます。Web App における最も簡単なデプロイ方法の一つで、.NET や Java など、様々な言語・フレームワークのアプリケーションをそのまま配置することができます。今回のハンズオンでは OS は Windows を選びましょう。
-
App Service Plan を作成します。この App Service Plan とは、 Web App など、App Service にデプロイされるインスタンスの課金単位になります。
-
App Service Plan の値を入力したら、モニタリングの設定に移ります。
-
Application Insights をデプロイするための設定に移ります。 Application Insights とは開発者や DevOps プロフェッショナル向けの拡張可能なアプリケーション パフォーマンス管理 (APM) サービスです。 初期設定で 値が入っていますが、任意の名前と場所を決定したら OK で確定します。入力する値は以上ですので、この後は入力内容の確認に移ります。
-
表示された内容で間違いがない場合、Web App をデプロイします。
-
数十秒待つと Web App がデプロイされますので、デプロイされたリリースを確認しにいきます。
-
Web App の画面に到達したらホーム画面にある URL をクリックして、デプロイされたものを確認します。
-
Web App の初期画面 が表示されたことを確認します。
-
App Service / Web App とは？ https://azure.microsoft.com/ja-jp/services/app-service/web/
-
Resource Group とは https://tech-blog.cloud-config.jp/2019-06-06-evening-azure-challenge-002/
-
App Service と App Service Plan の違いって？ https://www.cloudou.net/app-service/app001/
-
Application Insights とは？ https://docs.microsoft.com/ja-jp/azure/azure-monitor/app/app-insights-overview
この章では Azure DevOps のアカウントを作成し、ハコとなるプロジェクトを作ります。
- Azure DevOps のページにログインします (https://dev.azure.com)
- 初回ログインの際には名前を入力する必要があります。
- Continue で初回登録を完了します。すると、初期 Organization が設定されます。
- プロジェクトを作成する画面に映りますので、最初のプロジェクトを作成しましょう。プロジェクト名は任意です。
プロジェクトは Private か Public を選ぶことができます。
- プロジェクトができたらクリックしてプロジェクトページにアクセスします。
既存の組織がある場合
- もし既存の組織がある、また以前に Azure DevOps を使っていた場合は、ログイン後そのまま該当の組織において新しいプロジェクトを作ります。
また、新しく組織を作る場合は New Organization から新しい組織を作ります。
- Continue で先に進み必要事項を記入します。
- 組織名を入力する必要がありますが、この値はユニーク値にする必要があります。
この章では Azure Repos にソースコードを追加し、最初のパイプラインを作っていきます。
今回は ASP.NET で作られた 仮のショッピングサイトのアプリケーションを Azure DevOps でデプロイします。
-
下準備として、Azure DevOps の Azure Repos にアプリケーションのソースコードをストアします。GitHub のページから
git cloneして Azure Repos にプッシュする方法でもいいですが、既存のリポジトリをインポートする方法があります。今回は GitHub に公開されているリポジトリをインポートするところから始めます。 -
Azure Repos に下記のリポジトリをインポートします。 https://github.com/yuhattor/DevOpsHandson
-
インポートが完了するとインポートされたリポジトリに自動でリダイレクトされます。
-
リポジトリが正しくインポートされたことを確認します。
-
次に Azure Pipelines の基本的な CI/CD の設定を確認していきます。Azure Pipelines のメニューより 新しいパイプラインを作成します。
-
Azure Pipelines の最初の設定として、パイプラインを動かす際にトリガーとなるリポジトリを選定します。規定の設定だと、これらのリポジトリに何か変更が加えられるとパイプラインが起動するようになります。先ほどアプリケーションのソースコードをインポートした Azure Repos を選択します。
-
リポジトリを選択します。
-
このリポジトリには Azure Pipelines の定義の雛形が入っています。 Azure Pipelines では一般的な言語・フレームワークのビルドパイプラインのテンプレートを多く用意しています。一から yaml ファイルを書き始めるのではなく、テンプレートを使うと便利です。 また、これらの yaml ファイルの設定には GUI のアシスタントを使うことができます。右上の Show Assistant ボタンでアシスタントを呼び出します。
-
試しに Bash のコマンドをビルドパイプラインのタスクとして追加します。検索ボックスに bash と打ち込み検索をします。
-
単純な echo コマンドを追加します。これらのタスクから
azコマンドを呼び出すことで パイプラインの機能を強化することも可能です。 このハンズオンでは 35 行目に Add でこれらのタスクを追加します。単純に追加してインデントが合わない場合、Azure Pipelines のエディタがエラーを吐くため、 tab キーを押してインデントを追加します。Azure Pipelines のエディタを用いて編集することにより、最低限の構文チェックをすることができます。 -
続いて、既存のタスクを GUI エディタで編集します。VSTest@2 の
Settingsをクリックし、アシスタントを呼び出します。 Collect advanced diagnostic in case of catastrophic failures のチェックをオンにし、致命的なエラーが起こった場合の診断ログを取得する設定にします。チェックをつけ終わったら Add で更新します。 -
もとのタスクが更新されました。これでビルドの設定は終了です。
-
Save and run で構築したビルドが動くか確認します。
-
Azure Pipelines の定義ファイルは ソースコードリポジトリに保存されるため、この Save とは、リポジトリに commit して、既存の azure-pipelines.yml ファイルを更新することをさします。
-
ビルドが走り出します。
-
(Optional) ビルドの次に Bash のタスクを定義した結果もこの画面から確認することができます。
- App Pipelines とは？ https://azure.microsoft.com/ja-jp/services/devops/pipelines/
この章では Azure Pipelies にリリースパイプラインを作り、App Service につなげます。
-
続いて、リリースパイプラインを構築していきます。 リリースパイプラインは Pipelines 配下の Releases から設定します。New pipeline でパイプラインを新規作成します。
-
今回は、ビルドした成果物を App Service のうえにデプロイするため、Azure App Service deployment の雛形を使います。
-
まずは、検証環境の staging という名前のリリースパイプラインを作ります。この Staging には、前の画面で選択した Azure App Service deployment の雛形が適用されており、アプリを App Service にデプロイするための初期設定が完了しています。 1job 1task をクリックして、デプロイ先の設定を開始します。
-
Azure DevOps から Azure のサービスにアプリケーションをデプロイする際には Azure DevOps と Azure の環境を紐付ける必要があります。紐付けたいサブスクリプションを選んだら Authorize ボタンより、紐付けを行います。
-
サブスクリプションの連携が完了したら Resource Group と App Service を選択します。これでビルドされたアプリを App Service にデプロイする準備が整いました。 パイプラインの View に戻り、続きの設定を行います。
-
こまで Build パイプライン、Release パイプラインをそれぞれ作成しました。一方でこれらの パイプラインは必要に応じて複数作ることができるため、これらの2つのパイプラインは n:n の関係を持つ可能性があります。 そのため、どの Build パイプライン と Release パイプラインが繋がるべきなのか Azure Pipelines は知らないため、関連付けの設定をする必要があります。 ここでは、Pipeline View より、Build が完了した際のバイナリファイルやzipファイルを取得する設定をします。Add an artifact より前段階で設定した Build Pipelines の成果物を追加します。
-
Build を選択し、先ほど設定した Build Pipeline がソースになっているか確認します。このハンズオンようにプロジェクトを作成している場合、初期設定から変える必要はありません。
-
追加したら続いて、トリガーの設定に移ります。この段階では Build パイプラインと Release パイプライン が紐づいただけですが、次は Azure Pipelines 側に "いつ" このリリースパイプラインを起動させるか知らせる必要があります。 Continuous deployment trigger を enabled にし、ビルドが終わり、成果物ができた瞬間に Release パイプラインを起動するようにします。
-
設定したら Save で保存します。
-
パイプラインの変更を保存します。
-
ここまでの設定で、Repository の master ブランチに何か変更を加えた際に Build パイプラインが動き出し、それが終了したら Release パイプラインが起動する設定になりましたが。 まずは Release パイプラインが正しく動くか確認するため、手動で新規アプリケーションを App Service にデプロイします。Create release は特定のアプリケーションの Build ID に紐づく成果物(バイナリ) を指定して、Release パイプラインを動かし、リリースするための方法です。
-
先ほど Build は終了しているはずなので、該当する Version がリリースされることを確かめ、Release パイプラインを起動します。
-
リリースが開始されたら、リアルタイムでステータス確認が可能です。
-
リリースが成功したら、Web App のページにアクセスし、サンプルアプリケーションがデプロイされていることを確認します。
この章では Azure Pipelies に Staging 用のリリースパイプラインを作り、App Service の Staging 環境につなげます。
-
これまでのプロセスで一番基本的な CI/CD のパイプラインが作成されました。次はそれをもう少し高度なものにしていきます。 この章では 該当アプリケーションがまず Staging 環境にデプロイされ、内部ユーザーが挙動を確認したのち、承認プロセスを経てプロダクション環境にデプロイされるような設定をします。 まずは Edit より Release パイプラインの設定を再度開始します。
-
これまで設定してきた Release パイプラインが表示されたら、Staging にデプロイするための設定を複製します。Clone ボタンを使うことで、既存の設定を流用して楽に新しい環境へのデプロイ設定が定義的ます。
-
複製されたら、ステージの名前も変更します。staging -> prod の順番でデプロイされる設定にするため、複製したステージの名前は "prod" にします。
-
この段階では、Azure Pipelines 側には staging と prod の設定が定義されましたが、一方でまだ Azure 側には １つの環境しかありません。デプロイ先の App Service にも staging と prod が必要ですので、Azure 側でも新しい環境を作ります。 App Service で新しい環境を作るのはとても簡単です。スロット を追加することで全く同じ設定の複製環境を作ることができます。 App Service のメニューから スロットを追加します。
-
新しく staging スロットを作ります。2個目をつくることで、この App Service は staging と prod の区別をつけてアプリケーションをデプロイすることができるようになります。 スロット作成の際に、アプリケーションの設定を複製するようにします。この設定には Web.config や 環境変数が定義されています。
-
スロットの作成に成功したら、staging スロットの Azure Portal の設定をみてみます。
-
staging / prod の環境はほぼ一緒なので一見区別がつきにくいですがg、大きな違いは URL です。staging と名付けたスロットの URL には、 -staging の名前空間が postfix として追加されます。
-
この URL にアクセスすると 空のアプリケーションが表示されます。
-
これで Azure 側の環境は整いました。Azure DevOps の設定に戻り、staging の環境にまずアプリがデプロイされ、その後の承認を経て prod の環境にアプリがデプロイされる設定の続きをします。
-
staging ステージのパイプラインの設定を開き、 Deploy Azure App Service のタスクの Deploy to Slot のチェックをオンにし、続いて対象スロットも staging に設定します。値が更新されない場合は右の更新ボタンから値を更新します。
-
設定が終了したら Pipelines の View に戻ります。この段階で、Release パイプラインの staging ステージからは App Service の staging スロットにデプロイされ、Release パイプラインの prod ステージからは App Service の prod (何にも設定していない規定のスロット) にデプロイされるようになっています。
-
この段階では、まだ承認プロセスの設定をしていないので、staging にデプロイが完了した直後に prod へのデプロイも開始してしまう設定になっています。 Pre-deployment 承認者の設定により、prod のデプロイプロセスが承認なしでは起動しないようにします。 Pre-deployment approval のトグルをオンにし、 Approvers にユーザーを追加します。このハンズオンでは Approver は自分に設定します。
-
設定が完了したら Save します。
これで、全ての処理が完了しました。それでは全体の CI/CD パイプラインが正しく動くか確認します。
-
Build パイプラインを起動するため、Azure Repos の簡易エディタを使い、ファイルに変更を加え変更をコミットします。
-
わかりやすい任意のファイルを変更します。この例では Source > Tailwind.Traders.Web > ClientApp > src > assets > locales > translation.json を変更しています。
-
�変更したら master ブランチにコミットします。
-
コミットしたら、Build パイプラインの画面で、パイプラインが動き出したか確認します。
-
Build パイプラインが終わったら、Release パイプラインが起動したか確認し、staging に無事アプリケーションがリリースされたことを確認します。同時に prod にはデプロイされていないことを確認します。
-
prod 環境には変更が加わっておらず、 staging 環境には変更が加わったことを確認します。
この段階では、staging 環境には新しいアプリケーションがデプロイされ、prod には古い環境がデプロイされたままになっている状態になっています。 このタイミングでスロットの他の機能を試します。
-
ABtest / Test in Production App Service の prod 環境の画面に戻り、スロットごとの トラフィック % を設定します。 これにより、abtest / Test in production の環境を実現することができます。 このハンズのではそれぞれ の割合を 50% に設定し、prod 環境の url にきたレスポンスがそれぞれ半分ずつ 2つのスロット(今回の場合 prod とstagin) に分散される設定にします。 AB test の実現で、プロダクションの環境でタイプの異なるアプリケーションや新旧アプリケーション両方を運用し、それぞれのユーザーの反応をみてリリース戦略に役立て流ことができます。また、Test in production では安定しているとは言えない新しい機能を小規模なユーザーで試し、次第に展開の�%を上げていくことにより、リスクの少ないリリースを実現することができます。 App Service はセッションスティッキーなので、新しいブラウザやシークレットブラウザを起動して prod の URL のままで２つの異なるサイトに分散されているかを確認します。
-
スロットスワップ また、URL をそのままにして、staging の内容を prod の内容と入れ替える方法として スロットスワップ の機能が用意されています。 スワップの画面からソースとターゲットを決めて入れ替えます。
-
App Service 認証 App Service には GUI の簡単な操作でデプロイされているアプリケーションを AAD で保護する機能が用意されています。
-
設定を保存したら AAD のクレデンシャル情報がない シークレットブラウザで、App Service のアプリケーションの URL を開きます。 App Service はログインできなくなります。