Diary

@ssig33

05/Feb/2017 (Sun)

超シンプルな HTTP リバースプロキシとして動作するだけのコンテナ を作って Docker Hub に置いておいた。

https://hub.docker.com/r/ssig33/simple-reverse-proxy/

以下のように使う。

docker run -p 5000:80 ssig33/simple-reverse-proxy example.com:3225

こうすれば http://localhost:5000 => http://example.com:3225 へのリバースプロキシとして動作する。

これでどういううれしいことができるかというと、以下のようなことができる。 Docker Swarm Mode の外で動いている Web アプリがあったとき、それに対してリバースプロキシとしてのみ動作する service を Swarm クラスタに投入すれば、 Docker Swarm Mode のサービスディスカバリに Swarm クラスタ外のものを投入させることができる。

Swarm クラスタの状態などからエンドポイントを機械的に生成している場合などに、 Swarm クラスタ外のものに簡単に URL を付与できて便利。

たんに nginx の設定生成してるだけのばかげたものなんだけどコマンド一発で使えるとなにかとよい。こういう自分専用みたいなものもどんどん Docker Hub にあげてしまってよいと思っている。

18:38

31/Jan/2017 (Tue)

Amazon Polly わりと遅いので難しい

12:28

30/Jan/2017 (Mon)

WordPress を諸事情でいじりまくってて、気持ちです

22:11

docker 1.13.0 に上げたら Docker Swarm Mode かなりよくなった

  • docker service ps で mode=global なサービスの稼動状況が見えるようになった
  • service logs がきた(ただし experimental )

あたりがぼくにとっては猛烈に嬉しかった

13:16

いろいろ作っちゃいるんだけど表に出さないものばっか作ってる

12:17

22/Jan/2017 (Sun)

AWS に避難させてたサーバーを一部 Cloud At Cost に復帰させた

14:55

21/Jan/2017 (Sat)

glide をつかってつくったアプリを Heroku にデプロイする 方法ですが、 heroku/heroku-buildpack-go をみるとなんだかやれそうなかんじがしてくるのですが、

Heroku also supports GB. Glide support is a work in progress.

とあります。実際にやってみると、 glide つかってるとビルド時に vendor 以下をみてくれないようでビルドがこけます。

こっちがへんなことやってる可能性もたかいような気もするのですが、ドキュメントもないですしこのへん実際にやってるひともあんまりいないようです。ということでここは Docker と heroku Container registry でやってしまうのがいいとおもいます。ぼくはそうしてます。

Linux 向けバイナリの作成

これも Docker をつかうようにすると楽です。

docker run -v $(pwd):/go/src/PROJECT_NAME golang bash -c "cd src/PROJECT_NAME && go build"

こんな感じ。

実行環境用 Dockerfile

FROM frolvlad/alpine-glibc
RUN mkdir /app
COPY memo /app/PROJECT_NAME
CMD ["/app/PROJECT_NAME"]

こんなんでいいでしょう。 イメージサイズを極限まで節約したい人は glibc じゃない alpine でがんばればいいとおもいます。 Container registry が GA になったときどういう料金体系になるかわからないので、ある程度イメージサイズを節約しておくとよいかなとおもいます。

他の言語でこういうイメージサイズの節約をやろうとするとめんどうなものですが、実用性があり利用例もおおくでユーザーも沢山いる言語のなかで Go はやはりこのあたりの利便性はとてもたかいですね。

$ heroku container:push web -a APP_NAME

とかやると Dockerfile をみてビルドして push して Web アプリを更新するところまで自動でやってくれます。

Ruby アプリとかで積極的にこのしくみを使うメリットはないかなとおもいますが、公式未サポートの環境でもがんがんうごかせてすごい。

11:17

19/Jan/2017 (Thu)

Go でシングルバイナリな Web アプリを開発しているときに webpack --watch をうまいところやる

個人的なアプリをつくるとき、だいたい以下のような環境で作業しています

  • WAF は Echo
  • go-bindata をつかって各種アセットを Go のソースにくみこみ
  • webpack をつかって JavaScript をコンパイル

にたような環境の人はおおいのでは。

Go のアプリのビルドと実行は fresh でやってます。みんなつかってるとおもいます。 webpack にかんしては --watch オプションをつかうことで、物事がおこなわれていきます。

