普通のRailsデプロイ事例として読んでもらっても大丈夫だと思います。 Z Cloudのコンパネをデプロイする様子をそのままスライドにしました、一部で普段の作業内容をシェアして欲しいという要望があったので。

1. 密着! Niboshi更新デプロイ
13:00～13:05
2012/10/31
Niboshi::Version #=> 1.1.0.1
DocumentVersion #=> 1.2
制作・著作：HiganWorks合同会社

2. Niboshiとは
• Z Cloudのコンパネです
• Rails + resqueで構成
– Nginx + unicorn
– Rescure worker, scheduler
開発は Team Shinobi
• 外部サービスとの連携多し
– Joyent SmartDatacenter (SDC)
– Giraffi (モニタリングSaaS)
– ペイメント代行サービス
"sinobi".scan(/[niboshi]/)
#=> ["s", "i", "n", "o", "b", "i"]
密着！Niboshiデプロイ 2

3. 注意
• このスライドは2012年10月31に行ったNiboshi
デプロイ1.1.0.1の作業ログです
• 作業の視点はデプロイ担当者、アプリのコー
ドには関与していない
• 手法、コマンドなどは作業記録当時のもので
あり、最新とは限りません
密着！Niboshiデプロイ 3

4. デプロイはFEATUREの把握から
密着！Niboshiデプロイ 4

5. 前提知識：
一般的なRailsアプリの更新デプロイ
• 開発情報
– Gitのタグ
– Changelog
• マイグレーションタスク抽出
– DBマイグレーション
– コンフィグディレクティブ
• 運用情報
– 起動終了スクリプト
– モニタリング
– ワーカなどのデーモン管理
密着！Niboshiデプロイ 5

6. New Feature, changelogの聞き込み
Q A Do
タグは何？ 1.1.0.1 • リリース対象として認
識
• Git log , diff のチェック
どういうリリース？ 管理システムとキュー連携 サーバで必要なタスクの洗
してタスクを実行する機能 い出し
の実装 =>次ページへつづく
あとバグFix
Config変更は？ ない デプロイ時のStructure
チェックのみでOK
DBマイグレーション あったっけ。。？ デプロイ時、リスタート前
にrake db:migrate:statusで確
お互い確認⇒ あった。 認後db:migrate
が必要になる
密着！Niboshiデプロイ 6

7. なぜ聞き込みがいるのでしょう。
アプリが何の機能を提供するかを知ることで、インフラやミドル
ウェアがどういう状態であるべきかの判断材料とするためです。
その情報をもとにデプロイ先の動作環境を事前に調整します。
また、更新時に不必要なダウンタイムを発生させないためでもあ
ります、DBのマイグレーション・コンフィグのディレクティブ追
加の通知を忘れるとアプリケーションが正常にリスタートできず
ダウンします。
密着！Niboshiデプロイ 7

8. 掘り下げて把握＆Todo
dig Dug Todo / result
Feature: メッセージングはResqueで • 新規resque worker!の設
管理システムキュー連携 行う 置
実行はResqueでやる • Failのチェックタスク
エンキューは社内の管理シ • 管理サーバからのRedis
ステムから ポートのOpen
- (運用)新規resque worker 起動方法の • Capistranoスクリプト修
Monit でストップ/スタート 正
Bugfix: 詳細後述 本番稼働とリリース対象の
あれこれ タグでlogとdiffを見る
Migration: DB:migrate:statusで確認し メッセージキューを受けて
データベース つつ 叩くタスク用のカラムが2
db/migrate/ を見る つ追加される模様
密着！Niboshiデプロイ 8

9. 今回の掘り下げの成果は。
訳あってスプリント(※)の期間が空いたため、大いにありまし
た。
DBのマイグレートとConfigファイルは見逃した際の本番環境への
インパクトが特に大きいため、自動チェックの仕組みを幾つか用
意した上で直前にも口頭で確認しています。
開発側は普段がそれぞれのdevelopment環境で行っているため、
Productionとの差をあまり意識しません。期間が空くとどこまで
適用済みかなんて自分も含めてみんな忘れていますから。
(※)リリースのこと
密着！Niboshiデプロイ 9

