@jsakamoto

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

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

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

このプロパティが 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 でつながってるのかどうかを判定できるようになった。

　

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 サポートの追加を選択するか、

あるいは既存の ASP.NET Core プロジェクトをソリューションエクスプローラ内からの右クリックで Docker サポートの追加を行うことができる。

Docker サポートが追加されると、ソリューションの下に、主体である ASP.NET Core プロジェクトとは別に、Docker Compose のプロジェクト (.dcproj ファイル) が追加される。

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 イメージが作成される。

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」イメージにて設定が盛り込まれているようだ)

以上のことから、このイメージ内で稼働する 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 に配置することも可能だ。

ちなみに、この 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 上に配置しても、期待どおり動作してくれるようになる。

以上!

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 で実装しておけばよかったと反省である。

　

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 ならもっと簡単だった。詳しくはこちら。

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 のアプリケーション構成の中に、データベース接続文字列をポータル上から指定できるようになっている。

web.config の connectionStrings セクションと、この Azure のポータル設定とで同じ名前のエントリがあると、Azure のポータルで設定したデータベース接続文字列のほうが優先して採用されるのだ。

この仕掛けにより、

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

体制とすることができる。

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

...と、ここまではおさらい。

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

さて、以上の仕組み・体制で大抵の場合は問題ない。

しかし稀ではあるものの、開発環境においてデータベース接続文字列を変更したい需要がある。

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

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

LocalDB 2014を使っている場合、接続文字列はData Source=(LocalDb)\v11.0 じゃないし v12.0 でもないし ProjectsV12 でもなく、正解はData Source=(LocalDb)\MSSQLLocalDB でした。お疲れ様でした。

— ちきさん (@ovrmrw) April 1, 2015

まぁ普通に考えると、指定のバージョンの 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" がプロジェクトフォルダに存在しなければ、既定の内容で生成」

というバッチスクリプトをプロジェクトファイルに組み込んでおくのだ (下記例)。

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" をプロジェクトに含め発行対象となるようにしておけばよい。

こうしておくことで、

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

といったことができる。

まとめ

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

実際、もしも Azure Web App への配置が CI/CD の仕組みではなく手動による配置だと、配置を行うメンバーが "connectionStrings.config" を既定とは違う内容に書き換えていたら、それが Azure 上に配置されてしまうという気持ち悪さもある。

(どのみち、ポータルで設定されたデータベース接続文字列に上書きされて動作するはずなので、実害はないはずだが)

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

広く勧める技法ではないが、同じような需要に迫られてお困りの方の一助になれば幸いである。

よりクールでスマートなやり方・運用があればご教示いただければ嬉しい限り。

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

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

先に結論書いておくと、

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

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

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

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

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 ～」を実行するようにせよ、とのこと。

ということで氏の記事に従い、以下のように設定して試してみた。
しかしまたしてもテスト実行でコケる（ログは下記）。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

え、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 作ってみたらもっとすんなりできたりするのか、興味あるところである。
いずれ機会があれば試してみたい。
　

Azure Functions - Azure Table Storage との連携を試す

以前の投稿で、Azure Functions を活用することで、各種 Selenium WebDriver ファイルのバージョンアップを定期的に監視、メールで通知する、C# 実装による仕組みを作ったことを書いた。

Azure Functions を使って Selenium WebDriver の新バージョンリリースの通知を受け取る
http://devadjust.exblog.jp/23744108/

さて、新バージョンリリースを検知するためには、それまで時点でわかっている最新バージョンをどこかに保存・永続化しておく必要がある。

新バージョンリリースのチェック実行時、

• 今回チェック時に取得したバージョン番号と、
• その保存・永続化してあったバージョン番号

とを比較することで、新たなバージョンがリリースされたかどうかが判断できるためだ。

そのように最新バージョン番号を保存・永続化する具体的な手立てとして、安価で使い慣れている Azure Table Storage を採用したのであった。

そして前回投稿に書いたように、C# によるファンクション中から Azure Table Storage の読み書きを行うにあたっては、Azure Functions だからといって特別なことは何もない、いたって普通の C# による Azure Table Storage アクセスコードをゴリゴリと記述することで済ませていた。

しかし、である。

Azure ポータル Web サイト上での、Azure Functions の管理画面をいじっていると、入力 (Input) や出力 (Output) のバインディング(連携)先の選択肢に、"Table Storage" という選択肢が用意されているのだ。
ということで、Azure Functions が予め用意してある、Azure Table Storage との連携方法について調べてみた。

...なお、先に断っておくと、本記事に記載の内容は、下記の公式ドキュメントサイトをなぞった内容が多くを占めているので、その点は悪しからず。

Azure Functions Storage table bindings
https://docs.microsoft.com/en-us/azure/azure-functions/functions-bindings-storage-table

連携その1. Azure Table Storage のエンティティを引数にもらう

まずは入力から。

