fbpx

[和訳] Chef Client 12.0.0 リリース #opschef_ja #getchef_ja

Chef

この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。

本稿は Release: Chef Client 12.0.0 (2014/12/05) の和訳です。

本日、Chef Server 12 (訳注: [和訳] Chef Server 12 リリース)を完全なものとするChef Client 12.0.0のリリースを発表することを嬉しく思います。このバージョンは、Chef ClientとChef Serverの現在のバージョンと後方互換性を保持しつつ、Chef Clientに非常に多くの改善を導入しています。

MVP

このリリースはChef Communityの助けがなければ不可能だったでしょう。およそ70人の貢献者がいました。とりわけ、Jesse HuとSander van Harmelenの貢献はChef Communityに大きな影響を与えました。

Jesseの調査とパッチは、Chef Serverの高負荷時にChef Clientが動作不良を起こす原因となる問題を素早く解決する助けとなりました。SanderはコアRESTライブラリの本当に困難なバグを調査し、この問題の正しい解決方法を探すのに私達に協力してくれました。おめでとうJesse、Sander。あなた達が12.0.0のMVPです！

何が新しいのか

後方互換性

何が新しいのかを話す前に、些細だけど重要なものがあります。問題なく移行できるようにするために、Chef Client 12.0.0はChef Client 11と完全な後方互換です。Chef Client 11で動作している既存のCookbookや独自プラグイン、ハンドラは12にそのまま移行できます。

Chef Client 12.0.0は、Chef Server 12を含む、Enterprise Chef Server、オープンソース版Chef Server、ホステッド版Chef ServerといったあらゆるChef Serverに対して利用できます。ただし、1つ注意があります。Enterprise Chef Server 11.2.5以前を使っている場合、chef_max_version設定を更新する必要があります。次のように行います。

  1. private-chef.rbにlb['chef_max_version'] = 12を追加
  2. sudo private-chef-ctl reconfigureを実行

AIXサポート

Chef Client 12.0.0ではIBM POWERプラットフォームのAIX 6.1と7.2の公式サポートを発表することを嬉しく思います。Chef社社員であるJulian DunnとScott Hainがこの機能に関するブログをもうすぐ公開する予定です。

Windowsでのパフォーマンス改善

私達は、Windowsでのユーザ体験をLinuxでのユーザ体験と同等にするために注力し続けています。Chef Client 12では、Windows版Chefユーザに対していくつかの興味深いお知らせがあります。

Windows版Chefにおける大変痛い点の1つはパフォーマンスでした。Chef Client 12では、あらゆる点でツールのパフォーマンスを高めました。Chef Client 11のころは、chef-clientやknifeを実行すると、CPU利用率が一時的に100%に到達していました。Chef Client 12では、2つの新機能とともにこの問題を解決しました。

  1. requireパスの扱いがRuby 1.9より大変早いRuby 2.0.0を内包するように、Rubyバージョンを上げました。chefがgemの高いバージョンを要求することで、この更新は初期負荷を下げ、ツールを実行する際の初期CPU負荷を修正しました。
  2. Chef Client 12は、Chef Development Kitで用いているappbundlerを使うようになりました。Appbundlerは初期負荷をかなり下げるために、用いているgemのバージョン依存解決を前もって計算しておくようにします。

注意: appbundlerはWindowsだけでなくすべてのプラットフォームで有効になっています。つまり、この変更はすべてのプラットフォームのChef Clientでかなりのパフォーマンス改善があります。

Windowsイベントログ

パフォーマンス改善に加えて、Windowsのネイティブ機能との統合を改善し続けています。この方向での大きな一歩として、Windows管理者がシステムに起きたイベントを確認するための共通の場所であるWindowsイベントログに、イベントを記録するようにしました。Chef Client 12.0.0は、WindowsノードのApplicationイベントログに「Run Start」「Run Success」「Run Failure」といった基本的なイベントを記録するようになりました。

SSL検証をデフォルトにして安全化

