実録！AnsiblevsChef-solo

実録！ Ansible vs Chef-solo
リクルートテクノロジーズ/北野

自己紹介
 名前
北野太郎
 所属
リクルートテクノロジーズ
ITソリューション統括部
インフラソリューション部
インフラソリューション2グループ
 担当
Qassインフラ担当 (※ @ITをご覧ください)
リクルート共通インフラの自動化
新規導入ミドルウェアの検証担当

http://www.atmarkit.co.jp/ait/articles/1509/01/news030.html

アジェンダ
 Ansible , Chef-soloとは
構成管理ツールとは
Ansibleとは
Chefとは
 Ansible vs Chef-solo
 結論

はじめに
インフラ構成管理ツールとしてのAnsible(とChef)の使用感を、実際に利用した
立場から共有します。
※ 本来であれば、Ansibleの比較対象はChef-Serverが妥当ですが、試していま
せん。ごめんなさい。

その前に…構成管理ツールとは
 主に2つの目的を実現するためのツール
サーバ構築の自動化
サーバ状態のコード化
• 手動構築の手間と時間を減らす
• 手動構築による人為的ミスの防止
• コードベースのワークフローでのレビュー
• サーバの設定変更履歴の管理
• Serverspecなどのテストフレームワークによるテスト・継続的インテグレーション
http://gihyo.jp/admin/serial/01/itamae/0001
Ansible, Chef-soloも構成管理ツールの一つ

インフラの構成管理(+コード化)ツールを利用すると何がよいのか
今どんな設定だっけ？を実機を見ないで確認できる
誰が何度やっても同じ状態(環境)に収束する
• 不用意なサーバアクセスはそれだけでトラブルの元
• 環境構築が人に依存しない。秘伝のスクリプト不要
コードがそのまま構築手順になる
• 構築手順書と構築スクリプトを別に作る必要がない
環境の履歴を管理できる
• 誰が、いつ、どんな変更をしたかを残すことができる
テストに応用できる
• コード化されていれば、テストで利用することも

Ansibleとは
 Python製の構成管理ツール
 2012/2/20初回リリース
 最新stable バージョンは2.0.0
 最近RedHat社に買収された
 2015/9に行われたAnsible meetup in Tokyoでは
160人定員で265人が応募するなどかなり高い注目を浴びている
 語源は“アーシュラ・K・ル＝グウィンのSFシリーズ、
ハイニッシュ・ユニバースに登場する超光速通信技術”

Ansibleの特徴 (一般的に言われていること)
中央集約型
YAML形式の設定ファイル
導入が容易
• 複数サーバに対して並列実行可能
• エージェントレス (対象サーバにツールのインストールが不要)
• フォーマット(ルール)に従って記述するだけなので、人による質のばらつ
きが少ない
• 記述が分かりやすい
• インストールパッケージが各環境向けに用意されている
設定ファイルがなくても動く
• コマンドライン引数のみの実行も可能

Chefとは
 Ruby製の構成管理ツール
 2009/1/15初回リリース
 最新stable バージョンは12.5.1(client), 12.2.0 (server)
 Chef-soloというものは最新版では存在せず、
Chef-clientのlocalモード(Chef-Zero)が後継という扱い
 もともと”marionette”という名前だったが、
「長くて打ちづらい」という理由と
recipeモジュールを使っていたことから
Chefという名前にした(らしい)
 サーバ構成管理が爆発的に
広まったきっかけにもなった
 http://d.hatena.ne.jp/naoya/20130204/1359971408

Chef-soloの特徴 (一般的に言われていること)
スタンドアロン型
ruby形式の設定ファイル
豊富な文献
• 自身のサーバで動作
• 対象サーバにクライアントのインストールが必要
• フォーマットはあるが、rubyのコードである程度自由に記述可能
• 導入事例が豊富にある

検討の前提となるインフラ構成
Ansible → Redis、 Chef-solo → elasticsearchの導入で検証
環境
用途
対象
約10台 (オンプレ) 20台以上 (オンプレ、AWS)
構築、設定変更、運用(再起動など) 構築、設定変更、運用(再起動など)
Redisサーバ、ビルドサーバ elasticsearchサーバ、他
verAnsible 1.9.2 Chef-solo 12.10