ここで問題になるのが webpack がコンパイルしたものをいちいち go-bindata で処理しないといけないということです。これを手動でやるのはいかにもダサい。ということでいろいろかんがえたりしらべたりしたところ、 on-build-webpack というものをみつけました。

これで webpack の設定で

  plugins: [
    new WebpackOnBuildPlugin(function(stats) {
      exec("./static.sh", function(e, o, e){});
    })
  ]

とかしとくと webpack がビルドするたびに go-bindata が自動で実行されます。またこれで go-bindata.go が更新されるのでそれをトリガーに fresh がアプリをビルドしてくれます。

ブラウザの自動リロードなどはやっていない(あれすごくきらい)のでこれでだいたい満足な環境がえられています。

14:57

12/Jan/2017 (Thu)

セルフまとめ

力武さんが FreeBSD の開発者コミュニティは衰退して ports がやばいみたいな話書いたら、日本の利用者コミュニティの悪口みたいなエントリ上がってくるのまさに BSD 界隈のしょうもなさが象徴されていると思った

— アラブ (@ssig33) January 11, 2017

力武さんが「FreeBSD は衰退しました」と言ったところ、佐藤先生がやってきて「俺はやっておるぞ、それはそうとして日本人はダメ」って叫び始めたという光景であり、本当に壮絶。

— アラブ (@ssig33) January 11, 2017

佐藤先生のエントリこの部分が一番やばくて、「老人ばっかだって力武さんはいうけど、若者もいるし、老人は沢山もどってきたし老人は沢山います」ってかいてある。力武さんの懸念が完全にただしいことがわかる。 pic.twitter.com/Bsqh3gUDp3

— アラブ (@ssig33) January 11, 2017

FreeBSD 界隈は老人だらけへの反論が、 FreeBSD 界隈には若者も入ってきてるし老人も沢山復活してきていて老人だらけ、なのがまじで感動的。今世紀の優勝だと思う。

— アラブ (@ssig33) January 11, 2017

なんていうか、まさに佐藤先生は力武さんのいうところの「ポップカルチャー」の人なんだよな。俺はたのしくやってんだから日本人どもはだまってろよっていってるわけで。歴史と運用を重視する力武さんのあの視点と徹底的にかみあわないのは、まあしょうがないのかねえ。

— アラブ (@ssig33) January 11, 2017

わざわざ佐藤先生に言及しておられたのはああいうエントリ出ないようにするための配慮だったのではみたいな気持ちになってる、結局出たけど。

— アラブ (@ssig33) January 11, 2017

また、実質的にmaintainer不在のPort2は数多くあり、その中にはSKK関連のものなど、(少なくとも自分にとっては)ないとかなり困るであろうものが含まれている。こんな状態で、先が続くのだろうか3。

FreeBSDの日本語ツールに関していえば、11.0になってからのlocaleの扱いの変更など容易でない問題もあるし、UTF-8化すらされていないツールがまだ残っていることを考えると、先行きは厳しいかもしれない。

という意見にたいして

プロジェクトの運営に関する議論はもちろん大事だが、コードを書くという作業が続いているなら継続性の心配は要らない。

という反論をするのは言語を理解する能力があるのか疑われるところだと思う。

運用者の視点からプロジェクトの今後を心配する意見を提出し、しかも自身も積極的に開発コミュニティに貢献する意志をあらわしておられる方にたいして、「うるせー俺はやってるぞ!!!楽しい!!!!」っていう記事をたたきつけるひとがいる「開発コミュニティ」に未来はほんとうにまったくないとおもう。

13:02

08/Jan/2017 (Sun)

コマンドを Docker で配布するみたいな話あったけど俺は mutt を Docker で実行したかった のでやってみたのだがまあ大変にひどいかんじでとりあえずできた。

1. モチベーション

いろんな設定ファイルをいれている dotfiles とかなんとかそんな名前のリポジトリがみなさんにもあるとおもうのですが、それを分割したいというのが当初のモチベーション。

2. 思いついた解決策

  1. Dockerfile と muttrc を入れたプライベートリポジトリをつくって、それをビルドしたものを自分の private registry かなんかにぶっこんでおく
  2. シェルの設定ファイルで docker run hoge みたいなものを alias でサクっと実行できるようにしておく

