Download as PDF, PPTX
![Page 26
補足 : 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](https://image.slidesharecdn.com/20160226kitano-160308103401/75/AnsiblevsChef-solo-26-2048.jpg)
More Related Content
実録！AnsiblevsChef-solo
- 1. 実録！ Ansible vsChef-solo リクルートテクノロジーズ/北野
- 2. Page 2 自己紹介 名前 北野太郎 所属 リクルートテクノロジーズ ITソリューション統括部 インフラソリューション部 インフラソリューション2グループ 担当 Qassインフラ担当 (※ @ITをご覧ください) リクルート共通インフラの自動化 新規導入ミドルウェアの検証担当
- 3.
- 4. Page 4 アジェンダ Ansible, Chef-soloとは 構成管理ツールとは Ansibleとは Chefとは Ansible vs Chef-solo 結論
- 5.
- 6.
- 7. Page 7 その前に…構成管理ツールとは 主に2つの目的を実現するためのツール サーバ構築の自動化 サーバ状態のコード化 •手動構築の手間と時間を減らす • 手動構築による人為的ミスの防止 • コードベースのワークフローでのレビュー • サーバの設定変更履歴の管理 • Serverspecなどのテストフレームワークによるテスト・継続的インテグレーション http://gihyo.jp/admin/serial/01/itamae/0001 Ansible, Chef-soloも構成管理ツールの一つ
- 8. Page 8 インフラの構成管理(+コード化)ツールを利用すると何がよいのか 今どんな設定だっけ？を実機を見ないで確認できる 誰が何度やっても同じ状態(環境)に収束する • 不用意なサーバアクセスはそれだけでトラブルの元 •環境構築が人に依存しない。秘伝のスクリプト不要 コードがそのまま構築手順になる • 構築手順書と構築スクリプトを別に作る必要がない 環境の履歴を管理できる • 誰が、いつ、どんな変更をしたかを残すことができる テストに応用できる • コード化されていれば、テストで利用することも
- 9. Page 9 インフラの構成管理(+コード化)ツールを利用すると何がよいのか 今どんな設定だっけ？を実機を見ないで確認できる 誰が何度やっても同じ状態(環境)に収束する • 不用意なサーバアクセスはそれだけでトラブルの元 •環境構築が人に依存しない。秘伝のスクリプト不要 コードがそのまま構築手順になる • 構築手順書と構築スクリプトを別に作る必要がない 環境の履歴を管理できる • 誰が、いつ、どんな変更をしたかを残すことができる テストに応用できる • コード化されていれば、テストで利用することも
- 10. Page 10 Ansibleとは Python製の構成管理ツール 2012/2/20初回リリース 最新stable バージョンは2.0.0 最近RedHat社に買収された 2015/9に行われたAnsible meetup in Tokyoでは 160人定員で265人が応募するなどかなり高い注目を浴びている 語源は“アーシュラ・K・ル＝グウィンのSFシリーズ、 ハイニッシュ・ユニバースに登場する超光速通信技術”
- 11. Page 11 Ansibleの特徴 (一般的に言われていること) 中央集約型 YAML形式の設定ファイル 導入が容易 •複数サーバに対して並列実行可能 • エージェントレス (対象サーバにツールのインストールが不要) • フォーマット(ルール)に従って記述するだけなので、人による質のばらつ きが少ない • 記述が分かりやすい • インストールパッケージが各環境向けに用意されている 設定ファイルがなくても動く • コマンドライン引数のみの実行も可能
- 12. Page 12 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
- 13. Page 13 Chef-soloの特徴 (一般的に言われていること) スタンドアロン型 ruby形式の設定ファイル 豊富な文献 •自身のサーバで動作 • 対象サーバにクライアントのインストールが必要 • フォーマットはあるが、rubyのコードである程度自由に記述可能 • 導入事例が豊富にある
- 14. 3. ANSIBLE VSCHEF-SOLO
- 15. Page 15 検討の前提となるインフラ構成 Ansible →Redis、 Chef-solo → elasticsearchの導入で検証 環境 用途 対象 約10台 (オンプレ) 20台以上 (オンプレ、AWS) 構築、設定変更、運用(再起動など) 構築、設定変更、運用(再起動など) Redisサーバ、ビルドサーバ elasticsearchサーバ、他 verAnsible 1.9.2 Chef-solo 12.10
- 16.
- 17. Page 17 構成 :導入 & 実行 の容易性 Ansibleはプロビジョニング対象サーバにクライアントの導入が不要 (※) 導入管理側に導入 プロビジョニング対象に導入 実行Ansible内でsshにより遠隔実行 Chefとは別にssh実行の仕組みが必要 ※ 正確にはPython2.4以上またはsimple-json pkgが必要だが、 なくともraw moduleでsshによりインストール可能 サイト側サーバに予めクライアントを仕込んだり、バージョンアップ時にサイト側サーバを触る必要がない
- 18. Page 18 構成 :複数サイト/複数サーバ導入を踏まえた設計の柔軟性 結局AnsibleもChefも同じ思想に行き着く (どちらでもできる) サーバごとに 必要な手順を取得 ansible-galaxyを利用 requirementsに定義 必要な手順(role)を取得 Berkshelfを利用 berksfileに定義 必要な手順(cookbook)を取得 サーバごとに 実行順序を定義 playbookファイルに順序を 記載 rolesまたはnodesに順序を記載 Aサイト向け本番設定、Bサイト向け開発設定など、パラメータを柔軟にする仕組みはどちらも同じ 環境・サイトごとに パラメータを定義 varsにサイトごとの設定を 書き分ける environmentやroleに サイトごとの設定を書き分ける
- 19. Page 19 補足 :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のためなし) ※: ファイル内に変数定義も含まれる
- 20. Page 20 構成 :複数サーバ導入を踏まえたスケーラビリティ Ansibleは多重度を設定可能 スケールn台単位で並列実行可能 ただし都度並列数分待ち合わせ 100台規模は未検証 localhost内で閉じるため早い ただしそもそも並列実行の仕組みを 実装する必要あり エラー 時の挙動 途中で1台エラーの場合は そこまでで全台実行が止まる localhost実行のため、そもそも 他サーバとは足並みを揃えない
- 21. Page 21 構成 :安全性 冪等性、dry-run(仮実行)の仕組みはどちらも実装されている 冪等性 (何度実行しても 同じ結果になる) 実装されている 実装されている dry-run (仮実行)--checkオプションにより可能 -Wオプションにより可能
- 22. Page 22 まとめ :システム・用途から見た適合性 Ansibleの方が柔軟に導入でき、大規模にも対応可能 導入管理側に導入するのみでよい プロビジョニング対象に導入が必要 実行Ansibleからsshにより遠隔実行 Chefとは別にssh実行の仕組みが必要 サイト側サーバに予めクライアントを仕込んだり、バージョンアップ時にサイト側サーバを触る必要がない 柔軟性複数サイト・環境に対応できる 構成をとることができる 複数サイト・環境に対応できる 構成をとることができる 性能並列実行可能。多重度を設定できる 単体では早いが複数サーバに実装する ために別途多重化の仕組みが必要 安全性冪等性あり dry-runで変更箇所の事前確認が可能 冪等性あり dry-runで変更箇所の事前確認が可能
- 23.
- 24. Page 24 利用者から見た導入のしやすさ Ansibleは最小限の構成で動作するので手軽に始めやすいが、 実運用を見据えた場合は結局同じような構成が必要になる 最小構成inventoryファイルと ansibleコマンドだけで実行可能 (ただし実運用上有効なものではない) 最小構成というものはない 必ず規定のディレクトリ 構成をとる必要がある ansible -ihosts 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は導入時も運用時も同じ 定義が必要
- 25. Page 25 利用者から見た設計のしやすさ Ansibleはディレクトリ構成、Chefは中の実装が人依存になりがち dir構成Best Practice(※)はあるが、 強制ではない。言い換えれば、 インフラに合わせて設計が必要 基本構成が決まっており、その 構成から外れることはできない (=誰が作っても同じになる) taskの記述yaml形式でフォーマットに 準じて記載することしか できない(※) (=品質がある程度一定になる) rubyであるためプログラム化する (=人に大きく依存する) 代わりに自由度は高い ※ http://docs.ansible.com/ansible/playbooks_best_practices.html
- 26. Page 26 補足 :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
- 27.
- 28. Page 28 補足 :実行結果の見え方 Ansibleは実行結果の表示が煩雑 (Chefはシンプルで見やすい)
- 29. Page 29 まとめ :利用者から見た適合性 どちらも不便な点はあるが、どちらもほとんど同じ 構成自由度がある反面、実装者に依存 ほぼ基本構成が固定 手順の表現フォーマットが固定 自由度がある反面、実装者に依存 構成管理の機能冪等性、dry-runともにあり 冪等性、dry-runともにあり
- 30.
- 31. Page 31 Ansible :dynamic inventory 定義済みのホスト一覧を外部から取得し、プロビジョニングの対象とする ことができる Databaseなど 構築対象サーバ git ホスト一覧 (inventory) 構築手順(role) パラメータ(vars) ホスト情報を一元管理することが可能
- 32. Page 32 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 指定したものだけ動く
- 33. Page 33 Ansible :運用への応用 ホストの一覧情報を持っており、taskの一斉実行が可能ということは… 「全台に対して◯◯」ができる • 例 • 全台同時にスクリプト実行 • 全台同時にMW再起動 • 1台ずつ順番にコマンド発行 • 実際には : • 全台に対してrspec / serverspecでテスト実行 • 全台に対して障害時のサーバ情報取得スクリプトを実行
- 34.
- 35. Page 35 総括 実際に利用した感想としては、中央管理型で複数サーバに プロビジョニングできるAnsibleが便利 • 実際に使ってみて… •確かに、「ChefはできるのにAnsibleではできない(あるいはその逆)」は 細かいものも含めていっぱいある • ただ、根本的な構成管理の思想はどちらも同じで、致命的な問題もなし。 結局は「どちらに決めて仕様を理解し使いこなすか」の範疇の話 • その上で…便利だったこと • 中央管理でサーバ”群”に対してプロビジョニングをAnsibleだけで実現でき る • ミドルウェアの再起動など他の運用にも使える • 対象サーバにあらかじめクライアントをインストールする必要がない (特にオンプレだと大変) • tagやdynamic inventoryなど、追加で便利な機能が多い
- 36.
- 37. Page 37 おまけ :「Chefの学習コストが高いからAnsible」は本当か？ • 一般的に言われる乗り換えの理由 • 個人的には、どちらも本気で使うなら同じレベル • むしろ、コードに逃げられずに全てyamlで書ききる しかないAnsibleも相当な学習コストになる • 運用を考えない「触ってみた」レベルであれば、 Ansibleの方が確かに簡単だが、それで何が嬉しいのだ ろうか…。 本格利用を見据えるなら、どちらも同じ