結局Node.jsアプリケーションのデプロイはどうすればいいの？ - Qiita
node.js アプリケーションのデプロイをする時の選択肢が あまりにもありすぎて、結局どうすればいいのよ？ってなったので、 いったん基礎からまとめてみます。 デプロイとは何か？ アプリケーションのデプロイは大きく2つのフェーズに分かれます。 ファイルを所定の場所に置く 置かれたファイルの再ローディング 文章にするならば『ファイルを各サーバーの所定の場所におき、それらのファイルを再度ロードをする。』になると思います。 Webアプリケーションの場合 ファイルを所定の場所に置く前にテストを走らせたり 置いた後に静的ファイルを生成したりと、この２つの前後にはもっと色々なフェーズがありますが、 デプロイのタスクは、大きく分けてこの２つになります。 ファイルを所定の場所に置く サーバーにファイルを置く作業は、以下のような方法があります。 FTP tar などで圧縮scpで転送して解凍 rsync g
RailsのDeploy環境+運用を考慮したサーバー構築 - Qiita
Ruby on RailsでDev環境は使ったことあるけど、test・prod環境を考慮した環境構築をしたことがない人にお勧めの内容です。 サーバー構成図 サーバーの役割 リバースプロキシサーバー(ホスト名：rp01） ロードバランサ機能を使ってWEBサーバ二台に処理を振り分け、アクセスを１台のサーバーに集中させない WEBサーバーを外部から隠せることでセキュリティ面の向上 WEBサーバー（web01、web02） webサーバーを２台用意することでアクセスが１つのサーバーに集中しないため、レスポンスを早くできる マスターDBサーバー（db01m） DB内容をもう１台のDBサーバー（スレーブ）へリアルタイムにコピーし、障害でマスターが停止したときはスレーブに切り替える スレーブDBサーバー（db01s） 読み込み専用のサーバー。書き込みをしない分レスポンスが早くなる マスターの内容を常にコ
Capistranoでデプロイ対象のEC2インスタンスをタグで指定するものを書いている - There's an echo in my head
capistrano-ec2_taggedというgemを作った。まだrubygems.orgには上げていない。 これはCapistranoで指定タグのEC2インスタンスにデプロイのようなことをやるためのもので、次のようにして使う: # Gemfile gem "capistrano-ec2_tagged", require: false, github: "a2ikm/capistrano-ec2_tagged" # Capfile require "capistrano/ec2_tagged" # deploy.rb set :access_key_id, "ACCESS KEY ID" set :secret_access_key, "SECRET ACCESS KEY" set :region, "ap-northeast-1" # production.rb role :app,
今更だけど capistrano と chef-solo を組み合わせて複数のホストをセットアップする - ようへいの日々精進XP
はじめに knife-solo で一台のホストをセットアップすることは出来ても同時に複数のホストをセットアップするのはちと難しい でも capistrano と chef-solo を使えば同時に複数のホストをセットアップすることは出来そう ということで今更だけど capistrano と chef-solo を組み合わせてみる セットアップ後の確認は serverspec を使って確認する 早速試してみる 若干、課題はあるものの以下のような capistrano のレシピを使うことで実現出来た。 レシピ（chef のレシピでは無くて...） 以下のレシピを適当なファイル名で保存（例では setup.rb）する。 role :servers, "","" # set :user, "" set :path_to, "" # set :chef_local_dir, "#{path_to}/
Capistrano3のデプロイフレームワークの使い方 - Qiita
Capistranoはバージョン3から汎用的なデプロイフレームワークになりました。タスクのフックを利用することで簡単に自分のアプリケーション環境に特化したデプロイプロセスを記述することができます。 本稿では、この汎用化されたデプロイ機能の使い方に焦点を絞って解説したいと思います。より基本的なCapistrano3の解説は 入門 Capistrano 3 ~ 全ての手作業を生まれる前に消し去りたい | GREE Engineers' Blog がよくまとまっているので、そちらを参考にしてください。この参考記事では "5. Capistranoデフォルトタスクの消去" でCapistranoの新規導入時のコストを下げる目的で、このフレームワーク機能を消去しています。本稿はこのフレームワーク機能の使い方を解説するものです。 deployとframeworkの2つの抽象度が用意されている Capi
入門 Capistrano 3 ~ 全ての手作業を生まれる前に消し去りたい | GREE Engineering
はじめに この記事はGREE Advent Calendar 2013年の21日目です。お楽しみください！ こんにちは、アゴひげがダンディーだと評判の九岡です。GREEでは、JavaやScalaを布教するための土台を固めるため、デプロイや監視の仕組みづくりなどを横断的にやっています。今回はその過程で得られた知識を「Capistrano 3の入門記事」という形で共有させていただきます。 この記事ではCapistrano 3の基礎をご紹介します。Capistrano 3はRubyをベースにしたサーバ操作およびデプロイの自動化ツールです。Capistrano 3を利用することで、デプロイなどの複雑なサーバ操作を自動化することができます。ここの記事では、特にデプロイに焦点をあてながら、Capistranoでサーバ操作を自動化する考え方と実現方法をご説明していきます。 Capistrano 3の習得
Rails 3 + Nginx/Unicorn を Amazon AWS に Capistrano 3 でデプロイする - bekkou68 の日記
はじめに Amazon AWS 環境下で Rails 3 のアプリを Nginx/Unicorn で動くように Capistrano 3 でデプロイする手順をまとめました。 以下を前提に話を進めます デプロイ対象のアプリ/DBインスタンスはすでにつくられているとします デプロイ対象のアプリインスタンスのドメインは production.example.com とします アプリインスタンスは ephemeral disk がマウントされているとします プロジェクト名は myproject とします。ご自身のプロジェクト名に読み替えてください アプリインスタンスに SSHログインするための秘密鍵は ~/.ssh/myproject.pem に配置してあるとします RVM を使ってます。rubyenv での設定はこちらの記事が参考になるかと思います デプロイ先ディレクトリの準備 アプリを /va
インフラのOrchestration? - $shibayu36->blog;
Orchestrationやっぱりよく分かってなくて、色々話聞いてた。まだまだ分かってないけど、今のところをまとめるので、ここは違うとか指摘してください。 http://iiirc.org/snippets/321 Orchestrationに二つの意味が混ざっている？ という話になった。一つはmizzyさんも言っていたインフラの動的な部分という意味で、一つはnaoyaさんやstanakaさんが言っていたサーバ同士がうまくコミュニケーションしあって統制するという意味っぽい。 それぞれの役割やツールへの対応としては インフラの動的な部分 あるサーバの状態に合わせて、実行する内容を動的に変える capistrano, fabric, MCollectiveなどが該当 サーバ同士が相互的にコミュニケーションして統制する serfなどが該当 インフラの動的な部分としてのOrchestration
本番環境でのserverspecの運用方法 - Qiita
本番環境でのserverspecの運用方法 / さよならインターネット ミドルウェアの管理はchefを使用している サーバへのデプロイはcapistranoを使用している 上記2点が当てはまる場合、serverspecの使い方として Testing #chef Cookbook by #serverspec #devops / さよならインターネット serverspecでchefのjsonを読み込む / さよならインターネット serverspecをJenkins氏で回す場合について / さよならインターネット 上記エントリーを参考にして頂ければchef + serverspecである程度の インフラストラクチャの構築とテストが行えるかと思います。 また、こちらのエントリーのように、chefのrecipeからserverspecのテスト自体を 生成してしまうという素晴らしいアイデアもあり
Fabricは直列、Capistranoは並列 - Qiita
っていう感じで書けるんですが、複数サーバで実行する場合の順序が全然違うので要注意です。ロードバランサから外して、更新して、戻すなんてことを考えてると、Capistrano で死にます。 Fabric の場合: サーバAをロードバランサから外す サーバAを更新する サーバAをロードバランサに戻す サーバBをロードバランサから外す サーバBを更新する サーバBをロードバランサに戻す Capistrano の場合: サーバAをロードバランサから外す サーバBをロードバランサから外す サーバAを更新する サーバBを更新する サーバAをロードバランサに戻す サーバBをロードバランサに戻す Capistrano で Fabric の実行順序にするきれいな方法があればいいんですが。きれいな、というからには、汚い方法はあって、Can Capistrano Execute Tasks on Hosts Co
Capistrano | インストール + 疎通確認 ※Capistrano3.0.0 （検証用のVagrantfile付き） - Tbpgr Blog
概要 Capistranoのインストール + 疎通確認 ※Capistrano3.0.0 詳細 Capistranoのインストール + 疎通確認をインストールします。 配布物 sublime_snippetter（自作のSublime Text2向けスニペット生成ツールです。GitHubにあります） https://github.com/tbpgr/sublime_snippetter_old capistrano実行環境/配布先環境共通 前提 Ubuntu1204 Rbenv Bundler Ruby2.0.0.p0 capistrano実行環境 前提 192.168.33.12 capistrano 3.0.0 capistrano配布先環境 前提 192.168.33.13 事前準備 配布元、配布先の仮想環境構築 下記は配布元用。配布先用はipが192.168.33.13になること、
capistranoでのRails3アプリ配備チュートリアル | takemikami's note
load 'deploy' if respond_to?(:namespace) # cap2 differentiator # Uncomment if you are using Rails' asset pipeline # load 'deploy/assets' Dir['vendor/gems/*/recipes/*.rb','vendor/plugins/*/recipes/*.rb'].each { |plugin| load(plugin) } load 'config/deploy' # remove this line to skip loading any of the default tasks set :application, "set your application name here" set :repository, "set your reposit
Capistranoでデプロイ環境を構築する
今までずっと使わず嫌いだったCapistranoをやっと使ってみようと思う。 やりたい事はこんな感じ テスト環境で開発したソースをSVNにコミットする ステージ環境にて、テスト環境でコミットされたソースをアップデートで取得 デプロイ後の公開環境と、現在の公開環境の修正差分をrsyncで確認し、修正差分を取得する 3.で作成したデータを元に、修正差分のみデプロイする ※前提として、同じサーバ内にステージ環境と公開環境があるものとする ※修正差分のみデプロイの部分は、rsyncで実現してみる とりあえずCapistranoをインストールしなきゃ始まらない。 $ gem install -y capistrano $ cap --version Capistrano v2.12.0 こんな感じでバージョンが帰ってきたらインストール完了。 通常だと、次にはcapifyコマンドでCapfileとde
python boto + Capistranoで変態ちっくなEC2用デプロイスクリプト
EC2用に、ちょっと変態的(?)なデプロイスクリプトを組んだのでGithubに置いてみた。画面キャプチャーと一緒にご紹介します(・ω・)ﾉ https://github.com/wgkoro/ec2helper ※各キャプチャクリックで拡大します このスクリプトでdeployを実行すると 1.指定したNameを持つインスタンスを探して、起動しているかチェック。 Stopしていればたたき起こす。 起こした後、デプロイ実行していいか尋ね、ＯＫであればCapistranoでデプロイ実行。 2.デプロイが終了したらスナップショットを作成。 ということを行います。 Capistranoのrollbackもできます。 1.指定Nameのインスタンスの起動チェック、ロールバック実行。 2.以前作成したスナップショットも一緒に削除(削除実行前に確認アリ)。 ※スナップショット作成/削除機能はbotoを使っ
chef-solo + capistrano で複数ホストを管理する - 酒日記 はてな支店
chef-server は仕組みが大げさでインストールも大変だし、10〜20台ぐらいなら chef-solo と capistrano を組み合わせればいいよね？（同案多数） Capistranoとchef-soloを組み合わせて使う | ひげろぐ capistrano + chef-soloで構成管理する - delirious thoughts 実はこれまでもずっと、適当に書き殴った shell script で rsync && chef-solo 実行というのをやっていたのですが、複数の json をいい感じにマージして適用したかったので、capistrano で書き直してみました。 fujiwara/chef-solo-with-capistrano · GitHub 方針 cookbook などのファイルの同期は rsync で 共通で使用する json とホストごとにそれを上
明日はじめるCapistrano
Railsのdeployに使われることで知られるようになったCapistrano。でもその実態はRailsにとらわれているわけではありません。Capistranoは何かというと、こう言えます。SSHを使って多数のホストに同時並列に接続して、実行させたいコマンドを一斉に送信、実行結果を受け取って問題なければ次のコマンドを、というのを行うためのフレームワークです。 Capistranoを使い始めるのは簡単です。受け側に必要なものがあまりなく、一般的なUNIX系環境であればすでに準備が整っている状態です。Capistranoを実行するホストにはRuby環境が必要ですが、それ以上のものは基本的には必要ありません。コンパイラも不要ですし、ちょっと試してみるだけならインストールしてなくても大丈夫。 環境作り とはいえ、何もないところでCapistranoを試せるわけではありませんから、実行環境を作って
ruby製デプロイツール capistranoについて調べてみた
Capistrano::CLI.execute を実行してる 引数の解析 -r Preserve task roles -S pre_vars の指定 -s varsの指定 -T tasksの指定 -X skip system config -x skip user config ※他にもある。 引数の解析の後、capistrano/cli/execute.rb で主な処理がexecute!で行なわれてる # Using the options build when the command-line was parsed, instantiate # a new Capistrano configuration, initialize it, and execute the # requested actions. # # Returns the Configuration instanc
Capistranoのタスク一覧 - プログラマでありたい
Capistranoのタスクが、具体的にどのように動くか調べてみました。最初は下記のドキュメントを参考にしていたのですが、結局ソースを見たほうが10倍簡単に理解できました。コード中のrecipes/deploy.rb辺りを一度読むことを強くお勧めします。 Capistrano recipes: deploy capistrano/lib/capistrano/recipes/deploy.rb at master · capistrano/capistrano ほとんどのタスクが基本コマンドの組み合わせ実行です。この原則を知っているだけで、deployの挙動の大部分が解るようになります。 Tasks一覧 ・deploy update + restart ・deploy:check 依存性のチェック。Gem等のモジュールだけでなく、ファイルやパス等も依存性としてチェック出来る。またdepen
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
excale.net
Capistrano 3
