• AKS
  • Tiarra x 3 (IRCnet, Freenode, TIG)
    • fluentd
  • stunnel x 3
  • TweetIrcGateway
  • platformstatus.io
    • cert-manager + ingress-nginx (HTTPS)
• Netlify
  • このブログ (というかサイト)

今まで .NET なアプリがあったりしたのでWindowsなApp Serviceでしたが、.NET Core化して全部Dockerに乗せた結果Windowsで動いているものがなくなってしまった…かなしい。

ちなみに最初はGKEを考えたのですが、Load Balancerが月2,000円ぐらいかかるのでAKSにしました。まあk8sに乗せてればどこかに行くのも簡単でしょうし(慢心)。

しかしYAMLこねこね結構めんどくさかったので、改めてApp Serviceのお手軽さはいいですねと感じたのでした。

ところが設定しても再起動やユーザースイッチすると言語が英語に戻されてしまうという問題が発生しました。この現象自体は割とよくあるようです。

とはいえ不便なので試行錯誤したところ手元の環境ではMoreLocale 2で日本語に設定した後、第二言語設定にEnglishを追加したところ戻らなくなりました。もしこの現象で困っている人は試してみるともしかしたらうまくいくかもしれません。というメモです。

• mayuki/KumoDictionary - IDictionary<TKey, TValue> in the Cloud - Simple NoSQL/KVS wrapper for .NET

このライブラリは何かというと IDictionary<TKey, TValue> を操作すると、裏側ではネットワークの先にあるNoSQL的なもの、例えばAzure Storage TableやAmazon DynamoDBなどへ透過的に記録、読み取りを行うものです。

作った動機

Azure FunctionsやAWS LambdaのようなServerlessアプリ、もしかしたら単なるCLIで小さいツールといったものを作るということはよくありますが、その際にちょっとしたデータを保存したいということも同時によくあります。

例えばFunctionsでWebhookを作ったとして、特定のパラメータに対して最後にアクセスされた時刻を記録する…などなど。

じゃあデータ保存しましょうとなると、ファイルは永続化できる書き込み先はないし、Redisやデータベース的なデータアクセスはサーバーを用意するのもオーバーキル。そうなるとお手軽なのはNoSQL系かとなるのですが、いざSDKを入れて使ってみるとテーブルの設計と呼び出しがめんどくさいものです。

欲しいのは雑に Dictionary<TKey, TValue> が永続化されてくれるような程度でいいのですがーという気持ちからスタートしています。

IDictionary ということはブロッキングだし筋があまりよくないのではという疑問はごもっともですが、クラウド内であればレイテンシーも小さいことやそもそも低負荷のアプリであることをこのライブラリは期待しています。

パフォーマンスを真面目に気にする段階になったときは、Asyncメソッドをご利用いただくか、そもそも普通にSDKでアクセスしてください。

使い方

使い方はとりあえず Azure Storage Table であれば簡単です。

まずポータルやCLIでストレージアカウントを作成しておきます。

次に KumoDictionary.AzureStorageTable NuGetパッケージをインストールします。

そしてプログラムの頭で一度だけデフォルトのバックエンドの設定を行います。

using KumoDictionary;
using KumoDictionary.Provider;

// Set backend provider for Microsoft Azure Storage Table
var tableName = "MyTestTable";
var connectionString = "DefaultEndpointsProtocol=https;AccountName=...";

KumoDictionaryAzureStorageTableProvider.UseAsDefault(connectionString, tableName);

あとは KumoDictionary<TValue> クラスを使うだけです。ちなみにこれは KumoDictionary<string, TValue> の別名です。

// KumoDictionary を作るときにディクショナリーの名前を付けてあげる
var dict = new KumoDictionary<MyClass>("dictionaryName1");

// インデクサで値をセット
dict["key1"] = new MyClass { ValueA = 1234 };
dict["key2"] = new MyClass { ValueA = 5678 };

// インデクサで値を取得
Console.WriteLine(dict["key1"].ValueA); // => 1234

つまり最初のProviderの設定以外は普通のDictionaryっぽく扱えるのです(もちろん一部機能は実装されていなかったりはしますが)。

DynamoDB の場合

DynamoDBの場合にはテーブルの作成があらかじめ必要ですが、逆を言えばそれぐらいです。

裏側

裏側は単純にMessagePackでシリアライズして適当にストアに保存しているだけです。

ただ、値がもしデータストア側がネイティブで対応している型の場合にはそのままそれを使います。例えばAzure Storage TableやDynamoDBはStringを直接扱えるのでそのまま突っ込むことで管理画面や別なツールからもフレンドリーになるのです。

またキーの方も独自のクラスを使えますが、クラスの構造(プロパティやフィールドの名前、型、順番、数)が変更されると壊れるのであまりお勧めはできません。

雰囲気的にはRedis向けのCloudStructuresに近いですし、Redisに値を詰めたい or 詰めるのでよいのであればCloudStructuresを使うのをお勧めします。

まとめ

これでちょっとしたものを作るときにデータや設定の保存の手助けとなれば幸いです。

Application InsightsにはDependencyテレメトリーというリクエスト中に発行された外部リソースへのアクセスなどを記録する仕組みがあり、.NET向けの一式を入れておけばHTTPリクエストやSQL Serverへの問い合わせが自動で記録されます。

一方、標準で対応してないものをDependencyに出すには自前で何らかの方法で記録してあげる必要があります。MySQL Connector/Netもその例にもれず自動では記録されません。SQL Serverへの問い合わせが記録されるのはSqlClient (SQL Serverクライアント)のイベントを記録しているからであって、それ以外のデータベースドライバーでは記録されないのです。

というわけで、当然MySQLへの問い合わせでもDependencyに表示されてほしくなります。

Dependencyとしての記録

まずはそもそもApplication Insights上でDependencyとして記録するにはどうすればいいのかというところからです。

ドキュメントを見るとDependencyはテレメトリーの一種で、DependencyTelemetry というレコードを記録すればよいということになっています。

• See: Application Insights .NET SDK でカスタム操作を追跡する

記録するには DependencyTelemetry を生成する方法と、TrackDependencyメソッドで記録する方法があり、今回は DependencyTelemetry を使った記録方法で実装してみます。後者は細かいことはできないもののメソッド呼び出し一発とお手軽です。

実際の手順としては次のようになります。

• TelemetryClient クラスのインスタンスを作る
• TelemetryClient.StartOperation<T> メソッドを DependencyTelemetry 型を指定して呼び出す
• 帰ってきた IOperationHolder のTelemetryのプロパティを設定する
• 計測する処理を実行
• TelemetryClient.StopOperation メソッドを呼ぶ または IOperationHolder.Dispose メソッドを呼ぶ

これをコードにするとこうなります。

// TelemetryClientはスレッドセーフなので使いまわせる
var telemetryClient = new TelemetryClient();

using (var operation = telemetryClient.StartOperation<DependencyTelemetry>("DependencyName"))
{
    var telemetry = operation.Telemetry;
    telemetry.Type = "ResourceType"; // Dependencyの種類(Http, SQLなど)
    telemetry.Target = "リクエスト送信先"; // エンドポイントのホスト名とか
    telemetry.Data = "何か生データー"; // SQLとか

    // 何か時間のかかる処理...
    await Task.Delay(1000 * 3);
}

難しいことはないですね。これでApplication Insightsに記録する方法はなんとなく理解できました。

MySQLの呼び出しを記録する

Dependencyとして記録する方法がわかったので次はMySQLへの問い合わせを記録する方法です。

今回はMySQLドライバーはMySQL公式のConnector/Netを利用していて、単純にSQLのクエリを記録したいと考えていますが、それにはそのクエリのタイミングをつかむ必要があります。そこで少し調べてみると、Connector/NetにはInterceptorというExecute系メソッドに割り込んでSQLのロギングなどが行える仕組みがあったのでそれを利用します。

InterceptorにはあらかじめExecute系メソッドに割り込むためのベースクラスである CommandInterceptorBase クラスがあるので、このクラスを継承して各種メソッドをオーバーライドします。そしてここではオーバーライドしたメソッドでDependencyの記録を行えば良さそうというわけです。

実際に実装した例はこんな感じになります。DependencyのTargetやNameといった値の設定はSQL Serverでの記録と同じような形にしました。