10. ミドルウェアの設定変更がありますね。
Featureを引っさげてのリリースですから。
連携側のシステムも私が環境構築しているので色々とスムースで
す。
密着！Niboshiデプロイ 10

11. テスト通ってる？
密着！Niboshiデプロイ 11

12. 自動実行の結果をチェック
密着！Niboshiデプロイ 12

13. この時点でのJenkins実行内容
• Bundler 実行可否
– .lockから生成する “–deployment”モードで
• Config.sampleとdevelopmentの構造チェック
– 更新や階層変更、Syntaxエラーの検出
• Rakeから unit, functional, integrationテストの実
行
課題：Jenkinsサーバからデプロイできそうだが、まだ心配＆デプ
ロイコードのリファクタしたいので据え置き
密着！Niboshiデプロイ 13

14. Jenkinsの役割はなんでしょう。
まず結合テストの実行と実行結果のシェア＆通知です。
導入前に比べ、単体のRuby(rails)アプリケーションとしてのテ
スト効率は飛躍的に向上しました。
本番デプロイを想定した流れをジョブ化しており、テストもその
環境で行われます。DBやConfigの構成変更は特に周知せずともこ
こで検出できるようにしています。
密着！Niboshiデプロイ 14

15. アプリケーションのコンフィグはどの様に運用し
ていますか。
Niboshiでは関係者が値を確認しやすいよう、staging,
productionのコンフィグコピーをWEBで閲覧＆編集できるような
ツールを作っています。
編集したコンフィグのみそのままデプロイできますが、書式が変
なら警告して止まる仕組みです。
ほか、デプロイ用のサーバではgitのpost-mergeフックにて
config.yml(sample)のdiffを毎回出力させるなど、対応不要なら
スルーし、要対応はどこかで止められるようにしています。
密着！Niboshiデプロイ 15

16. デプロイの準備
密着！Niboshiデプロイ 16

17. Git logで雰囲気を把握
• 本番稼働中のタグ確認
• cap production deploy:version
– #=> (略)/current/VER_1.1.0b
– Logみる
• git log --oneline 1.1.0b..1.1.0.1
– 5e4e605 Update Gemfile.lock by doing bundle update
– fd20c2e Update the Email template for update payment information
– 21d8ab3 Comment-in newrelic gem in Gemfile
– 3529ba2 Add resque worker for run notification queue
– （中略）
– b972edc Set default value for path of HTTP monitoring
– コメントで気になったらコードみる
• git show 21d8ab3
– +gem “newrelic_rpm“ ＃ なるほど
密着！Niboshiデプロイ 17

18. コード見るの？
見ないことも多い、趣味で。
もはやRubyは必修科目なので参考にしたり。
密着！Niboshiデプロイ 18

19. Resque worker＋＋の対応
• 普通のワーカーなのでCapistranoにセット
– Production.rb
-set :resque_workers, %w{reap_free_machines}
+set :resque_workers, %w{reap_free_machines run_notification_queue}
• テンプレートから起動＆終了スクリプトの設置と
monit登録用コンフィグを生成するための配列
• DryRun (-n)でチェック
• cap production -n deploy:create_ctl_scrpts
– ====Start preview config ==resque_run_notification_queue_start.sh==
– #!/usr/local/rvm/bin/rvm-shell 1.9.3-p125
– (中略)
– ====End preview config ==resque_run_notification_queue_start.sh==
– 内容問題無さそう (ってかStagingで稼働の確認済み)
密着！Niboshiデプロイ 19

