Puppetを使い始めたばかりです。ウォークスルーの例とチュートリアルは、Puppet の有用性と基本的なツールセットを理解するのに役立ちましたが、完全なスタックを概念化するのに苦労しています。高度なチュートリアルでさえ、何が起こる必要があるかについて明確なイメージを与えてくれなかったようです.
私が学べる Rails スタックの完全な例はありますか?
Puppetを使い始めたばかりです。ウォークスルーの例とチュートリアルは、Puppet の有用性と基本的なツールセットを理解するのに役立ちましたが、完全なスタックを概念化するのに苦労しています。高度なチュートリアルでさえ、何が起こる必要があるかについて明確なイメージを与えてくれなかったようです.
私が学べる Rails スタックの完全な例はありますか?
フル スタックの例を見つけるのは困難です。ただし、これらの特定の例の一部を管理するモジュールの例を見つけることができるはずです。問題の 1 つは、すべてのサイト固有の仮定を抽象化し、真にクロスプラットフォームであるモジュールを作成するには、多くの余分な作業が必要になる可能性があることです。
http://forge.puppetlabs.com/は、人々が共有したいモジュールの正規の場所です。クイックスキャンで、nginx、varnish、およびpostgresのモジュールが見つかりました。
基本的な設定については、 Puppet のベスト プラクティスから始めることをお勧めします。
そこから、(少なくとも)nginx、varnish、thin、postgres、memcached、redis、およびサイトモジュール(おそらくサイトにちなんで名付けられた)のモジュールが必要になります。
nodes.pp では、各システムにかなり単純な役割が割り当てられます。(「役割を含める」)
「サイト」モジュールでは、システムロールごとにサブクラスが必要になります (複数のサーバーセットがあり、セット内では基本的に互いに同一であることを意図していると想定しています.また、上記のものが複数含まれている可能性が高いと想定しています)。他の複数のモジュールまたはクラスで必要になる可能性があるもの (ロール内のサーバーのリスト、パスワードなど) のために、site::commonvariables クラス (またはそのようなもの) が必要になる場合もあります。ベスト プラクティスでは、s_role のような名前を持つ /services セカンダリ モジュール領域にこれらの site::role のものがあるようです。そのため、代わりにその命名/配置スキームに従うことをお勧めします。これらのロール クラスには、それらのロールで必要な実際のコンポーネントのクラス、呼び出し定義などが含まれます。
あなたが言及した6つのコンポーネントのそれぞれに対して、モジュールがあります。そのモジュール内に、「サーバー」および「クライアント」サブクラスのようなものが必要になる可能性があります。そして、クライアントとサーバーの両方が必要とするもの (共通ライブラリなど) のために、クライアントとサーバーに含まれる 3 番目のクラスの可能性があります。また、サーバー サブクラス内では、特定のインスタンス (仮想ホスト、データベースなど) を設定する定義です。(絶対にサーバーだけである場合は、そのレベルのサブクラス化をスキップしてください)。
たとえば、次のようになります。
コンポーネント モジュールが完全に独立した (そして再利用可能な) 状態に保たれ、ロール クラスがより多くのサイト固有の構成が行われる場所であることが最善ですが、コンポーネント モジュールにサイト固有のものが含まれていても、それで終わりではありません。