Microsoft Azure クイック スタート テンプレート試してみた – ubuntu-desktop

こんにちは。ARMのお勉強のために公式で用意されているコミュニティによるクイック スタート テンプレートの紹介です。公式のものではなくなりますが、コミュニティ提供のものとしての一覧があります。

Azure クイック スタート テンプレート

Azure リソース マネージャーを通じてコミュニティ提供のテンプレートで Azure リソースをデプロイし、生産性を高めます。デプロイ、学習、フォークして、自分も貢献しましょう。

さっそくデプロイ

ここで見つけた、Create an Ubuntu desktopっていうものを試してみます。 Azureへのデプロイボタンをクリックすると、ポータルでのカスタムテンプレートのデプロイ画面になります。

パラメーター

  • NewStorageAccountName – ストレージアカウントを作るようなのでそのアカウント名。
  • AdminUserName – Ubuntuのユーザー名
  • AdminPassword – Ubuntuのパスワード
  • DNSNameForPublicIP – DNSホスト名
  • VMSize – 仮想マシンのプラン

これらのパラメータでDNS、ストレージアカウントは世の中の一意な名前じゃないとデプロイに失敗しそうな気がします。ので、ありきたりな名前としないほうがよさそうです。

できあがり

ぽちぽちしてポータルから作ったものと違って、ロードバランサーも用意されていますね。PublicIPはネットワークインターフェイスには関連付いてなく、ロードバランサーについています。ネットワークインターフェイスはVNETに所属するのみですね。ネットワークセキュリティグループは、TCP/22(SSH)のみ開けているようです。

このテンプレートの説明

https://github.com/Azure/azure-quickstart-templates/tree/master/ubuntu-desktop

ということで、デスクトップにつなぐためには、SSHでポート転送を行いなさいよとのことです。リンク先ではPuTTYの設定になっています。以下はTeraTermの設定追加です。(設定を保存して、つなぎ直す必要があるようです。)

あとは、VNCで接続!!

接続先は「localhost:5901 」パスワードは「password」ですね。

ちょっと手順はありますが、認証もSSHを経由する必要があることで生のVNC通信より暗号化されている分ちょっと安心。

それでは!

 

Ubuntu上のAsyncで遅延 – BlackJumboDog CoreCLR

ずーっと気になっていたんですが、Ubuntu上でサーバーのTCPソケットをAcceptAsyncかけていたら、しばらくアクセスがない状態だと1秒程度の遅延が発生していました。そして、連続したアクセスだとこれは起きなかったんです。

元々のBjdではWhileとSleepによるポーリングを行っていたので、おそらくそんなことは起きなかっただろうと思っています。(そもそも、Begin/Endが動かなかったので、根拠はない!)

同じことが、ManualResetEventSlimeでも起きました。ある程度時間がたったときに、シグナルセット後のWait解放が1秒くらい。これ、Windowsでは起きなかったんですよね。

正直、そこまでプラットフォームに詳しい人間ではないので、なぜこうなるのか?は理解できませんでした。ただ、どうすれば?に関しては、「深い眠りにつかないようにする」っていう発想で回避しました。

https://github.com/darkcrash/bjd5/commit/a9049f8630d2e788dda19065026c415654efcd05#diff-c042d296432145429c9f5f4d27bfef99

     -            tTcp.Wait(this.Kernel.CancelToken);  
 94   +            while (true)  
 95   +            {  
 96   +                if (tTcp.Wait(2000, this.Kernel.CancelToken))  
 97   +                    break;  
 98   +                if (tTcp.Status == TaskStatus.Canceled)  
 99   +                    break;  
 100  +            }

Waitを2秒までとして、完了時はループを抜け、キャンセル時もループを抜けます。こうすることで2秒に一回このWaitが実行されます。そして、結果として遅延1秒はなくなりました。

SpinWaitの絡みとか、タイムスライスのルールとかありそうなんですが、ブラックボックスです。Darkが作るBlackなだけに・・・

これが、Kernelによるものなら、今後もこういう仕様ということになるでしょうし、.Net Coreのものであれば、改善されていくかもしれません。ので、現時点ではこのコードは、一つの回避策として整理してくださいませ!

それでは!

BlackJumboDog CoreCLR Ubuntu – Socketの置き換え APMからTAPへ

こんにちは!いきなり動いてるスクリーンショットから!!(Azure上のUbuntu14.04で動かしている様子です。)

