[和訳] ファイアウォールの背後にあるChefの動作 #opschef_ja #getchef_ja

本項は Working with Chef Behind Your Firewall (2014/10/28) の和訳です。

自己完結しているChefで管理されたインフラは構成が容易ではありませんでした。Omnibusインストーラは、クライアントでのChefの動作に必要なソフトウェアのすべてを含んでいます。いくつかのKnife設定の代替品や、独自のbootstrapテンプレートなど、NodeがChef-Clientの関連ソフトウェアをどのようにどこから取得しているかをあなたが完全に管理しているでしょう。私達がインターネットを愛しているとしても、サーバが露出する量を制限することは一般的です。本番あるいは非本番環境に対してファイアウォール経由で流入を制限することは、Chefのデプロイメント機能に影響は与えません。しかし、流出の制限はいくつかの問題を引き起こす可能性があります。

インターネットアクセスなしでのChef Clientインストール

Chefソフトウェアはhttps://www.getchef.com/download-chef-client/から、あるいはhttps://www.getchef.com/chef/install.sh経由でダウンロードできます。しかし、ホストのすべてがインターネットに対してURLリクエストが不可能であるなら、環境にchef-clientをどのようにインストールするか、いくつかの方法が用意されています。

イメージにchef-clientパッケージを追加しておく

インフラを構築するイメージにchef-clientパッケージを追加しておくのは、イメージを容易に再生成できるなら、確かによい方法です。

イメージの中にどれくらいChef関係のソフトウェアを含めておくか選択することができます。chef-clientソフトウェアだけでなく、新規の具体的なシステム全体にわたって一貫して管理するためのOrganization validatorキーやclient.rbファイルをも、システムイメージに事前に含めておくことができます。この方法はシステムのすべてが単一のOrganizationに所属しているのなら、うまく動作します。

post-installスクリプトにchef-clientを追加しておく

事前にchef-clientを含むイメージから若干下流にあるのは、システムのpost-installスクリプトにchef-clientを追加しておく方法です。Kickstartのようなツールでは、%post ディレクティブでchef-clientをインストールし、安全な位置からOrganization validatorキーを取得できます。この方法であれば、ノードが所属するChef Organizationごとに新しいOSベースイメージを作成しなくても済みます。

これら2つのシナリオのどちらでも、イメージとOrganizationキーを安全に格納しておきたいでしょう。特にvalidatorキーはChef Serverに新しいNodeを追加するための特別な権利を持っているので、きちんと守っておくべきです。chef-client CookbookはNodeがOrganizationに所属した後にvalidatorキーを削除するRecipeを含んでいます。

bootstrapオプションのカスタマイズ

chef-clientをNodeにインストールするためのより摩擦の少ない他のメカニズムとして、bootstrapオプションをカスタマイズして、あなたのレポジトリからパッケージを取得するという方法があります。

knife bootstrapサブコマンドには、デフォルトのhttps://www.getchef.com/chef/install.shコマンドを、独自の処理に置き換えることができるいくつかのオプションがあります。

一様な環境において、knife.rbでknife_bootstrap_commandを用いることで、install.shを置き換える単一の新しいコマンドを指定することができます。


knife[knife_bootstrap_command] = "yum install -y chef-client"


この設定オプションはknife bootstrapのすべての場合におけるインストールコマンドを上書きします。

もし環境に複数のターゲットOSがあるなら、templateオプションやdistroオプションが使えます。

distroオプションとtemplateオプションはお互い似ていますが、templateオプションは作成するファイルに対して任意のパスを指定できます。distroオプションは検索パスに制限があります。

templateファイルの内容はとても単純です。templateは、chef-clientソフトウェアの取得・インストール、client.rbとvalidator.pemファイルを作成するためのコマンドを含む必要があるだけです。一方、templateは、chef-client omnibusパッケージがまだサポートしていないプラットフォームに対応するようにより複雑にすることもできます。

chef-clientとChef DKパッケージはたくさんのbootstrap templateの例を含んでいます。他の例はchef github repoにもあります。

それらのtemplateのすべては、/etc/chef/ディレクトリの作成、validator.pemファイルのコピー、client.rbファイルの作成、必要なら暗号化Data Bagを使った秘密ファイルのコピーのためのたくさんの方法を含んでいます。

knife bootstrapでどれだけの独自templateを使うことのできるかには限界がありません。例えば、1つ目はrpmベースのシステム、2つ目はaptベースのシステム、3つ目はWindowsシステムといったような独自templateです。

Windowsシステムのbootstrapは、LinuxやUNIXシステムのbootstrapと多少異なります。しかし、knife windowsに含まれるbootstrapスクリプトを参考に始めるとよいでしょう。

template中のurlの値は、あなたの環境で動作するダウンロードURLに置き換えることができます。

Chef環境のライフサイクル

インターネットから隔離された環境をメンテナンスするには、システムを最新にしておくためのローカルレポジトリを多数使いたいでしょう。Chefはこのメンテナンスサイクルのあくまで1コンポーネントでしかありません。

Chefはあなたのレポジトリにミラーできる公開レポジトリをもうすぐ提供します。PackageCloudにいる私達の支持者によってホストされるこのレポジトリをどのように使えばいいか、より詳しい情報をもうすぐ提供します。そうすれば、あなたのサイトガイドラインに則って、Clientを最新の状態に維持しておけるようになります。omnibus updater CookbookはClientを最新に保っておく一つの方法です。

chef-vaultのような便利なChefアドオンは、システムにRubyGemsの追加インストールを要求します。インターネットから隔絶された環境では、オンプレミスのgemサーバをミラーしメンテナンスするいくつかの方法があります。例えばGem in a Boxについてはhttp://guides.rubygems.org/run-your-own-gem-server/を参照してください。

最後に、yumやapt Cookbookは、クライアントNodeでレポジトリの構成管理をより簡単にするためのlightweight resources and providers (LWRPs)を提供しています。

更新情報を受け取るには

Chef Server、chef-client、Chef DKなどはたくさんの異なるオープンソースソフトウェアコンポーネントを用いていますので、利用コンポーネントの規則正しいアップデートスケジュールの策定を推奨します。インフラに影響を与えるかもしれないバグレポート、機能強化、更新などを受け取るために、私達のブログを注視していてください。