作成者: buchizo

Windows Server 2016 TP3のコンソールを閉じてしまったら

/ buchizo / コメントする

画面まっくろでどうしようもないですｳﾜｧｧ—–｡ﾟ(ﾟ´Д｀ﾟ)ﾟ｡—–ﾝ!!!!

という方はCTRL+ALT+DEL押してセキュリティメニューだしましょう。

image

Sign out選べば（RDPとかで）再接続したときにちゃんと表示されます。あとはTask Manager表示させて新しいタスクの実行とかでcmd.exeでも起動すればいいでしょう。

※ パスワードも変更できますよ。

Server Core普段使ってる人には自明かもしれません。

Azure Update (2015.08.22)

/ buchizo / コメントする

こまかいのもろもろ

Nano Server TP3を試してみる

/ buchizo / コメントする

Windows Server 2016 TP3もでてNano Serverも少し更新されたようなので試してみたいと思います。

Hyper-Vで試す

だいぶお手軽になった感があるので、Hyper-V上でまずは動作するイメージを作成してみましょう。

1.準備

Windows Server 2016 TP3のISOの中身を適当なフォルダーにコピーします。コピー後、ISOの中身\NanoServer\packagesフォルダにあるen-usフォルダをコピーしてja-jpにリネームします（OSが日本語環境の場合のみ）
あとは作成したイメージ（VHDファイル）を保存する先とワーク用のフォルダを用意しておきます。

2.イメージの作成

最初に new-nanoserverimage.ps1 を読み込んでおきます。

. .\new-nanoserverimage.ps1

※コピーしたISOフォルダーがカレントフォルダーとします

スクリプトを読み込むとNew-NanoServerImageが利用できるようになります。細かなパラメーターはヘルプでも参照してもらうとして、単純に作るには以下のようにします。

 New-NanoServerImage `
  -MediaPath E:\temp\Win2016TP3 `
  -BasePath E:\temp\NanoServer\base `
  -TargetPath E:\temp\NanoServer\vhd\buchinano `
  -ComputerName buchinano `
  -GuestDrivers `
  -ForAzure

MediaPathはISOフォルダ、BasePathは一時的なフォルダ、TargetPathは作成するVHDの保存先、ComputerNameは作成するコンピューター名です。
GuestDriversはHyper-Vで動作させる場合に必要です。物理サーバーの場合は代わりにOEMDriversを指定します。
ForAzureはAzure上で動作させる場合に指定します。（単にGuestDriversとRemoteWinRMを有効化してるだけのようですが）

実行するとAdministratorアカウントのパスワードの入力を求められます。実行後しばらくすると40GBほどのVHDファイルが出来上がります。

基本的にはこれだけです。細かい話は公式参照。

3.イメージの起動

出来上がったVHDを使って世代1（Gen1）の仮想マシンをHyper-V上に作ります。起動すれば依然のTPとはちょっと違って多少ましなコンソールが表示されます。
image

設定したパスワードで認証すれば簡単な情報を見ることができます。（Tabで項目移動です）
またCtrl+F6で再起動、Ctrl+F12でシャットダウンもできますね。
image

コンソールでは「＞」がついた項目にTabで移動してEnterすればより詳細な情報を見ることができます。Networkを選んでアダプターを選べばIPアドレスなどを参照できます。
image
image
カーソルの上下キーでスクロールできます。
ESCキーで元の画面に戻れます。（F4キーでアダプターのOn/Offができます）

あとはWinRMなどを使ってリモートからも接続できます。この辺りは同じですね。

相変わらずの軽快さです。

Azureで動かす

Azureで起動させる場合は出来上がったVHDをAdd-AzureVhdなどを使ってアップロード後、VMv1であればクラシックポータルから「ディスク」として登録します。（汎用化せずにそのまま使うので「イメージ」としては登録しない）

あとは普通に作ればいいのですが、RemotePowerShellは5985ポートが既定なのでなおしておきます。
image

イメージのコピーが無いのとそもそも起動が早いので、普通のVMに比べて早く立ち上がります。
ただ現状そのままだとRemoteでつながらない。（F/W周りだと思うのですがまだ解決してません）

VMAgentも入れたいしもうちょっとコネコネしないといけないかもしれません。

とりあえずのまとめ

.NET CoreのASP.NET 5なWebアプリとかならF/Wの設定してしまえば問題なく動きそうですね。とはいえWindows Containersが動いたりしてくれないと現時点ではなかなかつらいものがあるかもしれません。（アプリを動作させる基盤としては）

インフラの基盤としてHyper-Vクラスタにしたりという用途であればちゃんと評価を始めてもいいのかもしれませんね。（まだまだ大変な気もしますが）

