なんとなくお蔵入りしてたネタを引っ張りだしてきました。
AzureのVNETと動的ゲートウェイと、AWS上のVyOSなVPNルーターを使ってVPN接続しようというネタです。出来上がる環境はこんな感じ。
IPアドレスとかは例です。あと数か月以上前のネタなのでちょっと変わってる箇所あるかも(VyOSのAMIのバージョンとか)しれませんが適宜読み替えてください。それから簡易な接続なので本運用とかには使わない方がいいかもですね。なんにせよ自己責任で。
なんとなくお蔵入りしてたネタを引っ張りだしてきました。
AzureのVNETと動的ゲートウェイと、AWS上のVyOSなVPNルーターを使ってVPN接続しようというネタです。出来上がる環境はこんな感じ。
IPアドレスとかは例です。あと数か月以上前のネタなのでちょっと変わってる箇所あるかも(VyOSのAMIのバージョンとか)しれませんが適宜読み替えてください。それから簡易な接続なので本運用とかには使わない方がいいかもですね。なんにせよ自己責任で。
はいはいUpdateですよー。
なんかAzure PowerShellのGet-AzureVMとかGet-AzureDeploymentとかで得られる応答の一部要素(PersistentVMDowntimeのEndTime)でDateTime.MaxValueなISO8601形式の値(9999-12-31T23:59:59Z)が入ってるようで、こいつを日本みたいなUTCにプラスするタイムゾーン圏内でDateTime.Parseしようとして例外吐いてるみたいです。
> get-azurevm
get-azurevm : The DateTime represented by the string is out of range.
At line:1 char:1
+ get-azurevm
+ ~~~~~~~~~~~
+ CategoryInfo : CloseError: (:) [Get-AzureVM], FormatException
+ FullyQualifiedErrorId : Microsoft.WindowsAzure.Commands.ServiceManagement.IaaS.GetAzureVMCommand
仮想マシンをシャットダウンしたり再起動したりすると、EndTimeの値がまともな値になるのかちゃんと動作するようです。いやいや。。。
Management API側の挙動が変わったのかなー?(こんな値入ってたっけ?)という気がしますが、仮想マシンの再起動とかフザケンナという人はAzure PowerShellを実行するPCのタイムゾーンをUTCとかPSTにして凌ぎましょう。(なんとなくMSには報告済み)
DateTimeOffset使えば問題なさげだけど。
D:\> [System.DateTime]"9999-12-31T23:59:59Z"
Cannot convert value "9999-12-31T23:59:59Z" to type "System.DateTime". Error: "The DateTime repres ented by the string is out of range."
At line:1 char:1
+ [System.DateTime]"9999-12-31T23:59:59Z"
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (:) [], RuntimeException
+ FullyQualifiedErrorId : InvalidCastParseTargetInvocationWithFormatProvider
D:\> [System.DateTimeOffset]"9999-12-31T23:59:59Z"
DateTime : 9999/12/31 23:59:59
UtcDateTime : 9999/12/31 23:59:59
LocalDateTime : 9999/12/31 23:59:59
Date : 9999/12/31 0:00:00
Day : 31
DayOfWeek : Friday
DayOfYear : 365
Hour : 23
Millisecond : 0
Minute : 59
Month : 12
Offset : 00:00:00
Second : 59
Ticks : 3155378975990000000
UtcTicks : 3155378975990000000
TimeOfDay : 23:59:59
Year : 9999
やれやれです。
Management REST API側で吐き出す値を修正したらしいです。とりあえず動作するようになりました。
こんなサイトができてました。
今後のMicrosoftのクラウドまわりの方向性だとか、今現在ざっくりどんな感じなのかを把握することができそうです。日本語欲しいですね。
なんでこういうのを出したの?という話はMSHQの沼本さんがアナウンスしているものを、さとうなおきさんが日本語訳にしているので是非そちらを参照ください。
こまかい点いくつか。
これで国内で安心して使えますね(?)※西も東もAutomationの用途からしたらどっちでもいい感
Azure Batchの.NET向けクライアントライブラリがアップデートされました。細かなバグ修正のほかにAPI同期呼び出し時でデッドロックせずに使えるようになったとかなんとか。あとインテリセンスのバージョンアップですね。
サンプルもあるのでどうぞ。
※相変わらず英語の方に行かないとでないけど。
Azure Batchについてはこの辺どうぞ。
関連してBatchを管理するためのGUIアプリケーション(Azure Batch Explorer)もUpdateされたようなので、そちらもご覧ください。
公式にもアナウンスきてました。HttpPlatformHandlerはIISでHTTPリスナーのプロセスを管理するためのモジュールです。ひらたくいうとTomcatだとかNodeとかのプロセスをIISであれこれしたりリクエストをプロキシしたりするためのモジュールですね。WebsitesでJavaを動かすために使われてたりします。
今回のリリースでお手軽に使えるようになったのと(今まではWebsites内だけだった)、IIS8以上で利用可能になりました。
詳しくはしばやん雑記でもいろいろ書かれてるので、そちらを参照ください。
そんなわけでしゃべってきました。大阪会場の資料などはこちらを参照ください。
Togetterなどにも他の会場の資料などもありますので、ぜひそちらもご覧ください。
ざっくりと。
glibcの脆弱性のアレです。Ghost。
書いてるとおりsudo yum -y update して再起動すれば基本大丈夫でしょう。適用後、
$ rpm -aq | grep glibc
glibc-devel-2.12-1.149.el6_6.4.x86_64
glibc-2.12-1.149.el6_6.4.x86_64
glibc-common-2.12-1.149.el6_6.4.x86_64
glibc-headers-2.12-1.149.el6_6.4.x86_64
とかになればOKかと。6系は2.12-1.149、7系は2.17-55かな。
VyOSも更新があったので適用しておきましょう。
add system image とかすればいいかと思います。
タイトルの通り。前回せっかくDocker on Ubuntu用に作ったのでそのままWebsitesで動かしたいと思います。
やり方は2通り。
※Docker on Ubuntu用のproject.jsonなどは前回のPost参照で
結論から言うとVSからの直接発行は何の問題もなし。すんなり動作します。
でGit連携のほうはちょっとだけコツが必要。
Websitesの構成でアプリケーション設定にSCM_KRE_VERSIONを追加し、CTP5用のバージョン(1.0.0-beta2)を指定します。
これだけ。
x64にしたりランタイム全部持ってくる場合とか用(?)にSCM_KRE_ARCHやSCM_KRE_CLRとかの引数もあります。VS2015でプロジェクトのプロパティみたときのTarget KRE Versionで指定するあれを分解した感じですね。
※SCM_KRE_VERSIONを指定しないとbeta1が使われてCTP5だと500エラーになります。

※デプロイは一応成功する
まぁそんなわけで、設定してあげてあとはGit連携すればちゃんと動作するようになります。

一応これでASP.NET5 CTP5をWindowsでもLinuxでもAzure Websitesでも動作させられるようになりましたね。理屈的にはMac OS上でも動作すると思いますが環境ないのでわかりません。
細かい話はきっとしばやん先生が解決してくれると思います。あとこちら参照。