koudenpaのブログ

趣味のブログです。株式会社はてなでWebアプリケーションエンジニアをやっています。職業柄IT関連の記事が多いと思います。

Azure App ServiceのFreeやSharedプランでApp Service build serviceのデプロイに失敗した時にしていること

Microsoft AzureのPaaS、Azure App Serviceが好きでよく使っている。

アプリケーションのデプロイにはお手軽なApp Service build serviceを、使うことが多い。簡単な設定をするだけでリポジトリにPushした内容をビルド、デプロイしてくれてとても便利だ。

このデプロイ、(無料だったり安い)FreeやSharedプランではアプリケーションやデプロイの設定には問題がなくても失敗することがある。

そんなときは(App Serviceのリソースを使って動く)デプロイ処理によってサービスクォータの上限を超過していることが多い。概ねCPU、まれにストレージだ。

FreeやSharedプランはサーバーを占有ではなく複数ユーザーで共有しているため、単位時間内にどのくらいCPUを使用していいかや、ストレージの使用量に上限が定められている。

f:id:koudenpa:20200704184350p:plain
Azure Portalのクォータのページにしっかり書いてある

超過したのがCPU時間の場合、暫く待ってから再デプロイすればいい。

f:id:koudenpa:20200704185823p:plain
クォータを見るとリセットまでの時間を確認できる

ストレージ容量の場合、単に再デプロイではまた失敗するので、不要なファイルを消してから試す。Azure Portal上の高度なツールから過去のビルドやNuGetパッケージ(のキャッシュ)を消している。

f:id:koudenpa:20200704182918p:plain
高度なツール(Kudu コンソール)

f:id:koudenpa:20200704183202p:plain
`D:\home.nuget` 配下にNuGetパッケージがある

先日、.NET Coreのバージョンを2系から3系に上げたら一気に依存パッケージが増えてストレージ容量のクォータに引っ掛かってしまった。

FreeやSharedプランでホスティングしているアプリケーションのバージョンアップ時にはそんなこともある、と留意されたい。

f:id:koudenpa:20200704190002p:plain
ここが余裕の100%になっていた