Windows Server 2016 & System Center 2016 Technical Preview 3 ほか

/ buchizo / コメントする

それぞれTechnical Preview 3がリリースされました。MSDNなどなどからゲットしてください。
System Center 2016あたりはうるしませんせーに聞くと良いのではないでしょうか。

Windows Server 2016 Technical Preview 3 (TP3) での新しい部分などはこちらを参照。

続きを読む →

Azure App Service に.NET Framework 4.6がロールアウトされました

/ buchizo / 1件のコメント

以前のPostで8月中にAzure App Serviceで.NET Framework 4.6が使えるように～という話がありましたが、今日ロールアウトされて利用できるようになりました。

image

これで安心して（？）.NET Framework 4.6使えますね。ちなみにRyuJITは今のところ無効化されてるようです。

安定して利用できるようになるのを待ちましょう。

Azure PowerShell の変更予定など

/ buchizo / コメントする

以下のようなアナウンスがされています。

もともとASM（Azure Service Management）とARM（Azure Resource Management）の2種類あってSwitch-AzureModeでモードをかえつつ使ってたのですが、2015年9月25日をターゲットに削除する予定のようです。

当初、Cmdletを同じにそろえようとしてたのですが議論の末、AzureRMという統一した名称になるようです。

[Verb]-Azure[Noun]なのが[Verb]-AzureRM[Noun]ですね。（Get-AzureRMVmのような感じで動詞と名詞（サービスやリソースなど）という感じです）
あとはモジュールの分割、PowerShell Gallery経由でのARMモジュールの配布、自動化されたドキュメントのMSDNへの追加などが予定されてるようです。

もともとARMへの移行が推奨されてた感じではありますが、今は過渡期ということでもろもろ変わることを前提にしておく必要があります。

なぜ変えるのか？というところですがまぁSwitch-AzureModeでModal/Statefulな挙動に不満が多かったんでしょうね。そもそも中途半端ですし。まぁそういうことで将来的な基盤を提供したいから破壊的変更させてくださいという感じです。

細かい理由やロードマップは最初に挙げたGitHubのページを参照ください。

まぁ個人的には早く全部ARMで管理できるようになることと、Azure Portalでフルコントロールできること、Azure PowerShellももっとシンプルになることを望みます。（ASMが無くなればもっとシンプルになるんだけど）

Azureで.NET Framework 4.6を使う

/ buchizo / 1件のコメント

.NET Framework 4.6がリリースされましたね。さてさてAzureで（今、）使うにはどうすればいいでしょう？という話です。

Virtual Machinesの場合

基本的に自分でOSより上部分は管理するのがIaaSであるVirtual Machineなので、.NET Framework 4.6も自分でインストールしましょう。Azure Automation使ったりプラグイン使ったりでがんばって自動化するといいかと思います。

Azure App Serviceの場合

Managementなサービス/PaaSなので基本的に何もしなくてよいです。ただそこは自分で管理できないのがつらいところ、利用可能になるまで待つ必要があります。
現在検証中で今のところ2015年8月中にはロールアウトされる予定のようです。

→ 2015/08/15追記: ロールアウトされました

Azure Cloud Servicesの場合

PaaSではありますがちょっと面倒くさいです。基本的には.NET Framework 4.6のWebインストーラーをパッケージに含めてスタートアップタスクでインストールするという方法になります。

詳細は上記ドキュメントを参照ください。
ぶっちゃけインストール済みのGuest OSがほしいところですけど。

 

まぁ手動のやつは好きなように、そのほかはもうちょっと待ってれば使えますよという感じですかね。

 

おまけ

Azure Update (2015.08.12)

/ buchizo / コメントする

ちらほらと。

Azure CDNのUpdate

いまだにClassic Portalでしか管理できないCDNですが、補助ポータルができたことで機能のUpdateともう少しましな管理ができるようになりました。

Classic PortalのCDNを見れば新しく「CDNの管理」ボタンがあるのでそちらからどうぞ。

image
クリックすると補助ポータルが表示されます。

image
※使ってないCDNだから見せられるような情報ないですけど。