20. Capistranoとは。
コードベースからアプリケーションをデプロイするためのツール
です。デフォルトではRailsプロジェクト向けのタスクが組まれ
ていますが、Rubyの内部DSLでタスクを定義できるので便利で
す。
どちらかと言うと開発者が自分で自由にデプロイするために使う
ツールだと思いますが、最近はDevOpsとか言うしそこだけ特定の
誰かがやるのもあまり不自然ではないかも。
今回Resque-workerがテンプレ通りだったので追加も楽でした。
密着！Niboshiデプロイ 20

21. Redisの対応
• 先日立てた管理アプリとの連携のためポート開放
• デプロイ前
– Listenがlocalhost
– Iptablesは余計なものを開けてはいないが社内IPは通してい
る
⇒ bind address を変更すればOK
-bind 127.0.0.1
+bind 0.0.0.0
• Redisをリスタート
– # service redis-server restart
– # netstat -naplt | grep redis
– tcp 0 0 0.0.0.0:6379 0.0.0.0:* LISTEN 3553/redis-server
密着！Niboshiデプロイ 21

22. CAPでのデプロイをおこなう
密着！Niboshiデプロイ 22

23. と思ったけど 毎時30分に行うタスクが
“Resque scheduler”にエンキューされる寸前だったので完了まで待つ
密着！Niboshiデプロイ 23

24. 適当に見届ける
密着！Niboshiデプロイ 24

25. 今回のデプロイ段取りをおさらい
• Capで 1.1.0.1 をデプロイする
– Bundlerが複数ベンダのプライベートリポジトリをまたぐので多段
ssh-agent環境で行う
– Gemset も“ruby-1.9.2-p290@capistrano” を固定で使用
– migrate:status にてdown検出、リスタートしない
• db:migrateする
– Cap のdeploy:migrateも使えるはずだが、導入時にrvmとの連携を
作ってなかったのでそのまま
• Rackアプリをリスタート
• Resque-* (worker, scheduler, resque-web)を
リスタート
• 新worker用のMonitスクリプトのロード
密着！Niboshiデプロイ 25

26. “今回の“段取り？
ただのBugfixなどのケースだと、Deploy&Restartでオシマイです
からね。
密着！Niboshiデプロイ 26

27. Cap deployでコードを
• コマンド
– # cap production deploy
– (中略)
– Tag to deploy (make sure to push the tag first): [1.1.0rc4] 1.1.0.1
– やること（普通にカスタマイズ可）
• まずMysql のダンプ
• 新規Diｒに Git clone & checkout & rm –rf .git
• bundle install –deployment(ほかオプションも)
• currentリンクの付け替え
• コンフィグの設置
• 本来ならアプリのリスタート(※無効化済み)
代わりにdb:migrate:statusを表示させている。
密着！Niboshiデプロイ 27

28. Capistranoにカスタマイズで追加した
タスクは？
今回出てくるのでは、DBのバックアップ、コンフィグ/管理スク
リプト設置(Dryrunプレビュー込)、リビジョン確認くらいです。
あとはリバースプロキシ用のNginxの操作をテンプレート＆タス
クにしてます。
密着！Niboshiデプロイ 28

