Capistrano 3My talk about Capistrano 3 for budapest.rb meetup
本番環境でのserverspecの運用方法 - Qiita
本番環境でのserverspecの運用方法 / さよならインターネット ミドルウェアの管理はchefを使用している サーバへのデプロイはcapistranoを使用している 上記2点が当てはまる場合、serverspecの使い方として Testing #chef Cookbook by #serverspec #devops / さよならインターネット serverspecでchefのjsonを読み込む / さよならインターネット serverspecをJenkins氏で回す場合について / さよならインターネット 上記エントリーを参考にして頂ければchef + serverspecである程度の インフラストラクチャの構築とテストが行えるかと思います。 また、こちらのエントリーのように、chefのrecipeからserverspecのテスト自体を 生成してしまうという素晴らしいアイデアもあり
Capistrano3が良さげ - 一分一秒真剣勝負！
CapistranoのVersion3がリリースされてますね。変更点は以下のサイトに大量に書かれています。 Capistrano Version 3 ReleaseAnnounceme 変更点が多過ぎて全部まとめるのは諦めたので、個人的にこれはいいなーと思った点を上げます。 良かった変更点 マルチステージをデフォルトでサポート もうこれでcapistrano-extはいらない。まあ、これは標準サポートされてもいいですよね。 デプロイの高速化 確か以前はコマンド1回実行毎にsshのセッションを貼り直していたので遅かったはず。SSHのライブラリを変更したのと同時にココらへんも改善されたのかも。ただ、やっぱりRailsをデプロイする時はassetsのコンパイルでちょっと止まりますね。 実装が見やすくなった capistrano2はネットにドキュメントが少なくて結局実装を読む事になる場合が多かった
《Chef初心者》見ておくべき良記事とまとめ - Qiita
ユーザー解析のツールが社内でそろそろ必要なんだ。 僕のいる会社のユーザー数もだいぶ増えたし、サービスで利用しているDBに 同じようにログデータ突っ込んでるのはベターじゃないし、集計のクエリなんて 思いに決まっている、それでもし大事な大事なユーザー様に影響が出たらと思うと 今日も眠れない。。。 ってことでfluentdとかいいらしい。 fluentdを理解するためのまとめ fluentdを使ったwebログ イベントログ収集ツール fluent リリース！ でも一回のiOSエンジニアである僕がこんなん勉強して何になるのか・・・ どうせならちょっとインフラ環境作るあたりからやろう。 自前のさくらVPS(1年間1万くらいのプラン)が放置されてたので、 ちょうどいいし流行のchef なんかも使いながら構築して、 サンプルのログ流し込んでいろいろやってみよう！！ まぁ今は今はAWS時代なので サーバも
Serf を使ってみた
こんにちは。@jedipunkz です。 僕は Chef 使いなのですが、Chef はオーケストレーションまで踏み込んだツールでは ないように思います。せいぜいインテグレーションが出来る程度なのかなぁと。 しかもインテグレーションするにも Cookbooks の工夫が必要です。以前聞いたことの ある話ですが Opscode 社のエンジニア曰く「オーケストレーション等へのアプローチ はそれぞれ好きにやってね」だそうです。 個人的にオーケストレーションをテーマに色々調べようかと考えているのですが、 Serf という面白いツールが出てきました。’Serf’ はオーケストレーションを手助けし てくれるシンプルなツールになっています。 もう既にいろんな方が Serf について調べていますが、どのような動きをするのかを自 分なりに理解した点を記しておこうと思います。 参考にしたサイト 公式サイト ht
chefでattributeファイルを上書きしたい時 - アルパカDiary Pro
attributeファイルのオーバーライド 公式レシピを使う場合に、attributesファイルの一部のパラメータだけ更新したい時があると思います。 jsonでいちいち指定しても良いんですが、共通で設定したいパラメータは site-cookbooks以下にattributesファイルで書いておきたいこともあります。 その場合、今までは馬鹿正直にオリジナルのレシピを丸々コピペして一部だけ更新する、 といったように使っていたんですが*1 include_attribute使えば簡単に書けるのでは？と思った。 nginxの場合 いままではベタ書きしてたのを… site-cookbooks/nginx/attributes/default.rb # オリジナルのattributes/default.rbをコピペ default['nginx']['version'] = '1.2.9' defau
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
fabric でエラー時のロールバック処理をする - Qiita
ところで先日、ぼくの投稿を友人に見てもらう機会があったのですが、 「キモイ、写真がキモイ。ほんとキモイよ？今まで誰も指摘してくれなかったの？」 との絶賛コメントをいただきました。 fabric はシンプルでいて、とても強力なツールです。 しかし、それは使い方によっては危険なツールでもあるということです。 特にぼくのような、キモイ人間のクズが使うときには細心の注意を払う必要があります。 今日もぼくが本番環境に妙なものをデプロイしないか、 奇妙な人たち(上司ほか)が手錠をジャラジャラいわせながら監視しています。 気をつけないと。 ただ、どんなに気をつけていてもエラーというやつは起こるわけで、 だから色々ぶっ壊さないようにエラーハンドリングはちゃんとしてあげないといけません。 設定ファイルを編集した後にどこかでエラーが出たら、 ファイルだけ変えてるせいで2度とデーモンが起動しなくなった、とか、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
