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

App Centerでユーザー定義環境変数を取得できない

Created at:

Visual Studio App Centerではビルド時の環境変数を定義でき、ビルドスクリプトやGradleのようなビルドシステムから値を取得できるのですが、定義しても環境変数が取れないという現象が発生しました。

tl;dr

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

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

問題と調査

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

この定義を設定した上でビルドし、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 という名前を含めないでおくというのがハマらないポイントです。

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

Created at:

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

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

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

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

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

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

TiarraのIRCログをBigQueryに流し込む

Created at:

ふと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:

Deco M5

以前から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モード)で設定したのですが、とにかくちゃんと設定して安定して動くまでが怪しい…。

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

良かったところは設定の手順自体は簡単だったり、ネットワークが安定すれば切り替えもまあまあスムーズだし、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:

Chipolo Card & Plus

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

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

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

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

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

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