3. 実際に行なわれたこと

  1. とりあえず mutt をいれたイメージをつくって実行してみたところ Docker の Pseudo TTY はイマイチということがわかった
  2. SSH 経由ならどうか
  3. SSH と mutt だけいれたイメージをつくった https://hub.docker.com/r/ssig33/mutt/
  4. これをベースイメージに自分の設定だのロケールだのをぶっこむものをつくった
  5. bashrc には以下のように書いた
alias dmutt="docker run -d -p 3022:22 --rm --name=mutt #{IMAGE} && ssh -t -t -o 'StrictHostKeyChecking no' -p 3022 root@localhost mutt"

これで Docker 環境にとじられた mutt をまともにつかえることになった。

dotfiles リポジトリの縮小という目標にたいしてだいぶへんな解決策をあてはめているという自覚はあります。けどこんなかんじで普段つかってるソフトウェアを Docker でパッキングするのは以外とアリなのではとかちょっとおもってる。

20:00

06/Jan/2017 (Fri)

九州から東京かえってきたら一瞬で風邪なおった

14:38

03/Jan/2017 (Tue)

1/9 が休みなの知らなかった

17:53

02/Jan/2017 (Mon)

クリスマスとその後の休暇も終盤となり Cloud At Cost は落ち着いてきた。

00:33

01/Jan/2017 (Sun)

最近 C 書けなくて困ることがたまにあって、そろそろ年貢のおさめどきかと思う。

15:18

ページが糞ながくなっててだるいので短文日記をどんどん書くべきと思った

02:58

31/Dec/2016 (Sat)

etcd を Docker swarm mode の外で動かしたら galera cluster 安定するのかな。 それだと etcd のところが単一障害点になっちゃうかなと思うが現状ノード固定して MySQL 起動してるんだからそいつが明確に単一障害点だし変わらねえか。

00:06

年末なので Github で Star が多い Go のコード読んでる。 Go はわりと見様見真似で適当に書いてるのでたまにこういうことすると楽しい。

00:00

29/Dec/2016 (Thu)

今年買って微妙だったもの 10 選

Qtuo 金メッキコネクタ搭載1080P HDMI オス to VGAメスビデオ変換アダプタケーブル PC DVD HDTV用

出力先ディスプレイによって映ったり映らなかったり。そういうレビュー多いのでこれはそういうものっぽい。この手の商品はだいたい博打。

MOGU 補充用パウダービーズ 500g 822093

補充自体は成功して非常によかったのだけど、かなり注意深くやった結果やはりビーズの一部がゆかにぶちまけられる結果となった。覚悟はしてたし、想像してたよりずっと楽に掃除はできたけど。

掃除機で吸ってもどうにもならんので粘着テープのコロコロするやつがあるといいです。

ロゴス 着火剤 防水ファイヤーライター

木炭の着火剤。着火剤としての性能がまず文化たきつけと比較して大きく劣る。そしてそれ以上に致命的な欠点が、これ非常にぼろぼろと崩れやすく、室内で扱おうものならその辺がみんな着火剤の屑にまみれることになる。

文化たきつけを買った方がよいです。

オーム電機 カメラ一脚 3段階伸縮 540-1710mm OCM-001 OCM-001

耐久性に問題がありすぐ壊れた。

久順銘茶 謝さんの香る烏龍茶 凍頂四季春茶 80g

正直これそんなにおいしくない。凍頂四季春茶であって凍頂烏龍茶でないことを見逃していた点が失敗だったと言える

首・肩への負担軽減 【もちふわ エアチップピロー】 低反発チップまくら 枕 ホワイト Sサイズ 約35×50cm

枕に関しては合う合わないあるのでインターネットで買うべきではないなと思った。これの前に使ってたやつが本当にあわなくて辛かったので焦って買って失敗した。その後ニトリでやすいけどあうの見つけてよくなった。

【Spigen】 iPhone6s Plus ケース / iPhone6 Plus ケース, リキッド・クリスタル [ ソフト TPU クリア] アイフォン6s プラス / 6 プラス 用 カバー (クリスタル SGP11642)

大きな iPhone 6s Plus にこういうケースをつけるともう始末に負えない。結局すぐ外した。

