Muito pouco pertence ao site.pp, geralmente há um lugar melhor para isso que é mais gerenciável.
- Recursos individuais (arquivos, serviços, pacotes, entradas de cron, etc.) devem ser movidos para classes por componente / serviço que você está gerenciando. Tente dividir isso em componentes lógicos o máximo possível, por exemplo,
apache
emysql
classes em vez de uma classe de funçãolamp
. ( docs: Language: Classes ) - As classes devem ser movidas para módulos. Os módulos são uma maneira de conter classes relacionadas (por exemplo,
apache::service
comapache
), fornecendo ao Puppet uma maneira eficiente de localizar classes sem carregar todos os arquivos e de conter arquivos e modelos relacionados. Sua classe Apache pode então viver em/etc/puppetlabs/code/environments/production/modules/apache/manifests/init.pp
ou similar. ( docs: Fundamentos do módulo ) - Definições de nó e parâmetros de classe podem ser movidos para o Hiera ou um classificador de nós de nó (ENC). Usando o Hiera, você talvez usasse
hiera_include
( docs: Atribuindo classes a nós com Hiera ) para adicionar classes a nós, e dados Hiera regulares para armazenar parâmetros de classe ( docs: pesquisa automática de parâmetros . Os ENCs são scripts externos e podem consultar qualquer fonte de dados que você já tenha ou são fornecidos por outros aplicativos, como o Foreman . - Os padrões de recursos ainda podem permanecer em site.pp para aplicar a todos os nós e classes.