windyakinってなんて読む

うぃんぢゃきんではない

CloudFlareをDDNSで使うためにDDclientのDockerイメージつくった

つくった

f:id:windyakin:20180108172933p:plain

どうでもいい個人的な話から入ると、私がDDNSサービスというものに出会ったのは中学生の頃にDynDNSを使用した頃が最初出会ったと思う。いまでこそ有料会員にならないとまともに使えないサービスになってしまっているが、その頃は無料会員でもいろんなサブドメインを使用することができたので、ドメインを複数持っていなかった私はサブ垢までつくって色々取得していたように思う。

まあその辺の話はさておき、 CloudFlare というDNSサービスがある。無料でも込み入ったことさえしなければその辺のドメインレジストリが提供している無料DNSよりは高機能なので、私が所持しているドメインのほとんどのプライマリ DNS を CloudFlare にしている。しかも CloudFlare は API も充実していて大体の設定は RESTful な感じで設定することができる。つまりその API を使えば、実質的な DDNS を行うことができるので、いくつかのDDNSクライアントが CloudFlare に対応しており、 DDclient というソフトウェアもそのうちのひとつである。

DDclient は結構昔からある DDNS 用のクライアントソフトウェアで、もっぱら Linux のサービスとして動かすことを想定した解説記事などを見るのだが、時代は「cgroups だ！」「Docker だ！」という感じなので、どうせ Docker 化されたイメージが Docker Hub にあるんじゃないかとおもって探したのだがちょうどいいのがなかった。

  • linuxserver/ddclient
    • 設定ファイルを吐き出す Volume の持ち方があんまりイケてない
    • DDclient 側の問題だが起動するとマウントした設定ファイルのファイル所有者とパーミッションを変更する
  • outcoldman/docker-ddclient
    • 環境変数から設定できるのは Good だが CloudFlare で必要なパラメータの設定(zone)ができない
    • あとベースイメージが Ubuntu で無駄にイメージサイズが重い

これ以外にもいくつかあったのだが、面倒なので自分で作った。

ベースイメージはめちゃくちゃ軽い library/alpine で、DDclient が依存する Perl 関連のパッケージをいれるのに結構四苦八苦している。

DDclient の設定は環境変数からも設定ファイルマウントでも行うことができる。設定ファイルマウントを Read only にすることで、パーミッションの変更をむりやり抑制することができることに気づいた。

docker run -d \
  -e DDCLIENT_ZONE=example.com \
  -e DDCLIENT_PROTOCOL=cloudflare \
  -e DDCLIENT_SERVER=www.cloudflare.com \
  -e DDCLIENT_LOGIN=login-email-address@example.com \
  -e DDCLIENT_PASSWORD=your_api_key \
  -e DDCLIENT_HOST=ddns-host.example.com \
  windyakin/docker-ddclient

docker run -d \
  -v /path/to/ddclient.conf:/etc/ddclient/ddclient.conf:ro \
  --entrypoint ddclient \
  windyakin/docker-ddclient

実際に自分のサーバーでつかっているがいまのところ困ったことはなくて良い感じ。

社会を生き抜くためには「ラブライブ！ Dash Button」が必要だ

つくった

f:id:windyakin:20171225132223j:plain

これは ラブライブ！ Advent Calendar 2017 25日目の記事です。

前回のラブライブ！

ネットサーフィンをしているとよくみかける Amazon Dash Button と Raspberry Pi の組み合わせをやってみたくなった私は、Amazon Dash Button (PANTENE) と Raspberry Pi 3 Model B を買いました(これが1年ぐらい前)。買った当時はてきとーに Node.js をつかって「ボタンを押したらイベントが発動する」だけの実装をしたんですが、それで満足してしまったのともともと特に計画もないまま買ったものなのでそのまま部屋の片隅に放置されていました。

ところで私は家で酔っ払うと、しょっちゅう μ’s Live Collection を引っ張り出してきてはひとり鑑賞会を始める癖があります。μ'sのライブ演出は何度見ても見飽きない面白さがあると思います。

ラブライブ! μ's Live Collection [Blu-ray]

ラブライブ! μ's Live Collection [Blu-ray]

