ぷろじぇくと、みすじら。

App Centerでビルドスクリプトが動かない

Created at: 2018-02-13 00:55:00Z

Visual Studio App Centerでビルドする際、特定の名前でシェルスクリプトを置いておくことでビルドの前後でコマンドを実行できます。

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に流し込む

Created at: 2018-01-18 09:40:00Z

ふと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に良しなに送られます。便利。

TP-Link Deco M5

Created at: 2017-12-31 23:10:00Z

以前から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 PlusとChipolo Card

Created at: 2017-12-31 20:20:00Z

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

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

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

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

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

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

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

Linux Containers on Windows (LCOW)を使う

Created at: 2017-12-27 18:10:00Z

Windows 10 Fall Creators Update (Version 1709)やWindows Server 1709以降では、ExperimentalなステータスですがHyper-V Isolationを利用して、Windows向けDockerでLinuxコンテナーを動かせるようになりました。それがLinux Containers on Windows (LCOW)です。

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

というわけでこれを使ってみます。セットアップの仕方は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を使うか次のアップデートリリースをお待ちくださいという感じです。