Chefにおける NodeとClientの考え方について #chef

自分の中で、まったくNodeとClientの関係について整理できてなかったので、ここで整理したい。

1. [前提]Chefにおける、各ファイルの考え方

大きく分けて、下記の３つだと考えている

リソース(各アプリケーションの設定などをまとめたもの)
- cookbooks
  - apacheインストール用Cookbook
  - gitインストール用Cookbook
テンプレート(サーバのあるべき姿を定義する上での共通部分の定義)
- enviroment
  - development,testなど環境によって適用すべきリソースや、設定を定義
- role
  - WEBサーバ、DBサーバなど役割によって適用すべきリソースや、設定を定義
サーバのあるべき姿を定義したもの
- node
  - 物理サーバと１対１の関係
  - roleなどのtemplateを適用し、このサーバがどのテンプレートに当てはまるかなどを定義
  - Chefによる、プロビジョニングはこのNodeファイルの定義にしたがって行われる

Chef-solo,Knife-solo環境では、上記３つを理解しているだけで特に問題なくChefを使用することができるはず。
しかし、Chef-Serverでは、そうはいかない。

新たにClinetとPermissionという考え方が出てくる

上記を踏まえた上で、NodeとClientについて見ていく。

Chef-solo環境では、Cookbook , Role , Enviroment , NodeファイルはChef Repositoryが置いてあるサーバにログインできるユーザが編集を行うことができました。

しかし、Chefサーバ環境では、サーバに直接ログインしてこれらのファイルを編集することを想定していません。

workstation(今回は説明は省きます)と呼ばれるところで、RoleやNodeファイルを編集し、ChefサーバにRestAPIのPOSTメソッドを叩くことによってファイルを更新します。

しかし、ChefサーバにアップされているNode情報を誰もが見れたり、誰でも更新できたりする状態は好ましくありません。

ここで初めてClientという考え方でてきます。Clientは、Chefサーバにアクセスすることができる[人,サーバ]を管理する仕組みです。認証の方式には、公開鍵暗号方式が使用されます。

しかし、Clientであればすべての操作が許される訳ではありません。(Nodeを消したり、編集したり)

Chefサーバでは、管理するファイル(Cookbooks,Enviroment,Node,Role)に、Permission情報を新たに、付与します。
例えば、下記のようなイメージ

Node A 、Client A,B,Cが存在したとき
Client[A]はNodeの読み込み、編集、削除ができますが、Client[B]は読み込みしかできません。

ちなみに、workstationから

$knife node create hogehoge

とすると、デフォルトでは、下記のPermissionでNode情報が作成されます

Name	Read	Update	Delete	Grant
admins	○	○	○	○
clients	○	×	×	×
users	○	○	○	×
<作成ユーザ>	○	○	○	○

この状態では、nodeのアップデートは admin,usersグループのuserとNodeを作成したユーザしか行うことができません。

もし、Nodeを使い回したいと思っている人がいたら、このPermissionの扱い方に注意しましょう
clientsグループにUpdate権限を付与しないと、エラーでこけます。

Client
- Chef-Serverを使う環境初めて必要になる考え方
- Rest-APIを叩くためのClient
- Chefサーバ上の各Object(Node,Enviroment)の操作のPerrmissionが設定される
- Clientの認証は、公開鍵暗号方式で行われる(client.pem)
Node
- サーバのあるべき姿を定義したファイル
- Chefサーバ環境では、Nodeの現在の状態も管理できることになる(Client自身がNodeファイルを更新することで）