2016-11-07 4 views
0

私はシェフと知り合っており、シェフゼロとナイフゼロを使用してセントラルサーバなしでワークフローを構築したいと考えています。しかし、chef-zeroは.jsonファイルのノードについての情報を格納しています。これはかなり大きく、頻繁に変更されてgitリポジトリに格納されます。リポジトリに定義を保存するのではなく、毎日サーバを再スキャンしたい - これは私たちが多くのサーバーを持っていないので、簡単に自動化できるはずです。 sshの資格情報を提供するだけで、既存の統合ノードをシェフゼロに追加するコマンドはありますか?私はknife zero bootstrap <node-ip>がトリックをすることを知っていますが、余分な収束を引き起こします。私は起こりたくありません。ナイフゼロ既存のノード発見

+0

'--no-converge'オプションを発見した人のために:悲しいことに、これはノード定義を保存しません – Etki

+0

収束回避シェフの偶像崇拝哲学(複数回実行、必要な場合にのみ行動する)に対して。だから、あなたが望むものを達成するための方法はありません。希望の状態について考えているあなたの要件/料理の見直し。あなたはシェフを何度も気にしません。(他のSCMと同じように) – Tensibai

+0

@Tensibai偶像崇拝は本当にキーシェフの面では、必ずノードの状態を取得して登録する必要はありません。 – Etki

答えて

0

全体の質問が間違った仮定に基づいていました:

  • 私はシェフのノードが解消されないと、それ自身の状態を管理すると思いました。そうではない。シェフの実行終了時にノードの状態がシリアル化され、サーバーに渡されるため、シェフの実行なしに試していたノードを再検出することはできません。サーバ属性が必要な場合は、ノードを空の実行リストに収束させることができます。実行リストはノード自体に永続化されないので、これは安全な操作でなければなりません。
  • 私は、chef-zeroが何らかの形でjsonファイルを使う以外の方法でノードの状態を管理しているとも思っていました。これは、私がjsonで直接ノードの役割を指定しようとした結果、run_listから常に再構築されているので、私の役割は当てはまりません。それは「発見」を私が必要ではないと言っているようにしています。

次のような構造は、ノードを見てシェフゼロに十分なものであり、正常に収束:

{ 
    "name": "sonarqube.srv.company.my", 
    "automatic": { 
    // automatic attributes are managed by ohai, so be ready that next 
    // chef run may use another fqdn if you haven't pinned it with 
    // any means possible 
    "fqdn": "99-199-255-99.srv.company.my" 
    }, 
    "run_list": [ 
    "role[role-1]" 
    "recipe[cookbook::recipe]" 
    ] 
} 

Gitの中でそのような定義を格納した場合、あなたは常に手元にインフラストラクチャを持って行うことができますknife converge name:sonarqube.srv.company.myいつでも、それは私のすべての必要に勝つ。私のパーソナルワークフローには、上記のようなノード仕様のmanaged-nodesというディレクトリがあり、bin/resetのbashスクリプトにnodesディレクトリを上書きします。私はそれらが適切な実行リストと属性で保存されている限り、すべてが魅力のように機能します。ただし、同様のワークフローを選択した場合は、ノードでのシェフの実行が成功していなくても、完全な属性リストを作成する必要はありません。

永続的なサーバーを持たない純粋にgitベースのシェフワークフローの必要性は、私が開示したくないいくつかの内部的な理由によって決まります。 よろしくお願いします。

すべての努力のために@天照台に行ってください。

0

あなたは基本的に自分の(悪い)シェフサーバーを作ることを説明しています。集中管理をしたいのであれば、Chef Serverを使用して時間を節約してください:)

関連する問題