using System;
using System.Collections.Generic;
using System.Data;
using System.Text;
using Microsoft.ApplicationInsights;
using Microsoft.ApplicationInsights.DataContracts;
using MySql.Data.MySqlClient;

namespace WebApplication2.Diagnostics
{
    public class ApplicationInsightsBaseCommandInterceptor : BaseCommandInterceptor
    {
        private TelemetryClient _telemetryClient = new TelemetryClient();
        private string _name;

        public override bool ExecuteNonQuery(string sql, ref int returnValue)
        {
            using (var operation = _telemetryClient.StartOperation<DependencyTelemetry>(_name))
            {
                var telemetry = operation.Telemetry;
                telemetry.Type = "SQL";
                telemetry.Data = sql;
                telemetry.Target = _name;

                return base.ExecuteNonQuery(sql, ref returnValue);
            }
        }

        public override bool ExecuteReader(string sql, CommandBehavior behavior, ref MySqlDataReader returnValue)
        {
            using (var operation = _telemetryClient.StartOperation<DependencyTelemetry>(_name))
            {
                var telemetry = operation.Telemetry;
                telemetry.Type = "SQL";
                telemetry.Data = sql;
                telemetry.Target = _name;

                return base.ExecuteReader(sql, behavior, ref returnValue);
            }
        }

        public override bool ExecuteScalar(string sql, ref object returnValue)
        {
            using (var operation = _telemetryClient.StartOperation<DependencyTelemetry>(_name))
            {
                var telemetry = operation.Telemetry;
                telemetry.Type = "SQL";
                telemetry.Data = sql;
                telemetry.Target = _name;

                return base.ExecuteScalar(sql, ref returnValue);
            }
        }

        public override void Init(MySqlConnection connection)
        {
            _name = String.Format("{0} | {1}", connection.DataSource, connection.Database);

            base.Init(connection);
        }
    }
}

Interceptorを実装したら最後にアプリケーションの設定でデータベース接続文字列に commandinterceptors パラメータを追加して読み込ませます。パラメータの値は<CommandInterceptorClass>,<Assembly>というフォーマットで、次のようなものになります。

commandinterceptors=WebApplication2.Diagnostics.ApplicationInsightsBaseCommandInterceptor,WebApplication2

そしてこれを有効にした状態でアプリケーションを実行するとApplication Insightsに記録されます。もちろんAzureに接続していない場合でもVisual Studioで確認できます。

この例では問い合わせが1ms以下なので全く面白くなくて残念ですが、ともあれこれで取れるようになったので無いよりは全然よさそうです。

今回やりたいこととしては「認証機構は基本的に一つで、あるアクションの時だけ認証中に追加で特殊な処理を行いたい」というパターンです。例えばコントローラーに共通のAuthorizeを付けているが、一部特殊なアクションでは追加の処理をしたいというケースです。

難しいところ

そもそも認証ハンドラーはASP.NET Coreの一部であってMVCとは切り離されたものなので、操作可能なものは主にHttpContextとなります。つまりASP.NET Core MVCが認識しているアクションであるとかコントローラーであるとかを取り出すことは難しいため、アクションに付けた属性を引いてくるといったことはできないという悩みがあります。

うまくいかないパターン

そこで最初に考えたのは、二つの認証スキームとして登録してそれぞれで利用する認証スキームを変更するという方法です。

まず次のようなオプションを持つAuthenticationHandlerを用意します。

public class CustomAuthenticationSchemeOptions : AuthenticationSchemeOptions
{
    public bool EnableNanika { get; set; }
}

public class CustomAuthenticationHandler : AuthenticationHandler<CustomAuthenticationSchemeOptions>
{
    public CustomAuthenticationHandler(IOptionsMonitor<CustomAuthenticationSchemeOptions> options, ILoggerFactory logger, UrlEncoder encoder, ISystemClock clock)
        : base(options, logger, encoder, clock)
    {
    }

    protected override Task<AuthenticateResult> HandleAuthenticateAsync()
    {
        if (Options.EnableNanika)
        {
            // 一部で必要な特殊な処理...
        }
        return Task.FromResult(AuthenticateResult.Fail("Unauthorized"));
    }

    protected override Task HandleChallengeAsync(AuthenticationProperties properties)
    {
        Response.Headers["WWW-Authenticate"] = "Nanika";
        return base.HandleChallengeAsync(properties);
    }
}

このハンドラーをStartupで二つの認証スキームとして登録します。

services.AddAuthentication()
    .AddScheme<CustomAuthenticationSchemeOptions, CustomAuthenticationHandler>("Custom1", options =>
    {
        options.EnableNanika = false;
    })
    .AddScheme<CustomAuthenticationSchemeOptions, CustomAuthenticationHandler>("Custom2", options =>
    {
        options.EnableNanika = true;
    });

コントローラーにAuthorize属性を付け、その際にコントローラーとアクションで認証スキームを別々に設定します。

[Route("api/[controller]")]
[Authorize(AuthenticationSchemes = "Custom1")]
public class ValuesController : Controller
{
    // GET api/values
    [HttpGet]
    [Authorize(AuthenticationSchemes = "Custom2")]
    public IEnumerable<string> Get()
    {
        return new string[] { "value1", "value2" };
    }
}

これでどうかと思ったのですが、この指定で実際に動かすとコントローラーの指定の方が勝つことになります。当然ですがコントローラーにAuthorizeを付けずにアクションごと個別につけると期待通りに動作します。

うまくいかないパターン(2)

認証はフィルターとしても実装できるので(Authorizeも実体はMVCのフィルターで、中で認証ハンドラーを呼び出している)、それをかけてみるのはどうかという風になります。

public class CustomAuthorize : Attribute, IAsyncAuthorizationFilter
{
    public bool EnableNanika { get; set; }

    public Task OnAuthorizationAsync(AuthorizationFilterContext context)
    {
        // ここで認証処理をあれこれやる
        return Task.CompletedTask;
    }
}

この場合にはコントローラーとアクション両方に指定すると二つのフィルターが呼ばれることになる(=二回処理が走る)ので都合が悪い感じになります。それに加えてAuthorize属性と同じようなことを書いてあげる必要があり面倒です。

解決策: フィルターを組み合わせるパターン

認証はフィルターとして実装できるという点を利用して、認証自体は行わずリクエストのデータにフラグを立てておき、認証ハンドラーで取り出して何とかする方法があります。その方法であれば 自前のフィルター(ASP.NET Core MVC) → 自前の認証ハンドラー (ASP.NET Core) という形にできます。

まずアクションにつけるフィルターを作ります。

public class UseCustomAuthenticationWithNanikaAttribute : Attribute, IAsyncAuthorizationFilter, IOrderedFilter
{
    public int Order => int.MinValue;

    public Task OnAuthorizationAsync(AuthorizationFilterContext context)
    {
        context.HttpContext.Features.Set<IUseCustomAuthenticationWithNanikaFeature>(new UseCustomAuthenticationWithNanikaFeature
        {
            Enable = true
        });
        return Task.CompletedTask;
    }
}

public interface IUseCustomAuthenticationWithNanikaFeature
{
    bool Enable { get; set; }
}
public class UseCustomAuthenticationWithNanikaFeature : IUseCustomAuthenticationWithNanikaFeature
{
    public bool Enable { get; set; }
}

このフィルターはOnAuthorizationAsyncでHttpContextのFeatures(リクエスト単位の機能を入れておけるもの)にフラグ情報を持つFeatureを保存します。IOrderedFilterを実装しているのはAuthorize属性より先に来てほしいためです。

次に認証ハンドラーを作ります。このハンドラーの中でFeaturesから先ほどのフィルターでつけていたFeatureを引っ張り出します。

public class CustomAuthenticationHandler : AuthenticationHandler<AuthenticationSchemeOptions>
{
    public CustomAuthenticationHandler(IOptionsMonitor<AuthenticationSchemeOptions> options, ILoggerFactory logger, UrlEncoder encoder, ISystemClock clock)
        : base(options, logger, encoder, clock)
    {
    }

    protected override Task<AuthenticateResult> HandleAuthenticateAsync()
    {
        var enableNanika = Context.Features.Get<IUseCustomAuthenticationWithNanikaFeature>()?.Enable ?? false;
        if (enableNanika)
        {
            // 一部で必要な特殊な処理...
        }

        return Task.FromResult(AuthenticateResult.Fail("Unauthorized"));
    }

