(株)タイムインタメーディア
小宮健
http://www.flickr.com/photos/yelpar/6678239091/
自己紹介:小宮 健
 仕事
 (株)タイムインターメディア所属
 参加コミュニティ
 Sphinx-users.jp
 Python mini hack-a-thon
 Author of blockdiag
 Chef 歴 1.5年ぐらい
 Community cookbook 推進派です
 こつこつ Pull Req. 投げてます
Twitter: @tk0miya
宣伝:Sphinx をはじめよう
 世界初のSphinx本
 電子書籍
 100ページ弱相当
 オライリー・ジャパン
 1,680円
 2013/9/13 発売
アジェンダ
 サーバの構成管理していますか?
 構成管理ツールを使おう
 Chef の紹介
 デプロイツールを使おう
 Capistrano の紹介
 まとめ
アジェンダ
 サーバの構成管理していますか?
 構成管理ツールを使おう
 Chef の紹介
 デプロイツールを使おう
 まとめ
サーバの構成管理していますか?
 サーバの構築には沢山のステップがある
 OSのインストール/設定
 ミドルウェアのインストール/設定
 アプリケーションのインストール
 セキュリティ対策
 あなたのサーバは、それを再現できます
か?
 サーバの故障
 増強が必要となった
 新メンバー用の開発環境が必要になった
サーバの構成管理していますか?
 よくあるサーバ構築の方法
 サーバ構築手順書がある
 Wiki に集約されている
 職人芸 (担当者しかしらない)
 考えられてない (現在のサーバから推測)
よくあるトラブル…
 記述通りに構築しても動かない
 そもそも記述通りに進まない
 そもそも手順がまとまっていない
 隣の人と入っているパッケージが違う
 なぜかサーバごとに設定が違う(歴史的経
緯)
 手順を飛ばして本番で事故る
 バッチを停止したままだった
 何十台も手作業で設定してるとつい…
 手順書にはクロスチェック欄がある
 環境を管理せよ
 本番環境と同じ方法で開発
環境を構築せよ
 本番用スクリプトでは最後
までテストされない
 開発開始時点から環境構築
を自動化する
『継続的デリバリー』曰く
環境を管理する
 環境を管理するいくつかの方法
 手順書を用意する
 シェルスクリプトにする
 PXE + kickstart による自動インストール
 sed/awk などによる設定ファイル書き換え
 PHP で設定ファイルを生成したことがあります
 オレオレパッケージ(rpm,debなど)を作る
 AMI や VM snapshot を作る
 構成管理ツールを使う
その方法、変更に耐えられますか?
 システムは進化するもの
 ミドルウェアの追加
 設定の変更、チューニング
 ミドルウェア・ライブラリのバージョンアッ
プ
 構築済みのサーバを更新できますか?
 アップデート用のスクリプトを作る
 サーバを再構築/新規構築できますか?
 アップデート用のスクリプトが増えると辛い
冪等性 (べきとうせい)
 何度実行しても同じ結果になるという性質
 たとえば echo “…” >> /path/to/conf はダメ
 環境構築スクリプトが冪等性を持っている
と…
 サーバの新規構築にも使える
 既存のサーバのアップグレードにも使える
 何度実行してもエラーにならない
 AMI や VM snapshot と相性がいい
 いつ保存したものでも、実行すれば最新状態に
構成管理ツールを使おう
 構成管理ツールは環境管理に特化
 冪等性を持っている
 いつも指定したパッケージが入る
 いつも指定した設定になる
 いつも指定したディレクトリ構成になる
 サーバのあるべき姿を定義する
著名な構成管理ツール (1)
 Puppet
 Ruby 製の構成管理ツール
 比較的歴史があり、長く使われている
 各サーバにインストールして利用する
 クライアント-サーバ型 もしくは単体実行
 独自の DSL で環境の定義を行う
 puppet-forge という共有リポジトリがある
 誰かが書いた定義を使うことができる
 例: MySQL のインストール、設定の定義
著名な構成管理ツール (2)
 Chef
 Ruby 製の構成管理ツール
 去年ブームになった構成管理の火付け役
 各サーバにインストールして利用する
 クライアント-サーバ型 もしくは単体実行
 独自の DSL で環境の定義を行う
 Rubyベースなのでループや if などが使える
 OpscodeCommunityという共有リポジトリが
ある
 誰かが書いた定義を使うことができる
著名な構成管理ツール (3)
 Ansible
 Python 製の構成管理ツール
 興味を持っている人が多い注目株
 サーバへのインストールは不要
 SSHで接続して操作を行う
 YAML ベースの DSL で環境の定義を行う
 他の言語で補助コマンドを作ることも可能
 今のところ共有リポジトリは存在しない
著名な構成管理ツール (4)
 Fabric + cuisine
 Python 製のツール
 リモート管理ツール(fabric)とその拡張機能
 あまり利用事例は多くないが、書きやすい
 サーバへのインストールは不要
 SSHで接続して操作を行う
 Python スクリプトで環境の定義を行う
 Fabric, cuisine が提供する関数を用いる
 今のところ共有リポジトリは存在しない
環境構築ツールの比較
名前 言語 定義 インストー
ル
共有
リポジト
リ
Puppet Ruby 独自DSL 必要 ○
Chef Ruby 内部DSL 必要 ○
Ansible Python YAML 不要 ×
Fabric +
Cuisine
Python Python 不要 ×
どの構成管理ツールを使うべきか
 ベストアンサーはない
 手に馴染んだものを使うべき
 場合によってはシェルスクリプトでも可
 情報量では chef が一歩リードしている印象
 台数が多い場合はpuppet/chefが有利か
 共有リポジトリの有無も参考になるかも
 既に定義されているためショートカットでき
