Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
密着! Niboshi更新デプロイ     13:00~13:05          2012/10/31  Niboshi::Version #=> 1.1.0.1   DocumentVersion #=> 1.2             ...
Niboshiとは• Z Cloudのコンパネです• Rails + resqueで構成 – Nginx + unicorn – Rescure worker, scheduler                                ...
注意• このスライドは2012年10月31に行ったNiboshi  デプロイ1.1.0.1の作業ログです• 作業の視点はデプロイ担当者、アプリのコー  ドには関与していない• 手法、コマンドなどは作業記録当時のもので  あり、最新とは限りません...
デプロイはFEATUREの把握から        密着!Niboshiデプロイ   4
前提知識: 一般的なRailsアプリの更新デプロイ• 開発情報 – Gitのタグ – Changelog• マイグレーションタスク抽出 – DBマイグレーション – コンフィグディレクティブ• 運用情報 – 起動終了スクリプト – モニタリング...
New Feature, changelogの聞き込みQ            A                      Doタグは何?        1.1.0.1                • リリース対象として認         ...
なぜ聞き込みがいるのでしょう。アプリが何の機能を提供するかを知ることで、インフラやミドルウェアがどういう状態であるべきかの判断材料とするためです。その情報をもとにデプロイ先の動作環境を事前に調整します。また、更新時に不必要なダウンタイムを発生さ...
掘り下げて把握&Tododig                     Dug                     Todo / resultFeature:                メッセージングはResqueで         •...
今回の掘り下げの成果は。訳あってスプリント(※)の期間が空いたため、大いにありました。DBのマイグレートとConfigファイルは見逃した際の本番環境へのインパクトが特に大きいため、自動チェックの仕組みを幾つか用意した上で直前にも口頭で確認してい...
ミドルウェアの設定変更がありますね。Featureを引っさげてのリリースですから。連携側のシステムも私が環境構築しているので色々とスムースです。               密着!Niboshiデプロイ   10
テスト通ってる?      密着!Niboshiデプロイ   11
自動実行の結果をチェック    密着!Niboshiデプロイ   12
この時点でのJenkins実行内容• Bundler 実行可否  – .lockから生成する “–deployment”モードで• Config.sampleとdevelopmentの構造チェック  – 更新や階層変更、Syntaxエラーの検出...
Jenkinsの役割はなんでしょう。まず結合テストの実行と実行結果のシェア&通知です。導入前に比べ、単体のRuby(rails)アプリケーションとしてのテスト効率は飛躍的に向上しました。本番デプロイを想定した流れをジョブ化しており、テストもその...
アプリケーションのコンフィグはどの様に運用し         ていますか。Niboshiでは関係者が値を確認しやすいよう、staging,productionのコンフィグコピーをWEBで閲覧&編集できるようなツールを作っています。編集したコンフ...
デプロイの準備      密着!Niboshiデプロイ   16
Git logで雰囲気を把握• 本番稼働中のタグ確認   • cap production deploy:version       – #=> (略)/current/VER_1.1.0b – Logみる   • git log --onel...
コード見るの?見ないことも多い、趣味で。もはやRubyは必修科目なので参考にしたり。                 密着!Niboshiデプロイ   18
Resque worker++の対応• 普通のワーカーなのでCapistranoにセット  – Production.rb        -set :resque_workers, %w{reap_free_machines}        +...
Capistranoとは。コードベースからアプリケーションをデプロイするためのツールです。デフォルトではRailsプロジェクト向けのタスクが組まれていますが、Rubyの内部DSLでタスクを定義できるので便利です。どちらかと言うと開発者が自分で自...
Redisの対応• 先日立てた管理アプリとの連携のためポート開放• デプロイ前 – Listenがlocalhost – Iptablesは余計なものを開けてはいないが社内IPは通してい   る ⇒ bind address を変更すればOK ...
CAPでのデプロイをおこなう       密着!Niboshiデプロイ   22
と思ったけど 毎時30分に行うタスクが“Resque scheduler”にエンキューされる寸前だったので完了まで待つ                 密着!Niboshiデプロイ            23
適当に見届ける          密着!Niboshiデプロイ   24
今回のデプロイ段取りをおさらい• Capで 1.1.0.1 をデプロイする        – Bundlerが複数ベンダのプライベートリポジトリをまたぐので多段          ssh-agent環境で行う        – Gemset も...
“今回の“段取り?ただのBugfixなどのケースだと、Deploy&Restartでオシマイですからね。                     密着!Niboshiデプロイ       26
Cap deployでコードを• コマンド       – # cap production deploy       – (中略)       – Tag to deploy (make sure to push the tag first)...
Capistranoにカスタマイズで追加した        タスクは?今回出てくるのでは、DBのバックアップ、コンフィグ/管理スクリプト設置(Dryrunプレビュー込)、リビジョン確認くらいです。あとはリバースプロキシ用のNginxの操作をテン...
管理スクリプトも設置• 各種起動&停止スクリプトの設置  – 毎回上書き設置    • # cap production deploy:create_ctl_scrpts       – *_start.sh, *_stop.sh と moni...
DB:migrate• アプリのサーバでmigrate – 普通のrails的更新 – アプリの“Current” はsymlinkなので、毎回CDしない   といつのまにか古いディレクトリにいる    – ↓確認    – bundle ex...
なぜ”Current”は実体でなくシンボリックリン          クなのですか。Capistranoのやり方ですが、リンクの付け替えだけでアプリケーションのロールバックができるからです。Rails のDBマイグレーションの仕組みはロールバッ...
アプリのリスタートをしていく      密着!Niboshiデプロイ   32
Rackアプリ(Rails)• Monit に管理させている – Capで deploy:stop & deploy:startか – Monit でrestart のどちらでもOK      – とりあえず      – monit rest...
なぜMonitなのですか。いろいろやった結果、起動終了をスクリプトにしておいてmonit経由でデーモンをコントロールするのが分かりやすさや互換性、可搬性に優れていると思いました。コントローラとしても、自動リスタートの内部監視としても優秀です。 ...
Rackアプリのリビジョンチェック• 過去、再起動失敗でプロセス古いままという  事例があったのでチェックするようにしてい  る  • # cap production deploy:version  • “Current” にあるファイル群の...
リスタート失敗してた?いろんな要因の失敗があった。CIしてない頃は、もう何も信用出来なかった。最近は少なくともStagingに上げる頃にはコケる要素がほぼ駆除されている。                 密着!Niboshiデプロイ    36
Workerのmonitへの追加• Capistranoで作ったコンフィグをMonitの  include_dirへ   • ln -s /(略)/shared/system/monit_resque_run_notification_queu...
Resque関連リスタート• CWDが古いので、すべて一旦リスタートす  る。 – Resque-(worker, scheduler, web) – Monitでグループにしているのでまとめてリス   タート命令       – cap pr...
作業にはどのくらいの時間がかかりましたか。聞きこみ&把握はテンプレなので事前の準備などには20分、実際にデプロイ&新ワーカーの稼働はタイトル通り、5分で終わりました。               密着!Niboshiデプロイ   39
最後に何か。当初は各段階でその場の対応をよくしていたが、最近はほとんどのデプロイが目視確認&そのまま次へとなってきています。聞きこみの部分だけ何とかなれば、ワンクリック/完全自動化が次のステップになるでしょう。                密...
密着!Niboshi更新デプロイ    13:00~13:05     END          制作・著作:HiganWorks合同会社
Upcoming SlideShare
Loading in …5
×

