MacからSSHしてロケールのエラーが出た時の対処 - Qiita
原因が上記サイトに書かれているので引用します。 Mac の Terminal.app の Settings > Advanced > Set locale environment variables on startup がオンになっていると、 Mac 側で LC_CTYPE=UTF-8 が設定される。 Mac の /etc/ssh_config で SendEnv LANG LC_* になっているので、 LC_CTYPE が ssh サーバに送信される。 Ubuntu の /etc/ssh/sshd_config で AcceptEnv LANG LC_* になっているので、 Mac からの LC_CTYPE が Ubuntu に渡される。 UTF-8 というロケールはない (正しくは en_US.UTF-8 とか ja_JP.UTF-8) ので怒られる。 なるほど。ターミナルめ… 対処
stretcher + consul + capistrano を使ったデプロイを導入しようと思います | feedforce Engineers' blog
こんにちは。フィードフォース ボドゲ部の kano-e です。 こないだ『Last Night on Earth』というアメリカB級ゾンビ映画ゲーム(オリジナルサウンドトラック付き)で遊んで楽しかったのでまた遊びたい！ さて、最近 stretcher + consul を使ったアプリケーションのデプロイを tjinjin に布教1され、実際のプロダクト導入に向けてデモ用の環境で動かしています。 これまでの (capistrano を使った) デプロイとの違い stretcher や consul が何をしているか 良い点と現状の課題 について、社内勉強会で話した内容をまとめます。 これまでの capistrano でのデプロイ これまでの capistrano を使ったプロダクトのデプロイは、以下のようなフローでした cap production deploy などと実行するだけですので、
私の:santa:アイコンと、おすすめのクリスマスの過ごし方、あるいは新しいrubyのリリースを祝いつつgitのbranch名に:santa:をつける風習とそのせいでCapistranoでのデプロイに失敗するという事象 - Qiita
私の:santa:アイコンと、おすすめのクリスマスの過ごし方、あるいは新しいrubyのリリースを祝いつつgitのbranch名に:santa:をつける風習とそのせいでCapistranoでのデプロイに失敗するという事象RubyGitCapistranocapistrano3 この記事はフィードフォースエンジニア Advent Calendar 2015 24日目の記事です。 前日は tmd45 氏による「受付システムつくってみた（仮）」でした(早く使ってみたい!)。 今日は私とクリスマスにちなんだ3つのことについて話したいと思います。 私(hoshinotsuyoshi)のアイコン おすすめのクリスマス の過ごし方 新しいrubyのリリースを祝いつつをブランチ名にしよう・あるいはとCapistranoとの相性の悪さ 第一部：私のアイコンについて クリスマスは大好きです。アドベントカレンダー
twiwt.org - このウェブサイトは販売用です！ - twiwt リソースおよび情報
このウェブサイトは販売用です！ twiwt.org は、あなたがお探しの情報の全ての最新かつ最適なソースです。一般トピックからここから検索できる内容は、twiwt.orgが全てとなります。あなたがお探しの内容が見つかることを願っています！
無料でwerckerでRSpecのCI & Capistrano Deploy
プライベートなプロジェクトでもRSpecをデプロイのたびに実行したくて、『wercker』を使い始めましてた。 個人的には、Bitbucketのプライベートリポジトリを使って、RSpecで継続的インテグレーションしつつ、CapistranoでDeployできる 一連のプロセスが無料でスピーディに実現できるのでプライベートプロジェクトにめっちゃオススメです！ 😼 競合サービスとの比較無料で使いはじめることができるCIツールには、『Circle CI』や 『Magnum CI』などがありますが、日本語の情報が多く、Bitbucketのプライベートリポジトリが使える点を 考えて、『wercker』を選択しました。 🗽 前提： アプリケーションの環境について今回は以下のアプリケーション構成を対象としています。 - アプリ構成 - Ruby 2.2.0 - Rails 4.2.0 - RSpec
capistrano 3.3.3 が依存している capistrano-stats について - @znz blog
capistrano が 3.3.3 にあがって capistrano-stats という gem に依存するようになりました。 これは metrics.capistranorb.com:1200 にバージョン情報などを送信して capistrano のサポートの改善に役立てようとするもののようです。 対象バージョン capistrano 3.3.3 capistrano-stats 1.0.3 Capfile locked capistrano-stats とは関係ないですが、 Capfile locked at 3.2.1, but 3.3.3 is loaded と出るときは config/deploy.rb の最初の方にある lock '3.2.1' という行を lock '3.3.3' に書き換えれば OK です。 capistrano-stats 1.0.3 の挙動 初回実行時
Flow
Search Overview What is Capistrano? Getting Started The Readme, start here! Installation Structure Configuration User Input Preparing Your Application Flow Rollbacks Cold Start Version Locking Tasks Local Tasks Before / After Hooks Authentication & Authorisation Task cookbook Introduction Rails related tasks Advanced Features Console PTYs Filtering Properties Property Filtering Host filtering Role
オートスケール時のデプロイを User Data と Capistrano を使って行う（BootStrap パターン） | DevelopersIO
Auto Scaling を使った構成の場合、EC2 へのデプロイはどうやっているでしょうか？ AWS を使ってる方はご存知の方も多いと思いますが、EC2 には User Data という仕組みがあります。 User Data は、インスタンス起動時にタスクやスクリプトを実行する仕組みです。 今回この User Data を使って、自分自身のインスタンスから最新のソースを GitHub から取得してデプロイする方法についてご紹介したいと思います。 図で表すと以下のイメージですかね。 ssh localhost？ デプロイツールには Capistrano を使いますが、Capistrano は、デプロイ対象のサーバーに対してまず ssh で login を行います。 その後、サーバー上でデプロイ対象のコードの取得や、サービスの再起動をしたりしますが、 AutoScaling は自動でインスタ
wercker + Capistrano で自動デプロイ - milk1000cc
GitHub / Bitbucket のプライベートリポジトリも無料で CI し放題の wercker というサービスがあります。(2013/11/30 現在) サイトもきれいで素敵です。ビルド成功後、Capistrano でデプロイが自動実行される方法を書いておきます。 まず、アプリの設定で SSH 公開鍵を作成します。 生成された公開鍵は、デプロイ先サーバの ~/.ssh/authorized_keys や Bitbucket のデプロイ鍵などに追加しておきます。 次に、アプリの設定から Deploy targets の設定をします。Custom deploy を選択して、 master ブランチのビルドに成功したら、自動デプロイするようにします。 入力したら、Deploy pipeline の Add new variable をクリック。 SSH Key pair を選択し、先ほど
Capistrano 3への手引き - 今日のごはんは素麺です
Capistrano、便利ですよね。 capistrano/capistrano 最近メジャーバージョンアップがあったのですが、使い方、というかスクリプトの書き方やお作法が変わり、「Capistrano 3にアップデートしたはいいけど全然動かなくてどうなってんだ」という流れはもはやお約束みたいです。 試しに僕も個人で作ってるウェブサイトのCapistranoをアップデートしてみたので、その上でこんなところに気を付けたいな、と思うポイントでも書いておきます。 capifyは使わない Capistranoを使うときは$ bundle installをし、次に$ bundle exec capify .とするのがお約束の流れですが、これからはcapifyを使ってもcap installを使ってねと言われます。 ですので: $ bundle exec cap installとしましょう。 マルチス
Capistranoでのsudoの書き方 - orangain flavor
はじめに Ruby製のデプロイツールであるCapistranoを使ってみました。いろいろなレシピを眺めていると、sudoの書き方が次のようにいろいろあって違いがわからなかったので、調べてみました。 sudo "hoge" # (1) sudoアクション run "sudo hoge" # (2) 文字列 "sudo" run "#{sudo} hoge" # (3) 文字列 "#{sudo}" run "#{try_sudo} huge" # (4) 文字列 "#{try_sudo}" なお、対象のバージョンは、執筆時点で最新の2.14.2です。 (1) sudoアクション この書き方は、deprecatedなので今は使いません。 2.x DSL Action Invocation Sudo · capistrano/capistrano Wik
Fukuoka.php Vol.6でCapistranoについて話しました - Copy/Cut/Paste/Hatena
なんか久しぶりに話した気がします。 半ば強引でしたが、話す機会を下さったFukuoka.php運営陣のみなさんありがとうございます。 結構いろいろすっ飛ばして解説したので、多少間違いもあるかもしれませんが、導入として「いいかも」と思ってくれれば役目は果たせたと思っています。 質問もあったので個人的には満足です。 あと、公開を約束していた、CakePHP系プロジェクトのdeploy.rbのサンプル、というかリアルに使っているのを張り付けておきます。 ちなみに、勉強会中のDEMOも実サービスで行いました(まだ、正式公開前なので)。 基本的には、@ryuzeeさんのエントリーを参考に作っていて、概要もすべてこちらを参考にするとよいと思います。 というか、JenkinsもMigrationsもCapistranoも全て@ryuzeeさんの記事ドリブンです。この場を借りて御礼を述べたいと思います。
開発メモ#1 : Cinnamon によるデプロイ - naoyaのはてなダイアリー
このごろ作っているものが幾つかあるのだけど備忘録代わりにこの辺はこうしているということを書いて行こうかなと思います。 まずは Perl によるアプリケーションのデプロイについて。id:antipop と id:shiba_yu36 が開発した "Cinnamon" というミニマムなデプロイツールを利用しています。 Cinnamon - A minimalistic deploy tool https://github.com/kentaro/cinnamon シンプルで使いやすいデプロイツールです。 Capistrano? デプロイツールの定番といえば Capistrano で、最初は Capistrano を使っていました。けど、作っているものはほぼ Perl で書かれているのにデプロイツールだけ Capistrano で Ruby というのが、例えばモジュールの管理に Carton と
WebistranoをRails3.2.9に対応させた - yo_waka's blog
アプリのデプロイやDBのマイグレーションに Capistrano を使っているのですが、PM やディレクターでもテンプレートの修正くらいならコミットしてデプロイできるようなやり方をいろいろ探していて、Capistrano の WebUI であるWebistrano に行き着きました。 これめっちゃいいじゃん！と思って見てみると、なんと最後の更新が2年前でRailsも2.3ではないか・・ あきらめずにググってみたら、id:antipopさんがRails3.2.5対応しているのを発見した。神対応すぎる。 Webistranoをruby1.9.3-p194 + Rails 3.2.5で動くようにした ペパボも Webistrano 使ってるのかー ただ、記事にも書かれている通り、元のリポジトリからかなり変更が加わっている感じで外部ライブラリのアップデートで簡単に死ぬ感じはする。 デプロイツールの
CakePHP2アプリケーションをCapistranoでデプロイする
アプリケーションのデプロイを自動化すべきなのは言うまでもないことです。 一応手動でデプロイを行う場合の問題点について整理しておくと以下になります。 プロジェクトの期間中そして運用に入ってからも何度も手でデプロイするということはとてつもなく多くの時間を手作業に費やすことになるデプロイ先の環境の数が多くなればなるほど作業の時間も増える手作業で作業すると間違えやすい。特に手順が複雑だったり環境が多かったりすると確率は飛躍的にあがるもしデプロイしたアプリケーションに問題があってすぐに戻さなければならない場合に多くの時間がかかる。場合によってはビジネス上の機会損失に繋がる本来は価値を生むフィーチャーを実装することに時間をかけたいはずが、こういうことをやっているとどんどん時間がなくなっていきます。また手作業のリスクや消費される時間を恐れてデプロイの回数を減らしてしまうのは、ビジネス側からみると納得いか
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://github.com/capistrano/capistrano/blob/master/UPGRADING-3.7.md
https://github.com/capistrano/capistrano/blob/v3.5.0/CHANGELOG.md
UnicornにUSR2シグナル送っても無視される（Bundler::GemfileNotFound） - Qiita
Capistrano3でrailsをdeployしてみる - Qiita
Capistrano recipe for checking Travis CI build status | Railsware Blog