C#、ASP.NET、TypeScript、AngularJS を中心にプログラミングに関した話題を諸々。
by @jsakamoto
検索
リンク
北海道のITコミュニティ - CLR/H 無聊を託つ
タグ
カテゴリ
最新の記事
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
「お前の IP アドレスを ..
at 2017-07-27 12:47
最新のコメント
いえす、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年 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年 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)
2016年 04月 18日

ASP.NET SignalR を使った Web アプリに ngrok 経由でアクセスすると、サーバー側呼び出しが動作していない

ASP.NET SignalR を使ったリアルタイム Web サイト/アプリを開発中の話。

※ちなみに「SignalR」とは、「Node.js でいうところの Socket.io」に相当する、WebSocket などを活用した双方向リアルタイム通信を実現するための ASP.NET 用のライブラリ。

ngrok + SignalR が不調...

前回の投稿で取り上げた、ローカル開発 Web サーバーを "中継" して、インターネット上からアクセス可能にするサービス「ngrok」。

この ngrok、公式サイトの説明によれば「Websocket にも対応してるはずだよ」とのこと。

なので、SignalR を使った Web アプリ開発においても、その動作確認などの目的で ngrok を経由してインターネット上からアクセスするようにしても動作するだろうと予想された。

しかし残念ながらそうはいかず、期待どおりに動作しないケースがあった。

ブラウザ側の SiganlR クライアントコードから、サーバー側の Hub メソッドの呼び出しが、なぜかサーバー側に到達しないのだ。

