Chef社内勉強会（第1回）

Chef 勉強会
第1回概要編

TIS株式会社
コーポレート本部
戦略技術センター

中西剛紀

今日のゴール

以下のようなことを感じてください。
● Chef でできること
● Chef の動作の仕組み
● Chef の特徴、構成要素
● 環境構築を自動化する意義
● クラウドと環境構築、運用自動化の関係
● Chef の課題と今後の期待

とりあえずデモ

● デモ1 : サーバを自動構築する
● デモ2 : サーバの構成を変更する

初期状態

● インスタンスは存在しない。
● OSだけ導入したAMIは存在する。

– 今回は Ubuntu 12.04 (64bit) の AMI を利用
– AMI ID は ami-eca719ed

デモ１：サーバを自動構築する

● AWSにEC2インスタンスを作成する。
● WordPressサーバをセットアップする。
コマンド１発で！(長いけど)

# knife ec2 server create
--run-list 'recipe[chef-client], role[wordpress-server]'
--region ap-northeast-1 --availability-zone ap-northeast-1a
--image ami-eca719ed --flavor m1.small
--groups (適用するセキュリティグループ名) --ssh-key (適用するKeyPair名)
--ssh-user ubuntu --identity-file (EC2インスタンスへのSSH接続用鍵ファイル名)

結果確認

● EC2インスタンスが稼働している。
– knife コマンドで指定したリージョン、AZ
– knife コマンドで指定したAMI、インスタンスタイプ

● WordPressサーバが稼働している。
– EC2のPublic DNSでアクセスが可能

デモ1で行った自動構築の流れ
作業端末 AWS 東京リージョン
1. EC2インス
タンスを作成 WordPress Hosted Chef (SaaS)
Knife
PHP
SSH Apache
Ruby
MySQL
Chef Client
CentOS Ubuntu 3. 割当てられた
Instance 　 Recipeを実行
Instance
作業用インスタンス構築されるインスタンス
2. 適用するRecipeを
　リポジトリへ登録

# knife ec2 server create
--run-list 'recipe[chef-client], role[wordpress-server]' ※Chef のオプション
--region ap-northeast-1 --availability-zone ap-northeast-1a
--image ami-eca719ed --flavor m1.small ※AWS のオプション
--groups (適用するセキュリティグループ名) --ssh-key (適用するKeyPair名)
--ssh-user ubuntu --identity-file (EC2インスタンスへのSSH接続用鍵ファイル名)

の基礎知識
●
米OPSCODE社が開発元
●
サーバー構築を自動化するツール
●
類似ツール
– 商用： HP Operation Orchestration, 　　　　
　 Microsoft System Center Orchestrator 2012
– OSS： Puppet
●
最近の動向
– クリエーションラインが国内サポート開始
– SmarterCloud Continuous Delivery(IBM) で利用可能に

Chef の特徴
● 冪等性（べきとうせい）
– ある操作を複数回行っても結果が同じになる。
– 処理の順番を定義するのではなく、
「サーバーが最終的にどうなっていて欲しいか」
という状態を定義する。
● プラットフォームに依存しない
– 完全に依存しないわけではない。Cookbook 次第
– 仕組みが用意されているだけ。
● Ruby製。内部DSL
– Puppet は外部DSL
– 簡単に言うと、定義ファイル自体がRubyコードっぽい

Chef の構成要素

● Chef に登場するマシンの役割
– Server, Node（Client）, Workstation
● Chef で使用するツール
– Chef Solo, Chef Client, Knife, Ohai
● Chef の定義ファイルで使う用語
– Cookbook, Recipe, Attribute, Resource,
Provider, Role

Chef に登場するマシンの役割
● Server と Node (Client) と Workstation の関係

デモ1の環境では、、、

