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)