る
 ただし、すべて自分で書くという話もよく聞きます
 定義を書くときの参考になる
アジェンダ
 サーバの構成管理していますか?
 構成管理ツールを使おう
 Chef の紹介
 デプロイツールを使おう
 まとめ
構成管理ツール Chef
 Chef
 Ruby 製の構成管理ツール
 管理対象のホストにインストールして使う
 サーバ/クライアント型 (単体実行も可能)
 cookbook で環境を定義する
 インストール手順や設定方法をまとめたもの
 ソフトウェア単位で作成することが多い
 例: MySQL用cookbook、Postfix用cookbook
Chef の種類
 Chef-Server / Chef-Client
 大規模用
 ホスト間の連携(Orchestration)が可能
 設定の自動反映
 Hosted Chef
 ASP 版 Chef-Server
 Chef-solo
 単体で稼働する (実行ホストの設定をする)
 手動で実行する
 20台ぐらいまでは chef-solo で十分
まずはここからはじめましょう
chef-solo のインストール
 以下のコマンドを実行する
 /opt/chef 以下にファイルがインストールされ
る
 一部、/usr/bin, /etc/chef にファイルが入る
curl -L https://www.opscode.com/chef/install.sh | sudo bash
chef で環境構築をしていく流れ
1. 設定する対象を決める
 例: ntpd をインストールする
2. 共有リポジトリで cookbook を探す
 作成することもできます(今回は説明しませ
ん)
3. 設定ファイルを書く
4. chef-solo コマンドを実行する
共有リポジトリで cookbook を探す
 OpscodeCommunity
 http://community.opscode.com/cookbooks
 1,100以上のcookbookが登録されている
設定ファイルを書く
 solo.rb
 chef-solo の設定ファイル。主にパスを設定す
る
 solo.json
 chef-solo の定義ファイル (JSON形式)。
 run_list: 実行する cookbook を列挙する
 attributes: 各 cookbook に対するパラメータ
 設定できる値は各 cookbook の README 参照のこと
 例: ntp の設定情報
設定ファイルを書く
 solo.rb
 solo.json
file_cache_path "/home/app/chef-solo/cache"
cookbook_path "/home/app/chef-solo/cookbooks”
{
"run_list" : ["recipe[ntp]”],
"ntp" : {
"servers" : ["ntp.nict.jp”]
}
}
chef-solo コマンドを実行する
 chef-solo コマンドを実行する
 root 権限を持った状態(sudoなど)で実行する
こと
 何度実行しても同じ状態になる
 デモします
sudo chef-solo –c solo.rb -j solo.json
実際の構築例
 とある Rails アプリ用の環境
 OS 設定
 yum の設定 (EPEL, repoforge), timezone
 iptables, SELinux 無効化
 logrotate, rsyslog, NTP
 nginx, postfix, MySQL
 開発言語/ツール
 Ruby, Python
 vim, screen, git, mercurial, TeXLive
 Jenkins, Jenkins プラグイン
chef に関する情報源
 公式ドキュメント (docs.opscode.com)
 入門 Chef Solo (電子書籍)
 #opschef, #opschef_ja
 各種 chef 勉強会
アジェンダ
 サーバの構成管理していますか?
 構成管理ツールを使おう
 Chef の紹介
 デプロイツールを使おう
 まとめ
デプロイって何をやるの?
 アプリ(ソースコード/バイナリ)の配布
 リリース前の準備
 asset precompile
 JavaScript Compile/minify
 サービスの再起動
 トラブル発生時のバージョンダウン(切り
戻し)
 DB Migration
 データ修正など
構成管理ツールでデプロイできないか
 一部の操作は『冪等性』と相性の悪い
 切り戻し操作
 DB Migration
 データ修正
 デプロイ作業は他のツールが向いている
著名なデプロイツール (1)
 Fabric
 Python 製のツール
 Python スクリプトで操作を定義する
 プリミティブな機能が提供されている
 複雑な操作は自分で実装する必要がある
def create_link():
run("ln -s /usr/local/bin/ruby /usr/bin/ruby”)
著名なデプロイツール (2)
 Capistrano
 Ruby 製のツール
 Ruby スクリプトで操作を定義する
 あらかじめいくつかの機能を持っている
 VCS からのチェックアウト、デプロイ
 ソースコードの切り戻しに対応
task :create_link do
run "ln -s /usr/local/bin/ruby /usr/bin/ruby”
end
アジェンダ
 サーバの構成管理していますか?
 構成管理ツールを使おう
 Chef の紹介
 デプロイツールを使おう
 まとめ
ツールを導入するメリット/デメリット
 メリット
 量産、再構築をするたびに効果が得られる
 構築、アップデートのスピードが速くなる
 操作ミスが尐なくなる
 デメリット
 覚えるまでに試行錯誤が必要になる
 新しい設定を追加する際に苦労する
 Postfix の設定で半日かかった (手動なら 10分)
 手動管理を混ぜるとトラブルになる
まとめ
 サーバの構築にはツールを使うと捗る
 構成管理ツール
 デプロイツール
 個人的には chef, capistrano がお薦め
 手動派の人は見直すチャンス
 向かないケースもあるので検討は必要
 重要なのは自動化と環境が再現できること

Pythonユーザのための構成管理入門 #pyconapac