1. EC2インス
タンスを作成 WordPress Hosted Chef (SaaS)
Knife
PHP
SSH Apache
Ruby
MySQL
Chef Client
3. 割当てられた
CentOS Ubuntu 　 Recipeを実行
Instance Instance
作業用インスタンス構築されるインスタンス
2. 適用するRecipeを
　リポジトリへ登録

Workstation Node Server

Chef Server
●
Chef はクライアント－サーバ型のアーキテクチャ
クライアント：構築(管理)されるマシン。複数存在する。
サーバ：インフラ設定情報を集中管理する。1台だけ存在。
●
Chef Server は、なかなかの変態構成
– RabbitMQ, CouchDB, Solr とかを連携させて稼動
– 素人が下手に手を出すと怪我するぜ
●
Chef Server には複数の利用形態がある。

Chef Server の種類
●
Chef Solo
– 実は Chef Server を使わなくても自動構築はできる。
– Chef Server の構築/運用が不要なので、
お手軽に始められるが、使える機能は限定される。
セットアップ対象 Server上のCookbookを参照し、
通常形態自分のノードをセットアップする。
Chef Server
(Serverあり) Chef Client
cookbooks

Chef Solo セットアップ対象ローカルのCookbookを参照し、 Chef Server
自分のノードをセットアップする。
(Serverなし) Chef Solo
cookbooks
不要

●
オープンソース版
– 自分でサーバを立ててインストールする。
– インストール激むず。サーバの運用も自己責任で。

●
SaaS 版
– Chef Server のホスティングサービス
– Opscode 社が運営
– ５台までは無料で使える。
– 組織 (organization) の概念がある。
●
複数部署にまたがった利用
●
コンサルタントに閲覧だけ許可

●
オンプレミス版
– インターネットに接続できない環境でも、
SaaS版と同等機能の Chef Server を構築できる。
●
組織管理
●
冗長化（HA）
– 24H365D の有償サポートを Opscode 社が提供

●
利用形態に応じた使い分け
Chef Solo OSS版 SaaS版オンプレミス版

手軽さ ◎ × ○ △
検索 × ○ ○ ○
ノード情報保存 × ○ ○ ○
組織管理 × × ○ ○
コスト ○ ○ △ ×

● 開発環境、小規模システム ⇒ Chef Solo
● とにかく低コスト ⇒ OSS
● パブリッククラウドで楽に運用 ⇒ SaaS
● プライベートクラウド、DC内で運用 ⇒ オンプレミス

Chef で使用するツール
●
Chef Solo, Chef Client
– 構成情報に従って自動構築を行うツール
– 構築対象の Node 上で動作
– Chef Server なしなら Solo, ありなら Client を使う。
– Chef Client は定期的に実行される。（デフォルト30分間隔）
●
Knife
– Chef の管理、運用を行うコマンドラインツール
– プラグインによる機能拡張が可能
●
クラウド操作 knife-ec2, knife-openstack, knife-cloudstack、、、
●
仮想ホスト操作 knife-vsphere, knife-kvm, knife-xapi、、、

Chef で使用するツール
●
Ohai
– Chef 内部で Node の情報を取得する際に使うツール
– Chef をインストールすると一緒に導入される。
– Ohai で取得した情報は Chef Server に登録される。
●
全ての Node の情報を Chef Server で参照できる。
●
Node の attribute として使用可能
– Ohai 単体で使用することも可能 (gem install ohai)
●
Node のコマンドラインで ohai って打つ
●
Ruby プログラムからライブラリとして呼び出す
– プラットフォームに関係なく、同じ方法で同じ値を取得できる。
– プラグインで機能追加も可能

Chef の Cookbook の構成
● Cookbook: システムのあるべき姿を定義
– Chef のパッケージ配布単位
– apache2, mysql, php
● Recipe: あるべき姿を具体的に記載するスクリプト
– apache2パッケージをインストールする。
– apache2.conf を作成し、/etc/apache2に配置する。
● Attribute: サーバの役割、状態で変動する値
– Apache のパッケージ名（CentOSならhttpd）
● Template: ファイルを動的に生成するテンプレート
– Attributeの値を埋め込むことができる。

