ようへいの日々精進XP

よかろうもん

Jenkins と ChefSpec で cookbook の CI 環境を構築してみようと思った一部始終(1)

注意

要件

  • chefspec でのテストを自動化してみよう
  • せっかくだから Jenkins と github を絡めて使ってみよう

設計

理想

以下のようなワークフローでやれれば嬉しいなあ。

1. 手元の環境で cookbook を作成する
2. 手元の環境から github に push する
3. push されたことを Jenkins に github から通知(こんな事が出来るんかい...)
4. Jenkins サーバーから最新の cookbook を pull してきて chefspec を使ってテスト
5. テスト結果を受けて cookbook を node に適用する

環境(登場人物)

  • Workstation(cookbook を作成する環境)
  • github
  • Jenkins サーバー(chefspec もインストール)
    • github からの push 通知を受ける為に github からアクセスが必要なので Amazon Linux を使う

手順

jenkins 環境の構築

sudo wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat/jenkins.repo
sudo rpm --import http://pkg.jenkins-ci.org/redhat/jenkins-ci.org.key
sudo yum -y install java-1.6.0-openjdk
sudo yum -y install jenkins

jenkins と github との連携

plugin のインストール(以下をインストール)
  • GitHub API Plugin
  • Jenkins GIT client plugin
  • Jenkins GIT plugin
jenkins ユーザーにて公開鍵の作成
cd /var/lib/jenkins
sudo -u jenkins mkdir .ssh
sudo -u jenkins chmod 700 .ssh
sudo -u jenkins -H ssh-keygen -t rsa -C jenkins@yourdomain
jenkins ユーザーの公開鍵を github に登録
  • 上記で作成した鍵を github に登録する

EC2 の SecurityGroup の設定

github からの push 通知を受ける為に必要な IP アドレスの開放が必要な為、AWS コンソールの SecurityGroup に以下の赤枠内の IP からのアクセスを許可する設定を行う。

f:id:inokara:20130507004900p:plain

連携が出来ない場合等は /var/log/jenkins/jenkins.log 辺りを確認する。

chefspec のインストール

gem install chefspec --no-ri --no-rdoc

chef までインストールやってくれた。

テスト用の job 作成と実際にビルドしてみる

Jenkins にテスト用の job を作成
cd /var/lib/jenkins/workspace/${job_name}
/usr/bin/rspec -fd --color ${cookbook}

※ cookbook を githubリポジトリ名にしていて、且つ、jenkins の job_name を cookbook 名にしてしまった場合には下記のようになるので注意する。

cd /var/lib/jenkins/workspace/
/usr/bin/rspec -fd --color ${cookbook}

結論、Jenkins のジョブ名は cookbook の名前と同じにしない方が良いと思う。

  • github 側の WebHook URL に登録
    • [ビルドの実行] URL を WebHook URL に設定する

f:id:inokara:20130507020822p:plain

テスト実行
  • Workstation にて cookbook のレシピを修正

f:id:inokara:20130507014109p:plain

  • git push

f:id:inokara:20130507014118p:plain

  • Jenkins が push 通知を受け、ビルドが実行される

f:id:inokara:20130507014137p:plain

  • テスト完了

f:id:inokara:20130507014540p:plain

まとめ

  • 現状は 1 job = 1 リポジトリになっているのでビルドの際に cookbook を指定しなければいけない...
  • 1 job = 1 cookbook で運用出来ないか検討
  • 「こんなことやりたい」と思ったことをやってみたら何となく出来た感じなので、もうちょっと詳細に詰めていきたい
  • Jenkins と github の連携が比較的簡単に行えたのは先人たちの努力の賜物...感謝!

databags を使ってみた一部始終(1)

要件

databags とは...

attribute と使い分けについて悩みそうになるが、下記のような違いがある。(Chef ハンズオンセミナー(cookbook recipe basic編)で教えて頂いたことをまんま転載)

attribute
  • node や resource に紐づいた属性情報
  • ruby 形式で記載する
    • chef-soloの場合は json
  • 多岐にわたる場所で設定可
  • 適用の優先順位がある
databags
  • node や resource と直に紐づかない情報
  • json形式による記述する
  • data_bags ディレクトリ以下に、[ファイル名].json 形式で設置
  • 暗号化が可能

実際に使ってみる

node の /tmp/ 以下にお刺身に適した魚をリストアップした menu というファイルを作成する cookbook を作る

