一個前のやつはこのために書いたと言っても過言じゃない位気に入った機能 makotanって名前のnodeのカレントディレクトリの一覧を見る knife ssh "name:makotan" "ls -al" -i hoge.pem -x makotan "name:makotan" はノードを探すコマンド(前回のネタ) "ls -al" は実行するコマンド -i hoge.pem はログインに必要なpemファイル -x makotan はログインするユーザ 結果的にこんなコマンドと同じ ssh -i hoge.pem [email protected] ls -al exit これを使うと単発のコマンドならログインせずに実行可能 sudo rebootって書けばリブートするし、 sudo chef-client って書けばchef-clientがそのnodeで実行できる
たとえば 登録されてるはずのnodeを探すとき 特定のroleを登録しているnodeを探すとき そんなときには、 knifeとrecipe の search コマンドが便利 登録されてるはずのnodeを探すとき node名の一部は判るけど・・・あれなんだっけなぁ〜 chef server見たくないしなぁ〜って時用 knife search node "name:*hoge*" 特定のroleを登録しているnodeを探すとき このroleってどのnodeが使ってたっけ？？みたいなとき knife search node "role:hoge" 他にも node以外にもclient、DATA_BAG_NAME、environment、roleが探せる 一言で言うとuser以外全部っすw 応用 recipeの中でこんな風に検索出来るので・・・ nodes = search(:node, "rol
ISUCON10予選に参加し予選敗退しました。 今年も @Konboi, @tkuchiki と一緒にチーム流れ弾として参加しました。
![[rails]国際化対応でlocaleを省略したURLのrouting設定 – hello-world.jp.net](https://cdn-ak-scissors.b.st-hatena.com/image/square/1a64cc21309639f33304c4730f8ddaaf393eeaf8/height=288;version=1;width=512/https%3A%2F%2Ffanyv88.com%3A443%2Fhttps%2Fblog.hilotter.com%2Ffavicon%2Fogp.png)
cookbookを書くときの冪等性 cookbookはインストール時だけでなく、何度実行しても同じ状態に保たれることが重要視されます。 chef業界ではこれを冪等性（べきとうせい）と読んでいたりします。これは設定ファイルやパッケージのインストールなど、すべてに当てはまります。 例えば、パッケージシステム経由でvimをインストールするようば場合のrecipeは以下のようにして書きます。 package 'vim' このようにすることで、それぞれのディストリビューションにあったパッケージシステムをつかってvimをインストールしてくれます。当然、二重にインストールされることはありません。 sourceからインストールするcookbook たとえばCentOSにphpをパッケージ経由でインストールすると、ちょっと古いバージョンのものがインストールされてしまいます。 新しいバージョンを使いたい場合は
ChefとCapistranoの境界線 (Chef Casual Talks Vol.1) #eytokyo #opschef_ja 大きく分けて二つの話をしました。 Chefを導入する時の「考え方」 Chefのような構成管理ツールは万能でやり方もたくさんある(TMTOWTDI)ので、最初にどういうポリシーで組み立てるかが重要になります。今回「本気で使う」にあたり、以下のようなポリシーを設定しました。 原則サーバ上で作業せず、Chefで環境設定を実装する 公開されたcookbooksを再利用する opscode-cookbooksにあればそれを探す communityやgithubにあるcookbookを使う あきらめの心を持つ 必要ならばopscode-cookbook�sなど既存のcookbookをforkして手を入れる 半日調べて難しそうなことはあきらめる(自前Chef recip
https://github.com/dann/chef-macbox を分解して理解を深める。 とりあえずhomebrewでアプリケーションをいれるというところ。 chef-solo -c ./config/solo.rb -j ./nodes/local.json -c 設定ファイルを指定 current_dir = File.expand_path(File.dirname(__FILE__)) file_cache_path "#{current_dir}/../.chef/cache" # 自動的にディレクトリが生成される file_backup_path "#{current_dir}/../.chef/backup" # 自動的にディレクトリが生成される #cache_options( :path => "#{current_dir}/../.chef/checksums",
opscodeのリポジトリにあるMySQLのcookbookでは、rootユーザやレプリケーション用のユーザのパスワードをランダムに生成して設定している。 opscode の recipe の特徴 このランダムという点をカバーするべく、うまい仕組みが組み込まれている。 パスワードを設定するところは node.set_unless['mysql']['server_root_password'] = secure_password といった形で、attributeに設定されていない場合はランダムに生成するという事をして、2度目以降も同じパスワードとなるようになっている。 2回目以降も同じパスワードを保証するために、もうひとつの技が unless Chef::Config[:solo] ruby_block "save node data" do block do node.save end
前回使った http://community.opscode.com/cookbooks/yum で、鍵やリポジトリの追加もできるので、 を使ってNode.jsをインストールしてみます。 yum_key "RPM-GPG-KEY-tchol" do url "http://nodejs.tchol.org/RPM-GPG-KEY-tchol" action :add end yum_repository "nodejs-stable" do description "Stable releases of Node.js" url "http://nodejs.tchol.org/mirrors/nodejs-stable-el$releasever" mirrorlist true enabled 1 #key "RPM-GPG-KEY-tchol" end package "nodejs
今日、同僚から「突然、XXXに対してCapistranoでファイルをアップロードできなくなった」という相談が来ました。 XXXというのは、半年ぐらい運用しているRails製のWebサイトです。 私が試してみると、確かにエラーが出ています。 sftp upload # -> /var/rails/xxx/current/public/system/maintenance.html /usr/local/lib/ruby/gems/1.8/gems/capistrano-2.5.20/ lib/capistrano/transfer.rb:156:in `[]=': undefined method `[]=' for nil:NilClass (NoMethodError) 原因となっているのは、deploy.rb の中の次の記述。 put result, "#{current_path}/
Chefについては前々から気にはなっていたけどまとまった情報があまりなく、中々じっくりと取り組めていなかったのですが、ちょうど次のプロジェクトから導入しようとしていたところに、『入門Chef Solo - Infrastructure as Code』というありがたいまとめ本が出版されたので、それを片手に色々と実験してみました。 入門Chef Soloはよくまとめられていて非常に助かったのですが、Kindleで見ると目次がなくて逆引き的に利用しながら構築するのが結構大変でしたので、自分用に手順書としてまとめてみました。（目次に関しては現在修正版が出ているようです） とりあえずRailsのサービス開発プロジェクトで使いたいので、以前にさくらVPSの設定で行ったような感じでrvm, nginx, unicorn, mysqlでRailsアプリが動くところまでやってみました。もう1年以上前ですが
data_bagを使う chefにはdata_bagというものがあります。 attributeとは何が違うのかなーと思っていましたが、良い使い方を見つけましたのでご紹介させていただきます。 ユーザアカウントは全てdata_bagで管理 ユーザアカウント系は全てdata_bagで管理すると楽かも！と思ってやってみました。 例えばログインアカウント。 サーバの機能や場所ごとにroleを作りますが、そのroleの中でログインアカウントを管理するrecipeを入れるとします。 data_bagを使わないとrecpieもしくはroleのattributeにユーザ情報を格納して、recipeのuser resourceでユーザを作成することになると思います。 僕の管理している環境では鍵認証が基本なので公開鍵の情報も管理をしたいです。公開鍵はユーザに紐づいていてどのサーバでも同じ鍵で入れると便
Puppet や Chef で構築したサーバを RSpec でテストする で書いた仕組みを使いやすくするために serverspec という名前で gem 化してみた。 rubygems.org にも登録してあるので、gem install でインストールできる。 $ gem install serverspec インストールしたら、適当なディレクトリで serverspec-init を実行。すると、雛形となるディレクトリやファイルを生成する。 $ serverspec-init + spec/ + spec/www.example.jp/ + spec/www.example.jp/httpd_spec.rb + spec/spec_helper.rb + Rakefile spec/www.example.jp/httpd_spec.rb がサンプルテストコードで、こんな感じになって
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、日本 Ruby の会の有志による Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0058 号 バックナンバー Rubyist Magazine 0058 号 RubyKaigi 2018 直前特集号 Rubyist Magazine 0057 号 RubyKaigi 2017 直前特集号 Rubyist Magazine 0056 号 Rubyist Magazine 0055 号 Rubyist Magazine 0054 号 東京 Ruby 会議 11 直
db_server.rb `�\着 include_recipe "postgresql::server90" # inspiration from # https://gist.github.com/637579 execute "create-root-user" do code = <<-EOH psql -U postgres -c "select * from pg_user where usename='root'" | grep -c root EOH command "createuser -U postgres -s root" not_if code end execute "create-database-user" do code = <<-EOH psql -U postgres -c "select * from pg_user where usename='#
はじめに 過去の仕事でサーバーを1000台以上管理する仕事をしていて大変だったときに、chefというサーバー構成管理ツールを知りました。結局その仕事をしていた会社は辞めてしまったのですが、今の仕事でもサーバーの管理の必要が少なからずあるため、楽をするためにまずは使い方を覚えようと思い、自宅のPCに仮想マシンでLinuxを動かして試してみています。その時に参考にしたサイトをまとめます。 サイト一覧 ・Chefを最速で使いこなすためのいくつかのポイント 用語や概念の理解 ・Chefで始めるシステム構成管理入門 その1 用語や概念の理解 ・Chefで始めるシステム構成管理入門 その2 – インストールと初期設定 chef-serverのインストールと管理作業PCへの管理ツールのセットアップ ・http://www.creationline.com/lab/1742 node側の設定、設定したレシ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
