Примеры полного стека трудно найти. Однако вы должны быть в состоянии найти примеры модулей, которые управляют некоторыми из этих конкретных примеров. Одна из проблем заключается в том, что для создания модуля, который бы абстрагировал все специфичные для сайта предположения и действительно был кроссплатформенным, может потребоваться много дополнительной работы.
http://forge.puppetlabs.com/ - это каноническое расположение для модулей, которыми люди хотят поделиться. При быстром сканировании я нашел модули для nginx , лак и postgres .
Вы захотите начать с Puppet Best Practices для базовой настройки.
Оттуда вы (по крайней мере) захотите модуль для nginx, лака, thin, postgres, memcached, redis и модуля сайта (вероятно, названный в честь вашего сайта).
В вашем node.pp каждая система будет иметь довольно простое назначение для роли. («включить роль»)
В вашем модуле "site" вам понадобится подкласс для каждой системной роли (я предполагаю, что у вас будет несколько наборов серверов, и что внутри набора они должны быть в основном идентичны друг с другом. Я также предполагаю, что вы, вероятно, включили более одного из перечисленных выше). Вам также может понадобиться класс site :: commonvariables (или что-то в этом роде) для вещей (таких как списки серверов в роли, пароли и т. Д.), Которые могут вам понадобиться для нескольких других модулей или классов. Похоже, что в лучших практиках эти объекты site :: role находятся в области вторичного модуля / services с именами, более похожими на s_role, поэтому вы можете вместо этого следовать этой схеме именования / размещения. Эти классы ролей будут включать классы для фактических компонентов, которые необходимы для этих ролей, определения вызовов и т. Д.
Для каждого из 6 компонентов, которые вы упомянули, у вас будет модуль. В этом модуле вы вероятно хотите иметь что-то вроде подкласса "сервер" и "клиент". И, возможно, третий класс, включенный клиентом и сервером для вещей, необходимых обоим (общие библиотеки и т. Д.). А внутри подкласса сервера - определение, которое устанавливает конкретные экземпляры (виртуальные хосты, базы данных и т. Д.). (если это абсолютно единственный сервер, возможно, пропустите этот уровень подклассов).
Так, например:
- модуль postgres (манифесты, файлы, шаблоны и т. Д.)
- класс postgres (в init.pp): может быть, пустой класс, может быть, что нужно клиенту и серверу
- postgres :: client class: установить клиентские библиотеки postgres
- postgres :: класс сервера: установите код сервера postgres, убедитесь, что служба postgres работает, настройте ее, настройте резервные копии и т. Д.
- postgres :: server :: database define: внутри класса сервера, определение, которое принимает параметры, такие как имя базы данных, имя пользователя, пароль, создает базу данных и пользователя и предоставляет пользователю доступ к БД. Может быть, это два или три отдельных определения, в зависимости от того, как вы предпочитаете моделировать вещи.
Лучше всего, если модули компонентов остаются достаточно независимыми (и могут использоваться повторно), и ваши классы ролей - это то место, где происходит все более специфичная для сайта конфигурация, но это не конец света, если ваши модули компонентов включают некоторые специфичные для сайта вещи .