Weitere ähnliche Inhalte
Ähnlich wie 密着! nibohsiデプロイ 13:00-13:05 - railsアプリのデプロイ事例 - (20)
Mehr von Yukihiko SAWANOBORI (20)
Kürzlich hochgeladen (11)
密着! nibohsiデプロイ 13:00-13:05 - railsアプリのデプロイ事例 -
- 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
- 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
- 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
- 13. この時点でのJenkins実行内容
• Bundler 実行可否
– .lockから生成する “–deployment”モードで
• Config.sampleとdevelopmentの構造チェック
– 更新や階層変更、Syntaxエラーの検出
• Rakeから unit, functional, integrationテストの実
行
課題:Jenkinsサーバからデプロイできそうだが、まだ心配&デプ
ロイコードのリファクタしたいので据え置き
密着!Niboshiデプロイ 13
- 15. アプリケーションのコンフィグはどの様に運用し
ていますか。
Niboshiでは関係者が値を確認しやすいよう、staging,
productionのコンフィグコピーをWEBで閲覧&編集できるような
ツールを作っています。
編集したコンフィグのみそのままデプロイできますが、書式が変
なら警告して止まる仕組みです。
ほか、デプロイ用のサーバではgitのpost-mergeフックにて
config.yml(sample)のdiffを毎回出力させるなど、対応不要なら
スルーし、要対応はどこかで止められるようにしています。
密着!Niboshiデプロイ 15
- 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
- 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
- 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
- 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
- 27. Cap deployでコードを
• コマンド
– # cap production deploy
– (中略)
– Tag to deploy (make sure to push the tag first): [1.1.0rc4] 1.1.0.1
– やること(普通にカスタマイズ可)
• まずMysql のダンプ
• 新規Dirに 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
- 33. Rackアプリ(Rails)
• Monit に管理させている
– Capで deploy:stop & deploy:startか
– Monit でrestart のどちらでもOK
– とりあえず
– monit restart niboshi_unicorn_production
• デプロイをasset_pipelineにちゃんと対応してないので、
リスタート後一発目の表示が遅い
密着!Niboshiデプロイ 33
- 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
- 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