概要
2018年4月にChef(Client)14とChefDK3がリリースされ、それに伴いChef12が正式にEOLになります。
Chefは1年間隔でメジャーバージョンを更新、サポートするメジャーバージョンは1つ前のバージョンまでサポートするというサイクルをとっています。
すでに変更についてはリリースノートや動画がChef社から提供されていたりするのですが、新規機能については大した量はなかったので自分用にまとめてみたいと思います。
リソースの追加
- build_essential
- windows
- chef_handler
- chef_hostname
- sudo
- homebrew
- rhsm
- ohai
- dmg
- mac_os_x
- swap
- sysctl
は今まで外部依存cookbookだったのをcoreに取り込んでmetadate.rbに依存情報を書かなくてよくなりました。(該当している機能のresourceはリリースノートを一度確認してみてください)
coreに取り込まれるとバージョンの管理などを気にしなくてよくなるために、基本的にmetadate.rbから依存情報を削除することをお勧めします。
特に新規に追加されたリソースではwindows関連のリソースが多く追加されており、最近のChefの傾向としてはDockerなどのコンテナ化が進むLinux周りではなくWindowsに注力しているのではないかなと感じました。
mac_os_xのdeprecated
mac_os_x cookbookのcookbookがdeprectedになり、代わりにMSのエンジニアがメンテしているmacos cookbookを使うように推奨されるようになりました。
MSとしてサポートしているわけではない(はず)です。
Custom Resource
今回はCustom Resourceのinterface部分を強化したようで
validationに失敗したときのエラーメッセージが設定できるようになりました。
property :repo_name, String
:regex [/^[^\/]+$/],
:validation_message: "repo_name cannot contaion a forward slash",
今まで正規表現でチェックはできたのですが、ユーザー側にはあまり適切なエラーが返っていなかったようなので(入力が正規表現にマッチしていませんという類のエラーメッセージが出ていた模様)、かなり良い感じになったのではないでしょうか?
またCustom Resource提供者は自身のCustom ResourceをDeprecatedだと伝えれるように、deprecated propertyを設定できるようなりました。
またこのCustom Resourceの説明もCustom Resource内で説明を書くことができるように、description fieldが追加されました。
property :repo_name, String
regex: [/^[^\/]+$/],
validation_message: "repo_name cannot contaion a forward slash",
description: this property is repo_name for rpm
supermarketに上げると良い感じになったりするのだろうか・・・
optional plugin in ohai
ohaiのプラグインを無効にすることができるようになりました。
ohaiとはChefが管理するノードの情報を集約してChef server側で管理するプラグインなのですが、結構遠慮なく情報をぶっこぬくのでAD,LDAP周りの連携で問題になったり、そもそも必要もない情報がChef serverに上がってしまうので余分なトラフィックがchef-clientを実行毎に発生してしまう。
などの問題がありました。
それをChef Clientで制御できるようになったという変更っぽいです。とりあえずlspci, sessions shard,passwdがoptional pluginになったみたいです。
必要がないならすべて無効にしてもよいかもしれませんね。
yum
yumが超速くなって、メモリの使用量も半分になったらしいです。
あと書き方のバリエーションも増えて
yum_package "foo < 1.2.3" # バージョン制限
yum_package "perl(Git)" # providerを指定したパッケージのインストール
みたいな書き方ができるようになりました。
logger
loggerのloglevelにtrace
が増えました。
今まで、debugでログだすとしこたまログが出たのでtraceだとちょうどよくなるんじゃないでしょうか(願望)
Policyfile hoisting
今までChefにはPolicyfileというenv, roleなんかを一元的に管理できる機能がオプションとして存在していました。
env,role周りの設定管理はChefを複雑化させている要因の一つとして、割と問題だったと理解しているのですが、Policyfileはその管理を一つのPolicyfile.rb
で管理できるようになり設定の複雑化の解決方法の一つとして注目していました。
ただどうにもChef側としてはenv, roleの管理はChef automate(ちなみにこいつは有料です)の方を使ってほしいらしく、ユーザーからPolicyfileはdeprecatedなの?と言われる程度にはChef側はPolicyfileの改善・普及に熱心ではありませんでした。
ただ今回の変更でコニュニティーcookbookであるpoise-hoistの機能が取り込まれました。
poise-hoistとはどういう機能かというと、attributeをstagingとproductionで出し分けたい場合Policyfileに以下のように設定し
default['staging']['myapp']['title'] = "My Staging App" default['production']['myapp']['title'] = "My App"
client.rb
にpolicy_groupを例えば```staging``と設定することで, cookbook側で
node['myapp']['title'] # "My Staging App"
という感じに配列を一段減らすことができるようになる機能です。
このpolicy_group
はbootstrap時に指定することができます。
パフォーマンス改善
Ruby 2.5を使用します。
ChefDK 3
ChefDK3は以下のコンポーネントが含まれています。
- Chef Client 14
- Inspec 2
- FoodCritic 13
- CookStyle 3
- Test Kitchen 1.20
- Fauxhai 6.1
所感
大体リリースノートでまとまっていたのはここら辺です。
更新部分を見ると、破壊的な変更はなく既存のコミュニティーのcookbookの取り込み、DSLの強化、パフォーマンス強化などが目立ったメジャーアップデートだったように感じます。
すでにChefでvm, 物理サーバーを管理している方は追従するのがよいのではないでしょうか。対して新規のユーザーがChef 14になったから新しくChefを使用してみようと思わせるような変更内容ではなかったように感じます。(Windows関連で使いたいという方はもしかしたら、resourceが充実してきたので検討しても良いかもしれない?)
現在のInfrastructure as Codeの環境としてはdocker, k8sなどのコンテナ関連がメインプレイヤーでvm,ベアメタルの管理は少々レガシーな技術になりつつあるのかなというのが現状かもしれません。
現にChef社は新たに(といっても2016年の話ですが)Habitatという新しいプロダクトをリリースしており、どうもそちらのほうにリソースを割いているように見えます。
国内でもprovisioningのツールはansibleがよく使われており、Chefは設定の複雑さなどで敬遠される傾向があります。
とはいえ、大規模なサーバー管理だとrubyの記述力やohaiの情報収集力などChefにしかない魅力はたくさんあるので、機会があったら使ってみることをお勧めします。
参考リンク
https://docs.chef.io/release_notes.html
https://www.youtube.com/watch?v=rHdD1ClDf9E&t=1032s
https://www.chef.io/eol-chef12-and-chefdk1/