ある日、その日も飲み会帰りで酔っ払っていたため、ひとり鑑賞会をしていたのですが、そのときふと部屋の片隅に放置された RasPi が目に入ったわけです。

「ボタンひとつでライブ映像が見れる環境が欲しい！」

というわけで、Raspberry Pi と Amazon Dash Button を連携させて「ラブライブ！ Dash Button」を作ることにしました。

続きを読む

ここ数年のらりょすの雑コラ界、または雑コラが与える一般世間への影響について

日記

f:id:windyakin:20171201212016p:plain

この記事は らりょす Advent Calendar 2017 の1日目の記事です。

私はらりょす雑コラ界の端くれとしてよくらりょすの雑コラを作っています。はじめたきっかけは特にありません。Twitter を見ていて流れてきた会話とかから「このシチュエーションを画像にしたら面白いんじゃないか」みたいな思いつきではじめたようにおもいます。

さて、話は変わりますが、2年ほど前に Tumblr 上にらりょすの雑コラを集積するページを作ってたんですが、らりょす本人がアカウント更新を休止していた（とはいっても時たま動いていたが）時期もあったりしたため、2年前を最後に更新が止まっていました。しかしながらこの度 らりょす Advent Calendar があるということで、せっかくの機会なので更新をさぼっていた2年ほどの雑コラ画像をまとめなおしてみました。

raryosu-zatsucolla.tumblr.com

それぞれの画像については各記事のDescriptionをみてもらうことにして、改めてこの2年を振り返ってみると、らりょす雑コラ界のターニングポイントも多かったなと思いました。

というわけで今回はここ2年の間にらりょすの雑コラ界で起きた大きなできごとを振り返ってみたいなと思います。

続きを読む

Honoka を npm に対応させたので webpack に使って欲しい

Bootstrap

f:id:windyakin:20170802224242p:plain

8/3は高坂穂乃果さんの誕生日です。おめでとうございます。残りの言いたいことは概ねタイトルに書きました。

何日か前から対応していたので、もしかしたら気づいた人がいるかもしれないが、日本語も美しく表示できるBootstrapテーマ Honoka を npm で公開した。

www.npmjs.com

npm で追加するには以下のコマンドで追加できる。

npm install --save bootstrap-honoka
続きを読む

例えば、dotfilesをDockerイメージにする

f:id:windyakin:20170618180747p:plain

かねてより自分のシェルに関する環境設定を dotfiles として GitHub 上に公開することがベストプラクティスとして様々な人が行っていて、自分もそれを実践している一人である。

github.com

確かに dotfiles と GitHub による運用は便利だ。しかしながら dotfiles をある程度運用していくとほぼ必ず突き当たるであろう1つの課題がある。それは「クリーンな環境に適応するときにどうするか」だ。既に dotfiles を運用しているのであれば git pull すれば適応されるが、新しく用意した環境に対して自身の dotfiles を適用したい時どのような手順を踏んでいるだろうか。まさか初回インストールの度に各ファイルに対してシンボリックリンクを貼っていくといった単純な作業をしたいとは思わない。

その解決手段として、私はインストールのためのシェルスクリプトを書いて dotfiles に配置している。「私は」なんて偉そうなことを書いたが、だいたいこの問題に突き当たった人であれば同じような解決方法を考えるだろうと思う。シェルスクリプトは若干面倒ではあるが、基本的にはどのような環境でも動くはずであるし、追加ライブラリのインストールなんかもシェルスクリプト内に書けばその後の作業なんかも手間が省けるかもしれない。

というわけでシェルスクリプトを用意すれば初回インストールも完璧である。めでたしめでたし。

…ともいかない。新たな問題として「初回インストール用のシェルスクリプトをデバッグ＆テストする環境を用意する」という必要が出てきた。適当に書いたシェルスクリプトで「まあ動くだろう」と思っていたら、初期環境ならではの思わぬバグが潜んでいていざというときに使えないとか、そういう事態はできれば避けたいからだ。

まさか今使っているホストマシンを使ってテストするなんてことはやりたくないし、かといってそのテストのためだけに仮想マシンをいちいち用意するなんてこともやりたくない。

自由に使い捨てできる環境があればなぁ…

……そうか Docker だ。

続きを読む