portal shit!

ブログを Docker 化して AWS ECS で運用するようにした。

なぜ Docker 化したか

• 仕事で Docker を使う機会が増え知見がたまってきた
• 仕事では Production 投入はできていないので個人ブログで Production 投入して知見を得ておきたかった

どうやったか

ローカルセットアップ編

• Dockerfile & docker-compose.yml を作成した
  • Alpine Linux を使ってなるべくイメージを小さくする
• Gem::LoadError 問題
  • Lokka の Gemfile には動的な読み込みを行っている部分があるため、 Dockerfile で単純に COPY するだけでは Gem::LoadError になってしまう。
    • Lokka のプラグインは Gem 化されておらずリポジトリ内に含める形式
    • プラグイン側で必要な gem はプラグイン内に Gemfile を配置して宣言する形式
    • Lokka 本体の Gemfile には Dir["public/plugin/lokka-*/Gemfile"].each {|path| eval(open(path) {|f| f.read }) } のようなコードがあって強引に eval で内容を取り込んでいる
  • 対策
    • Gemfile.docker を用意する
    • Gemfile.docker を生成するためのシェルスクリプトを用意して実行する
    • Dockerfile の COPY は以下のようにする
    • COPY Gemfile.docker /app/Gemfile
• 他、 MySQL のコンテナを追加して手元でアプリが起動するところまでは確認済み

Production セットアップ編

• ECR にリポジトリを作成し image を push （公式のチュートリアル通りにやればできる）
• ECS にサービスやターゲットグループ、タスクの作成なども指示通りに行う
  • 土台となる EC2 インスタンスは手動で作るのではなく、 ECS の画面でポチポチやると勝手に作られる
  • 詳細コンテナ設定でエントリポイントを入力する欄に、 Dockerfile と同じように文字列で書いていたらコンテナが起動せずハマった
    • カンマ区切りで書かないといけないらしい
    • puma を起動したかったら bundle exec puma ではなく、 bundle,exec,puma というように書かないといけない
• 諸々設定を済ませたらロードバランサー（ ALB ）を EC2 のパネルで作成してターゲットに Docker コンテナが動いている EC2 インスタンスを指定する
  • ECS の用語やサービス構成に慣れるのに時間がかかるが、歯を食いしばってがんばるしかない
• DB に関しては RDS を使うことにした
  • 稼働中の VPS サーバーで mysqldump -ufoo -p db_name | mysql -ubar -p db_name -h foo.bar.ap-northeast-1.rds.amazonaws.com みたいな感じで雑に流し込んで移行する
• ECS は VPC でしか使えないので、 VPC に慣れてない人は VPC に慣れるところから頑張るしかない
• セキュリティグループの設定なども必要になるので頑張って下さい
• Nginx を利用しないので SSL の復号を ALB で行う必要がある
  • ACM で無料で証明書を発行できるのを知らず、 Let's Encrypt の証明書を取り込んで使う
• ここまでで一旦公開

運用して気づいた問題点

• サイトが 503 や 504 になる
  • Docker コンテナがすぐ死ぬ
  • ALB から切り離されることしばしば
  • VPS 時代は Nginx に静的ファイルの配信をまかせていたが、 Nginx を挟まなくなったので puma が担当することになりアプリの負荷が高まったのではと推察
    • CloudFront を挟んでいい感じにキャッシュしてもらい、静的ファイルの配信は CloudFront にまかせることに

CloudFront 導入編

• ALB で使っているのとは別に SSL 証明書を取得する必要がある
  • CloudFront <-> ALB 間の通信を HTTPS で行うため
  • Route53 で ALB に割り当てている A レコードをサブドメイン付きの別のものに変更
  • ALB 用にはワイルドカード証明書を使う（無料で証明書取得できる ACM 最高）
  • Let's Encrypt の証明書を使うのはやめ、ルートドメインの証明書も ACM で取得して CloudFront に設定
• 動的コンテンツ（ HTML など）はキャッシュしないようにしないといけない
  
  • 当初、設定がうまくいっておらず、以下のような問題が発生
    • POST, PUT, DELETE できない
    • Cookie が origin に転送されずセッションが維持できない
    • クエリストリングが無視されてしまい、ページ検索などができない