すぐに使えるセキュリティを提供するために、Chef Client 12.0.0ではSSL検証をデフォルトで有効にしました。Chef Clientのこの変更により、HTTPSを用いてリモートサーバと通信する際、それらのサーバのSSL証明書の検証を行います。ブートストラップのコードパスは、信用できる証明書を新しくプロビジョニングするNodeに移動するよう更新されました。何か問題がある場合は、knife ssl checkを用いて調査ができます。既存のNodeについては、不足した証明書を取得するためにknife ssl fetchがあります。

KnifeとRecipeのPartial Searchを組み込みに

Chef Communityの多くの人々が、しばらくの間partial search Cookbook (訳注: Chef 11 Serverの新機能: Partial Search)の恩恵を受けていました。Partial Searchは与えられたパターンに基いて、検索結果のフィルタリングを有効とします。Chef Client 12.0.0では、この機能はChef Client内に移されました。

この機能は、Recipe内ではsearch()に:filter_result引数を与えることで、knife searchでは--filter-result CLIオプションで有効になります。

動的Provider解決器

ChefにおけるResource/Providerインフラの構造的な問題の1つは、プラットフォームに基いてResourceとProviderの組み合わせが静的であることでした。与えられたプラットフォームのResourceに複数のProviderがある場合に、この問題は増幅していました。Ubuntu 14.04がよい例です。サービスを管理するためには、Debian (SysV)かUpstart Providerのどちらかを正しく指定する必要がありました。Chef 12では、ProviderResolverという、発見したinitscriptsに基いてProviderを決定するという非常に賢い方法があります。

ProviderResolverは、ディストリビューションにおけるinitシステムがsystemdで有効になっている場合はそれに基いて正しいProviderを用います。つまり、通常systemdがインストールされていないNodeは、systemdがインストールされているとしてsystemd Providerを利用します。逆に、通常systemdをサポートしているディストリビューションでsystemdを削除したNodeは、適切にSysV Providerを利用します。Recipeコードがsystemdをインストールするか削除するかした後、service Providerは動的に正しいProviderに切り替えます。

このResourceの解決はあらゆる点でより動的になるよう作られています。現在、Ubuntuでパッケージをインストールする際に用いるChef::Resource::DpkgPackage Resource、RHELディストリビューションで用いるChef::Resource::YumPackageは、オプションを正しく検証します。

Chef Client 12.0.0 Attributeの新機能

Phil Dibowitzの助力によって、Chef 12.0.0にChef RFC 23が実装されました。この変更は次のような機能を追加します。

  • 与えられた優先順位に対してAttributeツリーのキーを安全に削除できるように
  • すべての優先順位に対してAttributeツリーのキーを安全に削除できるように
  • ある優先順位に対して入れ子のキーの値の全体を上書きするためのある優先順位の値を設定できるように

これらの変更点は、ごく一部を除いて完全な後方互換性を保っているということを再度お知らせしておきます。node.force_default!とnode.force_override!はアクセサからセッタに変更され、これらの極めてまれな機能を用いているCookbookコードは、メソッドから!を単に省く必要があります。

Mac OSXでの改善

Chef Client 12.0.0では、Mac OSX 10.6と10.7のサポートを取り止め、10.10のサポートを追加しました。加えて、このバージョンではMac OSXに対してすばらしい改善があります。

Chefの以前のバージョンでは、パッケージ管理にmacportsを用いていました。コミュニティのすばらしい働きにより、より確実で簡単なパッケージ管理であるhomebrewを有効にしたCookbookを構築しました。Joshua Timbermanのおかげで、このロジックはChefコアの一部になりました。

12.0.0では、Mac OSXにおいて確実にユーザの管理が行えるようになりました。ユーザのパスワードは平文か、Mac OSX 10.8以上で用いられるSALTED-SHA512-PBKDF2スタイルのShadowハッシュで設定が行えます。

group Providerにも、確実性とべき等性を改善する多数のバグ修正が行われました。