というのも、動いてるだけでもすごいっていう気持ちを伝えたかったわけですが、今回に至るまでに行った変更点

  1. System.Net.Socketsのバージョンを他と統一し「4.1.0-beta-23516」としました。
  2. それに伴って、APMの実装は捨てられたため、TAPに書き直しました。
  3. パスの置換(\→.Netが提供するCharフィールド)を進めて動かしてみたところ、パスの置換が空回りして無限ループ!→修正済
  4. CPU利用率が起動直後で安定していても、10%以上という状況で、Thread.SleepをManualResetEventSlimに置換→アイドル中のレスポンスに1秒の遅延が発生。→検討中
  5. ConsoleTraceListenerの負荷がかかりそうなので、専用のタスクスケジューラ実装
  6. ログをそれっぽくフォーマットしました。

前回記事の、Begin/EndなどのAPM(非同期プログラミングモデル)なソケット実装がないとエラーになってました。これは、上のリンク先の通り、廃止されていくようです。このIssues(上と同じリンク) でその理由が書かれていました。Windowsに依存したようなものは排除する!っていう面白い話ですね。

ただ、これ変えてしまうと、そもそもポーリングしてるロジックとか全部作りなおしなわけで、結構時間かかってました&まだ懸念点が残ってます。行き詰っていろいろ試したのもあって、ソースの履歴が激しいことになっていてごめんなさいというところです。

また、ぜんぜん気づいていなかったのですが、Traceで出力したものは、Defaultのlistenerか何かによってだとは思いますが、しっかりとSyslogに出力されていました。(これはちょっと驚いた)

大物のWebServerが動いたので、懸念点を解消しつつデプロイ方向にシフトしていきます。

それではまた!

環境によるパスの違い – BlackJumboDog CoreCLR

前回から、Option.iniが読めてないのは見事的中しました。

https://github.com/darkcrash/bjd5/commit/789b737402a8e16b4d99147c6471eb83a426fce3?diff=unified#diff-e8a8a3be0e352480bc87c1f17ebc86bb

Windowsでは「\」をパスに利用しますが、Linuxでは「/」を利用します。ここにリテラルで「\」があったために、パスを拾えていなかったようです。これは、System.IO.Path.Combineメソッドを利用して対処しました。

でも、なんでこれで大丈夫なのだろうか?

という疑問が出てきましたので、ちょっとだけソースを追いかけてみました。

こうした環境の違いがあるために、.Net CoreのライブラリではPlatformによる違いを吸収する方法をとっているようです。

これが、Bjd(アプリ)が直接利用しているPathクラスの中身。(正確なバージョンまでは未確認。きっと多分)

System.Runtime.Extensions System/IO/Path.cs

中では「DirectorySeparatorCharAsString 」というフィールドを利用して、結合していますが、この実体はここにいません。

分割クラス(partial)となっており、

System.Runtime.Extensions  System/IO/Path.Windows.cs

System.Runtime.Extensions  System/IO/Path.Unix.cs

という風に複数定義されたものがありました。Unixでは「/」Windowsでは「\」(エスケープのため2文字なだけ)となっています。

これは、以下のプロジェクトファイルでターゲット($(TargetsUnix)、$(TargetsWindows))による切り替えが確認できます。

System.Runtime.Extensions.CoreCLR.csproj

つまり、プラットフォームごとに作られているものが違うということですね。

 

でも

2016-01-09 (1)

 

こ、今度は、BeginReceiveがないですと!!ポートが使われているよーはサービスを止めればよいとして、Windowsでは動いてるのに!!これも追いかけていこうじゃないですか!

それでは、また

 

 

Ubuntuで動いた!? BlackJumboDog CoreCLR

まずは無事に、動きました!DNX_TRACE=1から直接問題を検出できたわけではないですが、これを見ることによってどこまで動いているかの見当をつけることができたのは、StackOverflowExceptionのStackTraceを見れるのと見れないの違いくらいあるんじゃないかと思います。

2016-01-09

原因は、Consoleのサイズ取得もしくは変更をしようとしたところにありました。これは、本家Bjdにはない機能でした。GUIを捨てるときにどうしても何か見えるものをCUI上に出しておきたいと思ったのがきっかけです。Trace.Writeでトレースを出力するようにして、それをConsleに出力するためのTracelistenerを実装しています。

GitHub変更点

https://github.com/darkcrash/bjd5/commit/b42c4386866db1f681bbec13b6c20547b02e3320

