Sqale の Puppet と Chef (とテスト)

@hiboma
Sqale の
Puppet と Chef
2013年5月10日金曜日

• 伊藤洋也 (いとうひろや)
• 株式会社 paperboy&co. 6年目氏
• 弟 30年目氏
• 技術基盤エンジニア
• ホスティングの開発業務に関わってる時間が多め
@hiboma

どっちも買って下さい

前置きの話
• レンタルサーバー / ホスティング
• 分譲マンションモデル
• リソースの切り売り

ユーザーで共有されるリソース
システム管理者用リソース
PHP Perl Ruby Python Apache postﬁx sshd
user A user B user C user D
ユーザーごとのリソース (任意のタイミングで追加/削除)
レンサバモデルレイヤ
nagios munin ﬂuentd ldap
ftpd
resque

Sqale

http://www.slideshare.net/mizzy/inside-sqales-backend-at-sapporo-ruby-kaigi-2012
Sqaleのバックエンド諸々

＊ PaaS ＊

今日の話
• アプリがうごく環境
• 「コンテナ」と呼んでいます

Sqaleのコンテナ
• Rubyコンテナ
• Nginx + Rackアプリ
• PHPコンテナ
• Apache2.4 + PHP-FPM

コンテナの実体
• LXC ( Linux Container )
• chroot + namespace + cgroup
• 仮想化 = 隔離、分離、制限
• プロセスレベルでの仮想化
• chroot な環境を作らないといけない !
• 構成管理だ！

構成管理
• ということで構成管理の話

構成管理
• Sqale は基本的に Puppet 管理
• appサーバー(Rails)とか
• gitリポジトリ管理サーバーとか
• アプリをビルドする build サーバーとか
• queueサーバー(resque) とか ... etc
• ユーザのアプリを動かすサーバーが特殊
• Puppet と Chef

EC2 Instance
PHP Apache phpenv ruby unicorn nginx
chef-solo で chroot環境chef-solo で chroot環境
ldap munin nagios rbenv kernel cgroup
Puppet の土台
/var/rootfs/ruby/var/rootfs/php
lxc-start lxc-start lxc-start lxc-start

Puppetのレイヤ
• LDAP とか munin とか nagios とか何かいろいろ
• ログインしてオペできる土台
• カーネルも
• LXC を動かせる土台

Puppet + AWS 自動化
http://www.slideshare.net/lamanotrama/on-aws-sqale

Chefのレイヤ
• Puppet の土台の上に
• chroot 環境を chef-solo で作る
• ユーザーごとの環境も chef-solo で作る
• ユーザー追加のタイミングで作る

Chefでchroot環境
• chroot 環境を Chef 管理
• /var/rootfs/php # PHP用
• /var/rootfs/ruby # Ruby用
• chroot してから chef-solo 流す
• レシピは mount --bind してホストOSを参照
• レシピの作り方は慣例通り
• Ruby や PHPに必要なものをガッと入れる

Why Chef ?
• chroot するのでホスト名ベースでレシピを当てられない
• なので chef-solo にした
• puppet apply でもできるかも

#レンサバあるある

#レンサバあるある
• ユーザを追加する度に環境作成
• アカウントの追加
• ストレージ ($HOME) の作成
• mkdir したり
• uid:gid 変えたり
• パーミッション変えたり
• ミドルウェアの設定追加
• 例) httpd.conf

#ホスティングあるある
• たんぽぽ作業
• chef-solo で作ろう

ユーザー作成
user node.username do
action :create
end
directory "/var/www/#{node.username}" do
owner node.username
group node.username
action :create
mode "0755"
end
template "/etc/httpd/conf.d/#{node.username}.conf" do
notifies :restart, "service[httpd]"
source "httpd.conf.erb"
owner "apache"
group "apache"
mode "0644"
end
service "httpd" do
action :restart
end
{
"username": "sushi",
}
attribute/sushi.json

ユーザー作成
• attributeで変数を注入＊1
• ユーザー名を変えて環境複製
• べき等性 = 上書き、やり直しも簡単
(注) 任意の値を入れると死ぬので要バリデート

ユーザー削除
• 消す時にも便利
• べき等性が効いてくる
user node.username do
action :remove
end
directory "/var/www/#{node.username}" do
action :delete
end
file "/etc/httpd/conf.d/#{node.username}.conf" do
notifies :restart, "service[httpd]"
action :delete
end
service "httpd" do
action :restart
end

chef-solo -j <URL>
• でも attribute ファイル作るの面倒じゃないですか ...
• chef-solo -j <URL> 便利そう
$ sudo chef-solo -j http://chef-api.example.com/user/fuga
chef-api.example.com
ユーザ収容のサーバーs
① kick
② chef-solo

Sqale
• sqale でもユーザごとに attribute を作って管理

コンテナ作成のchef-solo
{
"run_list": [
"role[create_container_ruby]"
],
"sqale": {
"consecutive_number": "1",
"container_id": "1",
"port_offset": "0",
"project_name": "ruby",
"role": "ruby",
"username": "namahage"
}
}
$ sudo chef-solo -j namahage_sqale_1.json
• Resqueワーカーが chef-solo
attribute/namahage-ruby-1.json

仕様変更
• 仕様変更したい場合も chef-solo
• 1. レシピ更新
• 2. chef-solo 再度実行
• 3. コンテナのプロセスを再起動
• 4. 仕様 update !
• ユーザ名に依存しちゃうような仕様を変える際に便利

DSL
• #{node.key.value} と埋め込むのはイマイチ
• ふつうのRubyのコードっぽくなるし ...
• 内部DSLを逸脱するので若干 BK な匂い