デモで使った Cookbook で確認してみよう

Role
● サーバの「役割」を定義する。
● 複数の Recipe をグルーピングしたり、
Role 特有の Attribute を設定できる。
– Recipe がアラカルトなら Role はセットメニュー
● 例： wordpress-server という Role
– 6つの Recipe がグルーピングされている。
– この Role を --run-list に加えるだけで、
グルーピングされた 6つの Recipe が実行される。

デモで使った Role で確認してみよう

デモ２：サーバの構成を変更する
● MySQLの設定を変更したい。
– max_connections は 800 で設定されている。
– max_connections を 100 にしたい。
● 普通は、
– 対象サーバに SSH で接続、ログイン
– /etc/mysql/my.cnf を開く
– max_connection の値を編集
– mysqld を再起動
● 対象サーバが何十台もあったらどうする？

デモ2で行った構成変更の流れ

WordPress Hosted Chef (SaaS)
SSH PHP
２. Node の Chef Client を実行 Apache
（30分待つだけでもいい） MySQL
Chef Client
Ubuntu 3.変更内容だけを
Instance 　抽出して反映

WordPressをセット
アップしたNode
１. Role の Attributeを編集

【ポイント】
● Chef Server に反映した変更が「自動的」に Node に適用される。

● Chef Server に反映した変更を複数の Node に適用できる。

● 限定した Node にのみ変更を反映することも可能である。

Chef Serverを中心とした構成管理自動化

サーバ構築方法の比較

構築手順書を見ながら手動構築
パラメータシート、マシン設置、 MW, アプリ導入、
作業手順書作成 OS導入環境設定

Excel, Word DVDメディアから Excel, Word
で手書き入力手動インストール見ながら手動設定

メリット：
● （自動化に対して）何の準備もいらない。

デメリット：
● サーバ数に比例した構築時間がかかる

– 何台、何十台も手作業で構築していられない。
● サーバが正しく出来上がらないリスク
– 構築手順書のウソ、構築作業時のミス

Chef による自動化
手動構築パラメータシート、マシン設置、 MW, アプリ導入、
作業手順書作成 OS導入環境設定

Excel, Word DVDメディアから Excel, Word
で手書き入力手動インストール見ながら手動設定

Chefが立ち入れない領域

Chef 利用 Chefが
Cookbook、マシン設置、 MW, アプリ導入、制御する
Recipe 作成 OS導入環境設定領域

DSL, Ｒｕｂｙで DVDメディアから
Chef が自動実行
コーディング手動インストール

メリット：
● 構築時間の短縮　※Cookbookの作成時間を除く。。。

● サーバが正しく出来上がる。 ※Cookbookが正確なら。。。

それ、シェルスクリプトでもよくね？
メリット：
● まあ、フルスクラッチのデメリットは解消する。

● 技術的なハードルも低い（< Chef ）

デメリット：
● シェルスクリプトって読みづらい、メンテしづらい

– 他人のスクリプトを読みたくない。。。
● 同じスクリプトを複数回流すことは想定されない
– Chef は「べき等性」
● プラットフォームに依存しまくり

インフラを含めた構築自動化

● 基本、Chef で自動化できるのは OS より上
– 物理マシン、DISK、ネットワークの設置は手作業
● でも最近は OS より下の層で仮想化が進む
– マシン、OS： AWS EC2, VMWare ESXi, KVM
– DISK： AWS S3, EBS
– ネットワーク： AWS VPC, OpenFlow

構築自動化の範囲が広がっている

クラウド基盤での構築自動化
JEOS (Just Enough OS) 方式
– 最小構成のOS環境をイメージ化して利用
● AWS: 各種OSの公式AMI

– アプリケーションの導入、設定は Chef で自動化
– 変更が少ない部分は固定化し、
変更が多い部分のみを自動化する。
Chef による
アプリケーション自動セットアップ