Windows動かしている分には、サイズ変更できていましたが、SSH経由でそれをやると例外が発生していたようです。TryCatchを入れConsoleに出力したところメッセージが出てきましたので、取得または変更で間違いなさそうです。これもLinuxのGUI上からやったらどうなるかとかはわかりませんが、そんなことするなよって話もありつつ、やるならできない場合を考慮する必要があるようですね。

そもそも、何よ!って人に向けて

MSDN ライブラリ TraceListener クラス

これは、.NetFrameworkに昔からある機能で、Traceクラスを用いて、Writeメソッドやら、WriteLineとかで出したものを、受け取って何らかの処理をする機能を提供するための基底クラスです。ただ、.Net Core としても、Windows (ETW) があるようなので、Linuxでも動くならそっちのほうがよいでしょうね。

スクリーンショット見ると、サーバーは何も起動した形跡がないというオチが待っていました!おそらく、Option.iniを開けてとかその辺じゃあないのだろうかと思っていますが、本当に動くようになるまで戦いは続きます。

それでは、また!

 

 

 

 

 

Ubuntu dnxでTraceを出力する方法 – BlackJumboDog CoreCLR

前々日から、前日に続き

BlackJumboDogをUbuntu上で動かすために、いろいろ試行錯誤しています。どうやらUbuntuで動いていないのは本当に何か環境固有の問題ではないかと疑っています。

がしかし、何もエラーが出ずに困っていました。

そこで・・・

 

Creating a Cross-Platform Console App with DNX

https://github.com/aspnet/Home/wiki/Environment-Variables

 

ということで、環境変数を入れておけば、もっとトレース出すよ!ってことみたいです。ほかにもいろいろ変数があるようですね。

さておき、変数を設定して実行してみます。

env DNX_TRACE=1 dnx run

 

エントリポイントは再びお引越しして、bjdコマンドを定義してるので以下のように

env DNX_TRACE=1 dnx bjd

2016-01-07

何やら出てくるではありませんか!!

これをWindowsのものと比較してみます。

2016-01-07 (1)

 

アプリケーションが出すConsoleメッセージの直前は同じアセンブリを読んでるっぽいメッセージになってますね。

こうなると、PG側が悪いのではないかという疑いが出てきました・・・・!

ちなみに、UbuntuはAzureのもの使ってます。

明後日に続く!

VisualStudio がやっているdnxをLinux向けに置き換えるメモ

ちょっとメモとして残します。

BlackJumboDogのせこせこ実装も無事終わって、Linux上で動かすための.SH作るためのメモです。

Windows上のDNXとDNUはLinuxのそれと同じように作られているのでそれを置き換えていきます。

[VisualStudio – build]

“[USER].dnx\runtimes\dnx-coreclr-win-x64.1.0.0-rc1-update1\bin\dnx.exe” –appbase “[REPOSITORY]\bjd5\Bjd.Common.CoreCLR” “[USER]/.dnx\runtimes\dnx-clr-win-x86.1.0.0-rc1-update1\bin\lib\Microsoft.Dnx.Tooling\Microsoft.Dnx.Tooling.dll” pack Generalversammlung “”[REPOSITORY]\bjd5\Bjd.Common.CoreCLR” –configuration Debug cheap nba jerseys –out “..\artifacts\bin\Bjd.Common.CoreCLR”

[VisualStudio – Blogはじめました run]

“[USER].dnx\runtimes\dnx-coreclr-win-x64.1.0.0-rc1-update1\bin\dnx.exe”  –appbase wholesale nba jerseys “[REPOSITORY]\bjd5\Bjd.CoreCLR” “Microsoft.Dnx.ApplicationHost”  –configuration Debug “BJD.CoreCLR”

 

[Linux – build]

dnu cheap jerseys from China restore

dnx –appbase “Bjd.Common.CoreCLR” ~/.dnx/runtimes/dnx-coreclr-linux-x64.1.0.0-rc1-update1/bin/lib/Microsoft.Dnx.Tooling/Microsoft.Dnx.Tooling.dll pack “Bjd.Common.CoreCLR” och –configuration Debug –out “artifacts/bin/Bjd.Common.CoreCLR”

[Linux – wholesale mlb jerseys run]

dnx –appbase “Bjd.CoreCLR” “Microsoft.Dnx.ApplicationHost”  –configuration Debug Energy “BJD.CoreCLR”

 

お、重い・・・。

動機があれだけど、NuGetデビュー・・・しようかなー

 

2016-01-05 (6)

そして、、、、動かないぜ。。。エントリポイントがそこにいないことが原因のような気がするので、ランタイムとVS、MSBUILDの動きをおいかけないとだめね。

明日からはMSBuildを食せるね!