Chef社内向け解説とその課題について
•
40 gefällt mir•9,522 views
社内向けに説明した資料です 会社の技術ブログにChefの記事投下しました。http://devlab.isao.co.jp/chef-solo_vagrant_install/
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Chef社内向け解説とその課題について
Ähnlich wie Chef社内向け解説とその課題について (20)
Chef社内向け解説とその課題について
- 2. はじめに • 資料作った本人はサーバ構築運用を8年くらいしてる主 婦です。 • MySQLとシェルスクリプトがちょっと好きです。 • 本資料は概要の解説だけで実際の手順などはリンク先に 充実していると思います。 • お勧め書籍：「入門Chef-Solo」
- 3. 解説ターゲットと目的 • 社内向けに技術解説および検証結果の報告と共有をわか りやすく行う。（まずはグループ内、技術関係者向け） • 自由度の高い部分についての方向性を相談する。 • この先どうしたいのか(具体的にどの案件で構築時に Chefを積極的に用いていくかなど)を相談する。 ※手順のブラックボックス化を防ぎ、 冪等性（何度実行しても同じ環境が出来上がること）を担保する。 ※学習コストは高めですがそれに見合う以上のメリットがあるという 記事も見かけました。コスト削減とオペミス防止等々。 ※Chefで柔軟に使える試験環境をつくりたい、 何回も同じインストール作業したくないという要望にこたえられる。 Chefを用いる目的など：
- 4. CHEFとは • サーバの状態をあるべき姿に自動的に収束 (convergence)するツール。≠単なる自動化ツール。 • OSインストール後の状態からの初期設定やミドルウェア等 の環境セットアップに利用するものです。 • アプリケーションのデプロイツールとは性質が異なります （ロールバックとかテストとかは標準サポートされていな い）ので他のツールと組み合わせる必要があるようです （capistrano、serverspec等） • レシピに書いたとおりに動作します • Puppetと機能は一緒。ただChefのほうが表記方法にruby のクラスとメソッドが使えるので自由度が高く(配列等が使 える)、Puppetのほうがディレクトリ構成の自由度が高いそ うです。
- 6. 冪等性とその恩恵とは • Chefでは、同じレシピで何度繰り返しサーバ構築 してもまったく同じ状態になること。 • つまりレシピ＝手順＝実環境の状況であり、それ を読めばそのサーバがどんな状態なのかわかる。 • 冪等性を保つためには手動での追加変更オペレー ションは一切してはならない。 • 冪等性の恩恵としては、効率化による工数削減だ けでなく、古いシステムのリプレイスへの抵抗が 軽減、手順記載忘れがない、口伝のオペレーショ ンが減る、等があると思います。
- 8. CHEFの種類 • Chef-Server レシピのバージョン管理や並列処理等が可能なldapに似た仕組 みのもの。Environmentを利用すると試験環境と本番環境を分 けて処理を行えるようです。セットアップに手間かかるそうで す。必要に応じ追ってためしてみます。 • Chef-Solo 今回使うもので、並列処理はできないが20台くらいまでの構成 に適している、サーバ構成管理ツール。主に使うのはknife- solo。chef-soloでローカル適用し、knife-soloでローカルのレ シピをリモートに転送して適用します。手軽に利用できます。 • Hosted-Chef Opscodeが環境提供してるホスティング版。FBも使ってるら しく1万台等の規模にも対応できスケーラブルだそうです。 Hostedなのでお金がかかります。
- 9. 用語解説 Cookbook：一つ以上のレシピに必要なデータやファイルをまとめるもの レポジトリ(キッチン)：Chefの動作に必要なファイル群。複数のクックブック やRole,Nodeの設定を含むもの。 1つのシステムにつき1つが望ましい。 Recipe：複数のResouceを記述したファイル。使いまわしたい単位で分けて書 くとよい。 Resouce：設定の最小単位。ファイルやパッケージ単位の設定 • レポジトリ＞クックブック＞レシピ という階層でレシピ群が管理されます。 Node：Chefで管理される各サーバのこと。 Role： webやdb等のノードの役割を定義。使うRecipeや変数を設定する。 プロバイダ：ChefではOSの種類をさす。Ohaiというコマンドの集合でその違 いを吸収しNodeのパラメータを取得している模様。 Data_bags：クックブックに含ませたくないユーザやホスト他のデータを管理 する仕組み。 Emvironment：環境を分けるしくみ。たとえば本番環境と試験環境等。
- 13. 現時点の注意点など • Rubyのバージョンに注意(1.8.7以上) • Rubyをサービスで使う場合にオムニバスインストーラ に削除と上書きされるので注意。 http://tk0miya.hatenablog.com/entry/2013/04/16/1 15713 • Vagrant（ベイグラント）はどんどん開発されており 1.1以降や最新版を利用推奨。 • Knife-soloは0.3.0以降がよいと思われます。 • Chefの11.6以降からクライアント(solo)でも Emvironmentが利用できるようになったようです。 • not_ifの定義忘れ(再実行されると困る場合)
- 14. VAGRANTFILEについて • Vagrant（ベイグラント）とは、VirtualBoxのラッパーツールで、コマンド ラインから仮想OSを起動するのに用います。(Bootstrappingツールです) • AWS上でインスタンス起動する場合について。 # vagrant up --provider=aws # vagrant ssh # vagrant destroy 編集したVagrantFileの中身は以下のような感じです Vagrant.configure("2") do |config| config.vm.box = "dummy" config.vm.provider :aws do |aws| aws.access_key_id = ENV['AWS_ACCESS_KEY_ID'] aws.secret_access_key = ENV['AWS_SECRET_ACCESS_KEY'] aws.keypair_name = "komi-test" aws.ssh_username = "root" aws.ssh_private_key_path = "~/.ssh/id_rsa aws.instance_type = "t1.micro" aws.region = "ap-northeast-1" aws.ami = "ami-ca0784cb" aws.security_groups = [ 'default' ] end end ←インスタンスタイプ指定 ←東京リージョンを指定 ←AMI（OSイメージ）を指定 ←セキュリティグループを指定 ←管理ノードへsshログインするための秘密鍵を指定 ←管理ノードへsshログインするためのユーザを指定 ←外部からsshログインするためAWSの秘密鍵を指定 ←AWSのアクセスキーIDを指定 ←AWSのシークレットアクセスキーを指定 ←ダミーのBOXを指定 http://www.ryuzee.com/contents/blog/6538
- 15. レポジトリの構成 • 新規Chefレポジトリ（キッチン）を作るとできるディレクトリについて # knife solo init chef-repo # tree -L 1 chef-repo chef-repo |-- cookbooks |-- data_bags |-- nodes |-- roles |-- site-cookbooks `-- solo.rb cookbooksとsite-cookbooksはクックブックを格納するディレクトリで、 cookbooksにはダウンロードしてきたもの、site-cookbooksには自分で 作ったものを入れるのが推奨されているようです。 そのほか、knife-soloを入れると/root/.chef/knife.rbが作成され、必要な ディレクトリパスなどを指定します。 ←サードパーティレシピ置き場 ←ユーザ等データ管理機能使用時に使う ←各サーバ（node)用のJSONファイル置き場 ← Roleを使うとき用ディレクトリ ←自作レシピ置き場 ← cookbookのパスなどを設定
- 16. COOKBOOKの構成 knife cookbook create <cookbook-name>で作るディレクトリの中身 tree nginx -F nginx |-- CHANGELOG.md |-- README.md |-- attributes/ | `-- default.rb |-- definitions/ |-- files/ | `-- default/ |-- libraries/ |-- metadata.rb |-- providers/ |-- recipes/ | `-- default.rb | `-- server.rb |-- resources/ `-- templates/ `-- default/ `-- nginx.conf.erb ←filesの下に定数のみの設定ファイルを置く ←recipesの下でレシピを書いておく ←templatesの下に変数が必要な設定ファイルを置く ←templateリソースを使う場合、 attributesの下にデフォルト値を定義する ←default以外のレシピはnginx::server等で利用可能
- 17. レシピについて • Nginxのインストールと起動、設定ファイル設置とリロードするレシピ # vi site-cookbooks/nginx/recipes/default.rb package "nginx" do action :install end service "nginx" do supports :status => true, :restart => true, :reload => :true action [ :enable, :start ] end template "nginx.conf" do path "/etc/nginx/nginx.conf" source "nginx.conf.erb" owner "root" group "root" mode 0644 notifies :reload, 'service[nginx]' end レシピはやりたいことに応じた リソースを使って書いていきます。 パッケージをインストールするの はpackageリソース。 サービスを起動したり有効にする のはserviceリソース。 設定ファイル（変数有）を配置す るのはtemplateリソース。
- 20. TEMPLATEについて２ • Templateリソースでレシピを書く template "nginx.conf" do path "/etc/nginx/nginx.conf" source "nginx.conf.erb" owner "root" group "root" mode 0644 notifies :reload, 'service[nginx]' end • attribute/default.rbにデフォルト値を定義する default['nginx']['port'] = "80” • nodeまたはroleのattributeを定義する { "name":"webserver", "chef_type": "role", "json_class":"Chef::Role", "default_attributes":{ "nginx": { "port": "80", } }, # vi cookbooks/nginx/templates/default/nginx.conf.erb ～略～ server { listen <%= node['nginx']['port'] %>; server_name localhost; ～略～ ポート番号を変数に指定。 • Port番号を変数展開するようにした設定ファイル
- 21. NODE用ファイルの解説 • Chefでは管理対象サーバのことをノード(node)という • JSONファイルにかかれているのはある特定のノードの状態。 • JSONファイルに書いているデータ構造はNodeObjectと呼ぶ。 • NodeObjectのプロパティとしてそのノードに適用するべきレシピを列挙 し、そのノードが持っている変数(Attribute)の値も列挙する、これがJSON ファイルの役割。 vi 172.20.28.241.json { "mysqld" : { "server_id" : 103 }, "run_list":[ "role[dbserver]“ ] } ←変数（Attribute）の値 ←適用するべきレシピを含むrole(※※) ※リポジトリ直下のnodesディレクトリの下にjsonファイルを置きます
- 22. ROLEについて • 某システムでは、 webserver、 dbserver、 admserverでroleを 分けています。 cd chef-repo/roles vi webserver.json { "name":"webserver", webserverのロール "chef_type": "role", "json_class":"Chef::Role", "default_attributes":{ "base_setting": { "swappiness": "30", "tcp_tw_reuse": "0", "tcp_tw_recycle": "0", "tcp_fin_timeout": "60", "tcp_max_syn_backlog": "4096", "somaxconn": "4096" } }, "override_attributes":{}, "description":"webserver's role", "run_list": [ "recipe[base_setting::bkup_dir]", 基本設定、バックアップディレクトリ作成 "recipe[login_users]", ログインユーザを作る "recipe[base_setting::hosts]", 基本設定、hosts "recipe[base_setting::sysctl]", 基本設定、sysctl "recipe[base_setting::disable]", 基本設定、disable "recipe[base_setting::ntpdate]", 基本設定、ntp "recipe[base_setting::mail-client]", 基本設定、mail "recipe[base_setting::logrotate]", 基本設定、ログローテート "recipe[httpd::httpd-server]", httpdサーバ "recipe[httpd::basic_auth]", httpdのベーシック認証 "recipe[httpd::wordpress]", httpdのwordpress "recipe[httpd::s3mount]", httpdのs3mount "recipe[munin::munin-node]", munin-node "recipe[munin::munin-node-web]", munin-nodeのweb用プラグイン配置 "recipe[zabbix::zabbix-agent]" zabbix-agent ] } ※※Role内で run_listを管理する のは初心者Chefア ンチパターンによ ると、バージョン 管理できないため 非推奨の模様。リ ファクタリング対 象です。
- 24. NOT_IF, NOTIFIESについて • not_if：実行結果が0でない場合にそのリソースを 実行する。たとえばrpm –qaでパッケージが入っ てなかったらpackageリソースでインストール する等。 • only_if：実行結果が0だった場合にそのリソース を実行する。特定のディレクトリが存在した場合 にファイルを置く等、事前の確認を行いたい場合 に利用するものの模様。 • notifies：設定ファイルが更新されたらサービスを リロードしたい、といった用途に用いるもので複 数のリソース内に定義することが可能。 Scriptリソースや2度実行されたくないリソース内には 必ずnot_ifを定義する必要があります。
- 25. 仮想環境にレシピを反映する • Knife-Solo使う場合 • Vagrant使う場合 # knife solo cook <host> レシピ転送＆リモート実行 # vagrant provision ※一度レシピを書いたら次回から上記のようなコマンド実行するだけです。 これはとても重要なことです。
- 26. 確認について • Serverspecを用いるのが主流で推奨されています。 • とはいえ最初はコマンドで都度確認しながらになるか と思います。 • ScriptやExecuteというリソースはエラーだけどエ ラーが帰ってこずすんなり終わったりしますので要注 意。直接コマンドで確認しないと原因が特定できない 場合もあります。 • Cookbook毎のテストコマンドは、以下のとおりです。 シンタックスチェックができます。 knife cookbook test <cookbook-name> http://www.slideshare.net/mizzy/serverspec-hbstudy45 サーバ構築を自動化して確認は手動って面倒すぎるというお話。
- 27. 参考：某システムのレシピの構成概要 ディレクトリパス chefのレポジトリ /root/chef-repo VagrantFileの場所 /root/chef-repo/VagrantFile 要件 対応リソース cookbook レシピ名 コメント Node(Role) ホスト名の変更 VagrantFile - IF設定 VagrantFile - hosts設定 template,Attribute,Role base_setting hosts.rb Ohaiのhostnameを使う all bkupディレクトリ作成 Directory base_setting bkup_dir.rb all カーネルパラメータ設定template,Attribute,Role base_setting sysctl.rb all アカウント作成 Group,User,data_bags login_users default.rb all Selinux無効化 file base_setting disable.rb all yum設定修正 file base_setting disable.rb all IPv6無効化 file base_setting disable.rb all 不要cron停止 file base_setting disable.rb all yumリポジトリ設定 - base_setting opscode要らず元のAMIに あった all ntpデーモン設定 package,service,file base_setting ntpd.rb localhost cron設定(ntpdate) cron base_setting ntpdate.rb クライアント設定 allクライアント MTA設定 package,service,file,script base_setting mail-postfix.rb mail-dovecot.rb localhost メールクライアント設定file base_setting mail-client.rb クライアント設定 allクライアント logrotate.d設定 file base_setting logrotate.rb all apache導入基本設定 script,service,file httpd httpd-server.rb web,localhost mod_ssl導入設定 - httpd mod_ssl.rb ELB使うので要らなかった web ベーシック認証設定 file httpd basic_auth.rb web s3mount設定 file httpd s3mount.rb web wordpress導入設定 file,script httpd wordpress.rb web,localhost mysql導入基本設定 script,service,file mysqld mysqld-server.rb database mysqlアカウント作成 databags,script mysqld mysql-users.rb databaseクックブック依 存 database munin-node設定 script,service,file munin munin-node.rb munin-node-web.rb munin-node-db.rb web,db用のレシピをわけ た allクライアント munin-server設定 package,service,file munin munin-server.rb localhost 監視設定zabbix-agent package,service,file zabbix zabbix-agent.rb all 監視設定zabbix-proxy package,service,file zabbix zabbix-proxy.rb localhost phpmyadmin導入設定 - httpd phpmyadmin.rb 実は要らなかった模様 localhost Rubyわからない全くの初心者がレシピを書きあげるのに2カ月程度。 WEB1+DB1＋STG1な環境。
- 28. レシピのバージョン管理 • レシピのバージョン管理はServerはできるがSolo ではできないのでgitを使います サードパーティのレシピを使うときにコミット済みである必要があります。 # cd /root/chef-repo # git init # git add . # git commit -m 'fist commit' http://www.slideshare.net/yalab/git-9518230
- 29. 課題とこれからのとりくみ • レシピの書き方ほか自由度が高すぎて何がただしいのかよくわかっていないのが 課題の一つ。If文をもっと使いこなせたらよさそう。 • Host名の管理にdata_bagsをつかいたいけどどうなのでしょう。 • Scriptリソースを極力つかわないのが無用な問題を避けるまたは環境の違いを吸 収するために理想なようですが、使わないとどうにもならないところも多数あり ました。 • Chef-ServerでないとEnvironmentが使えずに試験環境と本番環境など環境分け のほうほうがRoleつかうくらいしか思いつかないです。 • サードパーティのレシピを使ってみたいがruby力等がたりずレシピを読み切れ ない。書いたとおりに動くものは書いてある内容が理解できないなら使用するべ きではないように思います。 • 自分でレシピを書いて育てていく。（ruby力の強化およびこれまで使ってきた 手順を整理する必要が生じます。 ） • Serverspecでテストを書いてテストする。（一応できたところです） • 実環境での適用を検討する。（某システムは適用する前に切り替わってしまった ためリリース済みの環境に試験ができない）これをすすめていかないと取り組ん でる意味がないというか自動化や冪等性の恩恵を受けられないです。 • サーバリソースに応じたパラメータ自動調整などに取り組みたい。 • 試験環境とかハンズオン用のサーバを一気に立てて使い終わったら落とす等、夢 は広がってるようです。