Azure Key Vaultは安全に保管したいキーや証明書などをREST APIでアクセスすることができるAzure上のサービスです。
キーにアクセスするための権限を細かく管理したり、そもそもキーや証明書の管理操作を開発者などから分離して集中管理することができるようになります。監査などもあるので便利です。
このエントリでは .NET Core 2.0 / ASP.NET Core 2.0 でKey Vaultの証明書を利用する方法を簡単にまとめます。
App Service
Azure App Service on Linux と Web Apps for Containers が GA
いつくるかなーと待ってたApp Service on Linux と Web Apps for Containers が GAしました。
- General availability of App Service on Linux and Web App for Containers
- Microsoft’s Azure App Service developer platform now available on Linux
- App Service on Linux と Web App for Containers が GA したらしい
概要はこちらも参照。
App Service on LinuxのほうはCI/CDやスロットなどもろもろApp Serviceの機能はもちろん、SSHサポートとかもあります。詳しくはしばやん雑記を参照。日本の東西リージョンでも使えるしすぐに本番で使えますね。
なおApp Service on Linux と Web Apps for ContainersはFree/Sharedプランでは使えないようです。
今後もいろいろ楽しみです。
App Service の CI/CDでビルドエラー
ちょっとはまったのでメモ。（そのうち改善されると思われる）
はまった環境: 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を参考に。
最低限Project要素の属性を新しくして TargetFrameworkVersion を TargetFrameworkにしてv.4.6.2 とかを net462 とかにします。あとは不要な要素はバスバスけして、AssemblyInfo.csも消したりしました。
修正後、Visual Studio 2017上でちゃんとプロジェクトがロードできてビルドできればひとまず大丈夫かと思います。（Minなcsprojにしてから後でNuGetパッケージ追加したりもろもろいじってもよいかと思います。
変換後は dotnet build や dotnet publish で問題なくビルドできます。（つら）
過渡期な問題だと思いますが、もし嵌った人がいれば参考にしてもらえると。
App Service on Linux (Preview)
そろそろ移動＆寝ようと思ってた矢先に我らが帝国兵殿から矢文が届きました。
AzureでPHPとNode.jsがLinuxで動くPaaSをPreview始めました。まだリージョン狭めです。ついに、ですな。 ift.tt/2cYHciB
—
吉田パクえ (@yuya_lush) October 04, 2016よーーーやくアナウンスできました。だいぶ前から作ってましたが言えませんでした @kanreisa @kosmosebi @shibayan
—
帝国兵 (@superriver) October 04, 2016ということでApp ServiceのLinux版がPreview公開されました。さっそくしばやん先生が触ってるのでそっちもどうぞ。
でも良い子のみんなはちゃんと公式ドキュメントをまず見ましょう。
App Serviceのトラブルシューティング用ツールがよくなりました
もともと 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 Certificate
App Service Certificate というのが増えてました。Azure 上でApp Service用のSSL証明書をGoDaddyから簡単に購入して利用することができます。
- How to buy a certificate for an Azure Web App
- Buy and Configure an SSL Certificate for your Azure App Service
- 価格ページにはちょろっと追記されています。
わかりにくいですが、S1だとネイキッドドメインとwww. に対応した証明書のみ、W1でワイルドカード証明書が発行されます。
（後述）
ドメインの確認が必要とはいえAzure上で証明書の購入プロセスが完了して、Azure Key Vaultで安全に保管しながら利用できるのは便利ですね。
App Service Environmentでバックエンドと通信できない
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側にも必要です）
ということで結局大変でしかも余計な口ができてしまうので、あきらめて作り直したほうがいいかと思います。
まとめ
ネットワークの設計は慎重に。ドキュメントは穴があくほど見まくりましょう。
