objetivo

instalar o puppetagent e integrá-lo com o puppetmaster

premissas

ter o puppetmaster instalado e rodando

ambiente

Duas VMs debian squeeze rodando em virtualbox no OSX

puppet, 192.168.56.101
puppetagent, 192.168.56.102

procedimento

instalando agente

habilite o repositório squeeze-backports e puppetlabs adicionando a linha abaixo em seu /etc/apt/sources.list

deb http://apt.puppetlabs.com/debian squeeze main
deb http://backports.debian.org/debian-backports squeeze-backports main contrib non-free

instale a chave puppetlabs

gpg --recv-key 4BD6EC30
gpg -a --export 4BD6EC30 | sudo apt-key add -

instale o puppet

aptitude install puppet

habilitando o puppet

Durante a instalação do puppet, recebemos a seguinte mensagem

puppet not configured to start, please edit /etc/default/puppet to enable

Para habilitar o puppet, edite o arquivo

root@puppetagent:~# vim /etc/default/puppet

E mude o valor da variável START para YES.

START=yes

Reinicie o puppet agent

root@puppetagent:~# invoke-rc.d puppet restart
Restarting puppet agent.

acessando puppetmaster

o agente vai procurar sempre o puppetmaster através do nome puppet ou puppet.dominio,

via dns

se possível crie um registro de DNS tipo A com o nome puppet apontando para máquina puppetmaster , se não for possível registro do tipo A, faça um registro do tipo CNAME.

via hosts

caso a configuração de DNS não seja uma opção, uma forma de resolver é inserir uma entrada no /etc/hosts

192.168.56.102 puppet puppet.dominio

isso será suficiente para o agente funcionar, coloque o ip do seu puppetmaster

via puppet.conf

se ainda não for uma opção, pode ainda editar o arquivo /etc/puppet.conf e inserir a diretiva

server=nomedoservidor

na seção [agent], mas prefira a configuração de DNS dentre as 3 opções.

primeiro contato

para fazer o primeiro contato com o puppetmaster vamos rodar o seguinte comando

puppetagent:/etc/puppet# puppet agent --test

a saída será similar a esta.

info: Creating a new SSL key for puppetagent
warning: peer certificate won't be verified in this SSL session
info: Caching certificate for ca
warning: peer certificate won't be verified in this SSL session
warning: peer certificate won't be verified in this SSL session
info: Creating a new SSL certificate request for puppetagent
info: Certificate Request fingerprint (md5): 94:69:1D:23:19:7D:C8:22:15:4E:E3:C2:71:B7:AC:07
warning: peer certificate won't be verified in this SSL session
warning: peer certificate won't be verified in this SSL session
warning: peer certificate won't be verified in this SSL session

observe que ao rodar o agent ele gerou um certificado digital e depois gerou uma requisição de assinatura do certificado e parou por ali pois ainda não está devidamente autorizado a utilizar recursos do puppetmaster.

é importante ressaltar que ele só gerou essa saída pois encontrou o servidor puppet graças ao ajuste no /etc/hosts, portanto fique atento as configurações de DNS ou do HOSTS.

entendendo o uso de certificados

a comunicação entre agente e master (cliente/servidor) é feita através de uma relação de confiança estabelecida através de certificado digital, nenhum servidor com puppetagent pode utilizar os recursos do servidor puppetmaster se este não for explicitamente autorizado.

a autorização funciona da seguinte forma:

  • ao rodar o agente pela primeira vez em um servidor com puppetagent este vai gerar uma certificado e uma requisição de assinatura de certificado.
    1. esta requisição será enviada para o servidor puppetmaster, lá deveremos verificar quais as requisições de assinatura de certificado estão pendentes, e se for o caso, assiná-las.
    2. a partir do momento que forem assinadas o servidor puppetagent estará apto a se comunicar com o servidor puppetmaster, estando então devidamente autorizado a buscar seu 'catálogo' de configurações.
    3. no servidor puppetmaster - por sua vez, você poderá declarar as configurações para o servidor com o puppetagent.

    assinando certificados

para verificar certificados com pendência de assinaturas rode o comando abaixo no puppetmaster

