cap2でつらかったこと

• cap2がそもそもメンテされてない
• capistrano-drecom-deploy や capistrano-drecom-sidekiq(社内gem)がcap3前提なのでcap2だと社内gemの恩恵を受けられない
  • capistrano-drecom-deploy はnginx, unicorn 系のRailsアプリでよくある便利taskが揃ってる
  • drecom:unicorn:setup で /etc/init.d/unicorn-appname を生成してサーバにアップロードする

cap3に移行した時の手順

• config/にあった既存のcap2タスクをconfig_old/ に移動
• Capfileを削除してcap3にアップデートして cap init
• cap3検証用のサーバを構築
  • OpenStackの既存のサーバのスナップショットを作ってコピー
• capistrano-drecom-deployを適用（1日）
• その他のタスクをcap3に地道に移行（1〜2週間）

既存の開発サーバ

• cap deploy
  • 本番と同じロケーションにある開発サーバからgit cloneした時に7GBあるリポジトリのgit cloneが15分だったので本番はそれ以上かからないだろうと予想
  • メンテ時間を短縮するために予め1台ずつgit cloneしておくことに（後述）
• その他initスクリプト系をcapistrano-drecom-deployに追従

【小ネタ】cap3で予めcap deploy前にgit cloneしておく方法

• cap deploy 時に git clone されるので、普通にやるとリポジトリがでかいとcloneに時間が掛かるので可能ならメンテ入れる前にgit cloneだけはしたかった
• v3.3.4くらいで動作確認

手順

Capfileに下記を追加

require "capistrano/git"

• git cloneだけするコマンドはcapistranoに存在するのだが個別に使うためには capistrano/git を require しておかないと使えない

コマンド

bundle exec cap xxxx git:update HOSTS=xxx.xxx.xxx.xxx

• cap git:clone だと git clone するだけだけど、cap git:update だとリポジトリがない場合には git clone してリポジトリがある場合には git fetch してくれるので冪等性があるのがよい
• HOSTSをつけることでそのhostだけにcapコマンドを実行できるのでwebサーバ1台ずつ作業したいとかには使える
  • 実は前方一致なので HOSTS=xx.yy.zz.0 って書くと xx.yy.zz.01 〜 xx.yy.zz.09 に対して実行される
  • 一歩間違えるとサーバ1台ずつ実行するつもりがサーバ全台でcap実行という恐いことになる

git cloneが思ったより時間がかかった

• 本番と同一ロケーションのステージングサーバでgit cloneした時は10〜15分くらいだったのに、本番だと30分弱かかった
• 一度に2〜3台ずつgit cloneしようとしたら逆に時間が伸びてしまった（3台同時で90分くらい）
  • 社内GitLabのトラフィックが詰まった？
• 1台だけgit cloneしておいて残りはrsyncでよかったかもしれないが未検証だったので実施せず
  • （文字通り）ぶっつけ本番で実行すると余計悪化する可能性があったため
• メンテ中にもつれ込んだのでメンテ中もgit cloneしつつ、cap3化していたサーバのみでサービスインしようと目論む

一定確率でメンテ画面がエラーになる（その1）

メンテ画面のリロードボタンを押すと2〜3回に1回の確率でエラーになる

原因

• 「13:00〜16:00までメンテナンス中です」みたいなファイルを /var/www/app/current/public/system/maintenance.json に置いていたのだが、cap3でデプロイした時にそのファイルが吹っ飛んだ
• LBにはcap2でメンテ入っているサーバとcap3でメンテ入ってるサーバが混在していたのでエラーになったりならなかったケースが発生
  • cap3でデプロイしたサーバにアクセスが来た時にエラーになる
• 再度ファイルを設置することでエラーは解消

一定確率でメンテ画面がエラーになる（その2）

メンテ画面のリロードボタンを押すと3〜4回に1回の確率でエラーになる（さっきよりちょい頻度は少ないけどそれでも結構多い）

事象

• nginxのエラーログに「SSL_do_handshake() failed (SSL: error:140A1175:SSL routines:SSL_BYTES_TO_CIPHER_LIST:inappropriate fallback) while SSL handshaking」が大量に発生
  • 普段でもちょいちょい出てるんだけど（1日数十件）、メンテ中のある20分間だけで800件発生
  • nginxの設定ファイルを更新してたが、改行とコメントアウトの削除くらいしか差分がない

• ずっと調べていても時間がかかるだけだったので、cap2に切り戻してリリース作業を継続することに
  • cap3にしたサーバはLBから切り離してcap2のままのサーバをサービスで使う
  • ソースコード上はcap3なのでメンテ中にcap2に戻した
  • config_old/ を config/ に上書きしただけなので切り戻し作業は20分くらい

メンテ翌日の調査

• /etc/hosts を書き換えてLBを通さずにサービスアウトしてた本番のwebサーバに直接リクエスト投げたけどSSL_do_handshakeのエラーは一切発生しなかった
• webサーバが原因でないことが分かったのでインフラにLBのログを調べてもらった

原因

• たまたま古い機種で接続が多かった？（としか思えないとのインフラ回答）
• cap3と全然関係なかった（つらい）

結果

20時頃メンテ開け（4時間延長）

【おまけ】先週起こった恐い話

本番で突然の大量エラーが出てゲームにログインできないので緊急メンテ入れた

原因のコード

Rails.cache.fetch(key_name, expires_in: 1.day) do
  SomeModel.find_by(key: key_name)
end

• cacheにあればそれを返して、なければブロック内を評価しつつ結果をcacheに保存する
• この結果が特定のkeyのみ nil になってて呼び出し元で NoMethodError になってた模様