構成 : 導入 & 実行の容易性
Ansibleはプロビジョニング対象サーバにクライアントの導入が不要 (※)
導入管理側に導入プロビジョニング対象に導入
実行Ansible内でsshにより遠隔実行 Chefとは別にssh実行の仕組みが必要
※ 正確にはPython2.4以上またはsimple-json pkgが必要だが、
なくともraw moduleでsshによりインストール可能
サイト側サーバに予めクライアントを仕込んだり、バージョンアップ時にサイト側サーバを触る必要がない

構成 : 複数サイト/複数サーバ導入を踏まえた設計の柔軟性
結局AnsibleもChefも同じ思想に行き着く (どちらでもできる)
サーバごとに
必要な手順を取得
ansible-galaxyを利用
requirementsに定義
必要な手順(role)を取得
Berkshelfを利用
berksfileに定義
必要な手順(cookbook)を取得
サーバごとに
実行順序を定義
playbookファイルに順序を
記載
rolesまたはnodesに順序を記載
Aサイト向け本番設定、Bサイト向け開発設定など、パラメータを柔軟にする仕組みはどちらも同じ
環境・サイトごとに
パラメータを定義
varsにサイトごとの設定を
書き分ける
environmentやroleに
サイトごとの設定を書き分ける

補足 : Ansibleとchef-soloのrepository構成
AnsibleもChefも同じ構成になる
repository repository
• host_vars
• group_vars
• environments
• playbook.yml • roles (※)
• nodes (※)
• inventory
• roles • cookbooks
• site-cookbooks
環境ごとに異なる変数の定義
ex: メモリサイズ、実行ユーザ
大まかな実行順序
ex: apacheインストール、tomcatインストール
詳細な手順
ex: ユーザ定義 ,ディレクトリ作成、ファイル配置
実行対象一覧
ex: ホスト1, ホスト2 (chef-soloはlocalのためなし)
※: ファイル内に変数定義も含まれる

構成 : 複数サーバ導入を踏まえたスケーラビリティ
Ansibleは多重度を設定可能
スケールn台単位で並列実行可能
ただし都度並列数分待ち合わせ
100台規模は未検証
localhost内で閉じるため早い
ただしそもそも並列実行の仕組みを
実装する必要あり
エラー
時の挙動
途中で1台エラーの場合は
そこまでで全台実行が止まる
localhost実行のため、そもそも
他サーバとは足並みを揃えない

構成 : 安全性
冪等性、dry-run(仮実行)の仕組みはどちらも実装されている
冪等性
(何度実行しても
同じ結果になる)
実装されている実装されている
dry-run
(仮実行)--checkオプションにより可能 -Wオプションにより可能

まとめ : システム・用途から見た適合性
Ansibleの方が柔軟に導入でき、大規模にも対応可能
導入管理側に導入するのみでよいプロビジョニング対象に導入が必要
実行Ansibleからsshにより遠隔実行 Chefとは別にssh実行の仕組みが必要
サイト側サーバに予めクライアントを仕込んだり、バージョンアップ時にサイト側サーバを触る必要がない
柔軟性複数サイト・環境に対応できる
構成をとることができる
複数サイト・環境に対応できる
構成をとることができる
性能並列実行可能。多重度を設定できる単体では早いが複数サーバに実装する
ために別途多重化の仕組みが必要
安全性冪等性あり
dry-runで変更箇所の事前確認が可能
冪等性あり
dry-runで変更箇所の事前確認が可能

利用者から見た導入のしやすさ
Ansibleは最小限の構成で動作するので手軽に始めやすいが、
実運用を見据えた場合は結局同じような構成が必要になる
最小構成inventoryファイルと
ansibleコマンドだけで実行可能
(ただし実運用上有効なものではない)
最小構成というものはない
必ず規定のディレクトリ
構成をとる必要がある
ansible -i hosts 192.168.33.12 -m yum -s -a name=telnet
ansible-playbook -i test-servers site.yml
chef-solo -c solo.rb –j test-server.json
特別な設定ファイルを必要とせずに実行することも可能
実運用では結局はしっかりとした構成を組む必要がある
Chef-soloは導入時も運用時も同じ定義が必要

利用者から見た設計のしやすさ
Ansibleはディレクトリ構成、Chefは中の実装が人依存になりがち
dir構成Best Practice(※)はあるが、
強制ではない。言い換えれば、
インフラに合わせて設計が必要
基本構成が決まっており、その
構成から外れることはできない
(=誰が作っても同じになる)
taskの記述yaml形式でフォーマットに
準じて記載することしか
できない (※)
(=品質がある程度一定になる)
rubyであるためプログラム化する
(=人に大きく依存する)
代わりに自由度は高い
※ http://docs.ansible.com/ansible/playbooks_best_practices.html