File Specificityのオーバーホール

Noah KantrowitzがChef Client 12.0.0にChef RFC 17 - File Specificity Overhaulを実装しました。このRFCによって、TemplateやCookbook Fileを作成する際のCookbookのディレクトリ構造の強制を省略できるようになりました。ChefのResourceで、直接ファイルに対しての検索パスを設定できるようになりました。

ユーザビリティの改善

このリリースにおける努力の1つは、セマンティックバージョニングの強制によって行えなかった些細な変更を行うことでした。メジャーバージョンアップによって、Chefのユーザ体験をより楽しくするためのAPIに対するいくつかの些細な変更を加えることができました。変更点のいくつかのハイライトは次の通りです。

  • knife bootstrapのコマンドラインオプションのクリーンアップ
  • Recipe内とKnifeを通じての暗号化Data Bagの自動的な暗号化と復号
  • コマンド実行をより簡単にするために、Recipe DSLでshell_out機能を追加
  • Chefを長期間動作していることでのトークンの問題を避けるために、デフォルトでlazyなCookbook同期を無効化
  • /tmpが別のディスクにある際の問題を避けるために、デフォルトで一時ファイルを宛て先のディレクトリに仮置きするように
  • 同時に多数のNodeをブートストラップする際の安定性を向上するために、デフォルトでクライアントサイドでのキー生成を有効化
  • :powershell_script Resourceや:batch Resourceを用いているコードを削減するために、デフォルトで親のResourceタイプを評価し、Attributeを引き継ぐように

他には？

これらの変更点の詳細は12.0.0 リリースノートを、すべての変更点は12.0.0 CHANGELOGを参照してください。

取得するには？

ダウンロードページを訪れてください。

加えて、Windows以外のプラットフォームで最新バージョンのChef Clientをダウンロードするには、次のコマンドを用いてください。

curl -L https://www.getchef.com/chef/install.sh | sudo bash -s - -v 12.0.0

Windows版では次のリンクからこのバージョンをダウンロードできます: Chef Client 12.0.0 Windows MSI

助けを得るには

Chef 12へ簡単に移行できるような道筋をここに挙げたつもりです。もしこのバージョンを実行したことで何か問題があれば連絡してください。手助けできるように私達は準備しています。

GitHubのイシューに登録する、chefやchef-devメーリングリストにメールにて連絡してください。

Chefをよりよくするためのすべてに感謝します！

既知の問題

この節ではChef Client 11からChef Client 12へ移行する際の既知の問題についての情報を含みます。

未署名のrpmパッケージ

Chef Client 12.0.0のrpmは、うかつにも署名せずにリリースしてしまいました。この問題は、私達のパッケージ配布のエンドポイントであるomnitruckからChef Client 12をインストールすることを妨げるものではありません。しかし、内部のyumレポジトリを通してのパッケージ配布の場合はインストールを遮断します。この問題について作業中で、問題が解決されたらこの節を更新します。

lvm CookbookにおけるNoMethodError: undefined method `directory'

Chef Client 11では、Recipe DSLはProvider基本クラスに含まれていました。Chef 12ではクリーンアップのためにProvider基本クラスからこのロジックを削除してLWRPBaseに属しています。この変更のため、直接directory Resourceを非常に重要なProviderから用いているlvm Cookbookに問題を引き起こしました。directory Resourceを独自Resourceから呼び出せるようにするための回避策はProviderではなくLWRPBaseから継承することです。この変更点を反映するためにドキュメントを更新する予定です。

execute ResourceにおけるNoMethodError: undefined method'

Chef Client 11では、execute Resourceにおけるpath AttributeはProviderに尊重されず使われてもいませんでした。Chef 12ではクリーンアップのためにこれを削除しました。この変更により、execute Resourceでpath Attributeを用いていると、Chef Clientは受け付けたうえで使わないのではなくエラーを起こすようになりました。回避策は、execute ResourceでPATHを設定するためのenvironment Attributeを用いることです。

新規CTA