Anker® タブレット用スタンド 角度調整可能 iPad・iPad mini・Nexus 7等に最適

スタンドとしては非常によろしく満足しているのだけど、意外と重くでかいので鞄に入れると、、、という感じ。これと iPad とキーボードを持とうものならたいていの PC ぐらいの重さになってしまう。

拠点ごとに複数買っておいておくみたいな使い方だといいと思う。

デイヴ・アスプリー - シリコンバレー式 自分を変える最強の食事

これは非常に危険な内容。人間が飢えているときの緊急事態モードを日常的に使おうという内容。どのような機械であれ最大出力を常時使ってやっていけるようには出来てないし、人間も例外ではないと思う。死ぬ気で頑張れば死ぬのでこういうことはしないほうがいいと思った。

20:41

28/Dec/2016 (Wed)

定期的に wget して CloudFlare あたためるみたいの規約的にはアリなのかな

00:50

27/Dec/2016 (Tue)

インフラエンジニアのいない会社で働いて 1 年半 が経った。 iOS で動く POS レジアプリとその管理インターフェイスの Web アプリケーションを作ってます。 iOS 側のことはほとんど分からなくて、データ同期用 API と Web アプリをずっと作っている。

ところで、 「NoOps」の時代がこない理由という記事が前にあったのですが、この点ぼくが働いている会社は NoOps です。アプリケーションは Heroku に乗っていて、 RDBMS が Amazon RDS で一部分析系に Google BigQuery を使っていること以外は全て Heroku 系の何かで動いています。

CI は Travis と circleCI を使っていて、 circleCI については来年初頭にも利用をやめて Travis に一本化する予定、というかんじ。

本当に自分達でなにもサーバーを管理していません。

これでやっていけているのかというと、まあやっていけています。 Heroku 使ってるからダメ〜みたいな感じの失注があったのかどうか知りませんが、まあそういう店舗はそもそもデータの置き場がベンダー側にしかない POS レジサービスを選択しないだろうと思う。

開発体制とか社内環境とかはさておき業務ドメインとしては割とおかたい感じのことをやっていますが、 NoOps でまわってます。

というわけで Heroku/NoOps で辛かったことと辛くないこと

  • Redis To Go という Heroku Add-on が極めて不安定だった
    • これ由来の障害が多発したので、 Heroku Redis に移行したら解決したみたいのがあった
  • Heroku Scheduler がたまに動かない
  • サービス名わすれたけどサポートチツールみたいなやつが 5 文字以上の TLD にメール送れない
    • shit@fuck.tokyo みたいなアドレスで死ぬ、この問題どうなったか忘れた

意外と辛くなかったこと

  • Heroku はアメリカ/ヨーロッパにしかサーバーがないので往復で時間無駄になる
    • これが嫌で Heroku 捨てる人達多いみたいだけど、これが嫌になるくらいチューニングされてんのか?
      • とはいえうちではチューニングが最近進んだのでそのうちこれが嫌になるかもしれない

自分達でサーバーメンテしてる故の強みみたいな話をする人達がよくいるけど、具体的にそれがなんなのか話してくれる人は意外と少ない。ロックインされてるデメリットはあるんだけど、まあ Heroku 捨てるってなったらそれはそれで半年もあればできるでしょう。

18:21

gulp はクソというのがもっとこう初心者にもリーチするようになってほしい

12:29

24/Dec/2016 (Sat)

バーベキュー

img

バーベキューとは何かということをアメリカ南部の田舎者に聞けば、おそらく肉を木で長時間スモークすることと答えると思います。今日はそういうことについて書きます。

バーベキューというのは日本では屋外でする焼肉みたいな意味の言葉ですが、上記のとおりアメリカでは肉を長時間スモークする料理であり、南部の郷土料理といえるでしょう。

img

この料理は一般にブラジル人の肉をローストする技法と、西アフリカ系の黒人の窯焼き料理の技法が組み合わさって完成されたといわれています。ただ、南部といっても奴隷と裕福な農場主だけがいたのではなくて、貧しい白人労働者もたくさんいたのですし、彼らがイギリスから持ち込んだサンデーローストの文化、技法の貢献も無視してはならないと思います。