所感

• 体感的にサイトの読み込みがチョッパヤになった
• CloudFront 導入したが、まだ 503 にはなる
  • そもそもインスタンスを良いやつに変えないとダメなのかもしれない
  • タスク数を増やしてクラスタリングするなどいろいろ試してみる
    • クラスタリングするためには Cookie セッションではなく Redis や Memcached などをセッションストレージに使う必要が出てくる…
• Deploy だるい問題
  • cap deploy しなくなり、イメージをビルドして push する感じになる
    • Alpine Linux でもそこそこイメージサイズはでかくなるので貧弱な回線では docker push にめっちゃ時間かかる
  • ECS 側でもサービスを更新するなどの作業が発生
    • Blue / Green Deployment できるがポチポチ作業が発生するのがだるい
    • Rails を運用する場合は migration なども発生するのでうまいことやる必要あり
  • git commit しなくても作りかけのコードの状態で docker-compose build してしまいがちになり、リポジトリのコードと動いてるコンテナイメージの間に差分が発生してしまいそう
    • ちゃんと CircleCI などを導入してイメージのビルドとプッシュは CI サービスでやる、というような運用にしないと破綻しそう
• 手順書問題
  • こんな風にブログを書いて雑な手順書を作成するようではいけない。 Terraform 化しないと破滅する。
• Lokka は CMS for Cloud です
  • git push heroku master するだけで使えることが売りの Lokka を AWS のガチな構成で運用するという皮肉
• お金高い
  • 毎月 3000 円くらいかかる感じになりそう。 VPS は年払いで 16000 円くらいなのでだいぶ高い。払えなくなったら VPS に戻しそう。

謝辞

r7kamura さんの amakan Docker 化の一連の記事と Classmethod 社の ECS 関連の記事には大変お世話になりました。

• amakanの開発環境をDockerに移行した - ✘╹◡╹✘
• amakanの本番環境をDockerに移行した - ✘╹◡╹✘
• Amazon ECSのELB構成パターンまとめ(ALB対応) ｜ Developers.IO
• CloudFrontとELB間をSSLで通信させる ｜ Developers.IO

Archives ページは部分的に React.js を使ってる。これを全部 React にして SPA 化してみたい。そのためには Server Side Rendering が必要。

Ruby で Server Side Rendering するライブラリでは react-rails が有名だけど、 Rails 以外で Server Side Rendering したい。

有名なやつでは airbnb の hypernova というのがあった。これ自体は Node.js で、 hypernova-ruby というクライアントからサーバーを呼び出して Server Side Rendering するというもの。なのでサーバー側に一個プロセスが増える。開発環境でも Node.js でプロセス起動したりしないといけない。仕事で Microservice には食傷気味になってきてるので趣味では Majestic Monolith™ で行きたい。

名前似てるけど Hyper-Ract というやつもあった。これは過激で JavaScript とか HTML を排除して Ruby で全部書こうぜという Opal が React 対応したもの。良いんだけど F/E の進化早すぎ問題に対応できなくなる気がする。数年後には CoffeeScript みたいになりそうな予感がある。スタンダードでシンプルなものを使いたい。

もう一個、スター全然付いてないしメンテナンスもされてなさそうなんだけど、 V8 で React 読み込んで出力するだけという簡単なのもあった。react-ruby-v8 という直球な名前。こんなので十分かもしれない。

京都であった RubyKaigi 2016 を観覧してきた。 RubyKaigi 、つくばであった 2010 がこれまでの人生での唯一の RubyKaigi で、人生二度目の観覧だった。

RubyKaigi 2010 の思い出

一度目のときは少し前に増田に上がってた勉強会ゴロ状態（受付の人と技術書を買ったジュンク堂の人と以外誰とも会話をせずに帰宅）だった。

ちなみにこのとき ESM の企業発表を見に行って、 ESM に転職したばかりの hsbt さんの姿を初めて目にした。なんか入社したばかりなのに社内ブログで暴れてて愉快、みたいな紹介のされ方だった。その後同じ会社で働くことになるとは思いもしなかった。