ミドルウェア
最小構成のOS
環境をイメージ化
OS

カスタマイズの柔軟性を確保しながら、
環境構築の時間を短縮

クラウドと環境構築、運用自動化の関係
● クラウドで構築するシステムの特徴
– ビジネス要件の変化に合わせて柔軟に変更したい。
● アプリケーション、システム構成、インフラ規模
– 開発期間の短縮と継続的なアップデートが必要
継続的インテグ
開発期間の短縮レーション(CI)の適用

要要要
件設実テ件設実テ件設実テ
定計装ス定計装ス定計装ス
トトト
義義義

運用

従来のプロセスでは、運用のサイクルが
アプリケーション変更のサイクルについていけない

自動化で開発と運用のサイクルを統合
● 運用プロセスの自動化がサイクル統合実現の鍵
Chefが担う部分
1. 環境構築、デプロイ処理を自動化
• 必ず同じプロセスで環境を構築し、アプリをデプロイする。
• 環境の違いで起こる問題を防止
2. 運用引継ぎに伴う作業（受け入れテスト等）を自動化
• 安全に頻繁なデプロイ作業を可能に
3. 運用業務を手作業からプログラムによる自動化に変更
• 手順書メンテナンスと運用作業の負荷を軽減

アプリケーションとインフラのライフサイクル統合を
実現することが理想（=「DevOps」）

構築自動化が運用に与えるインパクト
自動化で「障害復旧」の発想も変わってくる。
● 環境構築が自動化されれば、「壊れた環境の修復」より、
「新しい環境を作り直す」方が楽（安上がり）。
– 単純なインフラ障害なら、再構築で全て回復
– 自動で復旧可能かの判断が難しいのが現実だが、　　　　　　　　　　　　　　
復旧パターンの一つとして検討できる。
● 自動化前提の設計を行っておくことが重要
– 環境再構築がデータに影響しないアーキテクチャ
– アプリ実行環境とユーザデータを明確に分離
● AWS のアーキテクチャはこの方向性を示唆している。
● インスタンスが停止したらインスタンス上のデータは消える。
● 永続データは、EBS、S3への外部保存が前提

Chef を使う意義
● 自動化のメリットは作業の早さだけじゃない。
● インフラをアプリ開発のスタイルで管理
– Chef の Cookbook, Recipe はコードとして管理できる。
– アプリと一緒に Git に入れれば変更管理も容易
● このアプリはこのバージョンのCookbookで動く

● インフラ、サーバ構築ノウハウの伝承
– 作業属人化の排除
– 達人が書いた Cookbook を再利用
● パラメータシートではなくコードで伝える。
– 達人のノウハウはコード（Recipe）に込める。
● DBMSの達人が書く my.cnf, postgresql.conf
● Apacheの達人が書く httpd.conf

Chef の課題
● 学習コストが大きい
– 汎用性が高い反面、仕組みを理解しづらい
– 日本語情報は非常に限定的
● ノウハウが少ない
– Chef Server を構築、運用するのは容易ではない
– 質の良い Cookbook、Recipe が流通することを期待
– 国内サポートも始まったので今後の盛り上がりに期待
● インフラエンジニア必要とされる Ruby 力。。。
● Chef というプロダクト名。。。
– SEO的にどうよ。Cookbook とか Recipe とか Knife とか
– ぐぐっても関係ないものばかりひっかかる。。。

Chef を学習する方法
● とにかく試してみる。
– ぶっちゃけ自分で触らないとよくわからないので
● 他人が書いた Cookbook を読む。
– Opecodeが公開しているCookbook
http://community.opscode.com/cookbooks
– 公開されているCookbookの書きかえから始めよう。
● がんばり過ぎない。
– 一度に全てを自動化しようとしない。いやになる。
– 小さなCookbookを少しずつこつこつと育てる。

Chef社内勉強会（第1回）

More Related Content

Chef社内勉強会（第1回）