recipe
${chef-repo}/site-cookbooks/sashimi/recipes/sashimi.rb
sashimis = data_bag_item('fishies','sashimi')['menu']
template  '/tmp/menu' do
        owner "root"
        group "root"
        source "menu.erb"
        variables(
                :sashimis =>  sashimis
        )
end
templates
${chef-repo}/site-cookbooks/sashimi/templates/default/menu.erb
<% for sashimi in @sashimis %>
sashimi is <%= sashimi["a"] %> and <%= sashimi["b"] %>.
<% end %>
data_bags

data_bags 以下のディレクトリ構成が重要だと思う。理由は後述。

${chef-repo}/data_bags/fishies/menu.json

以下、なんの変哲もない JSON 形式のファイル。

{
        "id" : "sashimi",
        "menu" : [
                {
                        "a" : "maguro",
                        "b" : "tai"
                },
                {
                        "a" : "ika",
                        "b" : "tako",
                }

        ]
}

レッツクッキング

出来上がり

f:id:inokara:20130505081233p:plain

まとめ

ハマったところ

data_bags_item を扱う場合

JSON ファイルに必ず ID を持たせる必要があるにも関わらず、ID を持たせないまま書いていた。

        "menu" : [
                {
                        "a" : "maguro",
                        "b" : "tai"

上記だとダメ。下記のように "id" : "sashimi" を付ける。ここにもちゃんと書かれていました...。

        "id" : "sashimi",
        "menu" : [
                {
                        "a" : "maguro",
                        "b" : "tai"

参考にさせて頂いた blog でも同じポイントが書かれていて、大変、助かりました。

data_bags ディレクトリ以下

こちらも data_bag_item を扱う場合、data_bags 以下のディレクトリ構成と recipe の data_bags の指定は関連付ける必要がある。

chef-repo/data_bags$ tree
.
└── fishies
    └── menu.json

1 directory, 1 file

上記の通りに設定した場合には、recipe には下記のように記載することで JSON ファイルを展開することが出来た。

f:id:inokara:20130505085119p:plain

こちらに関しても、Opscode のドキュメントをちゃんと読めば理解することが出来る。

用途について

  • 冒頭にもあるように cookbooks ごとに持たせる情報よりも、もっと大きい枠の node に対して設定を施す際に使いたい
    • 例えば、ユーザーアカウント等
    • Opscode のドキュメントもユーザーアカウントを例に上げているし、ネット上の情報も同様にユーザーアカウントの設定を例に上げている
    • 個人的には /etc/hosts ファイルにレコードを追加、管理する場合に使えないか運用面と合わせて検討中

スライド

cookbook テストツール ChefSpec を使ってみた一部始終(2)

要件

  • cookbook をテストするツール(フレームワーク)を試してみる
  • 前回に続き、template resource を使った recipe を追加して cookbook をテストしてみる
  • 作った cookbook や example は github にアップする

準備

前回使った apache_install にレシピを一つ追加する。

vim apache_install/recipe/hoge.rb
service "httpd" do
        supports :status => true, :restart => true, :reload => true
        action :nothing
end
#
template "/tmp/hoge" do
        source "hoge.erb"
        mode "0644"
        owner "root"
        group "root"
        action :create
        variables(
                :hoge => node["hoge"]
        )
        notifies :reload, "service[httpd]", :immediately
end

試食

example

上記のレシピを受けて、下記のような example を作成した。

vi apache_install/spec/hoge.spec.rb
require 'chefspec'

describe 'apache_install::hoge' do
        let (:chef_run) { ChefSpec::ChefRunner.new.converge 'apache_install::hoge' }
        #it 'should restart httpd' do
        #       expect(chef_run).to restart_service 'httpd'
        #end
        it 'should set /tmp/hoge' do
                expect(chef_run).to create_file '/tmp/hoge'
                file = chef_run.template('/tmp/hoge')
                expect(file.mode).to eq("0644")
                expect(file).to be_owned_by('root','root')
                expect(file).to notify('service[httpd]',:reload)
        end
end

テスト

テストしてみる。

rspec -fd --color apache_install

f:id:inokara:20130504022241p:plain

ハマったところ

undefined method `***' for nil:NilClass

当初、以下のように記載していたところ、undefined method `mode' for nil:NilClass と怒られ...ruby 力が低い自分は非常に悩んだ。

        it 'should set /tmp/hoge' do
                expect(chef_run).to create_file '/tmp/hoge'
                file = chef_run.file('/tmp/hoge')

こちらを改めて読み返してみると...template の resource は下記のように書けとあった...

f:id:inokara:20130504022943p:plain

下記のように書きなおして undifined method を回避した。

        it 'should set /tmp/hoge' do
                expect(chef_run).to create_file '/tmp/hoge'
                file = chef_run.template('/tmp/hoge')

まとめ

  • cookbook_file と template で扱いは異なる
    • レシピの中で異なるのだから、当然のことなのかもしれないが...
  • ドキュメントは何度読んでも損は無い

Cookbook Refactoring and Extracting Logic into Rubygems を見て鼻血が出そうになった一部始終

@jhotta さんのツイートを見て鼻血が出そうになった...

なぜなら、丁度、サーバー設定の hostname やら /etc/hosts の設定について、あれこれと思いを巡らしていたから。スライドを拝見させて頂き、実際に話を聞けたわけではないので、個人的に解釈すると...

  • /etc/hosts で複数行に渡ってホスト名と IP アドレスの組み合わせを書く場合にどうしてまっか?
  • いろんな書き方あるよね
    • template と attributes の組み合わせだったり
    • role だったり enviroments だったり...
  • おすすめは data_bag だよ
  • そして ChefSpec を使ったテストだよね
  • テストも速いね
  • なんと 10000 テストを 28 秒で!

後半はイマイチ掴み難い内容だったが、おそらく ChefSpec でテストを書きましょう的な事が書かれていたと解釈している。

data_bag に関しては勉強会等で記憶に残っている程度の存在感であったが、自分が抱えていた悩みを解決する糸口になるのではないかと思いつつ、ChefSpec の存在感についても改めて認識する機会となった。

鼻血は出なかったけど、非常に貴重な資料となった。


おやすみなさい。

cookbook テストツール ChefSpec を使ってみた一部始終(1)

要件

準備

テスト用の cookbook の作成

cd ${Chef_Repos}/site-cookbooks
knife cookbook create apache_install -o ./

chefspec のインストール

gem からインストールする。

gem install chefspec --no-ri --no-rdoc

example のひな形を用意する(ChefSpec ではテストケースのことを「example」と呼ぶ)。

knife cookbook create_specs apache_install -o ./

実行後、apache_install ディレクトリ内に spec というディレクトリが出来ていて、その中に default_spec.rb というファイルが生成されている。

kappa@X1Carbon:~/git/chef-cookbooks/apache_install$ ls
CHANGELOG.md  attributes   files      metadata.rb  recipes    spec
README.md     definitions  libraries  providers    resources  templates

default_spec.rb を書きつつ cookbook を作成していく...

※詳しいテストコードと recipe は下記のリンク(github)をご確認下さい。

実際にテストを走らせてみる

以下のように rspec コマンドを実行することで、example を基にしたテスト(構文や諸々のチェック)を行なってくれる。

rspec -fd --color apache_install

問題が無い場合には下記のような表示となる。
f:id:inokara:20130502010057p:plain

recipe に構文エラーがあった場合等は下記のように警告してくれる。その他、example 自体にもエラーがあれば都度、エラーで警告してくれる。
f:id:inokara:20130502010351p:plain

Warning

should ではなく to を使いなさい

どうやら should ではなくて to を使うのがシェフの流儀らしく、テスト自体は通るものの、下記のようなエラーが出てしまう。

* `expect { }.should` is deprecated.
* please use `expect { }.to` instead.

まとめ

  • テストの為にコードを書くという概念が全くなかったので新鮮だった
  • 但し、Ruby 力が求められるので辛い...
  • レシピ自体を上から順番に評価していくが notifies 等があった場合、ちゃんと前後の関係も評価してくれるのが素晴らしい(と思う)
  • ChefSpec さえインストールされていればインターネットにつながらなくてもローカル PC だけで cookbook の確認が出来るのが有難い

rbenv を使って任意の ruby バージョンをインストールする cookbook を書いてみた一部始終

要件

  • rbenv を使って任意の ruby バージョンをインストール出来る cookbook を書いてみるぞ

環境

とりあえず...

以下のように書いてみた。

install_ruby_version="1.9.3-p392"
#
git "/usr/local/rbenv" do
	repository "git://github.com/sstephenson/rbenv.git"
	reference "master"
	action :sync
	not_if "ls /usr/local/rbenv"
end

execute "source_profile" do
	cwd "/etc"
	command <<-EOH
		echo 'export RBENV_ROOT=/usr/local/rbenv' >> /etc/profile
		echo 'export PATH="$RBENV_ROOT/bin:$PATH"' >> /etc/profile
		echo 'eval "$(rbenv init -)"' >> /etc/profile
		source /etc/profile
	EOH
	not_if "grep rbenv /etc/profile"
end

directory "/usr/local/rbenv/plugins" do
	mode "00755"
	action :create
	not_if "ls /usr/local/rbenv/plugins"
	#action :nothing
end

git "/usr/local/rbenv/plugins/ruby-build" do
	repository "git://github.com/sstephenson/ruby-build.git"
	reference "master"
	action :sync
	#notifies :create,resources( :directory => "/usr/local/rbenv/plugins" )
end

bash "install_ruby_build" do
	cwd "/usr/local/rbenv/plugins/ruby-build"
	user "root"
	group "root"
	code <<-EOH
		./install.sh
	EOH
	environment 'PREFIX' => "/usr/local"
end

bash "ruby_install" do
	cwd "/usr/local/rbenv/bin"
	code <<-EOH
		./rbenv install #install_ruby_version
		./rbenv rehash
		./rbenv global #install_ruby_version
	EOH
	not_if "ls /usr/local/rbenv/shims/ruby"
end

まとめ

忘れまい not_if

# hoge/huga の所在を確認する場合
not_if "hoge/huge" # ×
not_if "ls hoge/huga" # ◯ 
  • not_if の判断は " " で囲まれたコマンドの実行結果を判断する
    • これまでは " " で書かれたパスの所在のみを確認するだけだと思っていた...
    • その為、ファイルの所在確認を not_if で書いても、単純にパスだけ書いていたのでエラーになってしまっていた...
    • こういった判断に関しても ruby で書く方が美しい

action:nothing からの notifies :xxxx

cookbook_file "/etc/httpd/conf.d/common.conf" do
	source "common.conf"
	mode 0644
	action :nothing
end

package "httpd" do
	action :install
	notifies :create, resources( :cookbook_file => "/etc/httpd/conf.d/common.conf" )
end
  • とあるリソースが実行された時のみ実行するのが nothing...notifies
    • 上の例では cookbook_file の action は nothing となっているのが肝
    • package リソースが実行(httpd インストール)された時のみ cookbook_file リソースが実行(create)されることになる

Chef Server を使ってみた一部始終(2)〜実際の運用について考えてみる〜

要件

  • とりあえず Chef Server は動くようになったけど、node やら client の関係については引き続き勉強するとして
  • 実際の現場でどのような流れで運用するか(出来るか)を考えてみる

OS セットアップ

  • 例えば XenServer で構築するなら knife xenserver create でテンプレートからホストをセットアップすることが出来る
  • kickstart とかでも何でも良いか OS 自体のインストール時間は 5 分〜 10 分以内で

初期設定

  • ここから chef の登場!
node の登録

Workstation から knife を使う場合

knife node create ${knode_fqdn} -e vim

node の FQDN が Chef Server から名前解決できる状況が必要(だと思われる)。また、この時点では Chef Server には実際の node との関連付けは行われていない。

node から knife configure を実行する場合

knife configure -i

を実行すると

WARNING: No knife configuration file found
Where should I put the config file? [/root/.chef/knife.rb] 
Please enter the chef server URL: [http://debian.local:4000] https://${chefserver}
Please enter a name for the new user: [vagrant] admin
Please enter the existing admin name: [admin] 
Please enter the location of the existing admin's private key: [/etc/chef/admin.pem] 
Please enter the validation clientname: [chef-validator] 
Please enter the location of the validation key: [/etc/chef/validation.pem] 
Please enter the path to a chef repository (or leave blank): 
Creating initial API user...
Please enter a password for the new user: 
ERROR: Your private key could not be loaded from /etc/chef/admin.pem
Check your configuration file and ensure that your private key is readable

幾つかの質問を Enter で答えると knife.rb が作成される。(root 権限で実行した場合に /root/.chef 以下に生成される。)ので、環境に応じて適宜修正する。以下、自分が行った修正点。

Please enter the chef server URL: [http://debian.local:4000] https://${chefserver}

Chef Server の URL を指定する。Chef 10 までは http://${chefserver}:4000 だったのでその名残りが残っているが、Chef 11 からは https://${chefserver} を設定する。

Please enter a name for the new user: [vagrant] admin

Chef Server の WebUI に設定されているユーザーを指定する。デフォルトで Chef Server に存在する admin ユーザーを指定する。

Please enter the location of the existing admin's private key: [/etc/chef/admin.pem] 

admin ユーザーの秘密鍵のパスを指定。秘密鍵自体は [Users] → [List] → [admin] ユーザーの [Edit] をクリックして、[Regenerate Private Key] にチェックをして生成した秘密鍵を利用した。

Please enter the location of the validation key: [/etc/chef/validation.pem] 

varidation.pem ファイルのパスを指定する。これは Chef Server の [Clients] → [chef-validator] の [Edit] をクリックして [Private Key] にチェックをして生成した秘密鍵を利用した。尚、上記はあくまでも knife から Chef Server にアクセスする為に必要な設定。(という認識。)なので Chef Server から node に対する認識は別途行った。

client.rb を設定する
/etc/chef/client.rb を作成する。

log_level        :info
log_location     STDOUT
chef_server_url  'https://${chefserver}'
validation_client_name 'chef-validator'

chef-client を実行する
chef-client を実行し、正常に Chef Server に接続出来ると client.pem が生成されている。

root@debian:/etc/chef# pwd
/etc/chef
root@debian:/etc/chef# ls -l
total 20
-rw------- 1 root root 1675 Apr 21 06:22 client.pem
-rw------- 1 root root 1679 Apr 21 02:35 client.pem.bk
-rw-r--r-- 1 root root  133 Apr 21 02:35 client.rb
-rw-r--r-- 1 root root 1112 Apr 21 06:24 hoge.txt
-rw-r--r-- 1 root root 1679 Apr 21 02:28 validation.pem
root@debian:/etc/chef# 

また、Chef Server の nodes にホスト((node)が登録されている。
f:id:inokara:20130421153517p:plain

尚、client.pem を置き換えて接続しようとすると...

[2013-04-21T06:24:34+00:00] INFO: HTTP Request Returned 409 Conflict: Client already exists

================================================================================
Chef encountered an error attempting to create the client "debian.local"
================================================================================


Authorization Error:
--------------------
Your validation client is not authorized to create the client for this node (HTTP 403).

こんなエラーが出てしまう。この場合には、Chef Server の nodes と clients に既に登録されているホスト名を削除すると回避出来る。

node に対する cookbook の適用

knife コマンドにて node と cookbook を関連付ける。

knife node run_list add ${node_fqdn} 'recipe[${cookbook}]'
node にて cookbook の適用

node にて chef-client コマンドを実行する。

sudo chef-client

chef-client 自体をデーモン化することで、定期的に Chef Server と通信を行い cookbook を適用させることも出来る。

引き続き検討事項(まとめ)

  • なんと言っても、node と client の関係を明らかにしたい。node を登録すると client まで登録されてしまうのが煩わしい。client のアカウントは一つで node を複数持つことが出来ないのか?
    • 実際の運用の場合には client:node = 1:n という運用のほうが管理が楽なような気がする...
  • Workstation から node をコントロールすることは出来ないのか?
    • chef-client のデーモン化?

Chef Server を使ってみた一部始終

要件

  • Chef Server が必要になってきた
  • まずは手元で検証してみるが、情報を整理しながら実運用を見据えた検証をする
  • なんとなく動いてしまったので、手順を整理するまでは以下、暫定

問題点

  • client と node の区別、そこにきて user という登場人物...
  • cookbook をアップロードしてバージョンをクリックすると以下のようなエラーが出る(既知のエラーっぽい
ERROR: undefined method `close!' for nil:NilClass

手順

検証環境

Chef Server Debian 6.0.7
Chef Client(node) CentOS 5.8
Workstation Ubuntu 12.10

Chef Server のインストール(簡単...当然、chef でセットアップされている)

1. こちらよりパッケージをダウンロード
cd /tmp
sudo wget https://opscode-omnibus-packages.s3.amazonaws.com/ubuntu/11.04/x86_64/chef-server_11.0.6-1.ubuntu.11.04_amd64.deb
2. dpkg コマンドでインストール
cd /tmp
sudo dpkg -i chef-server_11.0.6-1.ubuntu.11.04_amd64.deb
3. sudo chef-server-ctl reconfigure
sudo chef-server-ctl reconfigure
4. ブラウザでアクセス

Chef client(node)のセットアップ

  • 既に chef-solo が使えている環境にセットアップ
  • knife で操作するけど、基本的には不要
1. /root/.chef/knife.rb を設置する(必須ではない)
log_level                :info
log_location             STDOUT
node_name                'root'
client_key               '/root/.chef/root.pem'
validation_client_name   'chef-validator'
validation_key           '/etc/chef/validation.pem'
chef_server_url          'https://${chef_server_fqdn}'
syntax_check_cache_path  '/root/.chef/syntax_check_cache'
2. /etc/chef/client.rb を設置する
log_level        :info
log_location     STDOUT
chef_server_url  'https://${chef_server_fqdn}'
validation_client_name 'chef-validator'
3. /etc/chef/validation.pem
  • Chef Server の /etc/chef-server/chef-validator.pem の内容を /etc/chef/validation.pem として保存する
4. Chef Server に node として登録する
chef-client -k /etc/chef/validation.pem -S https://${chef_server_fqdn}

Workstation のセットアップ

  • 既に chef-solo とか knife-solo とかバンバン叩いている環境
1. Chef Server に User を作る
  • 作成したユーザー(例:hoge)の Private Key を生成した上でどっかにコピっておく
2. knife configure -i で knife.rb を生成
log_level                :info
log_location             STDOUT
node_name                'hoge'
client_key               '/home/hoge/.chef/hoge.pem'
validation_client_name   'chef-validator'
validation_key           '/home/kappa/.chef/validation.pem'
chef_server_url          'https://${chef_server_fqdn}'
syntax_check_cache_path  '/home/hoge/.chef/syntax_check_cache'
3. /home/hoge/.chef/hoge.pem に 1. で作成した Private Key の内容を反映
  • コピペで対応した
4. /home/hoge/.chef/validation.pem
  • Chef Server の /etc/chef-server/chef-validatior.pem の内容を /home/hoge/.chef/validation.pem として保存する
5. cookbook をアップロードする
cd ~/${your_chef_repo}/
knife cookbook upload ${cookbook} -o ./site-cookbooks/
6. node にレシピを関連付ける
knife node run_list add ${node_fqdn} 'recipe[${cookbook}]'

以上で一応、準備が終了。

node にて cookbook の適用

chef-client

まとめ

  • 冒頭にも記載したが node と client と user の違いを整理したい
    • node は cookbook の適用先
    • client は API のユーザー
    • user は Web UI のユーザー...という感じかな
  • node の登録を明確にしたい
    • いつの間にか登録されていたので...(汗
  • ぶっちゃげ、色々と試行錯誤していたら出来たという印象

Recipeを書いて勘所を掴む!デベロッパのための『Chef』ハンズオンに参加した一部始終

※Evernote に箇条書きした内容を整理したものですので、誤字脱字、そもそも大間違いがるやもしれませんがご了承くださいませ。

要件

  • 最近は寝ても覚めても chef
  • chef 続きですいません
  • より良い cookbook を書けるようになりたい
  • 意識高いというか(意識)不明です

内容

前回のおさらい

chef-solo
  • 簡単便利
  • でも chef server を使いましょう
  • capistrano と chef-solo で苦労しているなら chef server を使いましょう
  • chef client と Ohai が chef クライアント(node)には入る
  • cookbook とか roles とか...が workstation に入る
knife
  • knife で chef server でアップロード
  • chef server で GUI で確認することが出来る
    • 意外と GUI で使っている人が多くい
  • Workstation から出来ることは chef server で出来る
リポジトリ
  • node
    • 設定先
  • cookbook
    • 設定内容をまとめたもの
  • レシピ
    • 設定ファイル群
  • リソース
  • node object
  • Roles
  • Runlist
  • Attlibute
    • node に直接関係した情報

cookbook に纏わる座学

knife cookbook create で作られるひな形についての解説
  • chef server を使う場合には metadeta.rb はちゃんと設定すべき
    • version を変えて cookbook を個別に適用すること出来る
  • definitions
    • 頻繁に発生するパターンを resource っぽく書いたファイルを置く場所
  • attribute の優先順位
    • いろんな場所に、いろんな優先順位でおける
    • 14 通りの優先順位
    • Environment で指定した attribute が優先される
    • Automatic
      • ohai が集めてきた情報
resouce 共通で使えるファンクション
attribute と databag の違い
  • attibute
    • node に紐付いた属性情報
  • datanag
    • DB のパスワードに使われる
    • 暗号化が可能
    • センシティブな情報に使える!
    • JSON 形式で記載
    • cookbook をアップロードしただけでは使えない
    • knife data bag create admins -> knife data bag...

ハンズオン

メモ
  • Omunibus インストーラの怪
    • /opt 以下だけではなくて /usr/local/bin 以下もイジる
  • /opt/chef/embedded/bin/ 以下の gem が利用される
  • インストール場所を意識する
    • .chef は chef-repo 以下に置く
    • ベストプラクティス
    • プロジェクト単位で .chef を置くべき
  • cookbook のテスト
    • knife cookbook test(ちゃんとシンタックスも見てくれる...)
    • whyrun
    • Food Critic
  • 要件
  • またしくった...
    • そもそも knife ec2 create で provision した EC2 インスタンスを見失った
    • 慌ててもう一回 knife ec2 create を叩いたらエラー...そりゃそうだね...
    • しかも knife cookbook upload ${cookbook} をしていなかった...気づかなかったよ、おっかさん...

質問

cookbook をまとめる単位は?
  • 好き好き
  • Opscode の cookbook を参考にするよ良いかも
Windows への適用は?
  • そこそこちゃんと使えている印象

まとめ

  • 昨日は様々事例が聞けて、今日は具体的な cookbook の作り方、まだまだ見習いだけど吐きそうな位充実した二日間でした...。
  • レシピ書きの肝は notify & subscribe と condition。ちゃんと使いこなせるようになりたい。
  • attribute の優先順位って...
  • knife cookbook test がシンタックスのチェックをしているからよさげ。
  • やっぱり chef server を使おうと思う。

Chef Casual Talks Vol.1 で 初 LT してきた一部始終

要件

  • Chef Casual Talks Vol.1 で chef に携わっている人、これから携わっている人達の話を聞いて三ツ星 chef を目指せ
  • ついでに自分も喋ってみる

いきなりまとめ

  • とにかく濃かった!!!!!!!!!!!!!!!!!!!
  • インフラエンジニアよりも開発側の人が多くてびっくり...と同時にインフラエンジニアも頑張らんといかんなと思った次第
  • Chef Server も触る必要があるなと思った次第
  • EngineYard さんのステッカーを沢山もらって嬉しかった
  • ビールを二本飲んだ

内容

以下、 Evernote に箇条書きした内容をちょっと整理した。

最近、Vagrantが楽しいのでその辺りを。

vagrant でしょ
  • chef めちゃくちゃ盛り上がっているよね。
  • ベストプラクティスがわかんない
  • 孤独のシェフ、コードレビューとかもやらない
  • EngineYard では第3月曜日に勉強会
  • Chef って本来のアーキテクチャはクラサバ構成→面倒
  • chef-solo があるぢゃん
  • vagrant(べいぐらんと)
    • 2010 年から開発されている
    • HASHICORP のはしもとさん
    • vagrant 1.1 系からプラグイン機構、色んなプラグインが作られるようになった
    • chef とか puppet とか cfengine に対応
    • 2 系が出るぞ
    • ちなみに EngineYard は chef-solo
    • ラズベリーパイって何??

nanapiの利用事例

nanapi というサービスで chefserver 使ってます
  • knife-solo はサーバー構築時
  • Chef-server について
    • サーバーの構成管理に使っている
    • リポジトリを分けている
    • 最初は subversion → chef-solo → chef-server
    • アトリビュートは優先順位が複雑
    • chef-client はデーモン化しない
  • chef-server にしてよかったこと
    • role の管理がやりやすい
    • アトリビュートの管理がやりやすい
    • 設定ファイルのバージョン管理が簡潔になった

これからちょうど新規にサーバー立てる予定があるので、ハマった事や疑問点などなど…

ハマったところ
  • ssh のポート変更
  • ufw の設定変更
  • 鍵をどうやって管理しようか…→リポジトリに入れてしまいたい
  • 初心者あるある
    • bash だらけ…
    • 既存サーバーへの適用はどうするか?

ChefとCapistranoの使い分けでハマった点

  • ポリシー
    • 原則サーバー上で作業しない
    • 公開された cookbooks を再利用する
    • あきらめのこころ
  • chef-solo-search
  • サーバー構築とデプロイの境界線
  • 質問
    • unicorn のプロセス管理
    • 初回のデプロイをどうするか?
    • chef でどこまでやっていますか?

使っている cookbook の紹介もしくは roundsman の紹介

  • cookbook を書かない(community のものを使う)
  • roundsman
    • capistrano から chef-solo を実行するもの
    • 並列実行出来る(chef-solo は出来ない)
  • 疑問(質問)
    • セキュリティアップデートはどうしているの?
    • Environmentsって

Vagrant1.1系でハマったところ もしくは、 vagrant + chef 勉強会をやってみた件について

  • vagrant 1.0 と vagrant 1.1 どっち使ってますか?
    • 自分はうっかり vagrant 1.0 系だった
    • バージョンの違いで使える使えないことの違いが多い

Cookbooks の品質を向上させるためにどんなアプローチがあるのか (rpmバージョン固定、

  • not_if で制御していいもの?
  • Chef 11 にバージョンアップしたら warning が出るようになった
  • 本当にこれで正しいのかが分からない!
  • foodcritic を使うといいかも!

最近、日本でPuppetの影が薄くなって悲しいので、ここであえてPuppetの話をする

  • puppet の話
  • puppet のベストプラクティス
    • StyleGuide
    • Module Fundamentals
    • Writing Grate Moduels
  • puppet 最新バージョン3
    • puppet forge
    • ベンダー連携が盛ん
    • VMware から出資
    • Juniper JunOS 上で Puppet Agent が動く
  • puppet をディスるのを止めて下さい

デプロイで苦労していることの相談など。chef

  • sociogram というソーシャルサイトのログ分析システムでのお話

開発に関わらないChefユーザの日々

  • 口伝!
  • どうやって伝承するのか?
  • 経験をソースコード
  • ノウハウを落としこむ
  • cookbook 作成時の留意点
    • 特定のサービス・ソフトウェアに特化しない
    • 自由度の確保
    • 顧客の環境を傷つけずに自動化
    • 運用の自動化の推進
    • プログラムを書く IT インフラエンジニアってカッコイイねえー
  • omuibus インストールは /usr/local/bin を触る
    • ギャー!

vagrant-lxc を試してみた

  • ぺぱぼの人だ!
  • puppet
    • と言えば mizzy さん!
  • vagrant-lxc
    • Linux のネイティブ仮想環境
  • vagrant-lxc と vagrant/VB の速さを比較
    • vagrant-lxc の速いけど...

この辺りから緊張で何も覚えてない...

CloudStack インストール Cookbook

  • 一年前のレシピは...
  • 現在は色々と改良を重ねて
  • omnibus インストールは /usr/bin/chef とか消してるよ。。。

ワタシは新米板前です

  • 新婚さんいらっしゃい出演の話しかしてないです...

ローカルPCのMacをchefで管理してみた(Beta)

  • キタコレ
  • 実際に cookbooks を見せて頂きながらの LT
  • アプリのインストールからコントロールパネルの中の設定まで書けてしまう!
  • Windows もきっと出来るんでしょうな...

最近使いだしたのではまった事や疑問点など

  • knife solo prepare よりは bootstrap を使うといい
  • 濃いな...

マイグレーション

  • chef 11 は速い
  • chef 10 から chef 11 への移行について
    • knife backup で JSON 形式で設定を吸い出す等など
    • 詳細はこちら
  • 本場のカンファレンスに参加予定です
    • chef に纏わる質問を現地で聞いてくるので、ぢゃんぢゃん質問して下さい

chef入門してみてvagrantでうまくberkshelfが動かない話

  • chef-solo の限界点とは?
    • 20 台くらいになったら苦しいと言われている

urasoko さん

  • ブラウザタグでプレゼン!
  • 面白いしテンポがいいなあ
  • #opschef_jp を付けて質問しよう

まとめ

  • ここまで書く間で濃すぎて吐きそう(笑
  • 実際に現場でバリバリ chef を使っている方の深い話から、最近始められた方のあるあるな話まで幅広い話であっと言う間の時間だった
  • roundsman は早速使ってみたいと思った
  • だいたい皆さん vagrant を使っているなった思いつつ LXC な方の話も聞けた
  • puppet もまだまだイケるなって思ったので、引き続きアンテナは張り続けていきたい
  • chef が ruby で書ける所以なのか、chef でどこまでやる(やれる)のかが皆さんの悩みどころなのかなって印象
  • 「これ!」と言ったスタンダードが無いのが(・∀・)イイネ!!

おまけ

  • 祝・初 LT 資料!