ESM の発表はとにかく鮮烈に印象に残ってて、ペアプロのライブコーディングだった。 ursm さんが CRM か何かの開発を実演してた。まず最初に落ちるテストコードを書いて、その後にパスするプロダクトコードを書く、というやつを初めて目にして、田舎で HTML コーダーをしつつちょっとしたプログラムを書いてた自分は衝撃を受けた。黒い画面の Vim で高速にコードを書いていく様がとにかくかっこよかった。はやくこういう感じでコード書けるようになりたい、と思ったものだった。

クックパッドの企業発表みたいのも聞きにいって、このときクックパッドもまだそんなにエンジニアの数多くなかったはずで、同じくはてなから転職してきたばかりのセコンさんが話してるのを聞いてトートバッグもらって帰った。

YAPC::Asia Tokyo 2015 の思い出

去年の夏、 YAPC で東京に行って、このときはペ社時代の知ってる人としゃべったりして無言の帰宅は避けられた。

YAPC 2015 は気がついたときには懇親会の申し込み締め切られててどこにも行けず、一人浜松町の宿泊先の近くの「とにかく安くて量が多い」と食べログにレビューが書いてある寿司屋に入って一人で寿司を食べたら寿司がねちゃっとしてて具合が悪くなったりしてた。

YAP寿司::Asia 始まった pic.twitter.com/5AI2FXedlJ

— morygonzalez (@morygonzalez) August 21, 2015

RubyKaigi 2016

今年も発表する側にまわったわけではないので一般ピープルである点は同じだったが、これまで話したことなかった人と話せたのがよかった。

取り分けよかったのが Fjord 社の komagata さんと話せたことだった。今後の Lokka の方針をどうするか開発者会議的なものを開催してババっと方針を決めましょう、という話をした。 Lokka 、思い入れがあるので積極的にメンテナンスに関わって今後も長く使い続けていきたい。

一日目

一日目は Kaizen Chat についてのブログ記事を公開するというタスクがあって、 Matz のキーノートとかはあまりじっくり聞けなかった。記事公開後に会社のブースで自分のシールを配布したりして公私混同してた。

今年の RubyKaigi は懇親会の枠が大きかったおかげで申し込みそびれるということにならなくてよかった。

オフィシャル懇親会で Fusic 社の k1low さんと初めてゆっくり話をした。Fukuoka.rb で顔を合わせることあっても一緒に酒飲んだりする機会なかったので RubyKaigi に来て初めてじっくり話すという感じだった。

ヒトデさんとその愉快な仲間たちの皆さんとも話して、 shikakun はオリジン弁当ばかり食べてるくせにやたら調理器具を持っていて不可解だとか、風呂蓋付きの浴室がある部屋にすんでいていけすかないという話をした。

Twitter で 8 年くらい前にハゲクラスタとしてわいわいやってた send_ さんとも再会できて、お互い帽子をかぶった状態でいまの仕事の話をしたりした。

オフィシャル懇親会のあとは、ヒトデさんオーガナイズの二次会に参加させてもらった。デンエンという物価が崩壊してる飲み屋に行ってタワーから注いで飲むビール飲みまくった。クックパッド社の著名エンジニアの皆さんと対面に座ったけど人に自慢できるような OSS とかなくて雑魚いので自己紹介に困ったが、とりあえずこういうアイコンのものですと言ってシールを見せたら「あ、なんか見たことある」という感じになったのでシール便利だった。

二日目

朝一番の Justin Searls さんのリファクタリングについての発表がとにかく面白かった。

Fearlessly Refactoring Legacy Ruby - RubyKaigi 2016

September 8..10, Kyoto, Japan

rubykaigi.org

去年 YAPC で GitHub の人が話してた sicientist と似てるけど、リファクタリング前後のコードで A/B テストをする gem の紹介。新しい方のメソッドが例外投げたら rescue して古い方のメソッドを実行するというのが面白かった。本番にも安心して投入できるとのこと。

三日目