機能拡張としては3つ

  • Analyze CDN usage patterns
    • 以下のレポートを使ってCDNの使用パターンを把握できます
      • 帯域
      • データ転送量
      • ヒット数
      • キャッシュステータス
      • キャッシュヒット率
      • IPv4/IPv6 データ転送量
    • こんな感じ
      image
    • レポートの期間は18か月間ですかね。
  • Restrict access to your content by country
    • コンテンツもしくはディレクトリパスに対してアクセス元の国によって制限（BlockするかAllowするか）を設定することができます
    • 設定するとサブスクリプション内のすべてのCDNエンドポイントに適用されるっぽいです（相対パス使う場合は注意が必要かな）
    • カントリーコードはこちら Country codes
    • ちょっと特殊なコードもあるので注意が必要です。
    • フィルタリングが有効になるまで最大1時間かかる場合があります
    • ワイルドカードを使った指定はサポートされてません
    • 相対パスで指定した国別フィルタリングは再帰的に適用されます
    • 同じ相対パスで異なる国別フィルタリングを指定することはできません
    • 使い方
      国別フィルターの追加ボタンをクリックして
      image
      パスとブロックするか許可するか選んで
      image
      国を選びます。
      image
      簡単ですね。
  • Improve performance by compressing files
    • コンテンツを送信する際の圧縮のサポートです。オリジンで圧縮しておいてそのままCDNで配信する方法（ようはCDNで何もしない）と、CDNのエッジサーバー上で圧縮を行う方法があります
    • エッジサーバー上で圧縮を行う場合は圧縮するコンテンツタイプを指定します。
      image
    • application/vnd.ms-sstr+xml,application/dash+xml,application/vnd.apple.mpegurl,application/f4m+xml についてはMedia Services側でCDNを有効にしたら有効になるので触れません
    • 1つのファイルバージョンだけエッジサーバーにキャッシュされます
    • 1MBより大きいファイルは圧縮されません
    • あとは通常の圧縮周りの話と同じ（動画など内部ですでに圧縮されてるようなコンテンツはメリットがないよとかとか）

※ はやく証明書のアップロードとか来ないかな、、

Azure HDInsightがAzure Portalで管理できるように

なりました。というかARM（Azure Resource Manager）対応です。

細かい話はお義父さん™か上記Blogを見てもらえれば。今後のHDInsightのASM（Azure Service Management）のクラスタとARMでのロードマップ周りはちょっと注意でしょうか。

  • ARM用ツールに対して新機能や拡張が行われていきます。
  • 最終的にASM関連のツールは削除されます。新しいARMに慣れておきましょう
  • 新しいARMツールはASMとARMのクラスタを管理できます。（ASMはASMのクラスタのみ管理可能）

ということで、ARMに慣れておきましょうね。

その他

Raspberry Pi 2とWindows 10 IoT Coreで温度センサーを使ってみる

/ buchizo / コメントする

公式（？）にあるサンプルはちょっとわかりづらかったので簡単な解説的な？ちなみにこちらです。

※というかMCP3002使った時のコード間違ってるんだよねーあとでPRするかな、、、

Raspberry Pi 2にWindows 10 IoT Core（Build10240=Public Release）をのせてるものとします。あとセンサーとしては一般的な3ピンなアナログ温度センサー、A/DコンバーターはMCP3002を使うものとします。

MCP3002のデータシートはこちら

ちなみに回路的にはこちらのBlogの通りです。温度センサーの極性とRaspberry Pi2のGPIOのピン間違わなければまぁ問題ないでしょう。

※回路図のせようと思ったけどhttp://fritzing.org/にサインアップできないので断念。
※あと温度センサーによるのかもしれないけど誤差とかにも注意しましょう（使ったやつは個体によって最大±4℃の精度らしい。。。）。キャリブレーションできるようにアプリ作っておくといいかもですね。

さてWindows 10 IoT Coreで動作するUniversalなアプリを作ってセンサーからデータを読み取ってみましょう。
まずはSPIデバイスの初期化。

        private const string SPI_CONTROLLER_NAME = "SPI0";
        private const Int32 SPI_CHIP_SELECT_LINE = 0;
        private SpiDevice SpiDisplay;

        private async Task InitSPI()
        {
            try
            {
                var settings = new SpiConnectionSettings(SPI_CHIP_SELECT_LINE);
                settings.ClockFrequency = 500000;
                settings.Mode = SpiMode.Mode0;

                string spiAqs = SpiDevice.GetDeviceSelector(SPI_CONTROLLER_NAME);
                var deviceInfo = await DeviceInformation.FindAllAsync(spiAqs);
                SpiDisplay = await SpiDevice.FromIdAsync(deviceInfo[0].Id, settings);
            }

            /* If initialization fails, display the exception and stop running */
            catch (Exception ex)
            {
                throw new Exception("SPI Initialization Failed", ex);
            }
        }

SPI0使うように設定してSpiDeviceのインスタンス作ってる感じです。

データ読み取るには以下のようにデバイスのTransferFullDuplex()を呼び出せばいいです。

byte[] readBuffer = new byte[3];
byte[] writeBuffer = new byte[3] { 0x68, 0x00, 0x00 }; //01101000 00; /* It is SPI port serial input pin, and is used to load channel configuration data into the device*/