実際、人種隔離時代の南部においても綿花収穫後などに盛大に行われるバーベキューの場においては人種の垣根が払われたそうです。バーベキューのみが南部において唯一人種を越える文化だったわけです。

img

ロースターの中には水皿を入れることが出来ますから、バーベキューという料理は要素技術としては以下のみっつに分解することができると思います

  1. シーズニング、ソースなどによるマリネ
  2. 低温調理
  3. 燻製
  4. 蒸し焼き
    • 酒蒸し、ワイン蒸し、ビール蒸しになる場合もあり

最近は銅蟲の影響で日本でも低温調理が再びブームになっていますから、皆さんの家に Anova やそのたぐいはあると思います。これで低温調理された肉に燻製の風味をつけることが出来ればバーベキューですから、さらにスモークガンを用意することで家が狭い皆さんもバーベキューを再現できるかもしれません。

img

幸いにして僕の家は(相対的には)広く庭があるので(一方で築 51 年に達しています)そのあたりの知識はあんまりない。

というわけで燻製などの話。

木には様々な物質が含まれており、これらは燃焼の際に様々な変化を起こしながら空気中にばらまかれます。これら化合物の香りを我々は通常煙の香りと認識します。また、肉からでた油が炭などに着いた際にもまた化学変化が起こり、この風味が肉に再び付着します。これらの作用によりバーベキューにおいては単なる真空低温調理よりも風味の深まった肉を得ることが出来るわけです。

img

そろそろ書くの飽きてきたわ。むろん温度管理などは Anova などよりはるかに難しいのでいろいろやっていく必要がありますが、毎週末やってればまあ 3 カ月ぐらいでものになると思います。その程度の技術だということです。

img

魚もこういう技法で処理していくことが出来ます。温度管理は肉より難しいです。

img

豚の肩ロースのバーベキューを一日冷蔵庫で保管したあと薄切りにしたものです。ロースハムなどのように使っていくことができます。燻製にしてるので一週間ぐらいかけて食べて大丈夫だと思う。サンドイッチにするとよいです。

img

具体的な技法は Youtube で BBQ とかで検索するとか、 Kindle で Texas BBQ Recipe とかで検索してでてきた本読むとかしてくれたらいいです。俺は解説したくない。

というわけで毎週末バーベキューをやると生活が改善するという話でした、終わり。

13:05

23/Dec/2016 (Fri)

うー

00:29

Docker イメージの最適化問題

前提 1. 実行環境は頻繁に捨てられる

  • オートスケールでの増減
  • CodeBuild 使う場合とか
  • サーバーの故障、不具合
    • ぼくが使ってるゴミクラウドみたいなやつではすっげー頻繁におきてる

前提 2. 面倒なことはしたくない

そりゃまあね。

すると?

綺麗に作られた Docker イメージはベースとアプリケーション固有部分が分離していて転送が最適化されるみたいな話はあるんですが、それはそうとして頻繁にベースごと吹き飛ばされるという環境で生活している人は多いのではないかと思う。

このような情勢のもとではいろいろ頑張って最適化したところでダメなときはダメだしみたいな話になってくる。

というわけでなのでこのへんあんまり神経質にやる必要はないと思う。普通に書けばまあ普通にある程度キャッシュされますよ以上のことを考えなくていいんじゃないかな。そういうところ神経質に気にしたい人は Docker 使わないほうがいいと思う。ただまあこのへんコストの判断基準をどこに置くかなので最終的には殺し合いになります、

golang:latest でビルドしたバイナリを alpine-glibc に突っ込むぐらいのビルドパイプラインだと複雑さはかなり低いと思うのでそれはありかなと思うけど、

ChimpoKnights とかあんなん維持するのにそんなに金払いたくないから alpine-glibc に Go のバイナリ一個載せるみたいなチマチマしたことやってるけど、これが仕事だったら絶対こんなことしないな

— イスラム原理主義者@天皇陛下生誕委員会 (@ssig33) December 22, 2016

という話です。ちなみに @ChimpoKnights さんは AWS Lambda と AWS CodeBuild で動いています。

00:28

22/Dec/2016 (Thu)

git のブランチ名 bash に出すやつ適当に設定したら補完の表示壊れてだるい

01:03

体調終わってる

01:00

Next