午前二番目に tkawa さんの HTTP クライアントについての発表聞いた。 HTTP クライアント乱立しててひどい、 API をラップしてリモートサーバー側のクラスを再現するような異常なクライアント多くて、 REST API とは一体何なのか状態だ、みたいな話だった。言われてみれば確かにそうかもしれない。独自の API クライアント作ることなく、 Rack が Rack Middleware を use して拡張していくみたいに、 HTTP クライアントの側でも Middleware を use していくのがよい、そこで Faraday ですよ、という話で、あ、 Faraday ってそういうことを目的にしてたんだと膝を打った。

午前中最後の Chris Arcand 氏の発表が面白かった。

Deletion Driven Development: Code to delete code! - RubyKaigi 2016

September 8..10, Kyoto, Japan

rubykaigi.org

Ruby のコードを解析して呼ばれてないメソッドを調べる、という発表だった。実際に Rails プロジェクトとかで使うのは大変そうに見えたけどいまから君のプロジェクトに投入できるよ、 Rails もダイジョブみたいなことを言ってた気がするのでスライド見直したい。

最後のセッションの前、一日目のデンエン会で知古を得た pastak さん見かけたので uiureo さんを紹介してもらって話をした。 uiureo さん、初対面だけど話しやすくて好青年な感じだった。 r7kamura さんとも少ししゃべらせてもらってよかった。

飛行機の時間の都合があったのでクロージングまでは残らず、最後のキーノートの途中で離席して帰途についた。ホールを出ようとしたところで滑り込みで会場にやってきた元同僚の hisaichi551 さんと邂逅して自分のシールを何枚か雑に渡した。ゆっくり話がしたかった。

京都での開催について

京都での開催良かった。個人的には福岡からだと東京に行くよりも京都の方が近いので移動が楽で良い。首都圏からの大多数の参加者も京都に宿泊して参加するので夜通しどこかで RubyKaigi 関連の飲み会が開かれてる感じで祝祭感あった。夕方から観光したりできて海外からの参加者も満足度高いのではないかと思う。京都国際会館のインフラも素晴らしかった（施設、庭園、食事内容）。スポンサーの提供で振る舞われたお弁当おいしかった。

総合的な感想

RubyKaigi 、海外からのスピーカーの発表はどうやってよいコードを書くかとかリファクタリングとかの話が多い。日本人の発表者の人は Ruby を開発する方の話が多い。（ Ruby コミッターのほとんどが日本人だから）。なので Ruby 本体の開発に興味ない人（ Ruby 開発者ではなく Ruby ユーザーなプログラマー）はぽかんとすることが多いかもしれない。自分は結構ぽかんとしてた。

あと今回多いと感じたのが Concurrency についての話だった。どうやって Ruby で並行性を上げるかという話。 Thread は難しいので素人は手を出すな、ということはわかったけど Ruby 3 の Guild というので素人でも Concurrent なプログラムが書けるようになるかどうかは今ひとつわからなかったので資料を読み直したい（ reuibld.fm の Episode 158 を聞くと良い復習になりそう）。 Ruby 3 に並行処理の使い勝手が向上する前に、他の言語で並行処理について学んで準備をしといた方が良さそうだと感じた。

2010年の勉強会ゴロ状態のときに比べれば、何人かの人と話したりシールを配ったりすることができて、有意義な時間を過ごすことができたと思う。ただアイコンの気持ち悪さで認知されるよりも書いたソフトウェアの知名度で認知される方がよいので、カンファレンスに行って自己紹介するときに「○×というソフトを作ってます」と言えるようになりたい。仕事だけじゃなく、オープンソース活動もやっていけるように頑張りたいな、と気持ちをあらたにした会でした。

公私混同してる pic.twitter.com/nlrFCMOPXb

— morygonzalez (morygonzalez) September 8, 2016

Rails 、初心者にとってもよいフレームワークだと思う。いろいろ学びがある。ただ、なんとかスクールとかで金払って習うのではなくて、 DHH が書いてる『 Rails によるアジャイル Web アプリケーション開発』を読むのがよいと思う。あの本はコラム欄に Rails の裏側の思想とかが書いてある。なんとかスクールで習うのだと最速で Twitter クローンを作るだとか、 Rails の使い方しか身につかないのではないかと想像する。なぜ Rails はその様に作られてるのか、その裏側にある考え方は何か、まで合わせて学べばかなり色んなことが勉強できる。 Rails を使うようになって 5 年くらいになるけど、いまだに毎日発見がある。