DSL
• ラップするクラスを入れてキレイに
• "deﬁne" でラップするのも良いですかね
directory lxc.userfs_root "/home/sqale/current" do
owner "sqale"
group "sqale"
mode "0755"
recursive true
action :create
end
directory "/var/sqale/namahage/ruby/1/home/sqale/current"
after

• puppet apply でもできそう ?
• antipopさんお願いします

混ぜるな危険 !!!!1
• Puppet と Chef が混在していましたが ...
• 管理しているスコープが違うのでOK
• 特殊事例

#テスト

#テスト
• 「Puppet, Chef」でプロビジョニングしました!!」
• 期待通り動くのかな ?
• 手作業で確認するの ?
• 変更する度に ?

Infrastructure as Code
• コード書いたらテストですよねー

#あるある
• パッケージの追加が怖い
• パッケージのアップデートが怖い
• パッケージの削除が怖い
• 設定追加が怖い
• 設定変更が怖い
• 設定削除が怖い
• 意図しないところで不具合

#あるある
• 振る舞いが把握できてないとこわい

#テスト
• 振る舞いをテスト = 動く仕様
• 「あれ、この設定なんだったかな...」
• テストで思い出す
• require "serverspec"
• Puppet, Chef のリファクタリング
• 振る舞いを保証してマニフェスト/レシピをいじる

EC2 Instance
PHP Apache phpenv ruby unicorn nginx
Chef の chroot環境Chef の chroot環境
ldap munin nagios rbenv kernel cgroup
Puppet の土台
/var/rootfs/ruby/var/rootfs/php
lxc-start lxc-start lxc-start lxc-start

Sqaleのテスト
• 1. chef-solo で LXCの作成/起動
• 2. LXCの外からプロセスが起動しているかテスト
• nginx, unicorn, supervisord, sshd, syslogd ...
• 3. SSHでログイン、コンテナでRSpecを実行
• 4. chef-soloで LXCの停止/削除

RSpecの中味
• ユーザーさんの行動を模擬テスト
• SSHログインできる?
• /etc/init.d/nginx で操作できる?
• Rails動く? Sinatra動く?
• bundle install できる?
• シェルコマンド使える?
• ログ見れる?
• cron 動いてる ?
• セキュリティ制限効いてる?
• cgroupのリソース制限効いてる?

RSpec / Railsの例
describe "rubyコンテナでRailsをUnicornで動かす" do
before(:all) do
system("/etc/init.d/rails stop")
end
it "アプリケーション /home/sqale/current に配置することができること" do
system("tar xfz /home/sqale/rspec/misc/rails_app.tar.gz").should be_true
system("rm -rf /home/sqale/current").should be_true
system("mv rails_app /home/sqale/current").should be_true
end
it "Railsを /etc/init.d/rails で起動することができる" do
system("/etc/init.d/rails start").should be_true
end
it "HTTPリクエストを出して200が返ってくること" do
response = http_get
response.code.should == "200"
response.body.should == "hello,world"
end
end

RSpec / rbenvの例
%w{ 2.0.0-p0 2.0.0-preview1 1.9.3-p327 1.9.3-p286 1.9.3-p194 }.each do |version|
context "rbenv で #{version} に切り替える場合に" do
it "バージョン切り替えできていること" do
rbenv_global(version)
end
it "rubyのパスが通っていること" do
system("which ruby >/dev/null").should be_true
end
it "irbのパスが通っていること" do
system("which irb >/dev/null").should be_true
end
it "gemsのパスが通っていること" do
system("which gem >/dev/null").should be_true
end
it "bundlerのバージョンが #{@bundler_version} であること" do
`bundle -v`.split[2].should == @bundler_version
end
end

RSpec / PHP Pearの例
describe "phpコンテナのpear" do
it "pearでライブラリをインストールできること" do
system("pear install Numbers_Roman").should be_true
end
it "pearでインストールしたライブラリを読み込めること" do
File.write("numbers_roman.php", <<'....')
<?php
require_once 'Numbers/Roman.php';
$roman = new Numbers_Roman();
echo $roman->toNumeral(1);
....
`php numbers_roman.php`.chomp.should == "I"
end
end

#お問い合わせあるある
• 「○○コマンドは使えますか？」
• 「○○ライブラリは使えますか？」
• 確認作業 => テストで残しておく
• サポートした仕様がデグレードしないようにする

#テスト
• 「○○できない」こともテスト
• su, sudo できないとか
• LXC を reboot できないとか
• forkbomb 対策できてるかとか
• されると困るアクションをテスト

Rspec / ○○できない
it "/var/log/messagesを読み込めないこと" do
expect { File.read("/var/log/messages") }.to raise_error(Errno::EACCES)
end
it "/var/log/secureを読み込めないこと" do
expect { File.read("/var/log/messages") }.to raise_error(Errno::EACCES)
end
it "cgroup の fork.remaing で fork bomb対策が施されている" do
# forkbomb するワンライナー
system "perl -e 'for(0..255){$i = fork;exit 255 unless defined $i;$i == 0 && sleep 1 && exit 0; }'"
$?.success?.should be_false
end
context "カーネルの制限で sqaleユーザーはポートをbindできない" do
it "httpdの予約ポート 8000 ~ 10000 をbindできない" do
(8000..10000).each do |port|
expect { TCPServer.open(port) }.to raise_error(Errno::EACCES)
end
end

#テスト
• 手続きをRSpec化
• 一般ユーザ権限で実行 = ユーザーの取れる行動
• パッケージの有無とかは見てない
• ホスティングだと価値高いテスト

SqaleのJenkins
• Jenkins で毎日 LXC のテスト
• yum も毎回 update
• RSpecが通る = 振る舞い保証

終わり

Sqale の Puppet と Chef (と テスト)

More Related Content