技術を活かし、新しい価値を創造する DeNAのエンジニアは、想像を超えるDelightを届けるために何ができるかを考え、技術力と発想力で新しい価値を生み出しています。 多様な専門性を持ったエンジニアが切磋琢磨し、互いに刺激し合える環境や制度がさらなる成長へとつなげます。
みんなのウェディングの高井です。 気軽に開発サーバーにデプロイできると便利なことがあります。 たとえば、開発中のブランチをデザイナーやディレクターに確認してもらいたいときがあります。また、プルリクエストのためのブランチが大きくなってしまったから動作をみながらコードレビューしたいときもあるでしょう。 もちろん、手元のマシンでアプリケーションサーバーを起動させ、そのサーバーで動作確認してもらうこともできます。とはいえ、タイミングをあわせてサーバーを起動させるというのも手間です。 そこで、みんなのウェディングでは、開発ブランチを簡単にデプロイして確認できるようにする仕組みを用意しています。 Capistrano 開発サーバーへのデプロイには Capistrano を利用しています。プロダクションサーバーやステージングサーバーに対するデプロイでは AWS CodeDeploy を使っているのですが
こんにちは。@ryuzeeです。 アプリケーションのデプロイを楽にするためにDockerを使いたいけど、別にクラスタは必要ない規模だったりクラスタの管理もしたくないという人は多いのではないかと思います。 そこで、今回は、DockerとCapistrano3を組み合わせて単にデプロイを楽にする方法を紹介します。 構成図まず今回の構成図はこんな感じです。AWS上での構成例になっていますが別にどの環境でもあまり関係ない普通のWebアプリケーションを想定してください。 実現したい要件次に実現する要件です。特に変わったことはありません。 いつも同じ方式でデプロイするダウンタイムなしでデプロイするデプロイに失敗したら簡単にロールバックできるようにするサーバが増えてもデプロイの方式は変えなくて済むようにするサーバを再起動してもサービスは自動で復旧する方式では方式を見ていきましょう。 Webアプリケーショ
背景 アカツキではRailsでゲームサーバを開発しています。インフラはAWSにあり、CloudFormation, Chef, Capistrano を用いて、Infrastructure as Code を実現しています。 エンジニアは普段ローカルマシンで開発していますが、ディレクター、レベルデザイナーなどは定義ファイルを変えた後、それを反映して動作を確認するための検証サーバ(以下、検証環境)を使っています。 検証環境へのデプロイも Capistrano で自動化しており、最初は問題が無かったのですが、ゲーム上のデータが増えることによって、一度のデプロイで10分程度かかるようになっていました。 以下、Capistrano ver.2系の話にはなりますが、検証環境のデプロイを高速化したので、その内容を紹介したいと思います。 現状分析 rsync について、capistrano_rsync_
perlでdaemontools + Server::Starterで面倒見てたあたりをRailsでもしっかりやりたいなぁと。 以外としっかりとやってるサンプルがウェブに落ちてなかったので、いろいろ調べました。 いろいろ検証してみたけど、最終的に以下のように落ち着きそうです。試行錯誤した中身もまとめたい気もする。 やること graceful restart Railsアプリの永続化 永続化してるやつの自動起動とか永続化とか capistranoからアプリの再起動などできるように 終着点 Railsアプリをgod + unicornで上げて、godをinit script置いてchkconfigで自動起動とかの設定。 あと、capistranoからgod監視下のアプリを再起動できるように unicornをgodで動かす よくあるやつ。 rails_env = ENV['RAILS_ENV']
We're deploying with cap and using a script that send USR2 to the unicorn process to reload and it usually works but every once in a while it will fail. When that happens looking in the unicorn log reveals that it's looking for a Gemfile in an old release directory that no longer exists. Exception : /usr/local/lib/ruby/gems/1.9.1/gems/bundler-1.0.21/lib/bundler/definition.rb:14:in `build': /var/ww
2017-08-15 追記 Googleの「Capistrano」検索順位で上位にあるためか、いまだにこの記事がたびたびブクマされるんですが、3年前の情報ですし、執筆者はRubyを専門としたプログラマーではないのでその点ご注意ください。(追記ここまで) いろいろエントリーを上げながら苦しんでいたCapistranoだが、ようやっとそこそこ落ち着いてきた気がするのでそろそろ完結編といく。Capistranoの基本とかはすでにこちらのエントリーで書いたので、今回は各設定ファイルの書き方とか、その他ハマったポイントを中心に。 今回作成したファイル 以下4ファイルを作成した。 Capfile config/deploy.rb config/deploy/staging.rb lib/capistrano/tasks/unicorn.cap 基本的にCapistranoを使う場合「必須」なのは上2つ
2013 年 6 月頃に capistrano のバージョン 3 がリリースされました。かなり久しぶりのメジャーバージョンアップで色々変わっているようです。 Intobox でもデプロイには capistrano を使っていて、今回 capistrano のバージョンアップをしましたので手順の紹介とハマったことなどをまとめたいと思います。 capistrano v3 capistrano v3 は、より良いモジュール化、より簡単なデバッグ、より高速なデプロイ、などを設計目標として掲げています。 変更点が多いのでアップグレードガイドが公式サイトより提供されています。基本的にはここを見ながら進めていくのですが、やることといえば Gemfile に gem 'capistrano', '~> 3.0' を追加 bundle install bundle exec cap install をやって
Capistrano、便利ですよね。 capistrano/capistrano 最近メジャーバージョンアップがあったのですが、使い方、というかスクリプトの書き方やお作法が変わり、「Capistrano 3にアップデートしたはいいけど全然動かなくてどうなってんだ」という流れはもはやお約束みたいです。 試しに僕も個人で作ってるウェブサイトのCapistranoをアップデートしてみたので、その上でこんなところに気を付けたいな、と思うポイントでも書いておきます。 capifyは使わない Capistranoを使うときは$ bundle installをし、次に$ bundle exec capify .とするのがお約束の流れですが、これからはcapifyを使ってもcap installを使ってねと言われます。 ですので: $ bundle exec cap installとしましょう。 マルチス
CapistranoのVersion3がリリースされてますね。変更点は以下のサイトに大量に書かれています。 Capistrano Version 3 ReleaseAnnounceme 変更点が多過ぎて全部まとめるのは諦めたので、個人的にこれはいいなーと思った点を上げます。 良かった変更点 マルチステージをデフォルトでサポート もうこれでcapistrano-extはいらない。まあ、これは標準サポートされてもいいですよね。 デプロイの高速化 確か以前はコマンド1回実行毎にsshのセッションを貼り直していたので遅かったはず。SSHのライブラリを変更したのと同時にココらへんも改善されたのかも。ただ、やっぱりRailsをデプロイする時はassetsのコンパイルでちょっと止まりますね。 実装が見やすくなった capistrano2はネットにドキュメントが少なくて結局実装を読む事になる場合が多かった
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く