http://david.heinemeierhansson.com/2012/rails-is-omakase.html

david.heinemeierhansson.com

Rails とかで例外が発生したときに Slack に通知するやつ作った。 exception_notification という便利 gem のプラグインとして動く。

GitHub - morygonzalez/exception_notification-slacky: Notify exception to slack channel

Notify exception to slack channel. Contribute to morygonzalez/exception_notification-slacky development by creating an account on GitHub.

github.com

実は ExceptionNotification 本体に SlackNotifier あるんだけど、通知内容があっさりしてて自分たちのユースケースには合わなかった。 IRC 使ってた頃は同僚のスーパープログラマー @udzura さんが作った exception_notification-ikachan を使ってて、それと同程度のエラー通知が来るのを Slack で実現したかった。

世の中には Airbrake のような便利なサービスあって、エラーの統計情報とか取ってまとめて通知してくれたりするものもあるけど、甘えてはいけない。エラーが即 Slack に通知されることで、バグを放っておくと Slack のチャンネルがてんやわんや状態になって業務に支障が出るのでバグを直すインセンティブが生まれ、ソフトウェアの品質が向上していくのである。

関わっているサイトの Rails のバージョンが 3.2.20 から 4.1.8 に上がった。自分は割と傍観していて他の人が主にバージョンアップしてたんだけど、いくつかはまりポイントがあって自分も Pull Request 送ったりしたのでやったことを書いときます。

1. session に注意

Rails 4 から Flash メッセージ（ログインしましたとか）を格納する session のオブジェクトが普通の Hash になってる。 Rails 3 ではこれは FlashHash とかいうやつ。

Rails 3 から Rails 4 へのアップグレードで一旦 Rails 4 を出してやっぱりやめて Rails 3 に戻したりとか、ロードバランサーに Rails 3 と Rails 4 で動くサーバーを混ぜてリクエスト捌いたりするとまずいことになる。

Rails 4 のサーバーで session 出来た人が次にリクエストしたときに Rails 3 に当たるとログイン後とかに session に残っているメッセージを消そうとする処理とかで NoMethodError が発生して落ちてしまう。しかもたちが悪いことに Rack 層で死んでしまったりするから皆さんよく使ってると思われる ExceptionNotification とかで気づくことが出来ない。これはつらい。

対処法としては Hash クラスをオープンしてモンキーパッチするというのがある。こういうの。

Rails 4 FlashHash Upgrade Gotcha | Jason Neylon's Blog

We upgraded an application from Rails 3 to Rails 4 this week and came across an interesting gotcha which I haven’t seen documented anywhere. As we rolled out the Rails 4 version of the app we split…

jasonneylon.wordpress.com

↑のだと #alert とか #notice が呼ばれたときにエラーになるので自分は以下のようにした。

# NOTE Rails 4 と Rails 3 を混ぜて使うと Hash#sweep が見つからなくてエラーに
# なるようなのでモンキーパッチします。
# 参照: http://jasonneylon.wordpress.com/2014/08/27/rails-4-flashhash-upgrade-gotcha/

class Hash
  def now
    Rails.logger.warn "Stubbing now during upgrade"
    {}
  end

  def keep
    # stub keep for upgrade purposes
    Rails.logger.warn "Stubbing keep during upgrade"
  end

  def sweep
    # stub sweep for upgrade purposes
    Rails.logger.warn "Stubbing sweep during upgrade"
  end

  def alert
    Rails.logger.warn "Stubbing alert during upgrade"
    self[:alert]
  end

  def notice
    Rails.logger.warn "Stubbing notice during upgrade"
    self[:notice]
  end
end

ただこれもパーフェクトではなくて、何もしないように上書きしているだけなのでログイン後のメッセージとか削除後のメッセージが消せなくなったりする。それでも 500 エラーになるよりかはましなのでどうしても Rails 3 と Rails 4 を混ぜて投入したいみたいときなんかは有効。

2. 絵文字に注意