密着! nibohsiデプロイ 13:00-13:05 - railsアプリのデプロイ事例 -

1,322 views

Published on

普通のRailsデプロイ事例として読んでもらっても大丈夫だと思います。

Z Cloudのコンパネをデプロイする様子をそのままスライドにしました、一部で普段の作業内容をシェアして欲しいという要望があったので。




Published in: Technology
  • Be the first to comment

密着! nibohsiデプロイ 13:00-13:05 - railsアプリのデプロイ事例 -

  1. 1. 密着! Niboshi更新デプロイ 13:00~13:05 2012/10/31 Niboshi::Version #=> 1.1.0.1 DocumentVersion #=> 1.2 制作・著作:HiganWorks合同会社
  2. 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. 3. 注意• このスライドは2012年10月31に行ったNiboshi デプロイ1.1.0.1の作業ログです• 作業の視点はデプロイ担当者、アプリのコー ドには関与していない• 手法、コマンドなどは作業記録当時のもので あり、最新とは限りません 密着!Niboshiデプロイ 3
  4. 4. デプロイはFEATUREの把握から 密着!Niboshiデプロイ 4
  5. 5. 前提知識: 一般的なRailsアプリの更新デプロイ• 開発情報 – Gitのタグ – Changelog• マイグレーションタスク抽出 – DBマイグレーション – コンフィグディレクティブ• 運用情報 – 起動終了スクリプト – モニタリング – ワーカなどのデーモン管理 密着!Niboshiデプロイ 5
  6. 6. New Feature, changelogの聞き込みQ A Doタグは何? 1.1.0.1 • リリース対象として認 識 • Git log , diff のチェックどういうリリース? 管理システムとキュー連携 サーバで必要なタスクの洗 してタスクを実行する機能 い出し の実装 =>次ページへつづく あとバグFixConfig変更は? ない デプロイ時のStructure チェックのみでOKDBマイグレーション あったっけ。。? デプロイ時、リスタート前 にrake db:migrate:statusで確 お互い確認⇒ あった。 認後db:migrate が必要になる 密着!Niboshiデプロイ 6
  7. 7. なぜ聞き込みがいるのでしょう。アプリが何の機能を提供するかを知ることで、インフラやミドルウェアがどういう状態であるべきかの判断材料とするためです。その情報をもとにデプロイ先の動作環境を事前に調整します。また、更新時に不必要なダウンタイムを発生させないためでもあります、DBのマイグレーション・コンフィグのディレクティブ追加の通知を忘れるとアプリケーションが正常にリスタートできずダウンします。 密着!Niboshiデプロイ 7
  8. 8. 掘り下げて把握&Tododig Dug Todo / resultFeature: メッセージングはResqueで • 新規resque worker!の設管理システムキュー連携 行う 置 実行はResqueでやる • Failのチェックタスク エンキューは社内の管理シ • 管理サーバからのRedis ステムから ポートのOpen- (運用)新規resque worker 起動方法の • Capistranoスクリプト修 Monit でストップ/スタート 正Bugfix: 詳細後述 本番稼働とリリース対象のあれこれ タグでlogとdiffを見るMigration: DB:migrate:statusで確認し メッセージキューを受けてデータベース つつ 叩くタスク用のカラムが2 db/migrate/ を見る つ追加される模様 密着!Niboshiデプロイ 8
  9. 9. 今回の掘り下げの成果は。訳あってスプリント(※)の期間が空いたため、大いにありました。DBのマイグレートとConfigファイルは見逃した際の本番環境へのインパクトが特に大きいため、自動チェックの仕組みを幾つか用意した上で直前にも口頭で確認しています。開発側は普段がそれぞれのdevelopment環境で行っているため、Productionとの差をあまり意識しません。期間が空くとどこまで適用済みかなんて自分も含めてみんな忘れていますから。(※)リリースのこと 密着!Niboshiデプロイ 9
  10. 10. ミドルウェアの設定変更がありますね。Featureを引っさげてのリリースですから。連携側のシステムも私が環境構築しているので色々とスムースです。 密着!Niboshiデプロイ 10
  11. 11. テスト通ってる? 密着!Niboshiデプロイ 11
  12. 12. 自動実行の結果をチェック 密着!Niboshiデプロイ 12
  13. 13. この時点でのJenkins実行内容• Bundler 実行可否 – .lockから生成する “–deployment”モードで• Config.sampleとdevelopmentの構造チェック – 更新や階層変更、Syntaxエラーの検出• Rakeから unit, functional, integrationテストの実 行 課題:Jenkinsサーバからデプロイできそうだが、まだ心配&デプ ロイコードのリファクタしたいので据え置き 密着!Niboshiデプロイ 13
  14. 14. Jenkinsの役割はなんでしょう。まず結合テストの実行と実行結果のシェア&通知です。導入前に比べ、単体のRuby(rails)アプリケーションとしてのテスト効率は飛躍的に向上しました。本番デプロイを想定した流れをジョブ化しており、テストもその環境で行われます。DBやConfigの構成変更は特に周知せずともここで検出できるようにしています。 密着!Niboshiデプロイ 14
  15. 15. アプリケーションのコンフィグはどの様に運用し ていますか。Niboshiでは関係者が値を確認しやすいよう、staging,productionのコンフィグコピーをWEBで閲覧&編集できるようなツールを作っています。編集したコンフィグのみそのままデプロイできますが、書式が変なら警告して止まる仕組みです。ほか、デプロイ用のサーバではgitのpost-mergeフックにてconfig.yml(sample)のdiffを毎回出力させるなど、対応不要ならスルーし、要対応はどこかで止められるようにしています。 密着!Niboshiデプロイ 15
  16. 16. デプロイの準備 密着!Niboshiデプロイ 16
  17. 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. 18. コード見るの?見ないことも多い、趣味で。もはやRubyは必修科目なので参考にしたり。 密着!Niboshiデプロイ 18
  19. 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. 20. Capistranoとは。コードベースからアプリケーションをデプロイするためのツールです。デフォルトではRailsプロジェクト向けのタスクが組まれていますが、Rubyの内部DSLでタスクを定義できるので便利です。どちらかと言うと開発者が自分で自由にデプロイするために使うツールだと思いますが、最近はDevOpsとか言うしそこだけ特定の誰かがやるのもあまり不自然ではないかも。今回Resque-workerがテンプレ通りだったので追加も楽でした。 密着!Niboshiデプロイ 20
  21. 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. 22. CAPでのデプロイをおこなう 密着!Niboshiデプロイ 22
  23. 23. と思ったけど 毎時30分に行うタスクが“Resque scheduler”にエンキューされる寸前だったので完了まで待つ 密着!Niboshiデプロイ 23
  24. 24. 適当に見届ける 密着!Niboshiデプロイ 24
  25. 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. 26. “今回の“段取り?ただのBugfixなどのケースだと、Deploy&Restartでオシマイですからね。 密着!Niboshiデプロイ 26
  27. 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. 28. Capistranoにカスタマイズで追加した タスクは?今回出てくるのでは、DBのバックアップ、コンフィグ/管理スクリプト設置(Dryrunプレビュー込)、リビジョン確認くらいです。あとはリバースプロキシ用のNginxの操作をテンプレート&タスクにしてます。 密着!Niboshiデプロイ 28
  29. 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. 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. 31. なぜ”Current”は実体でなくシンボリックリン クなのですか。Capistranoのやり方ですが、リンクの付け替えだけでアプリケーションのロールバックができるからです。Rails のDBマイグレーションの仕組みはロールバックもサポートしており(※)、だいたい可逆です。繰り返しになりますがデプロイ直後はカレントディレクトリに注意しないと古いものを見てしまいます。(※)特定のマイグレーションをDOWNにできる。マイグレーション内容によっては保証しかねるので流石にダンプの取得は必須 密着!Niboshiデプロイ 31
  32. 32. アプリのリスタートをしていく 密着!Niboshiデプロイ 32
  33. 33. Rackアプリ(Rails)• Monit に管理させている – Capで deploy:stop & deploy:startか – Monit でrestart のどちらでもOK – とりあえず – monit restart niboshi_unicorn_production • デプロイをasset_pipelineにちゃんと対応してないので、 リスタート後一発目の表示が遅い 密着!Niboshiデプロイ 33
  34. 34. なぜMonitなのですか。いろいろやった結果、起動終了をスクリプトにしておいてmonit経由でデーモンをコントロールするのが分かりやすさや互換性、可搬性に優れていると思いました。コントローラとしても、自動リスタートの内部監視としても優秀です。 密着!Niboshiデプロイ 34
  35. 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. 36. リスタート失敗してた?いろんな要因の失敗があった。CIしてない頃は、もう何も信用出来なかった。最近は少なくともStagingに上げる頃にはコケる要素がほぼ駆除されている。 密着!Niboshiデプロイ 36
  37. 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. 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. 39. 作業にはどのくらいの時間がかかりましたか。聞きこみ&把握はテンプレなので事前の準備などには20分、実際にデプロイ&新ワーカーの稼働はタイトル通り、5分で終わりました。 密着!Niboshiデプロイ 39
  40. 40. 最後に何か。当初は各段階でその場の対応をよくしていたが、最近はほとんどのデプロイが目視確認&そのまま次へとなってきています。聞きこみの部分だけ何とかなれば、ワンクリック/完全自動化が次のステップになるでしょう。 密着!Niboshiデプロイ 40
  41. 41. 密着!Niboshi更新デプロイ 13:00~13:05 END 制作・著作:HiganWorks合同会社

×