SpiDisplay.TransferFullDuplex(writeBuffer, readBuffer);

とりあえず後の話はセンサー側とか固有の話なので同じA/Dコンバーターなど使わなければ意味がないかも。
MCP3002の場合は欲しいチャンネルの情報を渡せば10ビットで応答が返る仕様です。WriteBufferに決まった信号をセットします。（1bitは固定で0、2bit目は必ず1（スタートビット）、SGL/DIFFも1、CH0を使うので0、MSBFで受け取るので1、あとは0という感じで0b01101000 = 0x68 であとはゼロ、という感じです。MCP3002は10ビット2chのA/Dコンバーターなんですがスタートビットからの分も含めると1回のやり取りで3バイト分の領域が必要になるのでbyte[3]な感じです。

さてreadBufferには読み取った値が入ってるわけですが必要なデータだけ3バイトの中から抽出します。

        private int ConvertToInt(byte[] data)
        {
            int result = data[0] & 0x03;
            result <<= 8;
            result += data[1];
            return result;
        }

スタートビットから数えると応答の1バイト目の3ビットが有効な値なのでその部分を取得して8ビットシフトして、2バイト目の値をそのまま足します。（なんでというのはデータシートでも見てください）

image

これでデータがとれました。で、取れた値を温度に変換する必要があります。
使った温度センサーは0℃で500mVの出力電圧で、1℃につき10mV出力電圧が変わる仕様です。なんでざっくり計算するとこんな感じ。

                var adc = ConvertToInt(readBuffer);
                var vol = adc * 3300 / 1024;
                var t = (vol - 500) / 10.0;

adcの値が得られた値で入力の3.3V(3300mv)を掛けて10ビットの1024で割ると出力電圧がでます。0℃で500mVなので500引いて単位をそろえると摂氏な温度が得られます。

あとは画面に出すなり外部に吐き出すなりお好きなようにどうぞという感じです。

※ブレッドボードで何も考えずつないでやってるあたり、学習コンテンツだなーとは思いますがまぁ面白いからいいです。1万円もかからずにC#（UWP）でアプリが組めてデバイスも触れてという環境はいいんじゃないでしょうか。

Windows 10 IoT Core（UWP）でSASトークンを生成

/ buchizo / 1件のコメント

Windows 10 IoT CoreでというかUniversal Windows PlatformでSASトークンを手動生成するのまき。

なぜそんな面倒くさいことをするのかという前提を書くと

  • Universal Windows Platformでは現状Azure周りの（.NET用の）ライブラリがそのまま使えない（Configuration Managerに依存してるものが使えない）ので代替案が必要
  • REST API等でShared Access Signature（SAS）トークンが必要になる

という感じです。

SASトークンそのものはアクセスしたいリソースのURIと期限等をHMAC_SHA256でハッシュ値を計算したものになります。とりあえずハッシュ値生成部分。

        public string ComputeSignature(string content, string key, BinaryStringEncoding encoding = BinaryStringEncoding.Utf8)
        {
            var algorithmProvider = MacAlgorithmProvider.OpenAlgorithm(MacAlgorithmNames.HmacSha256);
            var contentBuffer = CryptographicBuffer.ConvertStringToBinary(content, encoding);
            var keyBuffer = CryptographicBuffer.ConvertStringToBinary(key, encoding);
            var signatureKey = algorithmProvider.CreateKey(keyBuffer);
            var signedBuffer = CryptographicEngine.Sign(signatureKey, contentBuffer);
            return CryptographicBuffer.EncodeToBase64String(signedBuffer);
        }

UWP用のAPI（CryptographicEngineとか）を使ってる以外はごく普通ですね。
SASトークンそのものは以下のような感じで生成できます。

        private string CreateToken(string resourceUri, string keyName, string key)
        {
            TimeSpan sinceEpoch = DateTime.UtcNow - new DateTime(1970, 1, 1);
            var expiry = Convert.ToString((int)sinceEpoch.TotalSeconds + 3600); //EXPIRES in 1h 
            string stringToSign = WebUtility.UrlEncode(resourceUri) + "\n" + expiry;
            var signature = ComputeSignature(stringToSign, key);
            var sasToken = String.Format(CultureInfo.InvariantCulture,
            "SharedAccessSignature sr={0}&sig={1}&se={2}&skn={3}",
                WebUtility.UrlEncode(resourceUri), WebUtility.UrlEncode(signature), expiry, keyName);

            return sasToken;
        }

出来上がったSASトークンはHTTP RequestのAuthorizationヘッダに設定すればOKです。（別途書く予定ですがAMQPでSASトークンを使用する方法がわからない…）

※元ネタ How to create Shared Access Signature for Service Bus?