puppet:/etc/puppet/manifests# puppet cert --list
puppetagent (94:69:1D:23:19:7D:C8:22:15:4E:E3:C2:71:B7:AC:07)

se este for um servidor legítimo, autorizado a utilizar o puppetmaster, assine o certificado com o comando:

puppet:/etc/puppet/manifests# puppet cert –sign puppetagent

notice: Signed certificate request for puppetagent
notice: Removing file Puppet::SSL::CertificateRequest puppetagent at '/var/lib/puppet/ssl/ca/requests/puppetagent.pem'

para verificar todos servidores com puppetagent devidamente autorizados rode o comando:

puppet:/etc/puppet/manifests# puppet cert --list --all
+ puppet      (CF:AC:08:3B:32:CB:2B:CB:F7:AE:7E:27:5E:0B:7B:CD)
+ puppetagent (91:C5:E3:E9:45:21:44:60:54:A5:8D:13:4E:D9:B2:92)

para remover a autorização de um servidor rode

puppet:/etc/puppet/manifests# puppet cert --clean nomedoservidor

conferindo resultado

após assinar o certificado, autorizando o puppetagent a utilizar o puppetmaster, vamos rodar novamente o comando e avaliar a saída

puppetagent:/etc/puppet# puppet agent --test

saída

warning: peer certificate won't be verified in this SSL session

info: Caching certificate for puppetagent
info: Caching certificate_revocation_list for ca
info: Caching catalog for puppetagent
info: Applying configuration version '1337188661'
info: Creating state file /var/lib/puppet/state/state.yaml
notice: Finished catalog run in 0.04 seconds

perceba que agora ele conseguiu se comunicar com o servidor perfeitamente, apesar de não ter feito muita coisa, ainda, afinal ainda não declaramos nenhum tipo de configuração para o servidor puppetagent.

vale lembrar que além do controle de quem pode ou não usar os recursos do puppetmaster, o certificado também serve para estabelecer uma conexão segura (SSL) entre puppetagent e puppetmaster, protegendo assim toda a comunicação que ocorre entre eles.

Sei que ainda parece misterioso essa comunicação entre agent e master, então vamos detalhar um pouco essa comunicação

  • AGENT coleta informações de seu ambiente e envia para MASTER solicitando seu catálogo.
  • MASTER recebe informações do AGENT, verificando as configurações para ele e compara com o catálogo recebido.
  • MASTER compila catálogo com configurações e envia para AGENT
  • AGENT recebe catálogo compilado, faz uma QUERY e verifica o que deve ser aplicado
  • AGENT aplica as configurações de acordo com o catálogo recebido do MASTER
  • AGENT reporta estado atual com as mudanças para MASTER

Veja o gráfico abaixo retirado do site PuppetLabs para você entender melhor este processo.

empurrando uma configuração

vamos empurrar uma configuração bem simples, vamos instalar o pacote ntp e declarar que ele deve estar rodando.

para isto eu preciso declarar o node (servidor com puppet agent) e declarar uma classe com as configurações para o ntp.

vamos aprender a declarar cada uma a seguir.

declarando node

a declaração de node é bastante simples, você diz o nome da máquina e quais módulos ou classes ele deve utilizar.

node puppetagent {
	include classe
}

declarando classe

a declaração de classe deve conter o nome da classe e seus recursos, vou utilizar o recurso packages para instalar o pacote e o recurso service para orientar que o serviço deve estar sempre rodando.

class ntpd {
	package { 'ntp':
		ensure => present,
	}

	service { 'ntp':
		ensure     => running,
	}
}

site.pp

Agora precisamos juntar essas duas configurações em um arquivo chamado site.pp , o qual é o arquivo que o puppet vai buscar dentro de manifests sempre que um agent solicitar suas configurações.

vamos acessar o diretório

cd /etc/puppet/manifests

agora vamos criar um arquivo chamado site.pp

vim site.pp

e dentro dele colocar as duas configurações mencionadas acima

### declarando configuracoes de nodes (servidores com o agente)
 
node puppetagent {
	include ntpd
}
 