29. 管理スクリプトも設置
• 各種起動＆停止スクリプトの設置
– 毎回上書き設置
• # cap production deploy:create_ctl_scrpts
– *_start.sh, *_stop.sh と monit_*.conf ファイルの作成と設置
• deploy.rbでタスク、staging.rb, production.rbで環境別
attributeをセット！
（pathとかresque-workerとか）
• {# deploy_to}のshared/system に設置
密着！Niboshiデプロイ 29

30. DB:migrate
• アプリのサーバでmigrate
– 普通のrails的更新
– アプリの“Current” はsymlinkなので、毎回CDしない
といつのまにか古いディレクトリにいる
– ↓確認
– bundle exec rake db:migrate:status RAILS_ENV=production
» down 20121012075801 Add status and executed at to
notification queues
– ↓更新
– bundle exec rake db:migrate RAILS_ENV=production
密着！Niboshiデプロイ 30

31. なぜ”Current”は実体でなくシンボリックリン
クなのですか。
Capistranoのやり方ですが、リンクの付け替えだけでアプリケー
ションのロールバックができるからです。
Rails のDBマイグレーションの仕組みはロールバックもサポート
しており(※)、だいたい可逆です。
繰り返しになりますがデプロイ直後はカレントディレクトリに注
意しないと古いものを見てしまいます。
(※)特定のマイグレーションをDOWNにできる。
マイグレーション内容によっては保証しかねるので流石にダンプの取得は必須
密着！Niboshiデプロイ 31

32. アプリのリスタートをしていく
密着！Niboshiデプロイ 32

33. Rackアプリ（Rails）
• Monit に管理させている
– Capで deploy:stop & deploy:startか
– Monit でrestart のどちらでもOK
– とりあえず
– monit restart niboshi_unicorn_production
• デプロイをasset_pipelineにちゃんと対応してないので、
リスタート後一発目の表示が遅い
密着！Niboshiデプロイ 33

34. なぜMonitなのですか。
いろいろやった結果、起動終了をスクリプトにしておいてmonit
経由でデーモンをコントロールするのが分かりやすさや互換性、
可搬性に優れていると思いました。
コントローラとしても、自動リスタートの内部監視としても優秀
です。
密着！Niboshiデプロイ 34

35. Rackアプリのリビジョンチェック
• 過去、再起動失敗でプロセス古いままという
事例があったのでチェックするようにしてい
る
• # cap production deploy:version
• “Current” にあるファイル群の表示
– ** [out :: **.**.**.***] /opt/deploy/niboshi/current/VER_1.1.0.1
– ** [out :: **.**.**.***] 5e4e605fd2731d0f0a30a8e83ecc567d1bb55e65
• 起動中のunicorn_masterプロセスのproc/*/cwdの下
– ====
– ==== Revision of unicorn ========
– ====
– ** [out :: **.**.**.***] /proc/8639/cwd/VER_1.1.0.1
– ** [out :: **.**.**.***] 5e4e605fd2731d0f0a30a8e83ecc567d1bb55e65
密着！Niboshiデプロイ 35

36. リスタート失敗してた？
いろんな要因の失敗があった。
CIしてない頃は、もう何も信用出来なかった。
最近は少なくともStagingに上げる頃にはコケる要素がほぼ駆除
されている。
密着！Niboshiデプロイ 36

37. Workerのmonitへの追加
• Capistranoで作ったコンフィグをMonitの
include_dirへ
• ln -s /（略）/shared/system/monit_resque_run_notification_queue_production.conf
/etc/monit/enable-conf.d/
• # monit –t
> Control file syntax OK
• # monit reload
• # monit summary # ほっとくと起動してくれる
– Process 'resque_run_notification_queue' Initializing
– Process 'resque_run_notification_queue' Does not exist
– Process 'resque_run_notification_queue' Running
密着！Niboshiデプロイ 37

38. Resque関連リスタート
• CWDが古いので、すべて一旦リスタートす
る。
– Resque-(worker, scheduler, web)
– Monitでグループにしているのでまとめてリス
タート命令
– cap production deploy:restart2 #deploy.rbで定義
– * executing "monit restart -g resque_workers“
– cap production deploy:version でCWDのリビジヨン
チェック
– 全プロセスが VER_1.1.0.1
密着！Niboshiデプロイ 38

39. 作業にはどのくらいの時間がかかりましたか。
聞きこみ＆把握はテンプレなので事前の準備などには20分、
実際にデプロイ＆新ワーカーの稼働はタイトル通り、5分で終わ
りました。
密着！Niboshiデプロイ 39

40. 最後に何か。
当初は各段階でその場の対応をよくしていたが、最近はほとんど
のデプロイが目視確認＆そのまま次へとなってきています。
聞きこみの部分だけ何とかなれば、ワンクリック/完全自動化が
次のステップになるでしょう。
密着！Niboshiデプロイ 40

41. 密着!Niboshi更新デプロイ
13:00～13:05
END
制作・著作：HiganWorks合同会社