つまり、ファンクションの実行時に、(本稿は C# スクリプトでのファンクション実装を前提にしているので) Run 静的メソッドの引数に Azure Table Storage のエンティティ ( ≒ レコード ) を渡してもらえる、という連携だ。

Azure Functions は、Azure Table Storage の入力連携に関して、"条件に該当するエンティティを最大 n 件取得して引数に渡してもらう" など、いくつかのシナリオに対応している。
ここでは、予め決めておいた特定の 1 エンティティを引数に渡してもらう方法について記す。

とりあえずは何か適当なファンクション (タイマーで起動とか、手動で起動とか) がすでに作成済みであるとしよう。

※以降では、タイマー起動のテンプレートで作成した既存のファンクションに対し、編集する例で示す。

function.json

まずはファンクションの引数や戻り値をどう外部と連携させるかなどを設定している JSON ファイル「function.json」を編集する。

※註: Azure ポータル Web サイト画面上からは、既定では "Standard editor" と称される GUI フォーム画面から function.jsonでの構成内容を編集可能となっている。しかし、この GUI フォーム画面は、本稿作成時点では不都合な振る舞いがあったりする (例えばここでの説明のように "読み取る最大件数" を省いて設定したい場合に、しかし GUI フォームの "Standard editor" では既定の "50" が再表示されてしまう、など) 。そのため、function.json をテキストとして直接編集する "Advanced editor" モードに切り替えて編集する (下図)。下記の要領で、bindings に type="table" の項目を追加する。

{

  "bindings": [

    {

      "name": "myTimer",

      "type": "timerTrigger",

      "direction": "in",

      "schedule": "0 0 0 * * *"

    },

    {

      "type": "table",

      "name": "tableEntity",

      "tableName": "Foo",

      "partitionKey": "fizz",

      "rowKey": "buzz",

      "connection": "StorageConnectionString",

      "direction": "in"

    }

  ],

  "disabled": true

}

プロパティ名と上記記載例から概ねくみ取ってもらえると思うが、function.json にて、"1 エントリ" を特定する情報をすべて記載しているのがポイントだ。

上記例に基づき解説を加えると下記のとおりだ。

• ストレージアカウントへの接続文字列を記載したアプリケーション構成のエントリ名 = "StorageConnectionString"
• そのアカウント中の Table 名 = "Foo"
• その Table 中の1エンティティを特定するパーティションキー = "fizz" と行キー = "buzz"

例によって、接続文字列などのパスワードやキーを含む設定内容は、アプリケーション構成のほうに設定しておき (下図)、function.json からは、その設定エントリ名で参照する仕組みだ。

run.csx

さて次は、対する C# (スクリプト) の実装。

まず、受け取るエンティティを表現するクラスを、run.csx の冒頭で記述する。
例えばこんな感じ。

public class FooBar {

    public string PartitionKey { get; set; }

    public string RowKey { get; set; }

    public string SomethingElse { get; set; }

}

TableEntity クラスから派生する必要がないのは知らなかった。
その代わり、PartitionKey と RowKey のプロパティは必須である。
あとは、function.json で指定した連携対象の Azure Table と同じ構造となるようにプロパティを備えれば OK だ。

あとは Run 静的メソッドの引数に、function.json で指定したのと同じ引数名で、先述のクラスの型を引数を受け取るようにすればよい。

public static void Run(

  TimerInfo myTimer, 

  FooBar tableEntity, 

  TraceWriter log

){

 ...

}

以上で、

• 所定の接続文字列で接続したストレージアカウントの、
• "Foo" テーブル中、
• パーティションキー = "fizz"、行キー = "buzz" のエンティティが、
• FooBar 型のオブジェクトにマッピング・逆シリアル化されて、
• それが引数 tableEntity に渡されて
• Run 静的メソッドが実行される

ようになる。

補足・感想

なお、function.json で指定した条件に合致するエンティティが見つからない場合は、"Object reference not set to an instance of an object." という例外で落ちるようだ。

このようなシナリオ ( 予め読み取り条件が固定の "特定の1エントリ" だけを参照したい ) では、エンティティの特定条件を function.json に宣言的に記述するだけで、C# コード上は Azure Table Storage にアクセスするコードを一切書かずに、いきなりエンティティにマッピングされたオブジェクトとして入手・参照できる。

これはかなりシンプルで便利だと思う。

先述のとおり、公式ドキュメントサイトを見るとわかるように、入力連携にはほかにもいくつか対応シナリオがある。
目的・要件と、Azure Functions 側で用意してあるシナリオ・連携方式が合致する場合は、効率よく記述できそうだ。

連携その2. Azure Table Storage にエンティティを追加する

次いで出力。

つまり、ファンクションの実行によって、Azure Table Storage にレコード追加される、という連携だ。

入力の例の場合と同様、何か作成済みのファンクションについて、話を進める。

function.json

まずは function.json から。

下記要領で連携方法の記述を追加する。

{

  "bindings": [

    {

      "name": "myTimer",

      "type": "timerTrigger",

      "direction": "in",

      "schedule": "0 0 0 * * *"

    },

    {

      "type": "table",

      "name": "outputTable",

      "tableName": "Foo",

      "connection": "StorageConnectionString",

      "direction": "out"

    }

  ],

  "disabled": true

}

コンテナへの接続文字列の指定と、エンティティ追加対象となるテーブル名までを function.json で指定しておく。

run.csx

次いで C# コード (run.csx)。

何はともあれ、対象 Table のエンティティを表すクラスを定義しておく。
ここは入力連携のときと同じ。

public class FooBar {

    public string PartitionKey { get; set; }

    public string RowKey { get; set; }

    public string SomethingElese { get; set; }

}

そして Run 静的メソッドの引数なのだが、function.json 中、name で指定したのと同じ引数名で、ICollector<エンティティにマッピングするクラス> 型の引数を追加する。

public static void Run(

  TimerInfo myTimer,

  ICollector<FooBar> outputTable, 

  TraceWriter log

)

{

  ...

}

あとは、この引数に渡された outputTable に対し、Add メソッドを使ってエンティティを表すクラスのインスタンスを追加するコードを書けばよい。

public static void Run(

  TimerInfo myTimer,

  ICollector<FooBar> outputTable, 

  TraceWriter log

)

{

  ...

  outputTable.Add(new FooBar{

    PartitionKey = "fizz",

    RowKey = "buzz",

    SomethingElse = "wow!"

  });

  ...

}

こうすることで、引数 outputTable に追加されたオブジェクトが、function.json で指定した Azure Table へのエンティティとして追加される。

補足・感想

1回の Run メソッド呼び出しでも、その Run メソッド中で繰り返し Add メソッドを呼び出して複数オブジェクトを追加すれば、追加したオブジェクトぶんの複数エンティティが Azure Table に追加される。

なお、パーティションキー・行キーが重複するオブジェクト(エンティティ)を追加した場合は、Run メソッドを抜けたあと、ICollector<T> の引数に追加した内容をフラッシュするタイミングで、下記のような例外が発生するようだ。

Error while handling parameter outputTable after function returned:. Microsoft.WindowsAzure.Storage: 0:The specified entity already exists

感想としては、Azure Table Storage との接続処理などをこまごま C# コード側に明記しなくて済むので、うれしい印象だ。

では、更新はどうやるの?

さて、ここまでのシナリオでは、エンティティを読み取るか、追加するかだけで、既存のエンティティを更新するシナリオがなかった。

冒頭で紹介した公式ドキュメントサイトを見ても、本記事投稿時点では、なんと、
更新の方法について記載がない。

ということで、更新をやるにはどうしたらよいか、粘り強くネット上で検索してみた。
すると StackOverflow に有力情報のスレッドを見つけた。

Azure Functions Table Binding: How do I update a row?
http://stackoverflow.com/questions/36792547/azure-functions-table-binding-how-do-i-update-a-row

上記スレッドによれば、ある程度は Azure Functions による連携支援はあるものの、基本的には従来通りの Azure Table Storage にアクセスする典型的なコードを記述するしかないとのことだ。

実際にやってみよう。

function.json

例によって、とりあえず何かファンクションはある状況から開始するとして。
function.json の記述はこうだ。

{

  "bindings": [

    {

      "name": "myTimer",

      "type": "timerTrigger",

      "direction": "in",

      "schedule": "0 0 0 * * *"

    },

    {

      "type": "table",

      "name": "cloudTable",

      "tableName": "Foo",

      "connection": "StorageConnectionString",

      "direction": "in"

    }

  ],

  "disabled": true

}

出力連携のときとほぼ同じだが、"direction" (方向) の指定が "out" (出力) ではなく "in" (入力) になってることに注意。

run.csx

そして C# コード (run.csx) 側であるが、まず冒頭に、Microsoft.WindowsAzure.Storage アセンブリへの参照が必要になる。

#r "Microsoft.WindowsAzure.Storage"

記述を短縮化するために、名前空間 Microsoft.WindowsAzure.Storage.Table も冒頭でオープン (using) しておこう。

using Microsoft.WindowsAzure.Storage.Table;

で、先述の連携方法では、何からも派生させることは不要だったエンティティを表すクラスだが、この更新系の実装においては TableEntry からの派生が必要となる。

public class FooBar : TableEntity {

    public string SomethingElese { get; set; };

    public FooBar(){ }

    public FooBar(string partionKey, string rowKey) : base(partionKey, rowKey){ }

}

そして Run 静的メソッド。

functuon.json 中で指定した引数名で引数追加となるが、引数の型は CloudTable とする。

public static void Run(

  TimerInfo myTimer, 

  CloudTable cloudTable, 

  TraceWriter log

){

  ...

}

あとは、こうして引数に渡された CkoudTable オブジェクトに対し、Azure Table Storage の読み書き処理を記述するだけだ。

例えば以下のような感じ。

public static void Run(

  TimerInfo myTimer, 

  CloudTable cloudTable, 

  TraceWriter log

){

    // パーティションキー="fizz",行キー="buzz"のエンティティを検索

    var query = TableOperation.Retrieve("fizz", "buzz");

    var result = cloudTable.Execute(query);

    

    // 該当エンティティがあればその参照を取得、なければ new で新規作成

    var foobar = result.Result as FooBar ?? new FooBar("fizz", "buzz");



    // エンティティの内容を書き換え

    foobar.SomethingElese = "hey!";

    

    // 無ければ追加、あれば更新

    var upsert = TableOperation.InsertOrReplace(foobar);

    cloudTable.Execute(upsert);

}

補足・感想

読み込みのみ、または新規追加のみの連携と比べると、抽象度がぐっと下がってしまい、"生の" Azure Table Storage 読み書きのコードとなってしまった。

とはいえ、接続を開設して CloudTable オブジェクトを用意するところまでは書かずに済む。

まとめ

Azure Table Storage に対し「読むだけ」「追加するだけ」の場合は、Azure Functions が用意してくれている連携の仕組み ( バインディング ) により、ファンクションを実装する側はずいぶんとシンプルに書けるようになっていい感じである。

いっぽうで、既存のエンティティを「更新」する仕組みはずいぶんと荒削りだ。
生々しい Azure Table Storage へのアクセスコードを書くしかないのが今日時点での実情である。

しかし先の StackOverflow のスレッドによれば、"These steps will get easier with our next release," とのこと。
今後の Azure Functions の進化・アップグレードにより、"更新" シナリオについてももっとシンプルな実装手段が提供されることが期待はできそうだ。

それまでの間は、Azure Table Stoarge に対し更新系の連携が必要な場合は、上記のとおり CloudTabel オブジェクトで連携する手法でしのぐのが無難そうである。

それでも接続文字列の取得からはじめてすべて自前で記述するよりはマシだろう。

以上、Azure Functions における Azure Table Storage バインディングのまとめとする。
　

Azure Functions - 既存のファンクションに、SendGrid 連携によるメール送信をあとから付け足す

C# スクリプト、又は F# スクリプトで、「メールを送信する」という Azure Function App の "ファンクション" を実装する際の話。

Azure Functions では、"トリガー" (ファンクションを実行するきっかけ) やファンクションの実行結果として、様々な外部サービスと連携できるようになっている。

実行結果のひとつとして、メール送信サービスのひとつである SendGrid を使ってメール送信を行う、ということができる。

もちろん、C#/F# スクリプトでは、古くから .NET Framework に標準装備されている System.Net.Mail.SmtpClient クラスを用いることで、Azure Functions のファンクション中から任意の SMTP サーバに対してメール送信を行うことが可能だ。

とはいえそれはそれとして、Azure Functions が備える SendGrid 連携によるメール送信の実装がどのようなものか、試してみることにした。

新たなファンクションを作るなら...

「実行結果として SendGrid 連携によるメール送信が行われる」という "ファンクション" を、Azure ポータル Web サイト画面上から新規に追加するのであれば、帝国兵さんの下記の Qiita 記事が詳しい。

Azure Function Appから定期的にメールを送る
http://qiita.com/superriver/items/d245539b7652b7512f9b

既存のファンクションに、ポータルから付け足すこともできそうだが...

いっぽう、すでに実装済みの既存の "ファンクション" に対し、あとから「実行結果として SendGrid 連携によるメール送信が行われる」ようにすることも、当然可能である。

Azure ポータル Web サイト画面からは、当該 "ファンクション" のブレードを開いている状態から、「Integrate」カテゴリにて、「Outputs」の箇所で「+ New Output」をクリックすると、"ファンクション実行結果の出力内容" の選択肢がずらっと出てくる。
ここから「SendGrid」を選択すれば良いらしい。すると、画面に SendGrid 連携に関する必要構成項目の入力欄が現れ、宛先やら差出人アドレスやらが設定可能だ。ただこれにはちょっと落とし穴があって、ここまでの作業だけでは足りない。
詳しくはあとで説明するが、さらに Run.csx の変更も必要なのだ。

外部からデプロイしてるとポータル画面からは操作できない

さらに言えば、ローカル開発環境で開発していてそれを「Web発行」や ローカル Git リポジトリからの "git push"、はたまた CI 連携などの方法で Azure Functions 上にデプロイしている場合は、Azure ポータル Web サイト画面上での上記操作はロックダウンされてしまう（当たり前だが）。

ということで、手作業で各種ファイルを編集することで、既存の "ファンクション" に、実行結果として SendGrid 連携によるメール送信が行われるように変更する手順を明らかにしてみた。

仕組み・構造

改めて「"ファンクション" の実行結果として SendGrid 連携によるメール送信が行われる」仕組み・構造をまとめると以下のとおりだ。

"ファンクション" の戻り値に、SendGrid 用ライブラリに収録の Mail 型のオブジェクトを返すように構成することで、その "ファンクション" が実行された結果の戻り値で返却された Mail オブジェクトを用いてメール送信が実行される。

準備・前提条件

何はともあれ SendGrid サービスを使うのだから、SendGrid にサインアップして SendGrid アカウントを取得しておく必要がある。

Azure Functions で～という話なので、Azure のアカウントからマーケットプレイスで特典アカウントとして SendGrid アカウントを作成するのがよいだろう。

SendGrid アカウントができたら、API キーを生成し入手。

さらに、その API キーについて「Mail Send」「Alerts」「Email Activity」「Stats」の機能アクセス可否を「Full Access」に設定 ( Full Access の選択肢がないものは 「Read Access」) しておく。

このあたりの手順は先に紹介した Qiita 記事を参照されるとよろしいかと (URL再掲)。

準備1: SendGridのアカウントを作る
http://qiita.com/superriver/items/d245539b7652b7512f9b#%E6%BA%96...

準備2: SendGridのAPIキーを得る
http://qiita.com/superriver/items/d245539b7652b7512f9b#%E6%BA%96...

実装手順

すでにある "ファンクション" に、実行結果として SendGrid 連携によるメール送信が行われるようにする改造・変更手順は以下のとおり。

※なお、以下の説明では C# スクリプトで実装していることを前提に進めるが、F# スクリプトでも編集内容に大差ない。

"project.json" に、SendGrid NuGet パッケージを使用する旨を追記。

{

  "frameworks": {

    "net46": {

      "dependencies": {

        ...

        "Sendgrid": "8.0.5"

      }

    }

  }

}

※どうも、Azure ポータル Web サイト画面上での実装作業においては、project.json がなくても SendGrid のアセンブリが参照可能になっているように見える。が、とりあえずローカル開発環境でインテリセンス等の IDE 支援を得ることを前提として、上記のとおり NuGet パッケージを明示的に示す説明とする。

"function.json" に、SendGrid によるメール送信に関する構成を追記。

{

  "bindings": [

    ...,

    {

      "type": "sendGrid",

      "name": "$return",

      "direction": "out",

      "apiKey": "SendGridApiKey",

      "from": "Azure Functions <samples@functions.com>",

      "to": "foo@example.com"

    }

  ],

  "disabled": false

}

ちょっと落とし穴だったのが、"apiKey" プロパティの設定。

上記では「"apiKey": "SendGridApiKey"」としているように、
ここに実際の API キーを書いてはいけない。

このプロパティで指定しているのは、そのプロパティ名とは裏腹に API キーそのものではなく、
API キーを格納しているアプリケーション構成のエントリ名を指定
しているのだ。
(今さらだけど、なんでこんなプロパティ名にしたんだ...orz)

なので、後述するとおり、Azure ポータル Web サイトのアプリケーション構成設定画面にて、"SendGridApiKey" というエントリ名で SendGrid の API キーを設定追加する必要がある。

ちょっと話が逸れるがもうひとつ。

上記要領の "function.json" の編集が、どうやら、Azure ポータル Web サイト画面上から「+ New Output」したときの編集内容に該当する模様だ。

なので、もしも Azure ポータル Web サイト画面上でコーディングしてて、「Integrate」カテゴリで「+ New Output」で SendGrid を追加した場合は、ここまでの手順は不要で、このあとの Run.csx ( F# なら Run.fsx ) の編集以降の手順を行えばよい。

さて、話を戻して。

run.csx にて、SendGrid NuGetパッケージで提供される、SendGrid アセンブリへの参照設定を追記。
ついでにコードを略記できるよう名前空間「SendGrid.Helpers.Mail」も開いておく。

#r "SendGrid"

using System;

using SendGrid.Helpers.Mail;

...

ファンクション本体である "Run" 静的メソッドの戻り値を、(SendGrid アセンブリが提供する、SendGrid.Helpers.Mail 名前空間の) Mail 型とするよう変更。

public static Mail Run(...)

{

  ...

送信したいメール内容のとおり Mail オブジェクトを組み立てて、Run メソッドの戻り値として返却。

public static Mail Run(...)

{

  ...

  var message = new Mail()

  {

      Subject = "(件名)"

  };

  var content = new Content

  {

      Type = "text/plain",

      Value = "(メール本文)"

  };



  message.AddContent(content);

  return message;

}

最後に、Azure ポータル Web サイトの画面にて、「Function app setting」カテゴリから「Configure app settings」を開いて、アプリケーション構成に SendGrid の API キーを掲載したエントリを追加。このときのエントリ名は、"function.json" 中で指定した、"apiKey" プロパティの指定に従う。
以上で、このファンクションが実行されると SendGrid 連携によるメール送信が行われるようになる。

メール送信についてエトセトラ

ここまでの説明で例示した "function.json" では、宛先と差出人アドレスだけ指定していたが、件名や本文も "function.json" 中にて指定可能だ。

たとえば "function.json" に

{

  "bindings": [

    ...,

    {

      "type": "sendGrid",

      ...

      "from": "Azure Functions <samples@functions.com>",

      "to": "foo@example.com",

      "subject": "Hello",

      "text": "World"

    }

  ],

  ...

}

というように subject プロパティと text プロパティを追記しておけば、Run メソッドからは下記のとおり Mail オブジェクトを new して返すだけで、ほかのコーディング不要で、"function.json" にて指定された宛先・差出人アドレス・件名・本文にてメール送信が行われるようになる。

return new Mail();

はたまた、その逆というか、Run メソッド中でことごとメール送信内容を指定すれば、"function.json" での指定よりも優先してその指定内容が採用される。
なので、宛先や差出人アドレスも、Run メソッド中で実行時に指定可能だ (下記例)。

return new Mail(

  from: new Email("foo@example.com"), 

  subject: "(subject)", 

  to: new Email("bar@example.com"), 

  content: new Content(type: "text/plain", value: "(body)"));

あと、ファンクションが実行されてもメールを送信したくない場合は、Run メソッドの戻り値として null を返せばよいようだ。

return null;

まとめ

以上のとおり、Azure Functions が備える SendGrid 連携を使ってメール送信を行うよう、ファンクションを構成することができることがわかった。

System.Net.mail.SmtpClient を使った場合と比較して、Run メソッド中の記述量が減り、本来の「こういう内容をメール送信したい」という、
"やりたいこと" に集中して記述できる
のはよいと感じた。

とくにメール送信のサービスとして SendGrid を採用している場合は、API キーに基づいた認証・アクセス権管理となるので、セキュリティ面でも System.Net.mail.SmtpClient を使うよりは安全・柔軟だと思われる。

参考) SendGrid ブログ「APIキー認証でセキュリティを強化しよう」
https://sendgrid.kke.co.jp/blog/?p=3659


ただし、1回のファンクション実行によって、複数のメール送信を行いたい場合は、この方式では対応できなさそう、と感じた。

もっとも、ファンクションは単機能にして、複数のファンクションを連携・積み重ねてより複雑・大規模な構成へと構築していくのがベストプラクティスとは思うので、メール送信の粒度ごとにファンクションを分ければ解決するかもしれない。

それでもどうしても1回のファンクション実行で複数のメール送信の必要がある場合は、Azure Functions プラットフォームによる SendGrid 連携はやめて、

• System.Net.mail.SmtpClient を使った古典的な実装に戻すか、あるいは
• SendGrid.Helpers.Mail 名前空間下のクラスライブラリを自前で呼び出して SendGrid API 経由でのメール送信を自前実装する

のがよいのだろう。
　

C# スクリプトでインテリセンスが効かずむしゃくしゃして F# スクリプトにしたら幸せだった (オチあり)

前回、「Azure Functions を使って Selenium WebDriver の新バージョンリリースの通知を受け取る」という記事を投稿した。

Azure Functions を使って Selenium WebDriver の新バージョンリリースの通知を受け取る
http://devadjust.exblog.jp/23744108/

このように、プラットフォームとして Azure Functions を選択、プログラミング言語は自分の得意な・慣れている C# を採用することで、「Selenium WebDriver の新バージョンリリースの通知を受け取る」という目的を達成できた。


達成できた、のであるが...

C# "スクリプト" に悩まされる

この実装当初、プログラミング言語は C# とは言いつつも、Azure Functions では、拡張子が .csx の、「C# スクリプト」というちょっと変わった体裁で記述する必要があった。

しかしこの「C# スクリプト」がくせ者。
ナ、ナント、Visual Studio (当時、2015 及び 2017RC 使用) 及び Visual Studio Code (当時 v.1.8.1) のいずれでも、インテリセンスをはじめ

一切の IDE 支援が効かない

のだ。

まぁ、結局 IDE 支援なしで実装しきったのではある。
しかし疲労感というか、なんか、通常の3倍くらい実装時間がかかってしまった気がする (※計測したわけじゃないのであくまで感想です)。

自分でも信じられないのだけれど、文末のセミコロンを打ち忘れて Azure Function 上にデプロイしてからいざ実行してみたら構文エラー、みたいなパターンも頻発。
まさか自分が、IDE が画面上に示すインジケータを頼りにセミコロン打っていたとは自覚もなく、人間って不思議ー、とか思ったりもしたけれど、しかしそんなことはどうでもいい。

とにかく IDE 支援がないとやってられないのである。

こんな状況ならば、C# (スクリプト) ではなく、JavaScript で記述することを選択したほうが IDE 支援が得られてよかったのでは、などと思ってしまった。

※ Azure Functions は C# スクリプトのみならず、JavaScript ももちろんのこと、PHP や Bash シェルスクリプトなど、ほかの様々な言語・処理系でコードを記述・実装できる。

ただし、実際に JavaScript で記述するとなると、自分の場合、言語の問題ではなく、Node.js の各種 API に不慣れだというごく個人的な理由でことごと躓くことが目に見えている。
だからこそ慣れている C# を選んだのに、である。

C# スクリプトで IDE 支援を受ける方法は?

なお、新生コンパイラサービス Roslyn をベースとした Microsoft 純正の「C# スクリプト」が登場する以前からも、「C# スクリプト」の実装・処理系は存在している。

そして、そうした旧来から存在する非純正「C# スクリプト」向けの Visual Studio 拡張もやはり存在する。
StackOverfolw などで、「.csx だとインテリセンス効かないんだけどどうしたらいい?」という質問に、その種の拡張を Visual Studio に入れたらいいよ、みたいな回答が付いてるのを見た覚えもある。

ということで、そういった拡張を入れれば良かったのかもしれない。

でも NuGet パッケージの参照とか対応しているのかなー、
拡張入れて試すのめんどくさいなー、
結局うまくいかなかったら徒労感はんぱないなー、
...とかいろいろ考えてしまって躊躇してしまった。

と、ふとここで大変遅まきながら思い出した。


そういえば F# スクリプトでよかったじゃん!

救世主 - F# スクリプト

そう、Azure Functions は、その記述言語として、F# にも対応していたのであった。

F# はその登場時点から REPL 環境を提供し (fsiコマンド)、拡張子 .fsx によるスクリプト形式の体裁にも対応している。
そしてもちろん、F# スクリプト (.fsx) であっても、強力な IDE 支援は、コンパイル用の F# 記述 (.fs) と変わらず提供されているのだ。

そしてまた、ライブラリ類は C# と同じく .NET Framework を使い、C# と同じ NuGet パッケージで実装できる。
もちろん F# 固有のライブラリや構文を学ぶ必要はある。
しかし、こと自分の場合に限っては、過去に F# の習得を試みていたこともあり、Node.js の API をググりながら実装するよりは遥かに速く実装できることが予想された。

ということで「Azure Functions を使って Selenium WebDriver の新バージョンリリースの通知を受け取る」を、試しに F# スクリプトで実装することにしてみた。

使用する IDE は Visual Studio 2017 (2017年1月時点ではリリース候補版)。

で、コーディングを進めたところ...(すっごく当たり前だけど) バッチリ IDE 支援が効いている!

Azure Table Storage を扱うところも、ちゃんとインテリセンスで候補が出るし、警告やエラーのインジケータも表示される。

かなりサクサクと実装を進めることができた。
最初から F# スクリプトを選択しておけばよかったかも、である。

Chrome Driver の新バージョンリリース検知のところだけ F# スクリプト化を試して満足。
成果物は GitHub に別ブランチとして掲載しておくことにした (下記 URL)。

https://github.com/jsakamoto/WebDriverUpdateDetector/blob/experimental/using-fsharp/ChromeDriverDetector/run.fsx

まとめ

IDE 支援のない C# スクリプトでコーディングするくらいなら、学習コストかけてでも事前に F# を少しでも習得しておいた上で、F# スクリプトを採用して Visual Studio or Visual Studio Code でコーディングしたほうが幸せになれそうな気がする。

ただし、もしかすると、何らかの Visual Studio 拡張を導入したうえでなら、C# スクリプトコーディングでも潤沢な IDE 支援を得られるのかもしれないが、未確認である。

おまけ

...なんていう本記事を書こうと思ってたら、なんと、Azure Functions に、ビルド済みの .NET アセンブリをデプロイできるようになったとのこと。

Azure Functions のプリコンパイルサポート https://t.co/X6wqgouiSf #jazug #azurejp

— こすもす.えび (@kosmosebi) January 6, 2017

すなわち、「C# スクリプト」という .csx ファイルで苦戦する必要なく、そしてまた F# が扱えなくとも、IDE 支援バリバリの、通常の C# プログラミングで開発を進められるということだ。

まだ自分は、この「ビルド済みの .NET アセンブリをデプロイ」方式は試していないが、こちらの方式のほうが本命かもしれない。
　

Azure Functions を使って Selenium WebDriver の新バージョンリリースの通知を受け取る

Selenium と WebDriver

"Selenium" とは、Web ブラウザをプログラムから "操作" できるようにする、主には自動化テストの実現などの目的で使用されるソフトウェア/ライブラリである。

そして "Selenium WebDriver" とは、個々の OS/ブラウザ種類に応じて提供される、ブラウザ操作の終端を担うプログラムを指す用語である。

自分の場合、対象 OS は Windows で、且つ、以下の Web ブラウザに対応した Selenium WebDriver にかかわる機会がある。

- Microsoft Edge (MicrosoftWebDriver.exe)
- Internet Explorer (IEDriverServer.exe)
- Google Chrome (chromedriver.exe)
- Mozilla Firefox (geckodriver.exe)

WebDriver の新バージョンリリースをタイムリーに捕捉したい

さて、詳細は割愛させていただくが、とある経緯から、上記の Selenium WebDriver プログラムについて、新バージョンがリリースされたら最大で1日程度のタイムラグを目安に、その新バージョンリリースを知る必要がある、という要件に迫られた。

もちろん、自分が手作業で毎日先述の URL をブラウザで開いて目視でチェック、というやり方は除外。
どうにかコンピュータプログラムの力で解決したい。

ということで、各 WebDriver について、IT/プログラミングの力でどうやすれば新バージョンリリースを知ることができるか調べてみた。

FireFox 用は楽勝

Mozilla Firefox 用の Windows 用 Selenium WebDriver "geckodriver.exe" は、開発元の GitHub リポジトリにて、"Release" としてアップロードされるようだ。

幸い、GitHub の Releae ページは、その URL の末尾に ".atom" を足せば、同ページの内容が Atom フィードとして入手できるとの情報を得た（下記 URL）。

https://github.com/mozilla/geckodriver/releases.atom

そこで自分の場合は "IFTTT" サービスを利用し、上記 Atom フィードについて新着更新があった場合は自分のメールアドレスに通知を送るように IFTTT を設定しておいた。

他にも Feedly をはじめとした RSS reader を利用してもよいだろうし、Release に限らず種々の通知を受け取って構わないならば単純に GitHub リポジトリの "Watch" を On にしておくだけでもよいだろう。

というわけで、以上で FireFox 用の WebDriver のリリースを検知する体制は整えることができた。

IE、Chrome の WebDriver はちょい面倒...

Internet Explorer と Google Chrome 用の Windows 版 Selenium WebDriver (各々IEDriverServer.exe と chromedriver.exe) はそれぞれ下記 URL でアクセスできる Amazon S3 ストレージに格納されている。

- https://chromedriver.storage.googleapis.com/
- https://selenium-release.storage.googleapis.com/

上記 URL に HTTP GET 要求を送ると、XML 形式でストレージの収録内容が返ってくる。

但し返される XML のスキーマは Amazon S3 のもの。
Atom フィードをはじめとした公共(?)の規格ではない様子である。

いろいろ思案した限りでは、どうやらこの XML を何らかのプログラムで定期的に取得・監視して、新バージョンのリリースを検知するほかなさそう、との結論に至った。

Edge 用は構造化されたデータがない...

さらには Microsoft Edge 用の Selenium WebDriver、"Microsoft WebDriver" であるが、こちらは、下記 URL のダウンロード用 Web サイトがあるのみ。
XML や Atom フィードのような、構造化されたデータとしては入手可能な感じではなかった。

https://developer.microsoft.com/en-us/microsoft-edge/tools/webdriver

となると残される道は、上記 URL で入手できる HTML コンテンツを、何かしらのプログラムによってどうにかスクレイピングしてリリース情報を抜き出すほかなさそうだ。

実装手段は?

さてさて、ではでは、どういう形で先述の XML や HTML を定期的に監視し、新バージョンのリリースを検知して自分に知らせるようなプログラムを作成・運用できるだろうか?

やり方は本当にいろいろあると思う。
24時間通電稼働させている自宅サーバーで cron で監視プログラムを定期実行とかもありだろう。

しかし自分は
サーバー構築とかまっぴら御免なタイプ(!)
なので、できれば SaaS、せいぜい頑張ってパブリッククラウドの PaaS で何とかしたい、と考えた。

そこで目を付けたのが Azure Functions だ。

Azure Functions

Azure Functions とは、別途構成された URL への HTTP 要求だとか、cron のような時間による指定とか、Blob に何か追加されたとか、そういった "トリガー" によって起動され、ある一定の処理上限時間やメモリ消費量制約のもと、自分で作成した小さなプログラムコード = ファンクション (関数) が実行されるという、ある種の PaaS である。

Microsoft のパブリッククラウドサービス「Microsoft Azure」に含まれる機能・サービスのうちのひとつだ。

"サーバーレス" という文脈で語られ、「Amazon Lambda の Azure 版」といえば通じる方もいるかと思う。

自分の場合は Azure の Web Apps サービスによる Web アプリ配置に慣れていることもあり、Amazon Lambda ではなく Azure Functions で実装してみることにした。

Azure Web Apps 上に自作 Web アプリを立てるのと比べると...

Azure Web Apps でも同様のことは実現できる。
自分で立てた Azure Web Apps 上の Web アプリにて、所定の URL に HTTP GET 要求が届いたら監視/リリース検知処理を実行するようにしておき、この URL に対して SetCronJob (https://www.setcronjob.com/) などで定期的に HTTP GET 要求を送るようにしてもよい。

しかしながら Azure Functions で作っておけば、課金が Web Apps とは違い、「その Web アプリを稼働させてる時間」ではなく、「トリガーによって所定のコードが起動され、終了するまでの時間とメモリ消費量」及び「実行回数」に対して課金されるため、
フトコロに優しい
のだ。

さらに、
コード内容が「やりたいこと」に集中
できる。

自分の場合、得意なプログラミング言語が C# なので、Azure Web Apps 用に Web アプリを作るとなると ASP.NET という選択になる。
そうなると「Web.config がー」「URL ルーティングの登録をー」といったコード類を記述せざるを得ない。

その点、Azure Functions であれば、コードの "型" が決まっている代わりに、その定型コードの中身を埋めるかたちで自分のやりたいことを記述していくので、本来やりたいこと以外の余計なコードの記述量が各段に減るのだ。

実装結果

ということで実践してみた結果がこちら。

https://github.com/jsakamoto/WebDriverUpdateDetector

実装のプログラミング言語 - C# スクリプトを選択

Azure Functions では、ファンクションの実装・記述に使えるプログラミング言語として、C# はもちろんのこと、他にも
- Bash
- Batch
- F#
- JavaScript
- Php
- PowerShell
- Python
といった豊富な選択肢から選べる。

自分の場合は、先述のとおり得意なプログラミング言語は C# なので、C# (より厳密には C# スクリプト、という形になる) でファンクションを実装することにした。

実装内容としては、Edge用・IE用・Chrome用にサブフォルダ x 3つに分け、サブフォルダごとに新バージョンリリースを監視/検知するファンクション ("Run.csx") を配置してある。

Edge用・IE用・Chrome用のいずれのファンクションでも同じ内容となる共通コードは、それらサブフォルダと並べて Shared サブフォルダを用意し、こちらに .csx ファイルとして収録。
Edge用・IE用・Chrome用の各 Run.csx からは「#load "..\Shared\SendMail.csx"」のように記述して、これら共通コードの .csx を読み込むようにした。

リリース情報コンテンツの入手と解析

各 Run.csx 内では、冒頭で解説した URL から XML 及び HTML を HTTP GET で入手。
入手した XML・HTML を解析して、それらコンテンツに掲載されている、目的の WebDriver ファイルの最新バージョン番号を読み取るようにした。

IE 用と Chrome 用は、Amazon S3 による XML で構造化されたデータが取得される。
この読み取った XML を LINQ to XML で内容探索する実装とした。

Edge 用はそのような構造化された状況とは言えない HTML コンテンツであった。
そこで真面目に HTML として解析することはやめて、その HTML コンテンツを単純な巨大な文字列として扱い、正規表現検索で WebDriver ファイルのダウンロードリンクを探索する実装とした。

NuGet パッケージの追加

指定の URL から XML や HTML を HTTP GET で入手するために System.Net.Http NuGet パッケージの追加が必要になったりする。
そのように必要となる追加の NuGet パッケージは、各サブフォルダ内の project.json に記述しておく。

起動条件などファンクションの構成

起動条件や出力結果などは、同じく各サブフォルダ内の function.json で指定する。
今回の要件は cron よろしく時間に基づいて定期的に実行したいわけだが、その内容を function.json に記載するわけだ。
とくに実行時間については、毎日、UTC 時刻にて 0:00 と 12:00 の1日2回の実行としてみた。

通知手段

新バージョンリリースを検知した際の通知手段は e-mail での通知とすることにした。

もちろん、Slack 等のチャットシステムに Bot よろしくテキストを送信することもできるだろう。
「今時メール～!?」みたいなことも言われた。
けれど人それぞれ色々背景理由があるのであって、詳細は面倒くさいので割愛するが、自分の場合は e-mail による通知が最適だったので、このような選択とした。

しかしこの実装を進めていた当時、Azure Functions における実行結果としての SendGrid API との連携方法などがよくわからず、結局 System.Net.Mail.SmtpClient による古典的なメール送信で実装した。

今ならば、SendGrid API と連携させる方法については下記を参照されるとよいかと思う。

Azure Function Appから定期的にメールを送る
http://qiita.com/superriver/items/d245539b7652b7512f9b

状態の保存

あと、新しいバージョンのリリースを検知するため、"前回チェックまでにおける最新バージョン" という「状態」を保存する必要に迫られた。

「Functions に状態持たせるの～!?」と白目をむかれたこともあるが、要件と先述の利点とを考えると別に悪い選択ではないと思うのだが...どうなんでしょう...。

...さておき、状態の保存/復元である。

これまた未だにそのような用途での何らかの記憶域との連携方法がわからず、最終的に Azure Table Storage を読み書きする実装とした。

なお、Azure Table Storage の読み書きにあたっては、Azure Functions だからといって特別なことはない。
普通に project.json に必要な NuGet パッケージを記載し、.csx ファイルに普通に Azure Table Storage の読み書き処理を記述するだけである。

アプリケーション構成値

状態保存のための Azure Table Storage に接続するアカウント情報や、SmtpClient によるメール送信時の SMTP 認証情報といった情報は、.csx ファイル中に書いてはいけない。

代わりに、Azure ポータルページ経由で「アプリケーション構成」に設定しておき、.csx 内からは ConfigurationManager.AppSettings 経由で読み取るべきだ。

この点は Azure Functions もその土台は Azure App Services ベースということで Web Apps のポータル画面と操作感は変わらなかった。

下記の過去記事も参考までに。

ASP.NET Web アプリで、APIキーなどの "秘密のキー" をどこに保存するべきか?
http://devadjust.exblog.jp/20400427/

成果

この Selenium WebDriver 新バージョンリリースの監視/検知システム、11月末頃から本格稼働を始めた。

以来、これまでに計2回ほど、IE 用 x 1回と Chrome 用 x 1回、の新バージョンリリースを検知している。

おかげて1日以内での新バージョンリリースを把握できるようになった。
しっかりと当初目標・要件を満たすことができ、満足である。

※Microsoft Edge 及び Mozilla Firefox に関しては、2016年11月末以降現時点まで、まだ新バージョンがリリースされた実績がない。

課金

かれこれ1ヶ月ほど運用したわけだが、課金のほうはいかほどかというと、
この1ヶ月でざっくり、¥30 以下。

課金の内訳は、Azure Function が必要とする分と、先述の "状態保存" に使用する分の、双方の Azure Storage Account の料金がほぼすべてを占めていた。
ファンクションの実行時間/回数に関する課金は ¥1 に達していなかった。

そもそも実行時間/回数については無料枠がある。
今回のシステム程度の負荷では無料枠内で済んでしまうことだろう（下記リンク先参照）。

Functions の価格
https://azure.microsoft.com/ja-jp/pricing/details/functions/

まとめ

Azure Fuctions、ゆるーく1日数回の監視するような用途だと、

• 料金がむちゃくちゃ安く済む
• コードが「やりたいこと」に集中できる

という点で良かったと思う。

あと「よくなかった点」もあって、それは主に実装作業時・コーディング時におけるものなのだけど、それについては後日エントリを改めて触れたい。

そのほか、IE 用と Chrome 用に関しては、Amazon S3 での提供という形なので、もっと手抜きができる方法が実は存在するのではないかと気が気でならない。
「そんなにゴリゴリ書かなくても、ほら、こんな風にすれば新バージョンリリースの通知を受けられるよ！」
といった情報をお持ちの方がいらっしゃれば、本ブログへのコメントとか Twitter で触れていただくなど情報発信していただければ、自分の二の轍を踏む方が増えずに済むと思うのでぜひお願いしたい。

実際、@twit_ahf さんからも、Azure LogicApps/LogicFlow で実現する作例を教えていただいた。

多分、@jsakamoto さんに出された宿題はこんな感じでいける気がしている。1日1回、バージョン情報の xml 拾って、最終更新日が前日より新しければ通知する、って感じで。あくまでも多分こんな感じ。 pic.twitter.com/oASEQ5lMio

— Ahf(Tomoyuki Obi) (@twit_ahf) November 27, 2016

LogicFlow で XML データを繰り返し処理する
http://blogahf.blogspot.jp/2016/11/logicflow-xml.html

せっかく教えてもらったのだが、自分の場合は贅沢にも、XML 全体の最終更新日での通知ではなく、特定アイテムの新バージョン出現に限って検知したく、Azure LogicApps/LogicFlow での上記作例の採用は見送ってしまったのだが、以上ご参考までに。