    protected override Task HandleChallengeAsync(AuthenticationProperties properties)
    {
        Response.Headers["WWW-Authenticate"] = "Nanika";
        return base.HandleChallengeAsync(properties);
    }
}

Startupで認証ハンドラーを登録します。この際、AddAuthenticationでデフォルト認証スキームを登録しないように注意します。デフォルトの認証スキームとなるハンドラーは順番が特別なことになるので意図した挙動になりません。

services.AddAuthentication()
    .AddScheme<AuthenticationSchemeOptions, CustomAuthenticationHandler>("Custom", options => { });

そしてコントローラーにはAuthorize属性を、特別な処理をしたいアクションにはUseCustomAuthenticationWithNanika属性でフィルターを付けます。

[Route("api/[controller]")]
[Authorize(AuthenticationSchemes = "Custom")]
public class ValuesController : Controller
{
    // GET api/values
    [HttpGet]
    [UseCustomAuthenticationWithNanika]
    public IEnumerable<string> Get()
    {
        return new string[] { "value1", "value2" };
    }

    // GET api/values/5
    [HttpGet("{id}")]
    public string Get(int id)
    {
        return "value";
    }
}

これでアクションに属性を指定するだけで認証時の挙動を少し変更するということが可能になります。

製品仕様はキャンペーンサイトに書いてあり、Android 7.0であることが明記されています。

端末自体はHuaweiです。この手のセットトップボックスではHuawei製はよくあるようです(たしかauやdocomoのものもそうだったはず)。

OS

さて、Androidに関してですがよく見ると公式サイトの製品仕様にはAndroid 7.0とはあるもののAndroid TVとは書いていないのでもしかしたら…と思っていたのですがセットアップし始めるとやはりAndroid TVではなく単なるAndroidです。

そもそもセットアップステップがAndroid TV風でなくU-NEXTのログインが必須であったり、オンスクリーンキーボードもAndroid TVのそれではない、ホーム画面は独自というあたりでお察しです。

製品仕様によればアプリも利用できることになっているのですがAndroidがベースになっているだけでGoogleサービスが入っていないのでGoogle Playは使えません。「U-NEXTサービス、HDMI-CEC対応、Player for YouTube、Androidなど」とあるので使えるのかと思いきや。

YouTubeを観れそうな雰囲気ですがGoogle Play入ってないのにどうやって?と思ったらHuaweiの独自アプリでした。oh…。

