• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
密着! nibohsiデプロイ 13:00-13:05 - railsアプリのデプロイ事例 -
 

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

on

  • 1,137 views

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

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

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




Statistics

Views

Total Views
1,137
Views on SlideShare
1,134
Embed Views
3

Actions

Likes
1
Downloads
3
Comments
0

2 Embeds 3

https://twitter.com 2
https://si0.twimg.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

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