Com o fantoche, o cliente pode pedir para ter um determinado conjunto de papéis?

Question

Eu recentemente instalei meu mestre de marionetes e meu cliente e pedi que o cliente assinasse corretamente, solicitei e apliquei alterações simples, tudo bem.

Eu tenho um número crescente de máquinas (> 100). Eles não são nomeados consistentemente (razões históricas). Eles se enquadram em um punhado de categorias (pense nisso como: dataserver_type1, dataserver_type2, webserver_type1, webserver_type2 ....). Novas instâncias desses tipos de máquinas são adicionadas semanalmente.

Eu não entendo (ainda) ou não consigo ver como posso declarar um nó "genérico" de (digamos) "dataserver_type1" que contém os módulos necessários, e definir algo no cliente puppet.conf que diz "I Sou um dataserver_type1 "sem usar o hostname / FQDN

Se eu definir o nome do nó no catálogo como (digamos) "my-data-server-type1" - o nome do host certificado - ele será ativado e funcionará. Eu sei que você pode usar padrões para nomes de host, mas como eu disse, os nomes dos meus servidores não são consistentes, e eu não posso mudá-los.

Isso parece insincero de ter que editar um arquivo e adicionar manualmente um nó para cada servidor, quando eles continuam a crescer.

Editar:

Indo mais fundo, parece que papéis podem ser o que eu quero. Mas ainda parece haver um elemento pelo qual o mestre contém uma lista de funções que um servidor nomeado específico deve fazer. Talvez o que eu esteja perguntando seja, como um cliente pode dizer "eu quero ser esse papel", sem que o servidor precise ser atualizado?

    

Answer 1

Voltando com uma solução e para futuros googlers. Obrigado a outros pela entrada.

Houve uma discussão aqui que levou a um conjunto de arquivos sugerindo uma solução .

No entanto, minha experiência limitada sugere que isso estava um pouco desatualizado em termos de localização de arquivos. No cliente, você precisa de um arquivo assim:

root@vbox1-test:/etc/puppet# cat custom_facts.yml 
servertype: webserver-type1

No servidor (puppetmaster) se você seguir os arquivos no segundo link fornecido, então o .rb funciona bem, mas o local está errado (estou usando v3.x). Tente movê-lo para:

ubuntu@puppetmaster:/etc/puppet/modules/custom/lib/facter$ ls custom_facts.rb
custom_facts.rb

Em qualquer um dos seus arquivos .pp do módulo, etc, basta adicionar algo como

...
notify { "My servertype is: ${servertype}" : }
...

Novamente, o segundo link alude ao fato de que você pode fazer uma declaração de "caso" para escolher quais módulos / manifestos são usados. Então eu posso aplicar um conjunto básico de regras para a maioria das máquinas, depois algumas personalizadas para certos tipos, sem tocar nos manifestos do servidor.

O efeito que você obtém no cliente é algo assim:

root@vbox1-test:/etc/puppet# puppet agent --test
Info: Retrieving plugin
/File[/var/lib/puppet/lib/facter]/ensure: created
/File[/var/lib/puppet/lib/facter/custom_facts.rb]/ensure: defined content as '{md5}xxxxxxxxxxxxxxxxxxxxxxx'
Info: Loading facts in /var/lib/puppet/lib/facter/custom_facts.rb
Info: Caching catalog for vbox1-test
Info: Applying configuration version '1351762428'
My servertype is: webserver-type1
/Stage[main]//Node[default]/Notify[My servertype is: webserver-type1]/message: defined 'message' as 'My servertype is: webserver-type1'
Finished catalog run in 0.05 seconds

Estou bem otimista, isso me dá o que eu quero e posso manter os manifestos livres de nomes de servidores, que são herdados e estão crescendo continuamente.

    

Answer 2

Os nós são sempre definidos centralmente, em seus manifestos ou em um classificador de nós externos (ou ambos).

Eu acho que você poderia montar um ENC que permita que os clientes especifiquem o seu papel ... mas por que você está querendo tocar cada computador para configurá-lo localmente?

Parece que você só precisa de uma organização melhor para seus manifestos de nó. Talvez alguma herança de nó para o seu sistema "papéis" para reduzir a duplicação toda vez que você fizer um novo nó, bem como alguns bons nomes de nó regex que cobrem conjuntos de nomes de sistema (como em, você pode não ser capaz de cobrir todos os servidores de web com um regex, mas coloque um no lugar que cubra a convenção de nomenclatura que você está usando para novos nós).