はじめに † Rails環境でDB(MySQL)のバックアップとリストアをCapistranoから自動化する方法を書いてみます。 Capistrano v2.5.5、クライアントはWindows XP、サーバー側はUbuntu 8.04で確認しました。 ↑ 前提条件 † MySQLを使っている mysqldumpが使える capistranoがそもそもちゃんと動いている config/database.ymlの設定でDBにアクセスできる アプリ＆DBサーバーが1台の時しかテストしてない件 capistrano-ext(参考)使ってstaging鯖とproduction鯖とどちら向けに実行してもうまく行くようになってるハズ(ドメイン名でバックアップファイル名生成) リモートの”(プロジェクト)/shared/backups/”以下にどんどんバックアップする ローカルの”(プロジェクト)/..
Railsアプリのデプロイツールとしてデファクトスタンダード的な位置にあるCapistranoについて。 TL;DR HOSTSとROLESではなく、HOSTFILTERとHOSTROLEFILTERを使え。 タスクの実行先制限方法 Capistranoは、デプロイ先サーバに"ロール"を設定し、特定のロールに所属するサーバ全てに対して一括でなにかしらの処理を実行させることができる。 # deploy.rb server 'webserver1' :web server 'webserver2' :web server 'dbserver', :db, :primary => true ... task :do_something, :roles => :web do ... end cap do_something #=> webserver1, webserver2に対してのみdo_so
Capistrano、便利ですよね。 capistrano/capistrano 最近メジャーバージョンアップがあったのですが、使い方、というかスクリプトの書き方やお作法が変わり、「Capistrano 3にアップデートしたはいいけど全然動かなくてどうなってんだ」という流れはもはやお約束みたいです。 試しに僕も個人で作ってるウェブサイトのCapistranoをアップデートしてみたので、その上でこんなところに気を付けたいな、と思うポイントでも書いておきます。 capifyは使わない Capistranoを使うときは$ bundle installをし、次に$ bundle exec capify .とするのがお約束の流れですが、これからはcapifyを使ってもcap installを使ってねと言われます。 ですので: $ bundle exec cap installとしましょう。 マルチス
ここ数年で開発の現場でAgile開発の文化や手法が、ずいぶんと取り入れられるようになってきているようです。アジャイル開発はその根底に文化が大事ですが、それを支えるツールというのも重要になってきます。ソース管理やビルド管理、テストの自動化と色々ありますが、今回はリリースの自動化のお話です。その中で主にRails使われることが多いCapistranoの設定と使い方です。 環境の説明 ・Ruby 1.9 ・Rails 3.2 ・Passenger ・Git ・SQLite3 目指す構成 今回は単純化する為に、1サーバの中にGitのリポジトリもApache+PassengerもDBも入れておきます。また複数の環境（開発、ステージング、本番）にデプロイ出来るように、それぞれの構成を別けて記述するようにします。（capistrano-extを使用） 設定 必要モジュールのインストール $gem ins
デプロイツールとして capistrano が有名ですが、初心者向けの記事を検索してもなかなか情報が集まりませんでした。「とりあえずどんな感じか動かしてみたい」という人のためにリモート Git リポジトリからソースコードを取得して、指定したサーバーにデプロイさせるために、最もシンプルと思われる deploy.rb の記述方法を調べました。 実際にデプロイに成功した記述は下記の通りです。 set :normalize_asset_timestamps, false set :user, 'USERNAME' set :password, 'PASSWORD' set :scm, :git set :repository, 'git://github.com/suzukit86/REPOSITORYNAME' set :deploy_to, '/var/www/html' role :web,
RailsにCapistranoを導入して、Gitリポジトリと連携した自動デプロイのしくみを構築していきます。一度組み上げてしまえば、その後の作業量が激減するんでオススメです！ ちなみに、localにステージング環境を作る場合には、Capistrano 複数環境へのデプロイ[localhostへのデプロイ]がオススメです。 🐮 リモートのGitリポジトリを準備デプロイ先のサーバがアクセスできるGitリポジトリを準備してください。無制限でプライベートなGitリポジトリを作成できるBitBucketがオススメです！ ちなみに、BitbucketでのSSHキーセットアップ手順はこちらにまとめています。 🐞 Gitにリモートリポジトリを追加ローカル側でGitにリモートリポジトリを追加する。
サーバに対して何台も同じような設定をしていると、そんな刺身にたんぽぽのせるような仕事やってられるかー！となりますよね？特に最近だとクラウドや仮想化技術が身近になってきたので、環境をイメージコピーで構築する手法も増えているのではないかと思いますが、一方で、ハードやOSレベルでも技術が進化していくので、OSより上のレイヤー（ミドルウェアやアプリケーション）とOS以下のレイヤー（ハードウェアやOS）を粗結合にしておくことが重要だと思います。 OSより上のレイヤーのシステムの構成管理を自動化ツールとしてPuppetが有名でしたが、最近だとChefがRubyでスクリプトが書けて便利です。 ChefはChef-server, Chef-client, Chef-solo という3つの構成に分かれています。しかしChef-serverとChef-clientを利用した構成は構成がやや複雑になるので、中央
デプロイしたけど何かおかしい？ 先日、Unicornを採用しているウェブアプリで問題が発生しました。デプロイした最新のコードが実行されているように見えますが、時々古いコードの挙動を見せるのです。 今回はそのトラブルシューティングの一部始終を紹介しながら、Unicornのホットデプロイ（ダウンタイムなしでアプリケーションを更新すること）の仕組みをおさらいします。担当は私、去年KRAYに入社しました@irohirokiです。よろしくお願いします。 問題 まずはデプロイ先のサーバにSSHして、Unicornのプロセスを調べてみました。 $ ps ax -H PID TTY STAT TIME COMMAND 3159 ? Sl 0:00 unicorn master (old) -c unicorn.conf -D 3162 ? Sl 0:00 unicorn worker[0] -c unic
本連載の第1回から第3回までは、主にmoonlinxのインフラ技術を説明してきました。今回からはmoonlinxのウェブアプリケーション技術に着目して解説していきたいと思います。 デプロイツール「Capistrano」の魅力 ウェブメディア「moonlinx」では、moonlinx Membership Centerと呼ばれるクリエイター向けの登録制会員サービスを運営しています。これは、デザイナーや音楽活動を行うアーティストをターゲットとしたサービスであり、クリエイター自身の活動をプロモーションするツールとして活用できるサービスです。 このMembership Centerでは、フレームワークとしてRuby on Railsを利用して開発しています。また、PhusionのPassengerを利用して、Apache2上で動作させています。 Railsの運用環境は、MongrelとMongre
Capistranoってなんじゃ？（EC2にインストール編）
CapistranoはSSH経由でリモートコマンドを実行するためのツールで、端末間でのアプリケーションのデプロイなどに使用されています。Ruby on Railsの台頭とともに知名度をあげ、Railsのデプロイメントでは定番のツールになっています。 Capistranoはそれ自体がRuby製で、Rubyのためのツールのようですが、冒頭の通りSSHでリモートコマンド実行を管理する用途であればどんな状況でも利用できます。 今回試してみるユースケースでは 1台の管理サーバーから２つのサーバー上にファイルを作成してみます。 まずEC2でAmazon Linuxを3台分マイクロインスタンスで起動しておきます。 ここでは管理サーバーをadmin、リモートの2台をhoge1,hoge2とし、3台にそれぞれEIPを付与します。 仮にそれぞれのEIPは以下の通りとします。 admin: xxx.xxx.xx
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
