C#、ASP.NET、TypeScript、AngularJS を中心にプログラミングに関した話題を諸々。
by @jsakamoto
検索
リンク
北海道のITコミュニティ - CLR/H 無聊を託つ
タグ
カテゴリ
最新の記事
ASP.NET Core S..
at 2017-10-30 22:29
ASP.NET Core 2..
at 2017-09-22 21:54
ASP.NET Core 1..
at 2017-09-08 23:04
Visual Studio ..
at 2017-09-08 21:42
Application In..
at 2017-08-30 23:15
最新のコメント
いえす、F#! F#! :)
by developer-adjust at 21:46
F#はAzure Not..
by 幻のK泉さん at 18:37
> 今、Setcronj..
by developer-adjust at 08:25
今、Setcronjob..
by Kibe at 03:23
Jichym 改め yi..
by yi at 23:00
バッチファイル(.bat..
by Jichym at 01:26
なるほど、そこにテコ入れ..
by developer-adjust at 21:25
キャッシュを制御するディ..
by Hallo Brother. at 13:08
おっと、これはぬかりまし..
by developer-adjust at 23:57
ClickOneのILs..
by 通りすがり at 14:13
記事ランキング
最新のトラックバック
Web API における..
from 松崎 剛 Blog
[Other]Code2..
from KatsuYuzuの日記
Developer @ ..
from .NET Clips
asp.netでrail..
from 4丁目より
F#でASP.NET M..
from ナオキにASP.NET(仮)
[B!] これはいい h..
from Twitter Mirror
[報告] Microso..
from .NET Clips
Developer @ ..
from .NET Clips
[F#]F# でブログア..
from 予定は未定Blog版
ASP.NET MVC ..
from ナオキにASP.NET(仮)
以前の記事
2017年 10月
2017年 09月
2017年 08月
2017年 07月
2017年 06月
2017年 05月
2017年 04月
2017年 02月
2017年 01月
2016年 12月
2016年 11月
2016年 10月
2016年 09月
2016年 08月
2016年 07月
2016年 06月
2016年 05月
2016年 04月
2016年 03月
2016年 02月
2016年 01月
2015年 12月
2015年 11月
2015年 10月
2015年 09月
2015年 08月
2015年 07月
2015年 05月
2015年 04月
2015年 03月
2015年 02月
2015年 01月
2014年 12月
2014年 11月
2014年 10月
2014年 09月
2014年 08月
2014年 06月
2014年 04月
2014年 03月
2014年 02月
2014年 01月
2013年 12月
2013年 10月
2013年 09月
2013年 08月
2013年 07月
2013年 06月
2013年 05月
2013年 04月
2013年 03月
2013年 02月
2013年 01月
2012年 12月
2012年 11月
2012年 10月
2012年 09月
2012年 08月
2012年 07月
2012年 06月
2012年 05月
2012年 04月
2012年 03月
2012年 02月
2012年 01月
2011年 12月
2011年 11月
2011年 10月
2011年 09月
2011年 08月
2011年 07月
2011年 06月
2011年 05月
2011年 04月
2011年 03月
2011年 02月
2011年 01月
2010年 12月
2010年 11月
2010年 10月
2010年 09月
2010年 08月
2010年 07月
2010年 06月
2010年 05月
2010年 04月
2010年 03月
2010年 02月
2010年 01月
2009年 12月
2009年 10月
2009年 09月
2009年 07月
2009年 06月
2009年 05月
2009年 04月
2009年 03月
2009年 02月
2009年 01月
2008年 12月
2008年 11月
2008年 10月
2008年 09月
2008年 08月
2008年 07月
2008年 06月
2008年 05月
2008年 04月
2008年 03月
2008年 02月
2008年 01月
2007年 12月
2007年 11月
2007年 04月
2007年 03月
2007年 02月
2007年 01月
2006年 11月
2006年 10月
2006年 09月
2006年 08月
2006年 07月
ファン
ブログジャンル
画像一覧
2017年 09月 08日

ASP.NET Core 1.1 アプリで、現在の要求が https 接続であるかどうかを判定する方法 - Docker 対応版

ブラウザと https で接続しているのかどうかを判定するには

ASP.NET Core 1.1 アプリにて、現在の要求が https 接続であるか否かを判定するには、要求クラス Microsoft.AspNetCore.Http.HttpRequestIsHttps プロパティを参照するとよい。

このプロパティが true であれば、クライアントとは https でつながっている、ということを示している。

IsHttps プロパティは、例えば ASP.NET Core MVC のアクションメソッド内などであれば、そのコントローラクラスの Request プロパティ経由で参照できる。
public class ProblemController : Controller
{
public ActionResult Index()
{
if (this.Request.IsHttps) {
// クライアントと https でつながっている場合にここに到達
....

このプロパティは Microsoft Azure の Web Apps Service に配置して実行されたときも、適切に true または false を返す。

たとえば foobar というアプリ名で Azure Web Apps 上に配置した場合、IsHttps プロパティは、

  • URL http://foobar.azurewebsites.net/ でアクセスした場合は false
  • URL https://foobar.azurewebsites.net/ でアクセスした場合は true

となる。

Docker コンテナ内では...?

ところが、である。

同じ ASP.NET Core 1.1 アプリを Docker イメージにパッケージし、この Docker イメージを Azure Web Apps on Linux や Heroku の Docker コンテナ機能で稼働させると、

  • Azure なら https://foobar.azurewebsites.net/
  • Heroku なら https://foobar.heroku.com/

の https スキーマの URL でアクセスしても、その要求を受け取った ASP.NET Core アプリ内では、IsHttps プロパティは常に false となってしまうのだ。

まぁたしかに、Docker コンテナ内では ASP.NET Core アプリは、ポート 80 番で TLS 暗号化されていない素の http 通信で動いてるに過ぎない。
そのいっぽうで外界とは https で通信できてるのは、ポートフォワーディングやロードバランサ、リバースプロクシといった、クラウドサービス側のインフラによって実現されてるからである。

そうである以上、Docker コンテナ内に棲息している ASP.NET Core アプリの立場としては、"クライアント" というのはそれらエッジ側に配置されたサービスのことであり、「え、クライアントとは暗号化通信なんかしてないんですけど?」といって IsHttps プロパティが false になるのも理解できる。

※Azure Web Apps も、実のところ ARR などがエッジ側にあるはずなのだが、そのあたりはうまく連携されているようだ。そのおかげで最終的に外界と HTTPS でつながっているのか否かをアプリ上で正しく判定できるっぽい。

とはいえ、このままでは「で、最終的にブラウザとは https でつながってるの? どうなの?」ということを ASP.NET Core アプリ内で判定したい場合、困ったことになる。

X-Forwarded-Proto

そこで参照するとよいのが X-Forwarded-Proto サーバー環境変数である。

Azue Web App on Linux ないしは Heroku の Docket コンテナにおいて、ユーザーエージェントとはどんなプロトコル (http なのか https なのか) で接続しているのかを、この環境変数に設定してくれるのだ。

ASP.NET Core アプリ上は、この X-Forwarded-Proto サーバー環境変数は、要求ヘッダとして参照できる。

そこで、

  1. 要求ヘッダ X-Forwarded-Proto の値の取得を試みる。このヘッダが要求に含まれていればその値をスキーマとして参照する。
  2. もし X-Forwarded-Proto ヘッダが要求に含まれていなければ、現在の要求のスキーマを参照する。

という手順でスキーマ参照し、スキーマが "https" か否かで判定ができる。


具体的なコードとしてはこんな感じ。
(実際にはコントローラクラス/アクションメソッドにこんな風に直書きせず、何かミドルウェアとか実装して、そこで https でなかったら要求を HTTP 403 で拒否するとか https な URL にリダイレクトするとかやるのだろうけれど、とりあえずサンプルコードなので)。
public class ProblemController : Controller
{
public ActionResult Index()
{
var scheme = this.Request.Headers.TryGetValue("X-Forwarded-Proto", out var value) ?
value.ToString() :
this.Request.Scheme;
if (scheme == "https") {
// クライアントと https でつながっている場合にここに到達
....

このコードはもちろん、Azure Web Apps 上に配置した場合も正しく機能する。

これで、Docker コンテナ内で稼働する ASP.NET Core アプリであっても、ユーザーエージェントと https でつながってるのかどうかを判定できるようになった。
 

# by developer-adjust | 2017-09-08 23:04 | .NET | Comments(0)
2017年 09月 08日

Visual Studio 2017 上で作成した ASP.NET Core 1.1 アプリの Docker イメージを Heroku に配置・実行する

Visual Studio 2017 による Docker サポート

Visual Studio 2017 では、ASP.NET Core 1.1 Web アプリを開発する際、Docker イメージを生成するよう構成することができる。

新規プロジェクト作成時に、プロジェクト作成のダイアログで Docker サポートの追加を選択するか、
d0079457_08025168.png
あるいは既存の ASP.NET Core プロジェクトをソリューションエクスプローラ内からの右クリックで Docker サポートの追加を行うことができる。
d0079457_08025680.png
Docker サポートが追加されると、ソリューションの下に、主体である ASP.NET Core プロジェクトとは別に、Docker Compose のプロジェクト (.dcproj ファイル) が追加される。
d0079457_08030172.png
Docker Compose のノードをスタートアッププロジェクトに指定して F5 実行すれば、IIS Express や dotnet コマンド実行ではなく、Docker イメージの作成とそのイメージからの Docker コンテナの開始でアプリが実行される。
もちろん Visual Studio 上でいつもと変わらずデバッグも可能だ。

作成される Docker イメージには プロジェクト名の名前空間 + dev のタグ名が付く。
> docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
chomadproblemserver dev d6b1f650bd7d 1 hours ago 320MB
ただしこの dev タグ付きの Docker イメージは、単純に docker run しても、下記のようなメッセージを吐くだけで実行できなかった。
> docker run -p 32767:80 d6b1f650bd7d
Did you mean to run dotnet SDK commands? Please install dotnet SDK from:
http://go.microsoft.com/fwlink/?LinkID=798306&clcid=0x409
たぶん、Visual Studio から起動されるときは、何かしらの追加のオプションが指定されて実行されているのだろう (詳しくは調べていない)。

Release モードにして Docker Compose プロジェクトをビルドを実行すれば、単純な docker run でちゃんと稼働する Docker イメージが作成される。
d0079457_20285958.png
Release モードで作成される Docker イメージには、プロジェクト名の名前空間 + latest のタグ名が付く。
> docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
chomadproblemserver latest f650bd7dd6b1 a seconds ago 320MB
chomadproblemserver dev d6b1f650bd7d 1 hours ago 320MB

ところで、Visual Studio 2017 のプロジェクトテンプレートから作成した ASP.NET Core アプリのコーディングだと、環境変数 ASPNETCORE_URLS で指定したポート・URL でリッスンするようにできている。

それを踏まえつつ、"docker inspect {イメージID}" で件の Docker イメージの設定内容を確認してみると、環境変数 ASPNETCORE_URLS に「http://+:80」の設定が施されていて、それで TCP ポート 80 でリッスンするのだな、ということがわかる。
(どうやらこの環境変数設定は、元となっている「microsoft/aspnetcore:1.1」イメージにて設定が盛り込まれているようだ)
d0079457_20473638.png
以上のことから、このイメージ内で稼働する ASP.NET Core アプリは、docker run での開始時にとくに指定がなければ、TCP ポート 80 でリッスンしている。
そこで、docker run 時に、-p オプションでポートフォワーディング指定をすることで、指定のポート番号経由でブラウザからアクセスが可能となる。
> docker run -p 32768:80 chomadproblemserver:latest
この Docker イメージは、このように手元のローカルの Docker 環境だけでなく、Microsoft Azure の Web Apps on Linux に配置しても稼働する。
Docker Hub にこの Docker イメージを push してそれを Azure の Web Apps on Linux に配置することも可能だ。
d0079457_21244403.png
ちなみに、この Docker イメージを Docker Hub に公開するには、docker tag コマンドを使って Docker Hub の自分のアカウントの名前空間で別名を付与し、これを docker push すればよい。
> docker tag chomadproblemserver:latest jsakamoto/chomad-problem-server:latest
> docker push jsakamoto/chomad-problem-server:latest

...以上の話題は、今年 2017 年に開催されたマイクロソフトの開発者向けイベント「de:code 2017」の TL04 セッション「.NET 15 周年の今こそ考えるクラウド ネイティブ アプリケーションと .NET の活用」の動画でも知ることができる。


Heroku の Docker コンテナサポート

さて話は変わって、PaaS の老舗(?)、Heroku での話。

Heroku も時流に遅れることなく、Docker イメージを push して稼働させることが可能だ。

Heroku 上には registry.heroku.com という Docker リポジトリが用意されている。
このリポジトリに、Heroku 上のアプリ名の名前空間 + /web という名前空間で Docker イメージを push すれば、それで Docker コンテナが開始される。

Heroku CLI がインストール済みの環境であれば、下記要領となる。

まずは準備。
いちど済ませてあれば毎回行う必要はない。
# 念のため、事前に heroku CLI を最新版にしておく
$ heroku update

# 事前に、Heroku サービスにログインしておく。
$ heroku login

# さらに事前に Heroku の Docker リポジトリサービスにログインしておく。
$ heroku container:login
次に、Heroku 上にアプリ枠を作る。
アプリ名が "foobar" だとすると、こんな感じ。
$ heroku apps:create foobar
もちろん、このアプリ作成の手順は、heroku.com の Web コンソールから作っても構わない。

あとは、この foobar アプリとして配置したい Docker イメージに、Heroku の Docker リポジトリを指す、アプリ名 + /web を名前空間とした別名を付与して、push するだけだ。
$ docker tag {配置したい Docker イメージのID} registry.heroku.com/foobar/web
$ docker push registry.heroku.com/foobar/web
これで、docker push が完了すると、Heroku 上でこのイメージから Docker コンテナが自動で開始される。
"heroku open -a foobar" を実行すれば、手軽に当該アプリをデフォルトブラウザで開いてくれもする。

しかし VS2017 で生成したイメージでは Heroku で動かない

ところがところが、Visual Studio 2017 の機能で生成した ASP.NET Core アプリの Docker イメージは、この方法では Heroku 上に配置しても以下のようにエラーとなって稼働してくれない。
> docker push registry.heroku.com/chomado-problem-server/web
The push refers to a repository [registry.heroku.com/chomado-problem-server/web]
d678574e5668: Pushed
2783887ca397: Pushed
...(中略)...
unsupported: Your Docker image must specify a `CMD` instruction.
どういうことかというと、Heroku による Docker コンテナサポートには、以下の2つの制約がある。
  • CMD 指定が必須
  • 環境変数 $PORT で指定される TCP ポート番号でリッスンする必要がある

先のエラーは、メッセージからも読み取れるとおり、上記制約のうち最初のひとつめ (CMD 指定が必要) に抵触したことによるものだ。

これを踏まえつつ、Visual Studio 2017 の機能で生成された Docker イメージを見てみると次のとおりとなっている。
  • CMD 指定は使わず、ENTRY 指定を使用
  • リッスンするポート番号は、基本、80 番固定。(docker run 時に環境変数 ASPNETCORE_URLS を上書き設定すれば任意のポート番号でリッスンさせることはできる)

そこで、Visual Studio 2017 の機能で生成された Dockerfile を以下のように書き換えてビルドし直し・Docker イメージを作成しなおしすればよい。
  • ENTRY 指定をやめ、CMD での指定
  • ただし、単純に dotnet コマンドを起動する CMD ではなく、環境変数 $PORT を環境変数 $ASPNETCORE_URLS に反映させてから dotnet コマンドを実行するシェルスクリプトを記述する
  • なお、Heroku 以外の環境では、$PORT 環境変数は与えられないので、環境変数 $PORT の既定値 (80) を設定しておく

以上を反映した Dockerfile は下記となる。({ASP.NET Core プロジェクト出力 .dll 名} の部分は実際の名前に置き換わる)
FROM microsoft/aspnetcore:1.1
ARG source
WORKDIR /app
EXPOSE 80
COPY ${source:-obj/Docker/publish} .
# "ENTRYPOINT~" の行を削除し、代わりに下記2行を追加。
ENV PORT 80
CMD ASPNETCORE_URLS=http://*:$PORT dotnet {ASP.NET Core プロジェクト出力 .dll 名}
この Dockerfile に基づいて生成された Docker イメージであれば、Heroku に配置・稼働させることができるようになる。

もちろんこの変更を加えても、ローカルでの実行や、Visual Studio からのデバッグ、Azure Web Apps on Linux への配置など、これまでと同じ要領で変わらず実行可能だ。

補足・Dockerfile の変更・イメージの再作成ができない場合

例えば他の人が作成・公開したような既存の ASP.NET Core アプリの Docker イメージで、且つ、前述のような対 Heroku 問題を抱えているイメージを、Heroku の Docker コンテナに配置したい場合はどうするか。

その Docker イメージの "再作成" は手が届かないとしても、ENTRYPOINT 指定を "上書き" した、レイヤーを重ねた新 Docker イメージを作成することで実現可能だ。

具体的には、以下のような Dockerfile を作り、
FROM {イメージ名}

# 元のイメージの ENTRYPOINT 指定を null 値で書き潰す
ENTRYPOINT

# 代わりに下記2行を追加。
ENV PORT 80
CMD ASPNETCORE_URLS=http://*:$PORT dotnet {元の ENTRYPOINT 指定と同じ.dllファイル名}
その Dockerfile があるフォルダで以下のように Docker イメージのビルドを行えばよい。
$ docker -t registry.heroku.com/{Heroku上に配置するアプリ名}/web ./
こうして作成した Docker イメージなら、docker push して Heroku 上に配置しても、期待どおり動作してくれるようになる。

以上!


# by developer-adjust | 2017-09-08 21:42 | .NET | Comments(0)
2017年 08月 30日

Application Insights で Web アプリのクライアント JavaScript 例外を記録したら、URL は記録されていない?

Application Insights の試用を始めた

実はこれまでのところ、Web アプリの各種モニタリングには Application Insights は使っていなかったのだが、思うところあって、Application Insights の利用を始めることにした。
Application Insights の適用できるプラットフォームは多岐に渡る。
今回は Web ページの監視、クライアント側スクリプトにおける Application Insights の試用を開始した。

実装

ガイドに従って手続きを進め、下記のような JavaScript コードをページに埋め込んだ。
<script type="text/javascript">
var appInsights = window.appInsights || function(config){
... 省略 ...
}({
instrumentationKey: "a79dec8d...c3a427"
});
window.appInsights = appInsights;
appInsights.trackPageView();
</script>
これで、JavaScript コード上で捕捉されなかった例外が Application Insights サービスにインターネット経由で送信され、Visual Studio 上や、Web ブラウザからの Azure ポータルサイト上で確認することができるようになる。

試用を始めて早速に、捕捉されないクライアントスクリプト例外が発生。

それではと、Azure ポータルで発生した例外のログを確認してみた。

なるほどなるほど、例外のメッセージはもちろん、スタックトレースも当然のごとく閲覧可能。
d0079457_23024373.png

...と、見ているうちに気が付いた。

例外発生時のページ URL はどこ?

ページ URL の記載がない?

このクライアントスクリプト例外が発生したときの、ページ URL がわからない。

「http://host/#/foo/edit/123」みたいに URL がわかれば、「foo の ID = 123 を編集中に、この例外が発生したんだな!」と、現象の再現に大変役立つ。
しかしその URL がわからないとなると、かなりきつい。

"url" という項目はあるにはある。
しかしこれは例外発生個所の JavaScript ファイルの URL だった。
そういう URL は無用である (スタックトレースみればわかるし)。

何か見落としているのかもしれないが、現時点でもなお、にクライアント側スクリプト例外の発生時のページ URL の記録は見つけられていない。
いちおう、ブラウザの開発者ツールで、Application Insights への送信内容も傍受して内容の JSON を見てみたが、そこにもページ URL らしきものは、自分には見つけられなかった。

自前で配線

致し方ないので、捕捉されなかったクライアントスクリプト例外の記録を、Application Insights の既定のスクリプトに任せるのをやめ (下記)、
<script type="text/javascript">
var appInsights = window.appInsights || function(config){
... 省略 ...
}({
instrumentationKey:"a79dec8d...c3a427",
disableExceptionTracking: true // このオプション指定を追加
});
代わりに自前で、捕捉されなかった例外の Application Insights への送信を実装し、そこで window.location.href も盛り込むようにした。
window.onerror = function (msg, file, line, column, err) {
appInsights.trackException(err, null, {
url: file,
pageUrl: window.location.href
});
};
</script>
これで Azure ポータル上での例外ログを閲覧したときに、例外発生時の URL もわかるようになった。
d0079457_23031207.png

でも本当にこれでいいの?

...という感じで、とりあえずは自己解決したのだけれど、今になって落ち着いて考えるに、皆さん、クライアントスクリプト例外の記録に、例外発生時のページの URL が併記されてないまま Application Insights を利用されているのだろうか??

それとも自分が何か壮大な勘違い・間違いを犯しているのではないだろうか?

もし何か情報があればコメントや Twitter 上のツイートなどで教えていただけると大変ありがたい。
 


# by developer-adjust | 2017-08-30 23:15 | Web系一般 | Comments(0)
2017年 07月 27日

「お前の IP アドレスを echo する」Web アプリを作る (手順はあるけど実装コードそのものは6行!)

自 PC のグローバル IP を知るのに inet-ip.info を使ってたが...

以前、こんな記事を投稿した。

Azure CLI 2.0 ("az" コマンド) を使って Azure SQL Database のファイヤーウォールを開閉する

この記事の中で、「補足: 自 PC からのアクセスでのグローバル IP を知るには?」ということで、http://inet-ip.info の利用を紹介していた。

最近、inet-ip.info 落ちてる?

しかしながら、ここ数日、http://inet-ip.info がたまーに落ちてることがあった。
ほどなく復活はするのだが、自分は運が悪いのか、ここ最近は立て続けに利用不能の憂き目に逢っている。
どうやら Heroku 上に立てられているようなのだが、利用量の制約にでも触れてしまっているのだろうか。

それはさておき、まぁ、HTTP 要求に対し、要求もとのリモートアドレスを応答に返すような Web アプリの作成なんぞ大した手間ではない。
ということで、他人様がたててくれた Web アプリだけに頼るのではなく、ささっと自分専用の「お前の IP アドレスを echo する」Web アプリを作って立てることにした。

とはいえ、たかだか「お前の IP アドレスを echo する」のためだけなので、
Web アプリすら大仰
である。

ということで、Microsoft Azure の機能のひとつ、「Azure Function Apps」として構築することにした。

「お前の IP アドレスを echo する」Azure Function App

今回はプログラミング言語としては JavaScript を採用。

ということで、言語 = JavaScript で、HTTP Trigger な Function を1つ作り、下記内容で実装すれば完了である。
// index.js
module.exports = function (context, req) {
var remoteAddress = req.headers['x-forwarded-for'];
context.res = {body: remoteAddress.split(':').shift()};
context.done();
};
あとは、この Function を起動する URL に、HTTP GET 要求でも送れば、応答コンテンツに、アクセス元 = 自身の IP アドレスが echo されて返ってくる次第。

以下、Azure Portal での操作手順の説明となるが、もう少し詳しく手順を説明してみよう。

手順をもうすこし詳細に説明してみる

まずは Web ブラウザで Azure Portal サイトを開いてサインイン。
続けて、「New (追加)」から「Compute」>「Function App」とカテゴリをたどる。
最低限、アプリ名を指定し(アプリ名は URL の一部というか先頭部分となる)、適宜、ホスティングされる場所を選んで「Create」をクリック。
d0079457_12131086.png
これでしばらくすると新規 Function App の枠ができあがる。

続けてこの枠の中に個別の Function を作っいく(今回は IP アドレスを echo する Function x 1つだけだが)。

Azure Portal 上で今作った Function App のブレードを開き、下図のように Functions の追加ボタンをクリック。
するとどのような Function を追加するのかの画面になる。

この画面では、よく使われるシナリオ用の Function をさくっと追加できるようになっているのだが、あいにくと HTTP トリガーが選択肢にない。

そこで、「create your own custom function」をクリック。
d0079457_12130435.png
これで、細かく選べる画面になる。

「Language (プログラミング言語)」は「JavaScript」を選択、シナリオは「HttpTrigger」を選択して、最後に Function の名前(これが URL パスの末尾になる)を決めて入力、「Create」をクリックする。
d0079457_12125915.png
これで、HTTP 要求によって起動される Function がひとつできあがる。

実装内容を下図のように、今回案件の「お前の IP アドレスを echo する」内容に書き換えて「Save」をクリックして保存。
d0079457_12125424.png
これで完成である。

あとは、この Function を起動する URL が画面右上のリンクから知らされるので、この URL を手に入れておく。
d0079457_12124863.png
ちなみに、ここまで、既定の設定で作ってきたので、この Function は、いわゆる "パスワード" というか、API キーによる認証必須となっている。

つまり、API キーを添えて HTTP 要求を送らないと、Azure Function App のインフラストラクチャによって「401 Not Authorized」エラーになる。

なお、上図で見えている当該 Function を起動する URL には、クエリ文字列として、その API キーが込みで掲載されている。
なので、この URL で HTTP 要求を送れば...
d0079457_12124023.png
ご覧のとおり、ちゃんとアクセス元のグローバル IP アドレスが応答として返ってくる。
上図は PowerShell で Invoke-RestMethod による実行例だが、もちろん curl でも同じだ。
d0079457_12123486.png
ちなみに API キーの指定方法だが、上記のように URL 中のクエリ文字列で "code=..." に指定するほか、HTTP 要求ヘッダに「x-functions-key」を追加してそこに API キーを指定してもよい。

下記など参照されたし。
Azure Functions の API Key を扱ってみる
http://tech.guitarrapc.com/entry/2016/04/22/042331

まとめ

以上、Azure Function App を使えば、「お前の IP アドレスを echo する」程度の Web アプリは、さくっと立てられる。

なお、Azure Function の料金については下記を参照されたし。
ベースの無料枠もあるので、但しストレージの使用料金はかかるのだがそれもたかがしれていると思うのでかなり廉価に運営できると思われる。





# by developer-adjust | 2017-07-27 12:47 | Web系一般 | Comments(0)
2017年 07月 10日

ASP.NET Core では Web API でバイナリコンテンツを返すのは簡単だった件

前回の投稿で、ASP.NET Web API (.NET Core ではなく) において、バイナリコンテンツを返すにはどう実装するのかについてまとめた。

たかだかバイナリコンテンツを返すだけなのに、決して少ないとは言えない量のコードを記述する必要があることがわかり、もやっとする印象であった。

ASP.NET Core での実装はどうなる?

さてところで、ASP.NET Core における Web API からバイナリコンテンツを返す場合はどうなるか。

ASP.NET Core からは、ASP.NET MVC と ASP.NET Web API は、その実装が統一化された。

旧来の ASP.NET では、MVC のコントローラクラス (System.Web.Mvc.Controller) と、Web API のコントローラクラス (System.Web.Http.ApiController) とは別物であった。
しかし ASP.NET Core MVC からは両者は統一され、MVC コントローラと API コントローラで区別がなくなり、いずれも同じ Microsoft.AspNetCore.Mvc.Controller クラスからの派生となる。

その結果、バイナリコンテンツの返し方は、旧来の ASP.NET MVC と同じ、File() メソッド呼び出しを返すだけでよくなった!
[Rout("api")]
public class MyController : Controller
{
// 戻り値は IActionResult とする。
[HttpGet, Route("picture")]
public IActionResult Get()
{
// MVC/Web API の区別なく、File メソッド使うだけで
// 容易にバイナリコンテンツを返すことができる!
var bytes = new byte[] { /* バイナリコンテンツのバイト列 */ };
return this.File(bytes, "application/octet-stream");
}

// もちろん従来どおり、任意の型の戻り値を返すことができ、
// ブラウザには JSON に書式化して届く。
// HTTP GET /api/values => [1, 2, 3]
[HttpGet, Route("values")]
public int[] GetValues()
{
return new []{ 1, 2, 3 };
}
}

まとめ

ASP.NET Core ならとてもシンプルである。

これならはじめから ASP.NET Core で実装しておけばよかったと反省である。
 

# by developer-adjust | 2017-07-10 16:51 | .NET | Comments(0)
2017年 06月 30日

ASP.NET Web API コントローラにてバイナリコンテンツを返す方法

表題の件、毎回やり方を忘れてはネット検索しているので、自分用にメモ。

なお、ASP.NET Core ではなく、従来からの ASP.NET における話題。

まずは結論から

ASP.NET Web API コントローラにてバイナリコンテンツを返すには、API コントローラのアクションメソッドについて、以下のようなコードを書けばよい。
  • アクションメソッドの戻り値は HttpResponseMessage 型とする。
  • 返したいバイナリコンテンツを ByteArrayContent でラップする。
  • さらに、適宜、コンテンツタイプを ByteArrayContent オブジェクトに設定する。
  • Request オブジェクトの CreateResponse メソッドで、応答オブジェクトを作る。
  • この応答オブジェクトに、返したいコンテンツをラップした ByteArrayContent オブジェクトを設定する。
  • こうして作成した応答オブジェクトを、アクションメソッドの戻り値として返す。
public class FooController : System.Web.ApiController
{
// HTTP GET /api/Foo
public HttpResponseMessage Get()
{
...
var bytes = new byte[] { /* バイナリコンテンツのバイト列 */ };
var content = new ByteArrayContent(bytes);
content.Headers.ContentType =
MediaTypeHeaderValue.Parse("application/octet-stream");
var res = this.Request.CreateResponse();
res.Content = content;
return res;
}
}

うまくいかない例

ちなみに下記コードでは期待した動作とならない。
public class FooController : System.Web.ApiController
{
// HTTP GET /api/Foo
public byte[] Get()
{
...
var bytes = new byte[] { /* バイナリコンテンツのバイト列 */ };
return bytes;
}
}
上記コードだと、返したいバイナリコンテンツのバイト列が、JSON (ないしは XML) 形式で返されてしまうからである。

もちろん、たいていの場合、ASP.NET Web API コントローラの仕組みとしては、任意の型の戻り値が JSON (or XML) で返却されるのはうれしい仕様である。
しかし、今回のようにバイナリコンテンツを返したい場合には融通が利かず、先に書いたとおりの実装を記述しなければならないようだ。

もっとうまい方法がありますか?

それにしても、たかだかバイナリコンテンツを返すだけなのに記述量がちょっと多い気がする。
もしかしてもっとスマートに実装できるのだろうか?

個人的には下記の妄想例のように、アクションメソッドに属性指定することで、バイナリコンテンツを返すことができたらいいのにな、とか思ってしまった。
public class FooController : System.Web.ApiController
{
// HTTP GET /api/Foo
// ※こんな属性や仕組みはないのだけれど、
//  こんな風に書けたらいいな!という妄想
//  (まさか、もしかして既にあったりする?)
[ByteArrayContent("application/octet-stream")]
public byte[] Get()
{
...
var bytes = new byte[] { /* バイナリコンテンツのバイト列 */ };
return bytes;
}
}

そもそも API コントローラでバイナリコンテンツを返す?

ところで、そもそも API コントローラでバイナリコンテンツを返す需要があるのか、はたまた、API コントローラからはバイナリコンテンツを返すべきではないのでは、といった議論もあろうかと思う。

まず需要についてだが、昨今の SPA (Single Page Application) 実装におけるクライアント側からサーバー側 API の呼び出しにおいて「チケットの QR コード画像を動的生成して返したい」であるとか、「現在ログインユーザーのプロフィール画像を返したい」など需要はあるように思う。

MVC コントローラから返すなら容易だけれども...

そうしたときに、ASP.NET MVC コントローラであれば、File 拡張メソッドで容易にバイナリコンテンツを返すことができる。
よって、Web API コントローラでの実装にこだわらずに、MVC コントローラで実装すればいいのかもしれない。

しかし昨今の SPA 実装だと、サーバー側実装は MVC コントローラは無くて、Web API コントローラだけ、ということも多い。
そんな背景下、バイナリコンテンツを返すためだけに MVC コントローラを追加実装するのもどうかと思う次第。

CDN とか使うのでは?

また、それなりのアクセス数・負荷が見込まれるような Web アプリ・サイトの場合、そのようなバイナリコンテンツはこれらコントローラ類で処理していると性能が追い付かないであろう。
このようなケースでは、CDN にそのようなバイナリコンテンツを配信しておいて処理を移譲する、といったような策を打つべきだろう。

とはいえ、中小社内向けや B2B でユーザー数が限定されているよううな場合は、CDN をはじめあまり連携サービスを増やさずに Web アプリ本体だけで完結していることも、サーバーへの配置などの取り扱いが簡潔になるので、それはそれで価値があると思う。

2017年7月10日 追記

ASP.NET Core ならもっと簡単だった。詳しくはこちら


# by developer-adjust | 2017-06-30 10:13 | .NET | Comments(0)
2017年 06月 19日

ASP.NET アプリ開発時 & Azure への配置における、DB接続設定の使い分けについて 再び

(.NET Core ではないクラシカルな) ASP.NET Web アプリ開発と、Azure Web App への配置における、データベース接続文字列をどこにどう設定するのか、の話題。

本投稿では、SQL Server データベースに接続して、何かしらデータベースに読み書きする ASP.NET Web アプリを想定している。

そしてデータベースアクセスライブラリには Entity Framework を用い、Code Fist スタイルで実装するものとする。

まずはおさらいから。

開発環境では...


開発環境、およびバージョン管理システムにコミットされる内容としては、web.config の connectionStrings セクションに、SQL Server LocalDB によってプロジェクトフォルダ以下にデータベースファイルができあがるように、データベース接続文字列をインラインで記述する。
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<connectionStrings>
<add
name="MyDB"
connectionString="Server=(LocalDB)\MSSQLLocalDB;AttachDbFilename=|DataDirectory|MyDB.mdf;Integrated Security=True;Connect Timeout=30"
providerName="System.Data.SqlClient"/>
</connectionStrings>
...
</configuration>

このコード・構成ファイルをバージョン管理システムにコミットしておくことで、このリポジトリを clone (あるいはチェックアウト) した他のメンバーも、ビルドして実行するだけで、データベースも新規構築されてその ASP.NET Web アプリを動かすことができる。

もっとも、最低限、いずれのメンバーの開発環境にも、同じバージョンの SQL Server LocalDB が事前にインストール済みである必要はある。
とはいえ、そもそも ASP.NET Web アプリ開発のために Visual Studio が必要という程度には各メンバーの開発環境をそろえる手間をかけているはず。
なので、さらに SQL Server LocalDB についても環境をそろえることは大したコスト、問題にはならないと思う。

実行環境では...


さてこうして開発した ASP.NET Web アプリを、Azure Web App として配置するとしよう。

上記手順で開発したとすれば、接続先データベースに LocalDB が指定された web.config が配置されることになる。

しかし当然のことながら、一般的(?)なケースであれば、実行環境用のデータベースは LocalDB ではなく Azure 上の SQL Database サービスなどを別途用意済みで、そちらに接続するようにしたいはずだ。

このような目的で、Azure Web App のアプリケーション構成の中に、データベース接続文字列をポータル上から指定できるようになっている。
d0079457_21420390.png
web.config の connectionStrings セクションと、この Azure のポータル設定とで同じ名前のエントリがあると、Azure のポータルで設定したデータベース接続文字列のほうが優先して採用されるのだ。

この仕掛けにより、
  • 本番環境用のデータベース接続文字列をバージョン管理システムにコミットすることなく、
  • またいっぽうで開発者はソースコードリポジトリからプロジェクト一式を取り出したらすぐにローカル環境で実行できる
体制とすることができる。

開発環境側で、異なるデータベース接続がしたい!


...と、ここまではおさらい。
それなりに ASP.NET Web アプリ開発や Azure への配置を手掛けている経験があれば、ここまでの内容は半ば "常識" かもしれない。

さて、以上の仕組み・体制で大抵の場合は問題ない。
しかし稀ではあるものの、開発環境においてデータベース接続文字列を変更したい需要がある。

いくつかの面倒なシナリオがあるのだが、わかりやすい例としては、開発環境にインストールされている SQL Server LocalDB のバージョンが合っていなかった、という例が挙げられる。

久々に古いプロダクトのコードを開いて実行してみたら、開発機を入れ替える前のコードで、現在の開発機にはそのプロダクトが指している古いバージョンの SQL Server LocalDB がインストールされていなかった、とかである。

まぁ普通に考えると、指定のバージョンの SQL Server LocalDB をインストールすればよいのだろう。
しかしながら、いろんなバージョンの SQL Server LocaDB が開発機にインストールされるのは (しかもそのようなレアなプロダクトの保守のためだけに)、気持ち悪いかもしれない。

そんなことから指定バージョンの SQL Server LocalDB のインストールを嫌って、web.config にインラインで記載されているデータベース接続文字列を、自身の開発機にインストールされている SQL Server LocalDB バージョンに合わせて書き換えてしまい、これをコミットしてしまうと、あまり致命的ではないとはいえ (どうせ Azure に配置するときにはポータルで設定された接続文字列が使われるので問題ない)、開発メンバー間で面倒なことになりかねない。

「あいつのコミットをマージしたら、自分の環境で動かなくなったー!」みたいに、である。


ということで、最近編み出した手法を紹介する。

解決方法

まず、データベース接続文字列は、web.config にインラインで記述せず、web.config 中からは (例えば) "connectionStrings.config" という、もうひとつ外部の構成ファイルを参照するように変更する。
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<connectionStrings configSource="connectionStrings.config" />
...
</configuration>
いっぽうで、バージョン管理システムには、ファイル "connectionStrings.config" がバージョン管理下に含まれないようにしておく。
git であれば .gitignore に "connectionStrings.config" の1行を加筆しておくことになるだろう。

さてこれだけだと、新たにバージョン管理リポジトリからプロジェクト一式を clone しても、"connectionStrings.config" がないので、ビルドや実行時エラーになってしまう。

そこで、ビルドイベントの「ビルド前に実行」されるバッチスクリプトとして、
「もし "connectionStrings.config" がプロジェクトフォルダに存在しなければ、既定の内容で生成」
というバッチスクリプトをプロジェクトファイルに組み込んでおくのだ (下記例)。
d0079457_21542140.png
set configPath= "$(ProjectDir)connectionStrings.config"
if exist %configPath% goto SKIP
echo ^<?xml version="1.0" encoding="utf-8" ?^> > %configPath%
echo ^<connectionStrings^> >> %configPath%
echo ^<add name="MyDB" connectionString="Server=(LocalDB)\MSSQLLocalDB;AttachDbFilename=|DataDirectory|MyDB.mdf;Integrated Security=True;Connect Timeout=30" providerName="System.Data.SqlClient"/^> >> %configPath%
echo ^</connectionStrings^> >> %configPath%
:SKIP
※上記例以外にも、別途既定の構成の "connectionStrings.config" ファイルをバージョン管理下にはあるがプロジェクトフォルダの外に「テンプレート」として配置しておき、プロジェクトフォルダになければコピー、といった仕組みとすることもできるだろう。

あとは、"connectionStrings.config" をプロジェクトに含め発行対象となるようにしておけばよい。
d0079457_22025173.png

こうしておくことで、
  • 開発者はこれまでどおり、プロジェクト一式をバージョン管理リポジトリから clone した直後、そのままビルド、実行してもちゃんとアプリを動かすことができるいっぽう、
  • データベース接続文字列を記述している "connectionStrings.config" はバージョン管理下にないので、安心して自分の好きなように接続先データベースを書き換えて実行
といったことができる。

まとめ


ここで紹介したやり方は、実のところ、あまり美しいやり方とは言えないと思う。

実際、もしも Azure Web App への配置が CI/CD の仕組みではなく手動による配置だと、配置を行うメンバーが "connectionStrings.config" を既定とは違う内容に書き換えていたら、それが Azure 上に配置されてしまうという気持ち悪さもある。
(どのみち、ポータルで設定されたデータベース接続文字列に上書きされて動作するはずなので、実害はないはずだが)

とはいえ、本記事で取り上げたような需要 ― 既定のデータベース接続文字列を開発者間で共有しつつ、自分独自のデータベース接続文字列に書き換えたいときがある ― を、とにかくは満たしてはいる。

広く勧める技法ではないが、同じような需要に迫られてお困りの方の一助になれば幸いである。
よりクールでスマートなやり方・運用があればご教示いただければ嬉しい限り。

最後に補足として、ASP.NET Core ではアプリケーション構成の仕組みが変わっているので本記事は参考にならないと思うので悪しからず。


# by developer-adjust | 2017-06-19 22:05 | .NET | Comments(0)
2017年 05月 02日

.NET Core なクラスライブラリプロジェクトの xUnit.net 単体テストを AppVeyor で稼働させようとして躓いた話

先に結論書いておくと、

テストの実行設定は「Auto (自動)」ではなく、「Script」>「CMD」で
cd <テストプロジェクトがあるサブフォルダ>
dotnet test
を指定しましょう。

d0079457_22420386.png
AppVeyor とは

AppVeyor というのは、.NET 系フレンドリーなインターネット上の CI サービスである。

詳しくは下記など参照されるとよろしいかと思われる。


自分も AppVeyor の利用経験はある。
ただしそれは .NET3.x や .NET4.x といった従来からのフレームワーク用のプロジェクトのみ。
.NET Core なプロジェクトを AppVeyor に載せたことはなかった。

しかしながら今回初めて、.NET Core なクラスライブラリプロジェクト、そして単体テストのフレームワークに xUnit.net を採用したものを AppVeyor に載せる機会が生じたのでやってみた。

楽勝! ...と思いきや

対象となるプロジェクトはこちら。

AppVeyor の Web サイトにサインインして「NEW PROJECT」から新規プロジェクトを追加し、上記 GitHub リポジトリの URL を指定。

これで AppVeyor 上で git clone & ビルドが開始される。

...が、早速にビルドでコケる。

しかし大丈夫。
.NET Core なプロジェクトを AppVeyor でビルド成功させるには、MSBuild によるビルドが始まるより前にビルドパッケージの復元 (リストア) を明示的に行う必要があるだけだ。

下記にも事例が載っている。
...まぁ、@DarkCrash3 氏に「AppVeyor で dotnet コマンド使えるようになったらしいよ!」とお知らせしたのは自分だったりする :P

さておき、AppVeyor のプロジェクトの「SETTINGS」を開き、「Build」サブカテゴリを開いて「Before build script」の設定項目を既定の「OFF」から「CMD」に切り替え、「dotnet restore <.slnフィル名>」を設定して OK。
d0079457_22423235.png

なお、自分の場合は上記記事と異なり、「Build」サブカテゴリは既定の「MSBUILD」のままで済んだ。
代わりに「Environment」のカテゴリで「Build worker image」の選択肢を、既定の「Visual Studio 2015」から「Visual Studio 2017」に設定変更した。
このあたりは @DarkCrash3 氏の記事執筆当時と状況が変わっている点かもしれない。
d0079457_22430309.png

ビルドは通ったがテストが実行されない!

さて以上で無事ビルドがとおり、いよいよ単体テストも実行され... と思いきや、テストの実行で何かコケている。

AppVeyor に記録されてるログを確認すると下記のような内容が。xUnit.net Console Runner (32-bit .NET 4.0.30319.42000)
System.InvalidOperationException: Unknown test framework: could not find xunit.dll (v1) or xunit.execution.*.dll (v2) in C:\projects\csharpprolog\CSProlog.Core.Test\bin\Debug\netcoreapp1.1
「xunit.dll (v1)」または「xunit.execution.*.dll (v2)」が見つからない??

目を白黒させながら、改めて @DarkCrash3 氏の記事を見直すと、なになに、AppVeyor の「SETTINGS」、「Tests」サブカテゴリにて、テスト実行を自動検出させず、指定のスクリプト「dotenet test ~」を実行するようにせよ、とのこと。

ということで氏の記事に従い、以下のように設定して試してみた。
d0079457_22482745.png

しかしまたしてもテスト実行でコケる(ログは下記)。dotnet test CSProlog.Core.Test
Couldn't find a project to run test from. Ensure a project exists in C:\projects\csharpprolog.
Or pass the path to the project
なぜだ?
ログを見るとテスト対象のプロジェクトが見つけられないということらしい。ログではしきりに「~from .」とか「C:\projects\csharpprolog.」とか、ピリオド( . )、すなわちカレントディレクトリであろうことを示唆している。

でも、ちゃんと、単体テストプロジェクトのあるフォルダ「CSProlog.Core.Test」を指定したつもりなのだが。

そこで手当たり次第にいろいろなコマンド引数指定を試してみた。dotnet test .\CSProlog.Core.Test
dotnet test .\CSProlog.Core.Test\CSProlog.Core.Test
dotnet test CSProlog.Core.Test\CSProlog.Core.Test.csproj
dotnet test CSProlog.Core.sln
dotnet test CSProlog.Core.Test\bin\Debug\netcoreapp1.1\CSProlog.Core.Test.dll
しかしどれひとつとして成功しない。

煮詰まってしまったので、氏のブログ記事ではなく、ブログ記事中で取り上げている AppVeyor プロジェクトのログを直接見に行ってみたところ...

https://ci.appveyor.com/project/darkcrash/bjd5-vc4ju
d0079457_22433192.png

え、cd コマンドと、追加引数なしの dotnet test コマンド!?

ということで自分のプロジェクトでも
cd .\CSProlog.Core.Test
dotnet test
をテスト実行用のスクリプトに設定したところ、あっさりテスト実行が成功した。

よかった、けど、なんか変に疲れた...。

まとめ

今後同じ轍を踏まぬよう、AppVeyor の構成ファイル「appvayor.yml」を以下のように作成してプロジェクトのリポジトリに添付することにした。version: 1.0.{build}
image: Visual Studio 2017
before_build:
- cmd: dotnet restore <.slnファイルへの相対パス>
test_script:
- cmd: >-
cd <単体テストのあるフォルダへの相対パス>
dotnet test
あと、.NET Core な、そして xUnit.net を採用した単体テストプロジェクトを含むアプリやライブラリのプロジェクトを、AppVeyor ではなく Visual Studio Team Service で同じように CI 作ってみたらもっとすんなりできたりするのか、興味あるところである。
いずれ機会があれば試してみたい。
 

# by developer-adjust | 2017-05-02 22:52 | .NET | Comments(0)