補足 : yamlとrb(ruby)形式の違い
記述イメージはどちらも同じ
- name: create redis user
user: name={{role_redis_user_name}} group={{role_redis_group_name}} …(略)
- name: make sure that redis install path exists
file: path={{ item.value.install_path }} state=directory …(略)
with_dict: "{{ role_redis }}"
when: instance is undefined or instance == item.key
user 'elasticsearch' do
comment 'elasticsearch user'
uid node[‘elasticsearch’][‘user’][‘uid’]
(略)
action [ :create, :manage ]
end
yum_package 'elasticsearch' do
action :install
(略)
version node['elasticsearch']['version']
notifies :restart, "service[elasticsearch]", :delayed
end
yaml
ruby

冪等性
(何度実行しても
同じ結果になる)
dry-run
(仮実行)
結果の
見やすさ
利用者から見た運用のしやすさ
Ansibleは最小限の構成で動作するので把握しやすいが、最終的に動かす
場合は結局同じような構成が必要になる
実装されている実装されている
--checkオプションにより可能 -Wオプションにより可能
少し見づらい実行結果が分かりやすい

補足 : 実行結果の見え方
Ansibleは実行結果の表示が煩雑 (Chefはシンプルで見やすい)

まとめ : 利用者から見た適合性
どちらも不便な点はあるが、どちらもほとんど同じ
構成自由度がある反面、実装者に依存ほぼ基本構成が固定
手順の表現フォーマットが固定自由度がある反面、実装者に依存
構成管理の機能冪等性、dry-runともにあり冪等性、dry-runともにあり

3-3. ANSIBLEのその他特徴

Ansible : dynamic inventory
定義済みのホスト一覧を外部から取得し、プロビジョニングの対象とする
ことができる
Databaseなど
構築対象サーバ
git
ホスト一覧
(inventory)
構築手順(role)
パラメータ(vars)
ホスト情報を一元管理することが可能

Ansible : tag
各taskにtagを付け、tagで絞り込んだものだけ実行可能
- name: install application
yum: name=application state=present
tags:
- install
- name: deploy config
template: src=templates/app.conf.j2 dest=/etc/application/app.conf
tags:
- install
- config
- name: deploy scripts
template: src=templates/{{ item }}.sh.j2 dest=/usr/local/application/{{ item }}
with_items: "{{ script_list }}"
tags:
- install
- script
yaml
ansible-playbook example.yml –tags=install
指定したものだけ動く

Ansible : 運用への応用
ホストの一覧情報を持っており、taskの一斉実行が可能ということは…
「全台に対して◯◯」ができる
• 例
• 全台同時にスクリプト実行
• 全台同時にMW再起動
• 1台ずつ順番にコマンド発行
• 実際には :
• 全台に対してrspec / serverspecでテスト実行
• 全台に対して障害時のサーバ情報取得スクリプトを実行

総括
実際に利用した感想としては、中央管理型で複数サーバに
プロビジョニングできるAnsibleが便利
• 実際に使ってみて…
• 確かに、「ChefはできるのにAnsibleではできない(あるいはその逆)」は
細かいものも含めていっぱいある
• ただ、根本的な構成管理の思想はどちらも同じで、致命的な問題もなし。
結局は「どちらに決めて仕様を理解し使いこなすか」の範疇の話
• その上で…便利だったこと
• 中央管理でサーバ”群”に対してプロビジョニングをAnsibleだけで実現でき
る
• ミドルウェアの再起動など他の運用にも使える
• 対象サーバにあらかじめクライアントをインストールする必要がない
(特にオンプレだと大変)
• tagやdynamic inventoryなど、追加で便利な機能が多い

おまけ : 「Chefの学習コストが高いからAnsible」は本当か？
• 一般的に言われる乗り換えの理由
• 個人的には、どちらも本気で使うなら同じレベル
• むしろ、コードに逃げられずに全てyamlで書ききる
しかないAnsibleも相当な学習コストになる
• 運用を考えない「触ってみた」レベルであれば、
Ansibleの方が確かに簡単だが、それで何が嬉しいのだ
ろうか…。
本格利用を見据えるなら、どちらも同じ

実録！AnsiblevsChef-solo

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 実録！AnsiblevsChef-solo

Similar to 実録！AnsiblevsChef-solo (20)

More from Recruit Technologies

More from Recruit Technologies (20)

実録！AnsiblevsChef-solo