Como manter site.pp com muitos nós?

Question

Eu mantenho todos os meus nós em um arquivo, site.pp - mas como eu adiciono mais e mais nós, é muito difícil mantê-los.

A diretiva de importação parece muito promissora, mas, como entendo os documentos, é necessário reiniciar o puppermaster toda vez que algo mudar. Para mim é inaceitável.

Existe alguma outra maneira de fazer isso? Em vez de usar grandes comentários para separar nós / grupos. Agora eu uso apenas rdoc.

Ficarei feliz com sugestões: -)

Minha estrutura atual de diretórios de fantoches se parece com:

• manifests / site.pp
• manifests / extdata / (para extlookup)
• modules / module1
• modules / module2
• arquivos / pubkeys ...

Eu implemente a configuração de fantoches usando o git / rsync para substituir apenas os arquivos que foram alterados.

    

Answer 1

Eu tenho um site.pp que se parece com isso:

import "nodes/*.pp"

e tem um diretório nodes/ em manifests/

Para que eu tenha um conjunto de nós em "workstations.pp" "webservers.pp" e assim por diante ...

    

Answer 2

Defina seus nós fora dos manifestos. Eu recomendaria o sucessor do extlookup, Hiera, mas realmente qualquer classificador de nó externo seria suficiente para mover os dados do nó para fora dos manifestos.

Esta é a maneira recomendada de lidar com definições de nós nos dias de hoje - do docs :

Most users in most situations should use include-like declarations and set parameter values in their external data. However, compatibility with earlier versions of Puppet may require compromises.

O Hiera está incluído no Puppet 3.0 - ele precisa ser instalado separadamente em versões mais antigas. Para configurar o Hiera para lidar com as definições do seu nó, você gostaria de fazer algo ao longo destas linhas:

site.pp (a coisa toda):

hiera_include(classes)

hiera.yaml:

:backends:
  - yaml

:hierarchy:
  - %{clientcert}
  - os-%{osfamily}
  - common

:yaml:
   :datadir: /etc/puppet/hieradata
   # A good alternative if you want different node data based on environments:
   #:datadir: /etc/puppet/environments/%{environment}/hieradata

:puppet:
   :datasource: data

Agora, o Puppet procurará /etc/puppet/hieradata para extrair dados em seus nós. Digamos que você tenha uma classe ntp desejada em tudo e uma classe apache que você deseja em um nó específico:

/etc/puppet/hieradata/common.yaml:

classes:
  - ntp

/etc/puppet/hieradata/nodename.example.com.yaml:

classes:
  - apache

Esta matriz é agregada - o nó nodename.example.com obterá a classe ntp do arquivo comum e a classe apache de seu próprio arquivo.

Hiera também lida com seus parâmetros de classe para você. Digamos que você tenha sua classe apache esperando um parâmetro port :

class apache ( $port ) {
  ...

Você também pode definir isso em seus arquivos de dados Hiera. Se você quiser que o padrão para a porta 80 ..

/etc/puppet/hieradata/common.yaml:

classes:
  - ntp

apache::port: 80

Mas você deseja substituir isso por nodename.example.com , definindo-o como 8080:

/etc/puppet/hieradata/nodename.example.com.yaml:

classes:
  - apache

apache::port: 8080

Ou, você pode usar esse os-%{osfamily} do arquivo hiera.yaml para configurações com base em fatos sobre um determinado nó - o osfamily fact neste caso.

/etc/puppet/hieradata/os-debian.yaml:

apache::package_name: apache2

/etc/puppet/hieradata/os-redhat.yaml:

apache::package_name: httpd

(observe que o comportamento de pesquisa de parâmetro é um pouco diferente se você estiver executando uma versão anterior à 3.0, veja aqui para detalhes )

Dessa forma, você pode definir classes incluídas e configurações de parâmetro / variável em diferentes escopos (todos os nós, alguns nós baseados em um fato ou um nó específico), todos em arquivos diferentes.