Azure App Service の継続的配信(プレビュー)を試してみました
Azure App Service の継続的配信(プレビュー)
最近あまり触れていなかったASP.NET系の技術にそろそろじっくり取り組んでみようかな、と思う今日この頃。
ASP.NET Core & Azure App Service で何か作ろうとAzureポータルを触っていると、App Serviceのメニューに「継続的配信(プレビュー)」なる項目を見つけました。
今回はこれを試してみたいと思います。
どんな機能か
Visual Studio Team Service (VSTS)を利用して、Azure App Serviceへの継続的配信(Continuous Delivery)を行うためのワークフローを構成してくれる機能です。
これを使用することで、GitのリポジトリにコードをPushするだけでVSTSのビルドタスクが走り、コードの取得→ビルド→Unitテスト→デプロイ といった一連の流れを自動化できるようになります。
配信元のソースはVSTSのGit リポジトリ以外にもGitHubのリポジトリが指定できます。(その他、GitやSVNのプライベートなリポジトリを指定することもできるようです。)
事前準備
では、早速試してみましょう。今回はGitHubのリポジトリと連携させてみます。
サンプルアプリケーション
今回サンプルとして使用するアプリケーションは、Visual Studio 2017のASP.NET Coreのプロジェクトテンプレートを使用して作成したものを使用します。
- [ファイル]-[新規作成]-[プロジェクト]で「ASP.NET Core Webアプリケーション(.NET Core)」を選択します。
- ターゲットフレームワークに「ASP.NET Core 1.1」、テンプレートは「Web API」としました。
- 「Dockerサポートを有効にする」なるチェックボックスがありますが、今回はOFFで作成します。
こうして作成したWebAPIのアプリケーションを、そのままGitHubに上げておきます。
VSTSでプロジェクトを作成
Visual Studio Team Service(VSTS)で、このアプリケーション用のプロジェクトを予め作成しておく必要があります。
VSTSのアカウントがない場合は、以下で作っておきましょう。
アカウントの準備ができたら、プロジェクトを作成しておきます。ここではとりあえずプロジェクト名を決めて作成するだけでOKです。
Azure App Serviceを作成
Azureポータルで、アプリケーションを配置するApp Serviceを作成しておきます。
ここで注意が必要なのは、今回の継続的配信機能を使用するためには、Standerd(S1)以上のサービスプランを選択する必要があるという点です。
Freeプラン(F1)では使用できないので気を付けてください。
継続的配信(プレビュー)の設定
これで下準備は整いました。早速Azureポータルで「継続的配信(プレビュー)」を使ってみましょう。
詳しい手順は、以下のページ(英語)に掲載されていますので、こちらを参考に進めて頂ければ問題ないと思います。
動かしてみよう
これで必要な設定はすべて完了し、GitHubにPushするだけで最新のアプリケーションがApp Serviceに配置されるはずです。
はずなのですが・・・
ビルドに失敗します
GitHubへのPushをトリガーにVSTSのビルドタスクが動くところまでは問題なかったのですが、そのままではビルド自体が失敗してしまっていました。
VSTSのサイトで、今回のプロジェクトを開いてビルドタスクの設定を確認してみます。
ビルドタスクの設定は「Build&Release」タブで確認できます。
- ビルド設定名部分のリンクをクリックして
- Editをクリックすると、以下のようなビルドタスクの設定画面が表示されます。
ビルドタスクの設定を見直す
既定では、ASP.NET Core(PREVIEW)というテンプレートが使用されるようなのですが、そのままではうまくいきませんでした。
更に、各タスクの設定等を変えていろいろ試してもみたのですが、解決しませんでした。
そこで、ASP.NET Core(PREVIEW)のテンプレートを使うのは止めて、以下のページに掲載されている内容で試してみたところビルドが通るようになりました。
「Get Sources」を除く既定のタスクを全て削除し、「+Add Task」で新しいタスクに置き換えていきます。
以下に設定内容のスクリーンキャプチャを載せておきます。
- Build Solution
Visual Studio Buildタスクを実行します。
- Test Assemblies
対象のリポジトリにテストプロジェクトが含まれる場合にテストを実行します。
- Archive Files
ビルド成果物をZIPに圧縮します。
- Publish Build Artifacts
ビルド成果物をサーバーに公開します。
Build Agentを変更する
もう1つ。ビルド設定画面で「Options」のタブを選択して、右側の「Default agent queue」を”Hosted”から”Hosted VS2017”に変更しておかないとうまくいきませんでした。
ここまで終えたら、ビルド設定画面の右上にある「Save & Queue」をクリックして、設定したタスクを実行してみます。
これで、ビルド成果物を作成するところまでは何とか動かすことが確認できたのですが、今度は次のフェーズで失敗してしまいます。
今度はデプロイに失敗する
ビルド成果物の作成が完了したら、Azure App Serviceへ実際に配置を行うReleaseのフェーズに移行するのですが、ここで次のようなエラーが発生して失敗してしまいます。
error: Web Deploy cannot modify the file - ERROR_FILE_IN_USE
どうやら、配置先のDLLがロックされていて上書きできないことが原因のエラーのようです。
※この問題は、GitHubのIssuesでも議論されていました。
VSTSで「Release」の設定を見てみると、以下の様になっていました。
- 「Deploy Azure App Service to Slot」でStaging用スロットにデプロイ
- それが成功したら「Manage Azure App Service - Slot Swap」で本番用のスロットにスワップ
という構成になっています。
今回は「Deploy Azure App Service to Slot」でファイルが上書きできずにエラーとなっていました。
これを解決するには、配置先のStagingスロットのサービスを一旦停止してからデプロイを実行する必要がありそうです。
Releaseタスクの設定を変更する
そこで、以下の様に「Deploy Azure App Service to Slot」の前後にサービスの停止、再開を挟むようにしてみたところ無事デプロイされるようになりました。
以下に設定内容を貼っておきます。
- Manage Azure App Service - Stop App Service
- Deploy Azure App Service to Slot
- Manage Azure App Service - Start App Service
Manage Azure App Service - Slot Swap
まとめ
非常に長くなってしまいましたが、ようやくこれでGitHubリポジトリからAzure App Serviceへの継続的配信の設定はひとまず完了です。
今回試したのはあくまでも(プレビュー)なので、(プレビュー)が取れた暁にはAzureポータルからポチポチと数クリックするだけで済むようになっているかもしれません。(涙目)