サーバー側 C# コードが以下のように、常に文字列 "Boo" を返す Foo メソッドを持つ SignalR Hub 実装だったとして、
using Microsoft.AspNet.SignalR;
...
public class FooBarHub : Hub {
public string Foo() {
return "Bar";
}
}
ブラウザ側 JavaScript コードから以下のように上記 Hub の Foo メソッドを呼び出し、その戻り値を表示するとする。
let conn = $.hubConnection();
let hub = conn.createHubProxy("FooBarHub");
conn.start();
...
// 何かの DOM イベントのハンドラにて、下記を実行
hub.invoke('Foo')
.then(res => console.log(res);
これらコードを、ローカル開発環境で実行したり、Azure Web Apps に配置してインターネット上からアクセスするぶんには、当たり前ではあるが、ちゃんとブラウザの開発コンソールに (Foo メソッドの戻り値である)「Bar」と表示される。


ところが、である。


このローカル開発環境では普通に動作するこのコードが、ngrok コマンドを起動してのインターネット上からのアクセスで試すと、どういうわけか Foo メソッド呼び出し結果のコールバックが呼び出されないのだ。

Visual Studio にてサーバー側の Foo メソッドにブレークポイントを設定して待ち構えても、もちろんローカル開発環境ではちゃんとブレークするが、ngrok 経由ではまったくもってブレークしない。

サーバー側からの push 通知だけは動作

ちなみに、「conn.start()」メソッドの戻り値である jQuery の Promise オブジェクトについてコールバック関数を実装して様子を見てみると、ngrok 経由でもちゃんと接続成功のコールバックが発生している模様。

しかも、別の要因で発火させたサーバー側からの push 送信を購読していた場合、その push 送信ハンドラは、ngrok 経由の場合でも、正しく呼び出されるのだ。

ちょっと不思議な挙動である。

回避策

それはさておき、予想としては、ngrok の WebSocket 対応と、IIS Express や ASP.NET SignalR における実装との関連で、なにか相性問題のようなことが起きているのかもしれない。
※ちなみに、ローカル開発環境および ngrok 経由の各々で、トランスポート層は WebSocket が使用されていることを確認済み。


そこで回避策として、ブラウザ側にて SignalR のサーバー側への接続を開くにあたり、使用するプロトコルを自動で決めさせずに、もっとも古典的であろうロングポーリングで接続するよう明示的に指定するようにしてみた。

コードとしては以下のとおり。
SignalR 接続オブジェクトの start メソッドを呼び出す際に、トランスポート層をロングポーリングに限定指定した設定を渡すようにする。
let conn = $.hubConnection();
let hub = conn.createHubProxy("FooBarHub");
conn.start({
transport: 'longPolling'
}
);
こうすると、ngrok 経由でのインターネット上からのアクセスでも正常に動作するようになった。

ちなみに SignalR 接続オブジェクトの start メソッドにて、トランスポート層指定にどんな選択肢があるかについては以下が参考になる。

http://www.asp.net/signalr/overview/guide-to-the-api/hubs-api-guide-javascript-client#transport

補足

なお、この回避策は、あくまでも ngrok を利用してローカル開発中の Web アプリの動作確認が目的である。
よって上記のようにロングポーリングが指定されたコードがそのままリリースされてしまうのは "事故" であり、そのような事態は避けておきたい。

そこで自分のコードでは、現在のページの URL を見て、そのホスト名が ".ngrok.io" で終わっているかどうかを正規表現で判定して、もしそうである場合に限り、トランスポート層のロングポーリング限定指定を行う実装とした。
 
by developer-adjust | 2016-04-18 22:41 | .NET | Comments(0)
2016年 04月 14日

Visual Studio で開発中の Web アプリをスマートフォンから動作確認するのに ngrok を使う

Windows OS 上で Visual Studio を使っての、Web アプリ開発の話。

このような開発環境では、通常、Visual Studio から自動起動された IIS Express によってこの Web アプリがホストされる。

この開発環境内で PC ブラウザを起動し、開発中の Web アプリの URL ― 一般に "http://localhost:56789/" のような ― を開いて試験実行/動作確認をすることになる。

さらに昨今は、スマートフォン実機のブラウザからもこの開発中の Web アプリにアクセスして試験実行し、スマートフォン上でも正しく動作するか確認することが多い。

しかしスマホから見えるようにする手間が...

さて、上記のようなローカル開発環境で開発中の Web アプリにスマートフォン実機からアクセスするには、まずは同一 LAN 内に立てた WiFi アクセスポイントにスマートフォンを接続する。

その上で、"http://(開発機のホスト名):56789/" といった URL をスマートフォンのブラウザで開くこととなる。

しかしセキュリティ上の観点からであろう、Visual Studio による Web アプリ開発においては、その Web アプリは localhost (127.0.0.1 及び ::1) にしかバインドされていない。

つまり既定では開発機の "外" からは接続できないように構成されている。

これを開発機の外からでも接続できるようにするには、微妙に面倒くさい。
概ね以下の手順を踏む必要がある。
  • IIS Express に対する XML 形式の設定ファイルである applicationHost.config をエディタで編集し、開発機ホスト名でのバインドを追加
  • 開発機ホスト名での URL アクセスをユーザーに許可 (Visual Studio を管理者モードで起動するならば不要)
  • Windows OS のファイヤーウォールで、開発中の Web アプリのポートでの受信を許可
具体的な手順は下記などが詳しい。

しばやん雑記 - IIS Express で仮想サイトに複数のホスト名を割り当てる
http://blog.shibayan.jp/entry/20130306/1362572283

上記、各手順はそうたいした手間ではないけれども、どうにも微妙な面倒を感じる。

おまけに、URL アクセス制御やファイヤーウォールの許可を、ちゃんとこまめに都度元に戻すのであれば、この微妙な手間が倍増である。

そこで ngrok

ということで最近よく使うようになったのが "ngrok" というサービス。

ngrok
https://ngrok.com/

"ngrok" とは、ある種の "リバースプロキシ" サービスとでも言えばよいだろうか。

Web アプリ開発時などローカルループバックでリッスンしているような Web サーバーに対し、ngrok が提供する専用のプログラムを同じマシン上で起動すると、このローカル環境の Web サーバーを、ngrok 提供のインターネット上の URL に "中継" してくれるのだ。

ネットで検索すると、ngrok についての記事がわんさか見つかるので、詳しくはそれら記事も参照されたし。

https://www.google.co.jp/search?q=ngrok

使ってみる

ngrok は、ずばりサービス名と同じ名前の ngrok コマンドを提供している。
これをダウンロード・インストールし、PATH が通っている状態で、コマンドプロンプトから以下のように ngrok コマンドを実行する。
> ngrok http 54090 -host-header=localhost
第 1 引数と第 2 引数がローカルで実行中の Web アプリのプロトコルとポート番号。
第 3 引数は host 要求ヘッダ値の書き換え指定 (詳細後述) である。

実行すると下図のような画面が表示される。
d0079457_19572395.png
上図のようにコンソール上に表示されているとおり、これで http://e1b0d393.ngrok.io/ にインターネット上からアクセスすると、そのアクセスを ngrok が中継して、現在開発中の Web アプリにアクセスできるのだ。
※この URL "http://~.ngrok.io" のサブドメイン部分は、ngrok コマンドを実行するたびに毎回、ランダムに変わる。

これでお手軽にスマホ (に限らないけど) から動作確認ができるというものだ。

終了させるには、このコンソール内で Ctrl + C を押せばよい。
ngrok コマンドは終了し、先の URL にアクセスしても無効となる。

-host-header オプションについて補足

さて、先の ngrok コマンドの説明で第3引数に「-host-header=localhost」を追加した。
これについて説明を。

ブラウザから「http://e1b0d393.ngrok.io/」にアクセスした際、その HTTP 要求に含まれる Host 要求ヘッダには「e1b0d393.ngrok.io」と書かれていることになる。

ところが、Visual Studio で Web アプリ開発時の IIS Express の構成では、Host ヘッダが 「localhost」 でないと「おっと、これは "自分" 宛ての要求じゃないな」と判断してしまう。
その結果、HTTP 400 Bad Request「Invalid Hostname」を返してしまうのだ。

そこで ngrok 側にて、中継の際に Host 要求ヘッダ値を指定の値 (このケースでは "localhost" ) に書き換えるのが「-host-header=」オプションである。

まとめ

さて、毎回ランダムな URL になるとはいえ、LAN 内にとどまらずインターネット上に開発中の Web アプリを公開するということは、それなりのリスクはあるかもしれない。

とはいえ、必要になったらコンソールから ngrok コマンドを叩くだけで、スマホから容易にアクセスできるというのも魅力的だ。

ngrok は無償から利用可能。
毎回ランダムな URL ではなく固定したり、1度に複数の "中継" をしたり、といった使い方をしたくなったら有償プランに移行すればよい。

以上、インターネット上に公開されているという点はしっかり考慮しつつ、リスクとメリットを勘案して適宜利用するとよいと思う。
 
by developer-adjust | 2016-04-14 20:05 | Web系一般 | Comments(0)
2015年 12月 25日

Azure Web Apps 上で稼働している ASP.NET Web API サーバーでの補足されない例外を記録・通知する方法

ASP.NET Web API によって実装した Web アプリ/API サーバーを、Azure Web Apps 上に配置、運用する際の話題。

過去に似たような話題でブログ記事を投稿しているが、

Azure Websites に配置した ASP.NET Web アプリで、捕捉されない例外のログを記録してみた、けど...
http://devadjust.exblog.jp/21591888/

ASP.NET Web API v2 だとまたちょっと事情が違うようで、APIコントローラのアクションメソッド内で補足されない例外発生しても、素の状態では、Azure Web Apps のイベントログには何も記録されない様子なのだ。

そこで以下の要領でプログラムにもテコ入れをして運用している。

ASP.NET Web API での補足されない例外発生を、Trace.TraceError("~") の呼び出しに振り替える


詳しくは下記参照。

miso_soup3 Blog - ASP.NET Web API 2.1 その 2 ~Global Error Handling~
http://miso-soup3.hateblo.jp/entry/2014/01/22/022129

具体的には下記のコードを実装する。



Trace.TraceError("~") の内容がテキストファイルに保存されるように、Azure Web Apps の設定を変更する


Azure のポータル画面 ( https://portal.azure.com ) にサインインし、対象 Web アプリの設定画面までブレードを開く。

そして「設定」をクリックして設定ブレードを開き、「診断ログ」をクリック。

ログブレードが開くので「アプリケーション ログ (ファイルシステム)」を「オン」に切り替えて、最後に「保存」をクリック。
d0079457_1183249.png

これで C# コードの Trace.TraceError("~") の内容が、Azure Web Apps のファイルシステム上にテキストファイルで保存されるようになる。

なお、本投稿ではファイルシステムへの保存を選んだが、もちろん、Azure ストレージアカウントへの保存を選んでも運用可能だろう。

HTTP 500 が発生していたらメールによる通知を送信するよう、Azure Web Apps の設定を変更する

次に対象 Web アプリのブレードから「ツール」をクリックしてツールブレードを開き、「警告」をクリック。

アラートルールブレードが開くので、「ServerErrors (サイト名)」のアラートルールがもしすでにあればこれをクリック。
無ければアラートルールブレードの「アラートの追加」をクリック。

ルールの編集ブレードが開くので、ここで以下の要領でルールを編集する。

メトリック ... "Http Server Errors"
条件    ... "より大きい"
しきい値  ... "0"
期間    ... "直近 5 分"
...に電子メールを送信 ... チェック On

勿論、要件に応じて上記パラメータは適宜都合のよいように変更されたし。
例えば電子メールアドレスは、このルール編集画面で即値指定もできるし、はたまた、電子メール通知ではなく Web Hook による外部サービスへの通知も可能な模様 (Web Hook は自分では試したことがない)。
d0079457_1184011.png

以上で「保存」をクリック、さらに「有効」をクリックしてこのアラートルールを有効化する。

ASP.NET Web API アプリにおいて、補足されない例外発生時は通常 HTTP 500 ステータスによる返答を伴うはず。
なので、以上のアラートルールの設定によって、補足されない例外発生時にメールが送信されるようになる。

なお、このアラートルールによるメール通知は5分間隔で監視・実行されている様子。
補足されない例外発生したら即時にメール通知が届くわけではないようだ。

ログファイルの内容を見るには

方法その1.FTP/FTPSでダウンロード

先の手順で「設定」→「ログ」ブレードを開いたときに下のほうに表示されている FTP や FTPS の接続情報にて、FTP/FTPS クライアントから接続すれば、保存されたテキストファイルを取り出すことができる。

方法その2. ログブラウザの拡張入れてブラウザ上から閲覧

その他にも「ツール」→「拡張機能」→「追加」から、「Azure Web Site Logs Browser」拡張機能を追加すると、この拡張機能によって、Azure ポータル画面経由で Web ブラウザ上でログファイルの内容を閲覧できてなかなかに便利だ。

方法その3. Visual Studio のクラウドエクスプローラとか

はたまた、Visual Studio の「サーバーエクスプローラ」ないしは「クラウドエクスプローラ」からも、Azure に接続してアプリケーションログファイルをダウンロードして閲覧することができる。
d0079457_11501624.png
以上、状況・好みに応じて選択するとよいだろう。

まとめ

以上のアプリ側の実装と、Azure Web Apps の設定変更によって、万が一の補足されない例外発生時は、メールで通知がなされ、テキストファイルに記録されたログファイルを閲覧することで例外の内容を捜査可能となった。

ほかにもっと良い運用方法があるのかもしれないが、log4net や Elmah、NLog、あるいは Application Insights や New Relic などに依存せずにプラットフォームの引っ越しを容易にできるよう手軽に実現するとなると、こんな設定・運用になるのではないだろうか。

小規模・低負荷な API アプリを小さく運用する場合にのみ当てはまるシナリオかとは思うが、それでもどなたかの参考になれば幸いである。
 
by developer-adjust | 2015-12-25 12:34 | .NET | Comments(0)
2015年 12月 19日

複雑な条件分岐にサヨウナラ。ルールエンジンとして Prolog を使って複雑な条件をシンプルにしてみた

Qiita で下記記事を見つけて。

複雑な条件分岐にサヨウナラ。
PHPのルールエンジンRulerを使って複雑な条件をシンプルにしてみた

http://qiita.com/ritukiii/items/47443e0fb2988c1332b2

この記事を読みながら、
そういえばこの類の論理判定なら "Prolog" がお手の物では...?
と思いった。

"Prolog" とは?

"Prolog" (プロログ) とは、プログラミング言語のひとつ。
「○○は□□である」といった論理の定義を集積して、「△△は◇◇であるか?」のような問い合わせで駆動するプログラミング言語である。

例えば Prolog の実行環境で「ソクラテスは "人 (human)" である」と定義し (以下はその定義を行う実際の Prolog コード)、
human(socrates).
続けて「死ぬ運命(mortal)にある X とは "人" である」と定義しておく。
mortal(X) :- human(X).
ここまで済ませてのち、「ソクラテスは死ぬ運命にあるか?」とその Prolog 実行環境に "問い合わせ" することができ、
?- mortal(socrates).

すると、Prolog 実行環境は「ソクラテスは "人"」⇒「"人" は死ぬ」という定義の探索から、「ソクラテスは死ぬか?」の問い合わせに対し「Yes」と答えてくれる。

このように論理を積み重ねてプログラミングを作っていくのが Prolog の特徴である。

なので、先の Qiita の記事にあるような「結婚花子さんと結婚できるか?」のような論理問合せのルール定義を、Prolog で書くと、実に実直に記述できるのだ。

「結婚花子さんと結婚できるか?」は、具体的には以下のとおりに記述できる。



結婚可能の条件を列記したあと、求婚男性の名前と "スペック" をさらに定義し、結婚可能条件に適合する求婚男性を問い合わせする、という流れである。

Prolog ならではの面白さ

この作例では、結婚可能条件の定義で求婚男性のスペックを参照するように作成した。
しかし別の実装として、求婚男性のスペックを参照せず、直接、結婚可能条件の引数に、年収や身長等の特徴を記述することもできる。

しかしながらこの作例のように作っておくことで、複数名の求婚男性のスペックを定義してある中から、「結婚可能なのは誰か?」と問い合わせ、結婚可能な男性の名前を列挙することができる。

単に条件を満たすかどうかだけであれば、先の PHP のルールエンジンであるとか、Haskell などでもおそらくは Prolog 並みに容易に記述可能ではないかと想像される。
いっぽう、このように条件に適合するものを列挙する、ということをシンプルに記述・問い合わせできるのは Prolog の面白いところだと思う。

Web アプリからも使いたい!

さてこのように、ルールエンジンの DSL としても活用できる Prolog。
この Prolog を活用しつつ、「年収・身長・偏差値等々のパラメータを入力して、結婚花子さんと結婚できるかを判定する Web アプリ」を作ろうとしたら、どうすればよいだろうか。

ひとつの選択肢として、C# 等の .NET 言語による ASP.NET Web アプリ内で、同じく .NET 言語から呼び出し可能なクラスライブラリとして実装されている Prolog インタープリターを呼び出す、という方法がある。

ということで実際に実装してみた作例がこちら。

Using Prolog as rule engin on ASP.NET
https://sample-of-prolog-on-aspnet.apphb.com/
d0079457_21594876.gif
ソースコードは GitHub 上で公開している。

https://github.com/sample-by-jsakamoto/UsingPrologAsRuleEngineOnASPNET/

上記 GitHub リポジトリに掲載の README に記載している「Deploy to heroku」や「Deploy to Azure」ボタンから、皆さんご自身の Heroku 又は Azure Web Apps アカウントに配置することも可能だ。

Prolog コードを記述した文字列を読み込んで解釈実行するインタープリターとしては当初は先のツイートのとおり P# を使おうかと思っていた。
だがライセンスが不明であり NuGet パッケージにもないことから P# の採用は見送り。
nuget.org で "Prolog" をキーワードに検索すると数件ヒットするが、諸事情の結果、自分が sourceforge から fork した C#Prolog を採用。

C#Prolog を「PM>Install-Package CSProlog -pre」でプロジェクトに追加したら、
  1. PrologEngine オブジェクトを new して、
  2. 次に ConsultFromString() で定義を読み込ませ、
  3. 最後に GetFirstSolution(引数:問い合わせの Prolog コード文字列) を呼び出して、適合するものがあったかどうかの結果を取得する、
というシンプルな構造だ。

結婚可能判定 Web アプリでも、(コメントも空行も含めて) たかだか 19行程度でこの動作が記述できている。
求婚男性のスペックを表す Prolog コードの文字列を組み立てているのに若干行数がかさんでいるほどだ。

このデモサイトでは、結婚可能条件を示す Prolog コードを Web フォーム上から送り込むようにしてある。
そのため、Web フォーム上のテキストエリアに入力されている Prolog コードを変更して、色々な結婚可能ルールを定義して試すことが可能だ。

さらにはソースコード入手の上、「※但しイケメンに限る」チェックボックスを追加してそのルールを実装するなど試してみると、より深く学べるかもしれない。

まとめ

ルールエンジンとして活用可能な Prolog。
Prolog を "極める" のは結構大変かもしれない (プログラミングのパラダイムシフトを求められると思うので)。

しかし、
新たにルールエンジンライブラリの使い方を学ぶコストを払うのであれば、
ルールエンジンとして使える程度までに Prolog を学ぶコストといい勝負かも、

と思った次第。

実際、自分は今回は採用しなかったが、Unity 向けに UnityProlog なるものもあるようなので。

なお、ideone.com でも Prolog はサポートされてる。
つまり「Prolog の処理系持ってない」「インストール面倒」という方でも、インターネット接続さえあればいつでもどこでもブラウザ1本で Prolog を試すことができる。
ご参考まで。

Happy Coding! :)
 
by developer-adjust | 2015-12-19 22:22 | .NET | Comments(0)