JujuはどのようにしてChefと「共存」し、自動化プロセスを「さらに一歩」進めますか？
この投稿 から、JujuがChef Serverとは異なるレイヤーにあることが明らかです。 Jujuはオーケストレーションまたはserviceレイヤーに座っており、Chefは個々のサーバーまたはconfigurationレイヤーに座っています。
CanonicalのメインJujuページの1つ では、JujuはChefやPuppetなどのツールと「共存」するように設計されており、プロセスを「さらに一歩」進めています。私はこのテーマについて過去数週間インターネットを精査しており、howの良い説明を見つけることができませんが、ChefのようなツールはJujuと共存します。
したがって、タイトルの包括的な質問を分解するには：（JujuがChefサーバーと連携することに特に関心があります）
- 「シェフで書かれた」チャームの例は何ですか？それは
chef-soloコマンドを呼び出すbashで書かれた単なるチャームですか？その場合、チャームはchef-clientコマンドを呼び出してChefサーバーと連携して動作できますか？ - ジュジュとシェフのオーバーラップはどこですか？たとえば、Apache2チャームには
config-changedフックがあり、Chefの世界ではテンプレートファイルを適用することでレシピで行われる設定変更を行います。 Jujuチャームが、Apache2サービス（クラスター）のデプロイに関するChefクックブックと連携する場合、タスクを分離できるように、「Apache2-chef」チャームを記述する必要があるように見えます。この場合、チャームストアのApache2チャームは役に立たないでしょう。 - ChefロールをJujuによってデプロイ/管理されるノード（サービスユニット）に適用し、システム管理者が特定のサーバーロールのファイアウォールルールを変更することを決定し、Chefロールでこれを行う場合、Jujuはそれらの変更を上書きしますか？
- もっと簡単に言えば、Jujuを Ironfan のようなChef Serverラッパーにできますか？
Chef Serverはhowと見なしますが、Jujuはhowを行うことができますが、whatテーブルに。サービスとマシンの実際の現在の状態を照会し、それに基づいて行動できることを意味します。 Chef Serverでこれを行うことはできません。私の目標は、Jujuの認識とサービスオーケストレーション機能をChef Serverが管理するインフラストラクチャに組み込むことです。
Chefが管理するすべてのタスク/設定情報が省略されている場合、チャームのセット全体を記述する必要があるようです。
Canonicalの誰か（Jorge Castroのような）とOpscode（A. JacobやJ. Timbermanのような）からの計量を聞きたいです。
素晴らしい質問！
tl; dr
あなたの質問をいくつかのコメントに分けたいと思います...最初に、シェフとジュジュを統合するためのいくつかの一般的なアプローチがあります：
チャームフックは、サービスユニットでソロスタイルで実行される既存のシェフレシピを使用できます（推奨）
jujuサービスユニットは、chef-node下位サービスを使用して既存のchef-serverに登録します
これらのアイデア実装されていません /シェフのためにまだテスト済みですが、人形に相当するものが存在します。
...ええと..それほど短くない答え
Chefとjujuを統合する2つのアプローチの内訳をもう少し説明します。
トップドッグとしてのジュジュ
ここでは、ジュジュがショーを実行します。 jujuが提供する最大の価値は、分散構成管理中のイベント調整です。したがって、「サービスオーケストレーション」という呼び名です。ジュジュチャームは、サービス管理を調整するときに「適切なタイミング」でジュジュによって呼び出されるフックで構成されます。これらのフックの実装はほとんどオープンです。それらはシェルスクリプト、ソースコード、パペットマニフェスト、または...シェフレシピです。
Jujuは、サービス設定の一部を次のように分割します。
「インストール」..特定のサービスをノードにインストールすることに固有のビット
「関係」..そのサービスを他のサービスに関連付けるために必要な設定のビット
フックの実装としてシェフレシピを使用する鍵はまさにこれです...使用しているレシピがこの懸念の分離を尊重していることを確認する必要があります。そうでなければ、既製のクックブックの使用を妨げるものは何もありません。開発に時間/お金を費やした既存のレシピを活用することができます。..インストール固有のものとは別に関係固有のものを呼び出すことができることを確認する必要があります。
これのいくつかの例を必要としますが、人気があると思いますb/c chefは優れたdslと優れたテンプレートツールを備えており、複雑な設定を記述するときはbashよりもはるかに使いやすいです。シンプルな設定の場合、シェフのレシピは少しやり過ぎです。そのため、この統合方法は両方の世界で最も優れています。
トップドッグとしてのシェフ
ここでのアイデアは、jujuサービスを既存のシェフサーバー管理インフラストラクチャに統合することです。これを行うには、シェフノードの従属チャームを作成する必要があります。この下位サービスはプライマリjujuサービスにアタッチされ、これらのサービスをシェフサーバーのノード（特定のロール）として効果的に登録します。潜水艦は、jujuサービスの起動中、または各サービスのライフサイクルを通じていつでも接続できます。
これはpuppet-nodeサブに非常に似ていると思います。必要なすべてのキー、ロールなどは、設定を介してchef-node従属チャームに指定されます。そこから始めます。より洗練されたアプローチは、chef-node subが接続されているプライマリサービスとchef-serverの両方に問い合わせて動的にロールを決定することですが、subのconfigでそれらを指定するよりもかなり難しいでしょう。
ご意見
可能であれば、上記の方法1をお勧めします。構成ツールのtopに調整レイヤーを配置することは、おそらく長期にわたってうまくいくでしょう。言うまでもなく、実際のインフラストラクチャは、一定の期間、特に移行中に両方のアプローチの組み合わせまたはバリエーションになる可能性があります。方法2を使用して計画された共存は、おそらく両方のツールで管理されるコンポーネントが互いにある程度直交している場合にのみ機能します。それがどのようになるかは正確にはわかりません。おそらく、jujuとchefは別々の比較的分離されたサービスを管理していますか？ jujuがプライマリサービスを管理し、chefがより多くのインフラストラクチャの側面を管理できるようにするとうまくいくのではないかと思います。ダンノそれは少し長い議論ですが:)
補足事項... jujuを使用してchef-server自体を管理することもできます。大規模で複雑な多層chef-serverインストールも可能です。私は最近シェフサーバーの魅力を見ていませんが、それが現在サービスの階層化と分離を処理していない場合、それは確かに行うことができます。
上記の両方のタイプのシェフ統合の例をもっと見たいです...しばらくの間、それは私の願い/ todoリストにありましたが、まだ達成するのに十分な優先度でバブルしていません...助けてください興味があります！
わかりました、それはまともな塊です：）...そこから始めましょう。その後のコメントブロックでさらに詳しく説明します。