App Service の CI/CDでビルドエラー

2017/06/16 / buchizo / コメントする

ちょっとはまったのでメモ。（そのうち改善されると思われる）

はまった環境: Visual Studio 2017 で .NET Framework 4.6.2 なクラスライブラリでNuGetなパッケージを使用しているC#プロジェクト（NuGetはPackageReferenceを参照する）と、それを参照するASP.NETなアプリ（1つのソリューションにASP.NETとクラスライブラリなプロジェクトがある状態）
はまった理由: App Service上（Kudu上）で msbuild 15.x がないから（たぶん）

普通にApp Service上でCI/CDを使って（今回はLocal Git）上記なプロジェクトをデプロイ（git push）すると以下のようにNuGetで取得するパッケージに含まれるアセンブリが見つからない旨のエラーがでてビルドに失敗します。（nuget restoreやdonet restoreしてるにも関わらず）

省略
:
remote: D:\Program Files (x86)\dotnet\sdk\2.0.0-preview1-005977\Microsoft.Common.CurrentVersion.targets(1964,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "Newtonsoft.Json, Version=10.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed, processorArchitecture=MSIL". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors. [D:\home\site\repository\web1\Shared\Shared.csproj]
:
以下略

カスタムデプロイスクリプトを使用するようにして、dotnet build や dotnet msbuild を使ってもダメです。
※Kudu上に現状Previewなmsbuildがありますがそちらを使ってもダメ
※ちなみにプロジェクトがPackage.configを参照するようになってたら問題なくビルドできます。PackageReferenceの場合のみおかしい。

回避策: クラスライブラリなプロジェクトファイル（.csproj）を新しい形式に変換する

変換は以下のURLを参考に。

Old csproj to new csproj: Visual Studio 2017 upgrade guide

最低限Project要素の属性を新しくして TargetFrameworkVersion を TargetFrameworkにしてv.4.6.2 とかを net462 とかにします。あとは不要な要素はバスバスけして、AssemblyInfo.csも消したりしました。
修正後、Visual Studio 2017上でちゃんとプロジェクトがロードできてビルドできればひとまず大丈夫かと思います。（Minなcsprojにしてから後でNuGetパッケージ追加したりもろもろいじってもよいかと思います。

変換後は dotnet build や dotnet publish で問題なくビルドできます。（つら）

過渡期な問題だと思いますが、もし嵌った人がいれば参考にしてもらえると。

App Serviceのトラブルシューティング用ツールがよくなりました

2016/04/19 / buchizo / 1件のコメント

もともと Azure App Service Support (Preview) で見れていたものがAzure Portal上でも見えるようになった感じです。
Azure App Service Support (Preview)については以前書いたのでそちらも参照ください。

またAzure App Service Web AppsなどをStandardで使ってる場合にVM毎のメトリックも見えるようになりました。

AppServiceのStandard以上でVMごとのメトリックが見れるようになりました！これは便利なのでぜひご活用ください！ #jazug #azurejp
—
帝国兵 (@superriver) April 18, 2016

例えばSmall VM 1つでPHPサイトを10個以上立ち上げてて、それぞれは100MB程度までしか使ってなくても合計だとメモリが足りなくなってたケースが時々あったのですが、今までのメトリックだけだと把握できませんでした。このアップデートでこの問題が解決されます。
—
帝国兵 (@superriver) April 18, 2016

最初にサイト単体のところはこんな感じで見えます。これは前からかな？

ちゃんとVM単位でも見れますね。

※たまたま途中でVMが入れ替わったようす

CPU時間と平均メモリワーキングセットも参照できますよ

ではApp Serviceプラン全体ではどうかというと「App Service plan Metrics per Instance」で見ることができます。

プラン全体の概要

（そのプランに含まれる）サイト単位でのCPU・メモリ、HTTPの状態やネットワークの状態など

緑色のサイト名のところでOn/Offできるので、どのサイトに負荷が掛かってるか（圧迫してるか）などを簡単に把握できますね。もちろん上部のVM名のタブで複数インスタンスある場合にどのVMが、というのも調べられます。

その他ライブモニターや診断ログの取得などもポータルでできるのでApp Serviceについてはかなりのことがポータル単体で把握でき、対処できるようになりました。いい感じです。

App Service Environmentでバックエンドと通信できない

2016/03/04 / buchizo / コメントする

App Service Environment（日本語名：App Service 環境）を使うとVNET（v1）※現状に接続することができます。
普通のApp Serviceと違ってClosedな環境にしたり、VNETにつなげられるということはVPNであれこれしたりできるわけです。

なので内部用で外には公開したくないSQL Serverな仮想マシンとかVNET参加させたRedis（Premium）とかと合わせて完全VNETオンリーな環境が作れるわけですが、VNETの注意点として以下のように記載されています。

App Service 環境からバックエンドリソースへの安全な接続
App Service 環境から仮想ネットワーク内のエンドポイントへの送信トラフィックには、注意すべき点が 1 つあります。App Service 環境から、App Service 環境と同じサブネットにある仮想マシンのエンドポイントに到達することはできません。App Service 環境が、App Service 環境専用として予約されているサブネットにデプロイされていれば、通常、これは問題にはなりません。

クラシックなVNET（v1）の制限なのかNSGの制限なのか、はっきりとわかりませんでしたがApp Service Environmentと同じサブネット上の他の機器とうまく通信できないようです。

なので教訓としてApp Service Environmentは専用Subnetに配置しましょう。（作るのが大変なのでこちらを専用化したほうが楽でしょう。CIDRの都合もあるかもしれないし）

さてさて、そうは言ってもそこを何とかならないですか？というのが世の常ですね。
一応泥臭い回避策はないことはないのですが、、、

簡単に言うとApp Service EnvironmentのWorkerPoolであるWeb Appsの設定で明示的にVNETに参加させるという感じです。
この機能そのものは通常のApp Serviceでもある機能で、VNETにPoint to Site接続でVPN接続する機能です。

同じVNETにいるくせにVPNを張らないといけないとは！ｗ（おまけにPoint to Siteの設定がVNET側にも必要です）
ということで結局大変でしかも余計な口ができてしまうので、あきらめて作り直したほうがいいかと思います。

まとめ

ネットワークの設計は慎重に。ドキュメントは穴があくほど見まくりましょう。

ブチザッキ

いわゆる雑記

App Service