Diary

@ssig33

27/Feb/2017 (Mon)

conoha のサーバーがたまに死ぬ ので API で監視しては API 経由でリブートかけてるんだけどそのうち致命的にいろいろ吹っ飛びそうで怖い。

データはまあバックアップとってるし Docker Swarm Mode のおかげで復活にも大して時間はかからんのですが。。

23:31

26/Feb/2017 (Sun)

Docker 1.13 はだめ ということがわかってきたので 1.12 にいったん戻した。具体的になにが起きるかというと Docker swarm mode のマネージャーノードが 1.13 だと頻繁にメモリを大量消費してお亡くなりになられる。

worker が 1.13 で manager が 1.12 でも特に問題はないようなので当面その構成でやっていくことにする。

19:02

23/Feb/2017 (Thu)

LXD なんとなくさわってる。結構好き。

デプロイ以外の用途にも無理矢理 Docker 使ってる人はこっちも一緒に使ったほうがいいんじゃないか?

18:17

16/Feb/2017 (Thu)

iOS シュミレーター 遅いで検索したらサクっと答えがでてきてウケた。

http://ja.stackoverflow.com/questions/10019/ios%E3%82%B7%E3%83%9F%E3%83%A5%E3%83%AC%E3%83%BC%E3%82%BF%E3%83%BC%E3%81%AE%E5%8B%95%E4%BD%9C%E3%81%8C%E9%81%85%E3%81%84

このオプションなんのためにあんの、、、

18:36

最近 iOS Simulator が超絶遅くてこまってる

18:33

10/Feb/2017 (Fri)

WordPress で構築してたサイトを Heroku に移行させた

会社のサポートページが WordPress で構築されているのだが、これがよくわからないさくらの VPS にデプロイされていた。 OS が Ubuntu 12.04 でサポート切れ目前なのだが do-release-upgrade するよりは Heroku かなんかに引っ越してしまえばいいと思ったのでそうした。

を使うという手もあったんだろうけど、それはそれでめんどうそうだし自分達の運用ノウハウがある Heroku がよかろうという感じで決めた。

移行で実際にやること。

  1. 画像を S3 に上げる
  2. Heroku に WordPress デプロイ
  3. DNS 切り替え

まあこれだけなんだが、 1. は地獄である。

これについては実際のデータを見てほしいのだが、 wp_postmeta というテーブルの meta_value というカラムには例として以下のようなカラムが入っている(見やすくするために改行してます)。

a:4:{
  s:5:"width";
  i:2630;
  s:6:"height";
  i:1762;
  s:4:"file";
  s:44:"2017/01/d7ec2d3fea4756bc1642e0f10c180cf5.png";
  s:10:"image_meta";
  a:12{
    s:8:"aperture";
    s:1:"0";s:6:"credit";
    s:0:"";
    s:6:"camera";
    s:0:"";
    s:7:"caption";
    s:0:"";
    s:17:"created_timestamp";
    s:1:"0";
    s:9:"copyright";
    s:0:"";
    s:12:"focal_length";
    s:1:"0";
    s:3:"iso";
    s:1:"0";
    s:13:"shutter_speed";
    s:1:"0";
    s:5:"title";
    s:0:"";
    s:11:"orientation";
    s:1:"0";
    s:8:"keywords";
    a:0:{}
  }
}

えっ?なんだこのシリアライズ形式は。 WordPress が 15 年近く開発を継続されている CMS だと感じる瞬間である。画像を S3 に逃がすには WP Offload S3 というプラグインを使うのがよいのだが、過去画像について配慮してくれる機能はない。

WP Offload S3 は画像をアップロードするたびに wp_postmeta に上記の謎のシリアライズ形式で S3 に保存したよみたいな情報を保存してくれる。なので過去画像については自分で S3 にアップロードした後 wp_postmeta にそのデータを自分で insert すればよい。

ここで注意しなければならないのが、検索して出てくる情報は全て信用ならないということである。たいてい嘘か勘違いか古い情報が書かれている。すぐにデータベースをロールバックできる環境を作ってヒューリスティックになんども適当にやるのがよい。

過去記事に関しては、単に画像の URL を書き換えればいいだけなのでまあ sql の replace 構文かなにかを使って update をすれば一瞬。

Heroku へのデプロイはどうかというと、 wordpress ぐらいであれば push すれば動く。もし document root をプロジェクトのトップディレクトリ以外に変えたい場合(PHP だとそういうことは多いだろうし、実際僕は今回変えた)でも Heroku 側でサポートしてくれて Procfile を設置して

web: vendor/bin/heroku-hhvm-apache2

とかなんとか書けばいい。ローカルと Heroku で設置するファイルをちょっと変えたいみたいな需要もあるかもしれない(俺にはあった)。その場合はこの Procifile で apache 起動する前にふつうに cp コマンドとかでコピーするように設定すればいいだろう。

ちなみに上記のとおり Heroku では hhvm が使える。使えるのだが 3.5.1 とかなり古いので、まあ素直に PHP7 使ったらいいです。

なんか変なことしたい人は Container Registry 使ったらいいんじゃないですかね。

WordPress を Heroku に置くメリット

うちの会社の都合として Heroku に慣れてるというのがあった。それ以外に最大のメリットとしては Review Apps が使えるというのがあると思う。

デザインの変更の Pull Request の度に検証環境が立ち上がるようになるので、レビューとかはしやすくなるだろうと思う(とはいえまだサポートページの WordPress は Review Apps 有効化してない)。

感想

本当に WordPress と PHP は地獄で辛かった。

14:57

08/Feb/2017 (Wed)

WordPress の仕事が終わって本当によかった

18:51

06/Feb/2017 (Mon)

Go 化したやつ本番デプロイした、サイト軽くなった、、、

18:32

HTML 吐かせると一気に Go ダルくなる問題

18:26

Go で Web アプリ開発するメリット正直なんも無いと思うんだけど 、まあなんかやってるとなんとなく楽しいみたいのがある。

あとショボい環境とかでそこそこ速くなるか。

17:53

これ Ruby から Go に書き直してる

17:52

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

Next