Diary

@ssig33

16/Mar/2017 (Thu)

Cloud At Cost でのサーバー作成完全自動化した。 前は作成は手でやってちまちま Ansible で docker だの glusterfs だのをインストールしていたのだが、 Cloud At Cost の残存リソース量を監視してサーバーの作成から Ansible でのセットアップまでを勝手にやるようにした。

壊れたサーバーの削除まで自動化すればはかどるような気もする。壊れてるっぽかったらアラート投げるとかしてるので壊れてるっぽい時残存リソース量が十分あればとりあえず消しちゃってもいい気する。

02:41

手に巨大な血豆ができているのでチマメ隊になったとか言ってた

02:36

08/Mar/2017 (Wed)

mapk0y さんの反応で変なこと言ってないかとか確かめてるところある

16:26

money

16:25

06/Mar/2017 (Mon)

CloudAtCost がひさしぶりに大崩落している

16:16

05/Mar/2017 (Sun)

サーバーが多少体調崩してもサービス止まらないような構成を作った結果 としてサーバーが調子悪くなってることに気付けなくて、結構対処がめんどくさい段階になってから気付いて対処するみたいになっている。

ここで対処をもっと確実にやっていきましょうとかは当然だめで、早期の対処はなるべく自動化していく必要があるんだろう。縮退運転自動化みたいのばっか作ってきてしまった。

21:00

なんかいろいろ調子悪いっぽいけど気付いてなかった。

20:59

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)

セルフまとめ

また、実質的に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

Next