Rails 3 の頃は ActiveRecord が絵文字を DB に保存することが基本的になかった。ユーザーが POST してきたフォームの中に絵文字が含まれてたら絵文字のところでテキストをぶった切って DB に保存するような挙動だった。しかし Rails 4 からは ActiveRecord は絵文字を素通りさせるようになってしまったので困ったことになる。

絵文字を DB に保存するためには、 MySQL の場合は DB のテキストエンコーディングを utf8mb4 というやつにしてないといけない。ただの utf8 だと保存時に Mysql2::Error: Incorrect string value というエラーが出て DB に保存できない。emojimmy のような gem を使えば utf8mb4 でない DB でも使えるけど、 stores_emoji_characters :column_name を忘れずにモデルに定義しないといけない。たとえば購入時に購入した製品のスナップショットを注文テーブルに取るような DB 設計だと、製品テーブルのカラムは stores_emoji_characters してたとしても注文テーブルのカラムを stores_emoji_characters し忘れていて死亡、というような悲劇が起こり得る。

いまはスマートフォンの時代で、ユーザーが入力してくるフィールドには必ず絵文字が含まれると思っておいた方がいい。スマートフォンをメインで使ってる人たちは開発者が想定しないようなフィールド（名前の敬称とか）に平気で絵文字を使ってくる。下手すりゃ住所や名前にも絵文字を入れて送ってくるかも知れない。アスキー文字しか受け付けないようなフィールドは JavaScript やサーバーサイドでバリデーション行ってると思うけど、マルチバイト文字列を受け付けるフィールドの場合はせいぜい長さくらいしかチェックしてないと思う。チェックを入れて絵文字を弾くことも可能だけど、スマートフォンの時代の流れに反しているしユーザーを失うことになりそう。これから新規でサービスを作ってデータベースに MySQL を使う場合はエンコーディングは utf8mb4 にしておいた方がいい。

他にも script/rails が bin/rails に変わってること忘れてて rails runner なバッチ処理が動いてなかったとか、 paranoia.gem の Rails 4 対応バージョンで物理削除のときに呼び出すメソッド名が変わっててはまったとかいろいろあったけど大きなところは上の session と絵文字だった。開発環境で使ってるときには気がつかず本番に出すまで気がつきにくいという意味で非常にやっかいな現象だと思う。

これから Rails 4 に上げる皆さんは頑張ってください。応援しています。

Rails の E2E テスト、ずっと Capybara + Poltergeist （PhantomJS）でやろうとしてたけど結局うまくいかなかった。

つらいポイントいろいろあって、 SSL 通信が必要なアクションでリダイレクトが発生してうまく動かないとか、 RSpec の use_transactional_fixtures オプションが利用できなくなるため Database Cleaner とか使う必要あったりとか、Parallel Test するときだけ通らないテストケースあったりとか、高速なマシンを使うときだけ落ちる、 Jenkins でだけ落ちる、といった問題が出てきたりする。

この手の問題、 sleep を入れたりとか mutex 化したりとか場当たり的な対応でテスト通すようにできることはできるけど、 unit テストのようにずーっと通る状態を維持し続けることが難しい（上に書いたように特定の端末でだけ落ちたりする）。おまけに何をやっても RackTest を使う場合に比べてテストが遅くなる。 Pull Request ビルダーでテストが実行し終わるまでに 15 分とかかかったりする。良くない。

かといって JavaScript のテスト書かない訳にはいかない。 JavaScript いっぱい使っててテストがないのはやっぱり不安が大きい。結局、JavaScript のコードを DOM べったりな状態から切り離して、サーバーサイドの Rails アプリケーションの挙動は request spec なり controller spec なりでテストして、 JavaScript のテストは JavaScript で行うのが良いような気がした。どうしてもエンドツーエンドテストやりたかったら Selenium 使うしかない気がする。これはスピードはあきらめて、 Pull Request ビルダーとかでビルドするときはテストやらずに、 master ブランチの定期ビルドとかでぶっ壊れてないか試す、みたいな方法が良いと思う。

もうこれ以上、エクセルにスクリーンショット貼り続ける訳にはいかないんだ。