### declarando classe com configuracoes para ntp
 
class ntpd {
	package { 'ntp':
		ensure => present,
	}
 
	service { 'ntp':
		ensure     => running,
	}
}

bacana, agora só falta aplicar lá no servidor puppetagent

aplicando configurações

vamos rodar novamente o puppet para verificar se tem alguma configuração a ser aplicada

puppetagent:/etc/puppet/manifests# puppet agent --test
info: Caching catalog for puppetagent
info: Applying configuration version '1337190190'
notice: /Stage[main]/Ntpd/Package[ntp]/ensure: ensure changed 'purged' to 'present'
notice: Finished catalog run in 7.22 seconds

agora vamos observar, o puppetagent se conectou ao puppetmaster, informou suas configurações atuais, recebeu o catálogo do servidor, comparou e aplicou as mudanças necessárias, com isto o pacote ntp foi instalado, veja a mensagem abaixo:

notice: /Stage[main]/Ntpd/Package[ntp]/ensure: ensure changed 'purged' to 'present'
notice: Finished catalog run in 7.22 seconds

podemos verificar via dpkg se realmente foi insalado

puppetagent:~# dpkg --list|grep ntp
ii  ntp                                1:4.2.6.p2+dfsg-1+b1         Network Time Protocol daemon and utility programs

e podemos verificar via invoke se o processo está rodando, conforme declaramos

puppetagent:~# invoke-rc.d ntp status
NTP server is running.

dá para ver que a configuração declarada foi aplicada com sucesso.

modificações no ambiente

desligando o ntp

vou desligar o ntp para verificar se o puppet vai ligá-lo.

puppetagent:~# invoke-rc.d ntp stop
Stopping NTP server: ntpd.

o puppet roda por padrão a cada 30 minutos, mas vamos rodar o agente manualmente para testar seu comportamento

puppetagent:~# puppet agent --test
info: Caching catalog for puppetagent
info: Applying configuration version '1337190353'
notice: /Stage[main]/Ntpd/Service[ntp]/ensure: ensure changed 'stopped' to 'running'
notice: Finished catalog run in 0.26 seconds

bacana, o puppet viu que o serviço estava parado e como declaremos que ele deve estar sempre rodando, ele mudou o estado do serviço para 'running'.

removendo o pacote

agora vamos fazer um novo teste, vamos remover o pacote ntp e ver como puppet vai lidar com isto

puppetagent:~# aptitude purge ntp

The following packages will be REMOVED:  
  libopts25{u} ntp{p} 
0 packages upgraded, 0 newly installed, 2 to remove and 1 not upgraded.
Need to get 0 B of archives. After unpacking 1290 kB will be freed.
Do you want to continue? [Y/n/?] y
(Reading database ... 31882 files and directories currently installed.)
Removing ntp ...
Stopping NTP server: ntpd. 
Purging configuration files for ntp ...
Processing triggers for man-db ...
(Reading database ... 31848 files and directories currently installed.)
Removing libopts25 ...

após remover o pacote, vamos rodar o puppet manualmente

puppetagent:/etc/puppet# puppet agent --test  
info: Caching catalog for puppetagent
info: Applying configuration version '1337190353'
notice: /Stage[main]/Ntpd/Package[ntp]/ensure: ensure changed 'purged' to 'present'
notice: Finished catalog run in 2.62 seconds

bacana, o puppet percebeu que o pacote não está presente, e como declaramos que ele deve estar instalado e rodando, ele instalou o pacote novamente.

erros conhecidos

nao encontrou o servidor

caso não tenha sido configurado o dns, host ou puppet.conf com o endereço do servidor puppet, provavelmente vai receber este erro.

root@puppetagent:/etc/apt# puppet agent --test
err: Could not retrieve catalog from remote server: getaddrinfo: Name or service not known
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
err: Could not send report: getaddrinfo: Name or service not known

para corrigir isto veja as instruções em 'acessando o servidor'.

referências



puppet_instalando_agent_em_debian.txt · Last modified: 2012/06/01 16:01 by gutocarvalho
CC Attribution-Share Alike 4.0 International
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0