You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
管理対象のサーバー台数が少ない場合など、chefのサーバーを運用するコストとベネフィットを天秤にかけてみて、ああこれどう考えても労力ペイできないな、でも設定ファイルを手動で管理するのはやだな、といったときに[roundsman](https://g ithub.com/iain/roundsman)を使うといいという話。 roundsmanは、chefのレシピを転送してchef-soloを実行するcapistrano向けライブラリ。アプリケーションのリリースタイミングに併せてインフラ設定の変更が必要になることは往々にしてあるので、capistranoを使ってデプロイとインフラ設定変更を一括適 用できるのは便利だ。 ここでは、Railsアプリを対象にroundsman適用までの作業を簡単にまとめる。 手順 まずは適当なRailsプロジェクトを作るところから。 PROJECT="my_fant
このウェブサイトは販売用です! twiwt.org は、あなたがお探しの情報の全ての最新かつ最適なソースです。一般トピックからここから検索できる内容は、twiwt.orgが全てとなります。あなたがお探しの内容が見つかることを願っています!
capistrano-extとcapistrano-unicornを使ってRailsアプリをデプロイした時にハマったので、メモがわりに。 参考にしたのは下記サイト dan.thoughts » Blog Archive » Using capistrano-unicorn with multistage environment Capistranoとcapistrano-ext – 祈れ、そして働け ~ Ora et labora github sosedoff/capistrano-unicorn やりたかったこと Rails3.2xで開発しているアプリをnginx+unicornで動かす 本番環境としてデプロイされていたアプリをステージング環境としてデプロイし直す 前提条件 nginxはインストール済み unicornもインストール済み bundle exec cap . コマンド実
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 とホストごとにそれを上
UPDATE: I've updated the post to reflect changes in rbenv 0.4.0. I've recently decided to move away from in favor of . I thought RVM was a bit too finicky to use in production and I wanted something simpler that I could wrap my head around. This post is more or less an attempt to collect what I figured out from reading , George Ornbo's and the . On the server As the deployment user (in my case dep
問題 VMをぽこぽこ作りながらあれこれツールを入れて試してみたりしたいという時に、chefを使って構成管理はしたいけど、chef-serverを入れるのは面倒、というか、構成パッケージの記述・インストールだけできればいいという要求からするとオーバスペックなように感じるのだし、また、ホストの管理にはcapistranoを使っているので、cap実行側のみで処理が完結する方がよいという場合もあろうかと思う。 前提 デプロイ先ホストには、公開鍵認証でログインできるものとする(capを使うので) デプロイ先ホストでは、既にgit, chef-soloが使える状態であるものとする(そこまではなんらかの方法でがんばる) 解決案 そこで、chef-soloという、chef-serverなし、スタンドアロンにレシピの実行を行うコマンドをcapで実行するようにしてみる方法を試してみた。例として、GrowthF
Automating Capistrano Password Prompts with Expect I just started using Capistrano for deploying my Rails applications (like Snapclean.me"). I also just started using capistrano_rsync_with_remote_cache to help push releases out faster than the :copy deploy strategy. I’m very happy with how much faster it is than the a :copy, but I’m impatient and having to provide the password more than once per i
サーバに対して何台も同じような設定をしていると、そんな刺身にたんぽぽのせるような仕事やってられるかー!となりますよね?特に最近だとクラウドや仮想化技術が身近になってきたので、環境をイメージコピーで構築する手法も増えているのではないかと思いますが、一方で、ハードやOSレベルでも技術が進化していくので、OSより上のレイヤー(ミドルウェアやアプリケーション)とOS以下のレイヤー(ハードウェアやOS)を粗結合にしておくことが重要だと思います。 OSより上のレイヤーのシステムの構成管理を自動化ツールとしてPuppetが有名でしたが、最近だとChefがRubyでスクリプトが書けて便利です。 ChefはChef-server, Chef-client, Chef-solo という3つの構成に分かれています。しかしChef-serverとChef-clientを利用した構成は構成がやや複雑になるので、中央
WebistranoはCapistranoのWebフロントエンドであり、Web画面上からCapistranoを実行することができる。 これを利用することで、複数のプロジェクトを一括で管理したり、レシピを共用したりすることができ、デプロイの履歴を管理することも可能になる。かなりオススメ。なお動作させるにはRailsとなんらかのDBMSが動作する環境が必要だ。 Webistranoの入手Githubにホスティングされている。 適当なディレクトリにてgit clone https://github.com/peritor/webistrano.git すればOKだ。 インストール動作確認は僕のMacBook Pro (OS X Lion)で行った。なお既にMAMPによってMySQLが導入されていたのでそれを使っている。MAMP上でのrubyのmysql接続用ライブラリの導入sudo gem in
「ニフティクラウドユーザーブログ」は、移転しました。 自動でページを移動しない場合は、下記のリンクをクリックし、 新しい「ニフティクラウドユーザーブログ」をご覧ください。 今後とも「ニフティクラウドユーザーブログ」をよろしくお願いいたします。 > ニフティクラウドユーザーブログ
こんにちは。 タイトルの通りなんですが、Capistrano みんなつかってるよねー。 ってことで独自のデプロイシステムをもってなくてさすがにFTPでUPはしてませんって人は結構使ってるもんだと思ってるんですけど、Capistrano ってなんかデフォルト各サーバで vcs の update 的なことをするか、ローカルにソースツリーを用意してやる場合に使えるのは scp で、なんかエコじゃないよねと言う話で、いちいちソースツリー全部配布されてたら転送量も時間もかかってしょうがないので、まーrsyncがいいんだよね、ということで、そんな時は capistrano_rsync_with_remote_cache (なげえよ) を使えばいいよね!ってお話です。 *1 luisparravicini/capistrano_rsync_with_remote_cache · GitHub このご時世
What Capistrano plugins, recipes and templates. Installing sudo gem install capitate Running Add capitate to your Capfile. Copy this somewhere near the top: require 'capitate' require 'capitate/recipes' set :project_root, File.dirname(__FILE__) The basics Capitate has: Plugins to help install applications, via yum or manually unpacking, and building. Also to prompt for input, install gems, run she
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
とすれば、symfony本体とpluginsを除く、プロジェクトのファイル群を更新してくれます。 普段のリリース作業は、ほぼこれだけになると思います。 ざっと基本的な使い方を説明したところで、Capistranoのインストールからの利用手順と、各タスクの紹介を順にしていきます。 なお、Capistorano自体の基本的な説明は http://www.oiax.jp/rails/capistrano.html http://builder.japan.zdnet.com/sp/open-source-software-moonlinx-2009/story/0,3800096543,20396188,00.htm といったあたりをご覧ください。 一度どちらかでも目を通しておいて貰ったほうが、全体の理解が進むと思います。 では、ひとまずCapistrano自体の説明は上記のサイトを読んでもらう
ChefとCapistranoの境界線 (Chef Casual Talks Vol.1) #eytokyo #opschef_jaMasahiro NAKAYAMA
EngineeringDeployment Script Spring CleaningBetter late than never, right? As we get ready to upgrade our servers I thought it'd be a good time to upgrade our deployment process. Currently pushing out a new… Better late than never, right? As we get ready to upgrade our servers I thought it’d be a good time to upgrade our deployment process. Currently pushing out a new version of GitHub takes upwar
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Capistranoにはリモートホストでコマンド実行させるためのメソッドがいくつかある。その代表がrunメソッドとsudoメソッド。runメソッドはリモートホストにログインしたユーザ(特に指定しなければ実行ユーザ)でコマンドを実行する。sudoメソッドはsudoコマンドを使って指定したユーザ権限を得てからコマンド実行する。 この二つのメソッドは使い方がほぼ同じ。違いといえばsudoメソッドでユーザ名を指定できるということ。ただ、これは目的からして当然だといえる。ではそれ以外に違いがないのかというとそうでもない。実際のコマンド実行まで追いかけると二点ばかり、そしてけっこう大きな違いがあることに気付く。(以下、Capistrano 2.5.5で確認。) 一つめは複数コマンドの実行。runメソッドを使って複数のコマンドを一度に実行したいとき、たとえば次のように記述する。 run "mkdi
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く