Azure Key Vaultは安全に保管したいキーや証明書などをREST APIでアクセスすることができるAzure上のサービスです。
キーにアクセスするための権限を細かく管理したり、そもそもキーや証明書の管理操作を開発者などから分離して集中管理することができるようになります。監査などもあるので便利です。
このエントリでは .NET Core 2.0 / ASP.NET Core 2.0 でKey Vaultの証明書を利用する方法を簡単にまとめます。
Azure Key Vaultは安全に保管したいキーや証明書などをREST APIでアクセスすることができるAzure上のサービスです。
キーにアクセスするための権限を細かく管理したり、そもそもキーや証明書の管理操作を開発者などから分離して集中管理することができるようになります。監査などもあるので便利です。
このエントリでは .NET Core 2.0 / ASP.NET Core 2.0 でKey Vaultの証明書を利用する方法を簡単にまとめます。
いつくるかなーと待ってたApp Service on Linux と Web Apps for Containers が GAしました。
概要はこちらも参照。
App Service on LinuxのほうはCI/CDやスロットなどもろもろApp Serviceの機能はもちろん、SSHサポートとかもあります。詳しくはしばやん雑記を参照。日本の東西リージョンでも使えるしすぐに本番で使えますね。
なおApp Service on Linux と Web Apps for ContainersはFree/Sharedプランでは使えないようです。
今後もいろいろ楽しみです。
ちょっとはまったのでメモ。(そのうち改善されると思われる)
はまった環境: 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 で問題なくビルドできます。(つら)
過渡期な問題だと思いますが、もし嵌った人がいれば参考にしてもらえると。
そろそろ移動&寝ようと思ってた矢先に我らが帝国兵殿から矢文が届きました。
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公開されました。さっそくしばやん先生が触ってるのでそっちもどうぞ。
でも良い子のみんなはちゃんと公式ドキュメントをまず見ましょう。
もともと 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が入れ替わったようす
ではApp Serviceプラン全体ではどうかというと「App Service plan Metrics per Instance」で見ることができます。
プラン全体の概要
(そのプランに含まれる)サイト単位でのCPU・メモリ、HTTPの状態やネットワークの状態など
緑色のサイト名のところでOn/Offできるので、どのサイトに負荷が掛かってるか(圧迫してるか)などを簡単に把握できますね。もちろん上部のVM名のタブで複数インスタンスある場合にどのVMが、というのも調べられます。
その他ライブモニターや診断ログの取得などもポータルでできるのでApp Serviceについてはかなりのことがポータル単体で把握でき、対処できるようになりました。いい感じです。
App Service Certificate というのが増えてました。Azure 上でApp Service用のSSL証明書をGoDaddyから簡単に購入して利用することができます。
わかりにくいですが、S1だとネイキッドドメインとwww. に対応した証明書のみ、W1でワイルドカード証明書が発行されます。
(後述)
ドメインの確認が必要とはいえAzure上で証明書の購入プロセスが完了して、Azure Key Vaultで安全に保管しながら利用できるのは便利ですね。
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を張らないといけないとは!w(おまけにPoint to Siteの設定がVNET側にも必要です)
ということで結局大変でしかも余計な口ができてしまうので、あきらめて作り直したほうがいいかと思います。
ネットワークの設計は慎重に。ドキュメントは穴があくほど見まくりましょう。
帝国兵殿から正確な発音はくーどぅーじゃねと言われ衝撃を受けつつAzure App Serviceのサポートツールの話でもしたいと思います。
以前のPostで8月中にAzure App Serviceで.NET Framework 4.6が使えるように~という話がありましたが、今日ロールアウトされて利用できるようになりました。
Azure Web Apps are now running .NET Framework 4.6 (portal still says 4.5 and just needs a string update). #azure #azureappservice
—
David Ebbo (@davidebbo) August 14, 2015
これで安心して(?).NET Framework 4.6使えますね。ちなみにRyuJITは今のところ無効化されてるようです。
@bradygaster @jglozano It has RyuJIT disabled, so you won't see that bug.
—
David Ebbo (@davidebbo) August 14, 2015
安定して利用できるようになるのを待ちましょう。
今更ですけど、「北陸新幹線開通記念! 北陸・信州合同勉強会」でLTしてきました。
ネタはApp Serviceがらみです。ざっくり概要。それより筏井さんの後とかハードル高かったですね。
全体としてはHackforPlayとか知れたり、やっぱ高専とか若い人の活力っていいなーって思いました。うらやま羨望な眼差しで見てました。あと地場の人の吸引力というのは大事だなと思いました。(自分はどうなんだろうと振り返りつつ)
反省点は5分キッチリ終わらなくても大丈夫っていう油断があると5分で終わらせる気が全くないところですかね。。あとアイコン詐欺してますはい。 # あかん
なんにせよ皆さん楽しそうでよかったです!