現状U-NEXT用のアプリストアがあるわけでもないのでプレインストールのアプリのみ利用できます。なお設定のアプリ管理からアプリをアンインストールできるのですが、それらはインストールする口がないので消したら最後です(これはひどい。

参考までにほぼ同型機のdocomoのドコモテレビターミナルは説明書を見てもわかるのですが正真正銘のAndroid TVでロゴも表記されています。

adbを使う

とはいえAndroidなのでUSBデバッグとかできればなんかいろいろできるかもということで探すとちゃんとUSBデバッグはあります。

「アプリ」→「端末設定」→「情報」→「開発者オプション」→「USBデバッグ」で有効になるので有効にして、USBケーブルをつなぐと許可するかどうかのダイアログが表示されます。ちなみにUSBケーブルはType-Aなので注意が必要です。

接続後はいつものようにadbでコマンドを実行できshellにも入れます。そこで早速apkをインストールしてみようとすると次のようなエラーが発生しました。

adb -s 0123456789 install "app-release.apk"
adb: failed to install app-release.apk: Failure [INSTALL_FAILED_UPDATE_INCOMPATIBLE: Verify signature failed]

どうも署名チェックのようなものがあり、そこで引っかかっているようです。

提供元不明のアプリのインストールを許可する必要があるのか?と思ったので設定画面を開いてセキュリティから許可してみましたがダメです。Webを検索してもそれらしい情報はないので端末固有でロックをかけていそうです。うーん。

なお、設定画面は am コマンドを使えば開けます。

HWM380:/ $ am start -a android.intent.action.MAIN -n com.android.settings/.Settings

ちなみにバージョン情報はこんな感じです。

もう少し探ってみたところ /system/etc/security/apk_sign_white_list.xml というファイルがあり、署名のホワイトリストのようなものだったのでユーザーが任意にインストールするのは無理そうですね(HuaweiやU-NEXTだけが含まれている)。

一応 pm list packageの結果、パッケージの一覧はこんな感じでした。

まとめ

残念ながらAndroid端末としてはいじりがいがないのでそこを期待してはダメそうです。とはいえ特定サービス向けの装置なのでそこはしょうがないかなーという気もします。

U-NEXTのSTBとしてはきびきび動いたりするので普通に使う分には割とよいのではないかとは思いますが、実際お金を出す場合半額の4,980円でもどうかなー…って感じがしますね。リテラシがなくてつなげば使えるみたいなのを求めていない限り、正直縛りのないAndroid TVであるAirStick 4Kの方がよさそう。

そうそう、ログイン必須なので退会すると完全に使い物にならなくなります。

• Environment variables

tl;dr

SECRET のようなApp Centerが許可しないキーワードを含んだ環境変数を定義している場合、そのままの名前で露出しないようになっているようです。PASSWORD のような単語は通るので SECRET のみの制限かもしれません(ドキュメントに特に書いてない)。

ユーザー定義の環境変数は USER-DEFINED_ というプレフィックスがついた環境変数も定義されるのでそちらから取得する方法もありますが、ハイフンを含んでいるため参照も定義も一筋縄ではいかないのでお勧めできません。

問題と調査

API_KEY や NUGET_USERNAME のような環境変数を定義してみたところ特に問題なく取得できたので、もしかして変数名に問題があるのでは?と思いいくつかのパターンを試してみました。すると以下のパターンで違いが出ることがわかりました。

• SECRET_HAUHAU: hauhau1
• SEECRET_HAUHAU: hauhau2
• SECRE__HAUHAU: hauhau3

この定義を設定した上でビルドし、pre-buildスクリプトで環境変数をすべて出力すると…

##[section]Starting: Pre Build Script
==============================================================================
Task         : Shell Script
Description  : Run a shell script using bash
Version      : 2.1.3
Author       : Microsoft Corporation
Help         : [More Information](https://go.microsoft.com/fwlink/?LinkID=613738)
==============================================================================
[command]/bin/bash /Users/vsts/agent/2.127.0/work/1/s/app/appcenter-pre-build.sh
...snip...
SECRE__HAUHAU=hauhau3
...snip...
USER-DEFINED_SEECRET_HAUHAU=hauhau2
...snip...
USER-DEFINED_SECRE__HAUHAU=hauhau3
...snip...
USER-DEFINED_SECRET_HAUHAU=hauhau1
...snip...
SEECRET_HAUHAU=hauhau2
...snip...

…となり、SECRET_HAUHAU という変数のみそのまま露出しないようになっています。この結果からApp Centerは SECRET を含む環境変数をそのまま変数として露出しないようにしているようです。セキュリティのためでしょうか。

というわけで特別必要がなければ SECRET という名前を含めないでおくというのがハマらないポイントです。

2018年2月時点では Build scripts | Microsoft Doc にある通り、以下のスクリプトを認識します(for UWPなら.ps1)。

• appcenter-post-clone.sh: git clone後
• appcenter-pre-build.sh: パッケージ等復元後、ビルド前
• appcenter-post-build.sh: ビルド後

ここまでは書いてある通りなのですが、実際リポジトリにビルドスクリプトを含めても一向に実行されないという問題が発生しました。設定画面を見ると Build scripts: ✔ Post-clone と表示され認識はされているようでした。

新しいブランチを作ってビルド設定を追加して試すと問題なく動作したので悩んだのですが、実は Build scripts: ✔ Post-clone となった後に Save もしくは Save & Build で設定を保存する必要があるようです。

逆を言うと、ビルドスクリプトを削除した後も保存しなおさないとビルドがエラーになります。

新しいブランチを作った時に動いたのは、すでにビルドスクリプトが含まれていて、ビルド定義を作る際に Build scripts: ✔ Post-clone となった状態だったからということでした。

ふとTiarraでとったIRCのログをBigQueryに流し込むようにしたら手元にログを長期間残す必要もないし、検索もできるし便利そうだなと思ったので設定してみました。Twitterのログもあって若干流れますがBigQuery的には誤差の範囲レベル(1日1MB程度)なのでStreaming Insertして、たまーに検索しても無料枠で余裕で収まりそうです。

主な流れはTiarraで吐いたテキストログをfluentdのin_tailで読んで、fluent-plugin-bigqueryでBigQueryに流し込むという何の変哲もない形です。

Docker

ですでに手元のTiarraはDocker(docker-compose)で起動しているのでfluentdもDockerで起動しています。fluent-plugin-bigqueryはfluentdの公式イメージに追加する必要があるので適当に追加します。

FROM fluent/fluentd

RUN apk --no-cache --update add ruby-bigdecimal ruby-dev build-base && \
    fluent-gem install fluent-plugin-bigquery

ruby-bigdecimalが必要ということはREADMEにあるのですが、ruby-devとbuild-baseも必要で追加していないとfluent-plugin-bigqueryをインストール中にstrptimeのビルドで失敗します。

BigQuery Schema (schema.json)

次にBigQueryのスキーマを用意します。今回は次のようなものになっています。

[
    { "name": "Time", "type": "TIMESTAMP" },
    { "name": "User", "type": "STRING" },
    { "name": "Server", "type": "STRING" },
    { "name": "Room", "type": "STRING" },
    { "name": "Text", "type": "STRING" }
]

テーブル自体はこのスキーマを使ってfluent-plugin-bigqueryに自動生成させるので、BigQuery側にはプロジェクトとデータセットだけ作っておきます。このスキーマファイルは次のfluent.confと同じところにおいてください(最終的にdockerでマウントされるところ)。

fluentd (fluent.conf)

最後にfluentdの設定です。

source(入力)はssig33 - Tiarra のログを fluentd で流すを参考にin_tailを設定します。手元ではTIGのログが流れてくるのとサーバー名を分解するために少し変更しています。ログはローテートされるので %Y.%m.%d.txt で。

出力はfluent-plugin-bigqueryの設定を auto_create_table で設定します。これ自体は何のことはない設定なのですが table を年で分けるようにしようとしたところでハマりました。

table にはプレースホルダ文字列を使えることになっているのですが、文字列置換が有効になる条件としてまず buffer time/timekey を設定しているというものがあります。そこで timekey を設定すると %Y ではなく %d 精度のプレースホルダを持つ設定を要求します(参考: output.rb)。しかし今回は%Yでいいのに…困った…と考えた末に fetch_schema_table という使っていない設定項目に log_%Y%m%d 入れて回避しました。

とはいえ真面目にBigQueryを使うレベルなら日別にすると思うので(扱いづらいし…)罠にははまらないとは思います。日付パーティションにしてもいいかもとか頭をよぎりますが量も大してないので最悪あとで何とかすればいいでしょう(適当。

<source>
    @type tail
    path /fluentd/log/tig/tig-twitter/%Y.%m.%d.txt,/fluentd/log/ircnet/*/%Y.%m.%d.txt,/fluentd/log/freenode/*/%Y.%m.%d.txt
    tag tiarra
    
    format /^(?<time>[^ ]+)\ (<(?<room>[^ ]*)@(?<server>[^ ]*):(?<user>[^ ]*)>|\((?<room>[^ ]*)@(?<server>[^ ]*):(?<user>[^ ]*)\)|>(?<room>[^ ]*)@(?<server>[^ ]*):(?<user>[^ ]*)<|-(?<user>[^ ]*)-|>(?<user>[^ ]*)@[^ ]*<)\ (?<text>.*?)(?: \u0003\d+\([^)]+\).*)?$/
    time_format %H:%M:%S
</source>

<match tiarra>
    @type bigquery

    method insert

    auth_method json_key
    json_key /fluentd/etc/serviceaccount_key.json

    project <YourProjectName>
    dataset <YourDataSetName>
    table Log_%Y

    auto_create_table true
    schema_path /fluentd/etc/schema.json

    # table でplaceholderを使うために必要
    # buffer time/timekeyの設定が必要でそのためにplaceholderの%dをもつ設定が必要なので使わない項目をダミーとして使う…
    fetch_schema_table log_%Y%m%d

    <buffer time>
        timekey 1d
    </buffer>
    <inject>
        time_key time
        time_type string
        time_format %s
    </inject>
</match>

あとはこれでfluent/fluentd-docker-imageを参考にDockerでマウントしつつ起動すればログがBigQueryに良しなに送られます。便利。

以前からWi-Fiの電波の届き具合があまりよくないなと感じていて、アクセスポイントもAterm WR8500Nなので10年前のものだし、それ一台(途中で中継器を足したけど)で一軒家をカバーするのもまあ厳しいしもういい加減変えてもいいでしょう…。ということで、電波の届き具合で悩んだのでやはりここはメッシュWi-Fiにしてみようと思いTP-Link Decoを設置しました。

メッシュWi-Fiは一つのネットワークを複数のユニットでいい感じにカバーする仕組みらしいです(雑な説明)。まあ賢いローミングシステムをお手軽に構築できるものって感じでしょうか。Google Wi-Fiなどもこの手の製品ですね。Decoはスターターキットとして3つのユニットがセットになっています。

とはいえ個人的にはTP-Linkにはいろいろ思うところがあり、C5400を買ったときのメモを見ていただくとお察しいただけるかと思いますがブリッジモード(APモード)ではまった経験と最近話題のNTPサーバーへのアクセスの件もあって、正直心象はよくなかったのですが選択できる製品もあまりなく。あとから調べたらASUSのWi-Fi ルーターは組み合わせてメッシュを組めるとか…でもEthernet Backhaul相当があるのかはわからないですね。NETGEARのOrbiは2+1だとちょっとお高いです。

実際設置してどうだったのかというと安定のTP-Linkクオリティです(ほめていない)。今回もまたブリッジモード(APモード)で設定したのですが、とにかくちゃんと設定して安定して動くまでが怪しい…。

怪しかったのは次のようなところ。

• ユニットの追加セットアップしていたらなぜかネットワーク設定が消える
• ユニットの追加セットアップしたらなぜか同じ名前の別なネットワークが生み出される
• ユニットがネットワークから外したり、追加するとネットワークがしばらく不安定になる
  • 追加したのとは別なユニットが切断状態になって、しばらく待っていると復帰する謎
• ユニットがオフライン扱いだけどつながっている
  • 再追加すると上記の通りしばらく不安定になるのであまりやりたくない…
• プライマリとなるユニットがいるはずなのですが区別つかない
  • 最初ルーターモードから切り替えたときはゲートウェイって表示されていた
• 何が悪いのか見るすべがないのでエスパー力を問われる
  • Ethernet Backhaul してるのが悪いんじゃないか説?(追記あり)
  • 単に接続待ち?

良かったところは設定の手順自体は簡単だったり、ネットワークが安定すれば切り替えもまあまあスムーズだし、Backhaulしているおかげでどこにつないでも速度が出るというあたりでしょうか。C5400の時と同じで一度動けばWi-Fiは優秀みたいな…。

なんというかTP-Linkのルーターのブリッジモードはやっぱりやめた方がいいんじゃないかというのを改めて感じますね。Ethernet Backhaulせず、ルーターモードで使う分にはサクッとネットワークを組み立てられそうですが、ブリッジモードはある程度苦労を覚悟することをお勧めします。

まあとりあえず電波が家中に届くようになってなんとなく動いているので結果オーライということで。

追記(2018-01-03): どうやらEthernet Backhaulが鬼門らしく、ブリッジモードでEthernet Backhaulを有効にしたDecoユニットを追加すると謎の再起動や参加失敗(オフライン扱いになったり消えたりする)が発生するのでEthernet Backhaulを一旦諦めました。詳しくは検証していないのですがどうもスイッチと相性が悪い場合に似たようなことが発生するらしくそれかもしれません。

フォーラムの書き込みによるとD-Linkの一部スイッチはIEEE1905.1 プロトコルをうまく通さないため問題(リブートループ)が出る場合があるという話があり、D-Linkのスイッチではないものの手元も似たような現象なので原因は同じかもしれません。もし不安定なようであればスイッチを外してEthernet Backhaulを試していくのがよいようです。

ChipoloはBluetoothで鳴らせる忘れ物探しタグみたいなやつで、
kyoさんが買ったというのを読んで、まさにカード型のものが欲しいなあと思っていたのでこれは、と。国内の代理店ではCardを扱っていないので例によって輸入です。

HolidayでCardとPlus(普通のタグ的なタイプ)のセットが安くなっていて何にも考えずそれを選んだのだのですが、よく考えたらPlusは電池交換できないということにあとから気づくもまあRenewal Programあるしいいかなと思うことに。なおエントリーの頭のリンクから買うと20%オフになります。

で、Chipoloは何ができるかというと…

• スマートフォンからタグを鳴らせる
• タグからスマートフォンを鳴らせる
• タグとスマートフォンが離れすぎた場合に通知 (ただしBeta)

など。他にもカメラアプリのシャッターにもつかえるらしいとか。

特にタグから離れたときに教えてくれるのを目的に買ったのですが、実はその機能はChipolo Lab…つまりいわゆるベータという扱いで隠し機能になっているということにあとから気づくという…。kyoさんのエントリーを読んだときにはちゃんと理解していなくてちょっと悩んだのでした。

Labとはいえ家から出て少しするとスマートフォンに通知が来たので割とよさそうな雰囲気です。ただ、離れるとスマートフォンだけでなくタグもピロピロなるのですが、そっちを止める方法が欲しい…。電源が切れたりしても鳴るのでちょっとうーむ。

何がうれしいのかというと、通常WindowsでDockerを使ってコンテナーを動かす場合にはWindowsを動かすのであればWindows Containersを使い、Linuxコンテナーを動かすのであればHyper-VのVMを起動する、というどちらかの切り替えることになります。一方でLCOWを使った場合はどちらも同列に扱われ、LinuxコンテナーはHyper-V Isolationで起動されるようになります。

• Linux containers | Microsoft Docs
• Preview: Linux Containers on Windows - Docker Blog

というわけでこれを使ってみます。セットアップの仕方はLinuxKit based LCOW imagesにあるのでそれに従うと簡単に動きます。

Containers と Hyper-V を有効にする

Windows 10 Fall Creators Update (Version 1709)やWindows Server 1709以降でWindowsの機能の Containers と Hyper-V を有効にします。

Docker をダウンロードする

Dockerは開発版ブランチのビルドを使う必要があるので適当にダウンロードしてきます。逆を言うとこの時点でDocker for Windowsが入っていない環境でも大丈夫です。

Invoke-WebRequest -UseBasicParsing -OutFile dockerd.exe https://master.dockerproject.org/windows/x86_64/dockerd.exe
Invoke-WebRequest -UseBasicParsing -OutFile docker.exe https://master.dockerproject.org/windows/x86_64/docker.exe

Linux Kit をダウンロードして展開/配置する

Linux KitのReleaseページからの release.zip をダウンロードして、管理者権限のPowerShellで次のコマンドを実行してZipを展開して配置します。

Remove-Item "$env:ProgramFiles\Linux Containers" -Force -Recurse
Expand-Archive release.zip -DestinationPath "$Env:ProgramFiles\Linux Containers\."
rm release.zip

Docker デーモンを起動する

続いてDockerデーモンを起動します。管理者権限のPowerShellで次のコマンドを実行してください。

$env:LCOW_SUPPORTED=1
$env:LCOW_API_PLATFORM_IF_OMITTED="linux"
Remove-Item c:\lcow -Force -Recurse; mkdir c:\lcow
.\dockerd.exe -D --experimental --data-root c:\lcow

この dockerd を起動するときには --experimental オプションと LCOW_SUPPORTED 環境変数が重要なポイントです。

Linux コンテナーを起動してみる

あとはコンテナーを起動するだけです。Dockerデーモンを起動したコンソールはそのままになっていると思うので、別途管理者権限でPowerShell(かコマンドプロンプト)を開きます。

その前にバージョン情報を見てみましょう。

PS C:\Users\Tomoyo\Downloads> .\docker.exe version
Client:
 Version:       master-dockerproject-2017-12-23
 API version:   1.35
 Go version:    go1.9.2
 Git commit:    70db7cc0
 Built: Sat Dec 23 23:53:34 2017
 OS/Arch:       windows/amd64
 Experimental:  false

Server:
 Engine:
  Version:      master-dockerproject-2017-12-23
  API version:  1.36 (minimum version 1.24)
  Go version:   go1.9.2
  Git commit:   3e1df95
  Built:        Sat Dec 23 23:57:11 2017
  OS/Arch:      windows/amd64
  Experimental: true

注目すべきは Server の OS/Arch で、windows/amd64 となっているのでサーバーはWindowsであるということになります。リリースされているDocker for WindowsでLinuxモードにしている場合、DockerデーモンはLinuxのVMで動くため OS/Arch は linux/amd64 となります。

というわけで普通にUbuntuイメージを起動してみます。

PS C:\Users\Tomoyo\Downloads> .\docker run -it --rm ubuntu
Unable to find image 'ubuntu:latest' locally
latest: Pulling from library/ubuntu
50aff78429b1: Pull complete
f6d82e297bce: Pull complete
275abb2c8a6f: Pull complete
9f15a39356d6: Pull complete
fc0342a94c89: Pull complete
Digest: sha256:ec0e4e8bf2c1178e025099eed57c566959bb408c6b478c284c1683bc4298b683
Status: Downloaded newer image for ubuntu:latest
root@a3e889d2ad0d:/# head -2 /etc/os-release
NAME="Ubuntu"
VERSION="16.04.3 LTS (Xenial Xerus)"

ちゃんと起動できました。

Windows コンテナーを起動してみる

続いて同じ環境でWindowsコンテナーも起動できることを確認します。

先ほどDockerデーモンを起動する際に $env:LCOW_API_PLATFORM_IF_OMITTED="linux" を指定したので、起動するプラットフォームを指定しない場合にはLinuxコンテナーを起動することになっています。そんなわけで起動時にプラットフォームを指定するのを忘れないようにします。

今回は折角なのでWindows Server 1709のnanoserverを起動してみます。ちなみに nanoserver は latest タグを取ってくるとWindows Server 2016 (Semi-Annual Channel)のイメージが降ってくるので 1709 タグを明示的に指定する必要があります。(なおHyper-V Isolationならばホスト側とバージョンが異なっても動きます)

PS C:\Users\Tomoyo\Downloads> .\docker run -it --rm --platform windows microsoft/nanoserver:1709
Unable to find image 'microsoft/nanoserver:1709' locally
1709: Pulling from microsoft/nanoserver
407ada6e90de: Pull complete
9c9e16cbf19f: Pull complete
Digest: sha256:e6b719a2b4939c9bac0b16a970ef01f2a3b31d0b9d20079eb0163e15d815e46f
Status: Downloaded newer image for microsoft/nanoserver:1709
Microsoft Windows [Version 10.0.16299.125]
(c) 2017 Microsoft Corporation. All rights reserved.

C:\>

Windowsもちゃんと起動できました。

うれしいこととは

現状Experimentalなステータスであることを考えると実運用はちょっと…という感じですが、手元で開発するときなどLinuxもWindowsもコンテナーを起動したいという場合にどちらも深く考えず動かせるのは便利です。

起動はそれぞれのコンテナーが独立したVMになる分、若干遅いです(起動まで3秒ぐらい)。Docker for WindowsのLinuxコンテナーはMobyLinux VMの中でコンテナーが起動するのでその分速いのでしょう。

ちなみにDocker for WindowsのLinuxコンテナーのMobyLinux VMの中で動作するという仕組みからわかる通り、単一VHDXの中にイメージが降ってきて展開/起動するのですが、一方のLCOWはコンテナごとにVMなのでVHDXが裏で作られて捨てられる形になっています。

ボリュームマウントに関してはSMBのShare Driveではない仕組みで動いているのでShare Driveの設定が不要です。逆を言えば違う仕組みゆえにまだサポートされていないファイルシステムオペレーションがあるようなので一長一短ですが。

/ # mount
overlay on / type overlay (rw,relatime,lowerdir=/tmp/base/:/tmp/gcs/e82074d74d807cb0905916bd4fd5c2240bac5a1d24d7e8f61e3c080426c43a82/layer0,upperdir=/tmp/gcs/e82074d74d807cb0905916bd4fd5c2240bac5a1d24d7e8f61e3c080426c43a82/scratch/upper,workdir=/tmp/gcs/e82074d74d807cb0905916bd4fd5c2240bac5a1d24d7e8f61e3c080426c43a82/scratch/work)
(略)
/tmp/gcs/e82074d74d807cb0905916bd4fd5c2240bac5a1d24d7e8f61e3c080426c43a82/binds/mnt on /mnt type 9p (rw,sync,dirsync,relatime,trans=fd,rfdno=7,wfdno=7)
(略)

ともあれExperimentalなステータスを抜けたらだいぶ便利そうです。

FAQ: Not enough memory resources are available to complete this operation. (0xe)とか言われる

Windows 10 Insider Preview 17063だとLCOWで起動できない模様。

FAQ: -p や EXPOSE でバインドしたポートに localhost でアクセスできない

Available to Windows 10 Insiders Today: Access to published container ports via “localhost”/127.0.0.1 によれば Windows 10 Insider Preview では対応されたようなので、Insider Previewを使うか次のアップデートリリースをお待ちくださいという感じです。

• mayuki/Kurukuru: Terminal Spinner for .NET Core/Standard

コンソールで時間がかかる処理をやっているときなどにくるくるするやつを.NET Core(.NET Standard 2.0)で表示するライブラリを作りました。node.jsのcli-spinnersとoraを参考にというか実質ポートみたいな感じです。これで.NET Coreでツールを作った時にもちょっとオサレにできるはず…!

使い方は簡単で Spinner.Start もしくは Spinner.StartAsync にアクションを渡すだけです。

await Spinner.StartAsync("Stage 1...", async spinner =>
{
    await Task.Delay(1000 * 3);
    spinner.Text = "Stage 2...";
    await Task.Delay(1000 * 3);
    spinner.Fail("Something went wrong!");
});

ちなみにくるくるするやつが記号や絵文字を使っているものが多い都合、WindowsではコマンドプロンプトのコードページがCP932のようになっていると残念なことになるのでコードページを見てASCII文字のアニメにフォールバックする仕組みが入っています(他のライブラリにはない)。

また ora と同様にCI環境のようなノンインタラクティブな時には発動しないようにして、結果のみが表示されるようになっています。

コマンドラインツールを作る際にはどうぞご利用ください。

暑さと重さ

Core i7(dGPU)モデルでは無印のdGPUモデルよりもベース側(通称下半身)が1mm程度厚くなり100g程度重くなっています。

無印のwith Performance Baseモデルと同じになったと言った方がいいかもしれません。大きく重くなるの嫌だなーとは思っていたのですが、実際比べると元から重いのでもはや誤差みたいなものでした。とはいえMacBook Proは薄く軽くなる方へ進化しているので頑張っていただきたかったところですね。

ベースのヒンジ

ベースのヒンジは見た目が変わらず中身が変わったという話ですが、比べてみると開く角度が若干広がっています。ヒンジを改良するなら開く角度変わらないかなーと思っていたのでうれしい改修ですね。

キーボードまわり

キーボードのファンクションキーのFnでの機能をみると若干変わっていました。以前はキーボードのバックライトの明るさ調整(F1とF2)でしたが画面の明るさ調整になっています。ちなみにキーボードのバックライトは1つのキーで段階切り替えになっています。…まあ、そうなるな。

CPU

目に見えないところで地味に変わっている点としてディスプレイ側がファンレスとなったのはとても大きいです。

第8世代 Core i7が搭載されたことで4コアになったにもかかわらずファンレスになっていてヤバそうな感じがしますが、負荷のかかり続けるセットアップ時にサーマルスロットリングのようなものを感じなかったので基本問題なさそうです。素直にすごいですね。当然ベース側にはGPUの冷却用のファンはあるのでGPUをヘビーに使うとそちらはファン音がします。ちなみに日本では発売されない15インチモデルはディスプレイ側にもファンがついているそうです。

CPUの速度自体は第6世代のCore i5と比べると当然速いというか、デスクトップでCore i5-4570Sを使っているのですが、それと同等かむしろ上回るぐらいなので十分です。やはり4コアは偉大…。

その他

一応今回からついたUSB Type-Cにも触れておくと、この口からSurface Bookを充電できます。出力が足りないと充電できないのはMacBook Proと同じです。試した感じNintendo SwitchのACアダプターで充電できたのでMacBookのACアダプターでも充電できそうです(試してはいない)。

最後は買うときの注意ですが、初代はペンが同梱でしたがSurface Book 2では別売りになっているのでペンを使いたいと思っているのであれば一緒に買う必要があります。Surface Proとかもそうみたいなのでそういう方向性なのでしょうか。その一方でOfficeは日本モデルらしくOffice Home & Business Premiumがついています。Office 365をすでに契約していると完全に損なので同時購入でOfficeを安くみたいなキャンペーンにしてむしろOfficeを外してほしいですね。

最初はほとんど変わりがなくて面白くないなーと思ったのですが、Surface Dockはそのまま使えるし、細かい改善があったりCPUも体感で圧倒的に速くなっているので全体的な満足度は高いです。あとは値段がもう少しお安くなるといいのですがー。

• mayuki/Beatrice: Everything is a smart home device works with Google Home/Assistant.

これを家の中で立ち上げて連携しておくと、プロセスを実行したり、IRKitをキックしたり、WebHookを呼び出したりをGoogle Homeから仮想的なデバイスとして認識できるので、例えば「OK Google、Excelをオン(オフ)にして」でExcelを起動したり終了するといったことができます。

WebHookとプロセス実行さえあれば何とでもなるじゃろ感というやつです。

特徴 & IFTTTを使う場合との違い

[それIFTTTでできるよ]と言われそうですがBeatriceはIFTTTのトリガーと異なり、スマートホームデバイスのサービスとして振舞います。

例えばIFTTTのtriggerでは特定のワードに反応してWebHookを呼び出すといった形のため特定のワードを正確に発音する必要があり、「明かりをすべて消して」とお願いしてもホームデバイスとして認識していないので反応しません。

対してBeatriceはキーワード反応ではなく、操作する対象をスマートホームデバイスのサービス(Hueなどと同じ)のデバイスとして見せかけるため、他のホームデバイスと同列の操作可能がです。例えばプロセスの起動/終了を仮想的なスイッチとして公開できるので、いろいろなことができます。ただしその分設定は面倒です。

動機

最初はGoogle Homeで明かりのオンオフなどを行うのにIFTTT経由のIRKit呼び出しでいいかと思ったのですが、いざ使ってみるとそもそも設定したワードから外れると認識されない、スマートホームのデバイス扱いではないのでまとめてコントロールする命令が効かないといったところがイマイチだなーと感じていました。

そこでHomeKitに対するHomebridgeのようになんでもスマートホームのデバイスに見えるようにブリッジするツールがあればよいのではというところが出発点となっています。

仕組み

一般的にGoogle Homeの連携アプリはDialogflowあたりを使うと思いますが、Beatriceでは先にも書いた通りスマートホームデバイス向けのGoogle on ActionsのSmart home appの仕組みを利用します。

Smart home appの作り方のページにも書いてあるのですが、Smart home appはBeatriceに限らず下記の図のようにサービス登録して、連携するというフローとなります。

要するにサービスはOAuthのサーバーとなって、Googleは音声入力を解釈してコマンドに変換した後OAuthのクライアントとして投げつけてくるという構成ですね(意外とめんどくさい)。

そもそもこれは一般向けではなくHueのようなデバイスを多くのユーザーに対して提供する企業向けの仕組みです。そのため完全個人の固有のものであるBeatriceはテストプロジェクトとして動かすことになり、完全無保証です(!)

ちなみにもしこのようなものを作りたい(作ることになった)という方は
actions-on-google/actionssdk-smart-home-nodejsというサンプルがあるのでこちらを参考にするのがおすすめです。

動作環境 & クイックスタート

外部からアクセスでき、.NET Core 2.0が動けば動きます。つまりWindows、Linux、macOSで動作します。Raspberry Pi 3 + Raspbian Lite (Linux)でも動作可能です。

お試ししたい方はQuickStart(Quickとは言っていない)にそってお試しください。これ以外のドキュメントはREADMEしかないのです…。

なお現状サポートしているFeature(Beatrice用語で機能単位)はIRKit, WebHook, Process, Loggingです。

制限

テストプロジェクトで動かす都合、1アカウントにつきプロジェクトは1つしか有効にできません。
そもそも使い方として想定されていないので使えなくなってもまあそういうものです。

おわりに

現状ではオンオフ以外に対応していませんがステートを公開したり、モード切替、Web UIからの実行テストなどにも対応していきたいところです。

微妙なハックをしてる感のある代物の上、まだ作りかけなところも多くきちんと動かないかもしれませんが、もしお役に立つようであればどうぞご利用ください。

Windows 10でドメインに参加しているデバイスでMicrosoft アカウントを登録してもアカウントの同期設定を有効にできない問題があります。その一方で以前からある環境は有効なままとなっていることもあります。

発生する環境

• Windows 10 Creators Update以降のバージョン
• コンピューターがドメインに参加している
  • オンプレミスActive Directoryに限らず、Azure Active Directory参加(Join)の場合も含む
• ドメインアカウント(AD or Azure AD)でサインインしている

理由

設定とデータのローミングに関する FAQにあれこれ書いてありますが、要するにWindows 10 Creators Update以降ではいわゆる企業のアカウント(AD, Azure AD)とMicrosoftアカウントを結びつけることができなくなった影響です。

企業の所有の下で Azure AD に接続された Windows 10 デバイスの Microsoft アカウントは、今後ドメイン アカウントに接続できません。 Microsoft アカウントをドメイン アカウントに接続してそのユーザーの全データを Microsoft アカウントに同期させる機能 (Microsoft アカウントと Active Directory との接続による Microsoft アカウントでのローミング機能) は、Active Directory と Azure AD とが接続された環境に参加している Windows 10 デバイスからは削除されます。

Feedback Hubにもフィードバックが起票されていますが、企業アカウントの場合にはMSAではなくてAzure ADのEnterprise State Roamingを使ってくださいと。

In the Windows 10 Anniversary Update, domain joined users who connected their Microsoft Account (MSA) could roam settings and data between Windows devices. Many IT Pros told us that this functionality was not consistent with their policies for managing information owned by the organization. They did not want their PCs roaming to an individual’s personal cloud. A group policy to prevent users from connecting their MSAs did and does exist, but this setting also prevents users from easily accessing their personal Microsoft services. To address IT Pro concerns, we removed the ability for domain joined machines to roam with an MSA. Enterprises can still enable Enterprise State Roaming with Azure Active Directory.

ややこしいのが同期できている環境も場合によってはあるというところでしょうか。

どうやらCreators Update前にすでに同期していた環境であれば設定が引き継がれているためMicrosoftアカウントとの同期が可能なままということのようです。そのため新しくセットアップした場合に設定できずにハマります。

現時点で一応機能は残っているのでレジストリをいじると動かせるという話もありますが、今後を考えるとやめておいた方がよい気もします。

まとめ

つまり要するにどういうことなのかという話ですが…

• Microsoftアカウントでサインインしている場合
  • 気にしなくていい
• オンプレミス Active Directoryに参加してドメインアカウントでサインインしている場合
  • Azure ADとオンプレミスADが連携されている
    • Enterprise State Roamingが有効でAzure ADにJoinしていれば同期される
  • Azure ADとオンプレミスADが連携されていない
    • 無理
• Azure Active Directoryのアカウントでサインインしている(デバイスがAADにJoinしている)場合
  • Enterprise State Roamingが有効であれば同期される

確かに一貫性はありそうではありますが…うーん、今までできていたので不便ですね…。

まあとりあえずこれを踏まえて新しく設定するのであればアカウントの種類の使い分けとしては以下のような感じにするとよさそうです。

• 企業所有のデバイス
  • ADまたはAzure ADにデバイスを参加
  • プライマリアカウントをAD/AADアカウントでサインイン
  • AADのEnterprise State Roamingで同期
• BYODのデバイス
  • AD/AADには参加しない
  • プライマリアカウントをMicrosoftアカウントでサインイン
  • セカンダリアカウントでAzure ADに接続
  • 個人のMicrosoftアカウントで同期

メモ: Enterprise State Roamingで同期するとテーマが同期されない

ところでAzure Active Directoryに参加したデバイスでEnterprise State Roamingを利用した同期を行った際、テーマの設定(背景、ロック画面、アクセントカラー)が同期されませんでした。ExplorerやEdge、タスクバーなどの設定は同期されているので謎です…。

例えばLet’s Encryptは認証のために /.well-known/acme-challenge/Kk5osRC8Q2IKAVgreqBx6lCNgZ-nxzyKje8HJa611_c のようなパスにアクセスを試みますが、標準の挙動のままであればファイルがあっても404が返ってエラーとなります。わかりやすい組み合わせではAzure App Serviceで.NET CoreとLet’s Encrypt Site Extensionを利用している場合に発生します。

解決方法1. StaticFiles のオプションで不明な種類も返せるようにする

UseStaticFiles メソッドには StaticFileOptions という StaticFiles ミドルウェアの設定を渡せますが、その際に不明な種類を返せるようにする ServeUnknownFileTypes プロパティがあるのでそれを true にすることで返せるようになります。

app.UseStaticFiles(new StaticFileOptions
{
    ServeUnknownFileTypes = true,
    DefaultContentType = "application/octet-stream"
});

ただしこの設定を行うと、アプリケーション全体に反映されてしまうので意図せずファイルが公開される可能性が増えるのでやらなくていいのであれば設定したくないものでもあります。

解決方法2. ファイルの種類を提供する IContentTypeProvider を実装する

StaticFiles ミドルウェアはファイルの種類を取得するためのプロバイダー IContentTypeProvider を受け取ることもできます。この IContentTypeProvider にはファイルパスも渡ってくるのでパスを見て判断できます。

例えばLet’s Encryptが来るのは /.well-known/acme-challenge/ 以下と分かっているのでそこだけ知っているかのように処理をして、それ以外はデフォルトの FileExtensionContentTypeProvider や指定された IContentTypeProvider に任せます。

public class LetsEncryptWellKnownContentTypeProvider : IContentTypeProvider
{
    private IContentTypeProvider _baseProvider;

    public LetsEncryptWellKnownContentTypeProvider()
        : this(new FileExtensionContentTypeProvider())
    { }

    public LetsEncryptWellKnownContentTypeProvider(IContentTypeProvider baseProvider)
    {
        _baseProvider = baseProvider;
    }

    public bool TryGetContentType(string subpath, out string contentType)
    {
        if (subpath.StartsWith("/.well-known/acme-challenge/"))
        {
            contentType = "application/octet-stream";
            return true;
        }

        return _baseProvider.TryGetContentType(subpath, out contentType);
    }
}

IContentTypeProvider を実装したら、StaticFileOptions の ContentTypeProvider プロパティにセットすれば完了です。

app.UseStaticFiles(new StaticFileOptions
{
    ContentTypeProvider = new LetsEncryptWellKnownContentTypeProvider()
});

そんな時は IFileProvider を実装することで対応できます。

例えば、AddJsonFileに指定されたパスをJSONそのものとして扱ってしまえというようなものも作れて、以下のようなコードで実現できます。

// Install-Package Microsoft.Extensions.Configuration
// Install-Package Microsoft.Extensions.Configuration.Json
// Install-Package Microsoft.Extensions.FileProviders.Abstractions
void Main()
{
    var configuration = new ConfigurationBuilder()
        .AddJsonFile(new VirtualFileProvider(), @"{
            ""Foo"": ""barbaz"",
            ""Hoge"": 1234
        }", false, false)
        .Build();

    configuration.GetChildren().Dump();
}

public class VirtualFileProvider : IFileProvider
{
    public IDirectoryContents GetDirectoryContents(string subpath)
    {
        return new NotFoundDirectoryContents();
    }

    public IFileInfo GetFileInfo(string subpath)
    {
        return new VirtualFileInfo("virtual.json", Encoding.UTF8.GetBytes(subpath));
    }

    public IChangeToken Watch(string filter)
    {
        return NullChangeToken.Singleton;
    }
}

public class VirtualFileInfo : IFileInfo
{
    private byte[] _bytes;

    public VirtualFileInfo(string path, byte[] bytes)
    {
        _bytes = bytes;
        PhysicalPath = path;
    }

    public bool Exists => true;

    public long Length => _bytes.Length;

    public string PhysicalPath { get; }

    public string Name => Path.GetFileName(PhysicalPath);

    public DateTimeOffset LastModified => DateTime.Now;

    public bool IsDirectory => false;

    public Stream CreateReadStream()
    {
        return new MemoryStream(_bytes);
    }
}

要するにファイルを表す IFileInfo を返す、IFileProvider を実装して AddJsonFile メソッドに渡すことでその IFileProvider を通して内容を読み込むことになります。

上記の例では指定されたパスをそのままbyte配列にして IFileInfo で Stream として返すというだけのものです(重要ではないプロパティは適当なものを返す)。

テストやちょっと試したいときなどにファイルを作れない/作りたくないといった場合、他のデータソースから取得するといったパターンが必要になったときには役立つかもしれません。

例えばビルドしたアプリケーションをテストするために、後からコードを差し込んで診断用のコードを動かしたいといったパターンです。テスト用のコードをアプリケーションには含めておきたくない場合にはプラグインするかコードを差し込むかになります。

ここではMono.Cecilを利用してコードを後から差し込む方法を説明します。

Mono.Cecilとは

Mono.Cecilは.NETアセンブリを解析したり、書き換えたりするための便利なライブラリです。このライブラリを使うことで既存のコードを書き換えて新しいアセンブリを出力できます。

簡単な差し込み方

Mono.Cecilでコードを書き換えて既存のコードに自分のコードを差し込んでみます。

例えば以下のようなプログラム ConsoleApp1.exe があるとします。

using System;

namespace ConsoleApp1
{
    public class Program
    {
        public static void Main(string[] args)
        {
            Console.WriteLine("Hello Konnichiwa!");
        }
    }
}

そこでこの Console.WriteLine の呼び出しより前に処理を差し込みます。差し込みたい処理は以下のようなコードで別なアセンブリ(.dll)にしておきます。

using System;
namespace ClassLibrary1
{
    public class Class1
    {
        /// <summary>
        /// 差し込んだ側から呼び出してほしいメソッド
        /// </summary>
        public static void Initialize()
        {
            Console.WriteLine("差し込み案件です!");
        }
    }
}

そしてstaticなメソッドにしておくことで呼び出すためのILを最低限とでき、コードを差し込んだ側のスタックやローカル変数のつじつま合わせを考えなくてよくなるので単純になります。もちろん元のコードやオブジェクトに依存した処理を行いたいときは何らかの処理が必要となります。

ILの書き換えをする

というわけでILの書き換えをして新たに作ったアセンブリのメソッドを呼び出すように書き換えます。具体的には以下のようなコードとなります。

// ConsoleApp1.exe と ClassLibrary1.dll があるディレクトリ
var baseDir = @"Path\To\ConsoleAppDirectory";

// 対象となるアセンブリと型、メソッド名
var targetAssemblyName = "ConsoleApp1.exe";
var targetTypeName = "ConsoleApp1.Program";
var targetMethodName = "Main";

// 差し込みたいアセンブリと型、メソッド名
var injectAssemblyName = "ClassLibrary1.dll";
var injectTypeName = "ClassLibrary1.Class1";
var injectMethodName = "Initialize";

// 出力アセンブリ名
var outputAssembly = "ConsoleApp1_Injected.exe";

var assemblyResolver = new DefaultAssemblyResolver();
assemblyResolver.AddSearchDirectory(baseDir);

var asm = AssemblyDefinition.ReadAssembly(
    Path.Combine(baseDir, targetAssemblyName),
    new ReaderParameters
    {
        AssemblyResolver = assemblyResolver,
    }
);
var targetType = asm.MainModule.GetType(targetType);
var targetMethod = targetType.Methods.First(x => x.Name == targetMethodName);

var asmInject = AssemblyDefinition.ReadAssembly(Path.Combine(baseDir, injectAssemblyName));
var injectType = asmInject.MainModule.GetType(injectTypeName);
var injectMethod = injectType.Methods.First(x => x.IsStatic && x.Name == injectMethodName);
var injectMethodRef = targetMethod.Module.Import(injectMethod);

var ilProcessor = targetMethod.Body.GetILProcessor();
ilProcessor.InsertBefore(targetMethod.Body.Instructions[0], Instruction.Create(OpCodes.Call, injectMethodRef));

asm.Write(Path.Combine(baseDir, outputAssembly));

まず、AssemblyResolverを用意します。これはCecilでアセンブリを追加したりするときに正しく見つけるために必要となります。

var assemblyResolver = new DefaultAssemblyResolver();
assemblyResolver.AddSearchDirectory(baseDir);

次に差し込み先となるアセンブリを読み込んで、型とメソッド(差し込み先)を取得します。

// 差し込み先アセンブリを読む
var asm = AssemblyDefinition.ReadAssembly(
    Path.Combine(baseDir, targetAssembly),
    new ReaderParameters
    {
        AssemblyResolver = assemblyResolver,
    }
);
// 型を探してくる
var targetType = asm.MainModule.GetType(targetType);
// 差し込み先メソッドを探してくる
var targetMethod = targetType.Methods.First(x => x.Name == targetMethod);

差し込む先が見つかったら次は差し込みたい処理を読み込んで探します。

// 差し込みたいアセンブリを読み込む
var asmInject = AssemblyDefinition.ReadAssembly(Path.Combine(baseDir, injectAssemblyName));
// 差し込みたい処理の型を探す
var injectType = asmInject.MainModule.GetType(injectTypeName);
// 差し込みたいメソッドを探す
var injectMethod = injectType.Methods.First(x => x.IsStatic && x.Name == injectMethodName);

差し込み先に参照を追加し、その差し込み先内でメソッドの参照を得ます。これは差し込み先で差し込まれる側のアセンブリに対する参照情報を使うので必要です(MethodDefinitionは直接アセンブリをまたぐことはできない)。

var injectMethodRef = targetMethod.Module.Import(injectMethod);

そして呼び出すためのコードを差し込み先のメソッドに書き込みます。

// 差し込み先のメソッドのILを操作するILProcessorを取得
var ilProcessor = targetMethod.Body.GetILProcessor();
// 一番最初のIL Instructionの前に差し込み先メソッドを呼ぶ call opcode を差し込む
ilProcessor.InsertBefore(targetMethod.Body.Instructions[0], Instruction.Create(OpCodes.Call, injectMethodRef));

これが…

IL_0000:  nop
IL_0001:  ldstr      "Hello Konnichiwa!"
IL_0006:  call       void [mscorlib]System.Console::WriteLine(string)
IL_000b:  nop
IL_000c:  ret

こうじゃ。

IL_0000:  call       void [ClassLibrary1]ClassLibrary1.Class1::Initialize()
IL_0005:  nop
IL_0006:  ldstr      "Hello Konnichiwa!"
IL_000b:  call       void [mscorlib]System.Console::WriteLine(string)
IL_0010:  nop
IL_0011:  ret

最後に書き換えたアセンブリを書き出して終了です。

asm.Write(Path.Combine(baseDir, outputAssembly));

実行結果

これで書き換えたアセンブリ (ConsoleApp1_Injected.exe) を実行すると以下のような出力となります。

差し込み案件です!
Hello Konnichiwa!

まとめ

Mono.Cecilで簡単にアセンブリを書き換えられるのでビルドしてしまったアプリの魔改造がはかどります。普段、ビルド後のアセンブリを書き換えたい機会は多くないと思いますがいざというときに処理を差し込む一つの方法としては覚えておいて損はないのではないでしょうか。

サンプルコードは https://github.com/mayuki/Sample.MonoCecil に置いておきますのでどうぞご利用ください。

ところがSONYのBRAVIA (Android TV)と外部サウンドシステム(サウンドバーなど)を組み合わせていると正常に動作しないようです。Nougatな機種ではわかりませんが、現状初代のMarshmallowな機種(X8500C)では挙動がおかしく正常に設定できません。

解決方法

いろいろ試した結果、この問題を解決する方法は2つありますが根本解決はできないようです(場合によってはどうにもならない…)。

一つはサウンドシステムの利用をやめてテレビからのオーディオ出力にする、ですがこれは現実的ではありません。

もう一つはサウンドシステムがHT-NT3のような単体でChromecastに対応しているのであれば、サウンドシステムの名前を「スピーカー」とすることで「スピーカーの音量を10%にして」ということで直接コントロールできます。

ちなみにHT-NT3を接続して操作した場合には音量10%の指定はテレビで音量10、サウンドバー側でVol 5相当になります。

まあしかし他にもちゃんとキャストされないことがあったり全体的に挙動が怪しいのできびしいですね…。SONYさん頑張ってください…。