Apostila Introdução A Gerência de Configurações + Instalação Do Puppet

4511
Gerncia de Configuraes com

Puppet
www.4linux.com.br
Projetos na sua empresa

com a qualidade dos treinamentos
ence
Business Intelig lx8
F
u/
.m
va
http://
BPM
http://va.mu/EuiT
Servidor Java EE
http://va.mu/FlyB
PostgreSQL
http://va.mu/EuhV
Monitoramento
http://va.mu/EukN
Virtualizao
http://va.mu/Flxl
Groupware Yj
u/FN
http://va.m
Backup
http://va.mu/Flxr
Auditoria e Anlise
http://va.mu/Flxu
Segurana
http://va.mu/Flxy
Ensino Distncia
http://va.mu/Flxc
Integrao Continua
http://va.mu/FlyD
GED - ECM
http://va.mu/Flx3
Alta Disponibilidade
http://va.mu/FNbL
Infraestrutura Web
http://va.mu/Flxi
Implantao garantida
http://va.mu/GcFv
Contedo
2 Introduo a Gerncia de Configuraes + Instalao do Puppet
2.1 Introduo terica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 Trabalho Artesanal . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2 Efeito Cascata . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.3 Ambiente no padronizado . . . . . . . . . . . . . . . . . . . . .
2.2 Tratamento de demandas . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1 Gerenciamento de usurios . . . . . . . . . . . . . . . . . . . . .
2.2.2 Gerenciamento de servios . . . . . . . . . . . . . . . . . . . . .
2.2.3 Mudanas no ambiente . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.4 Criao de novos ambientes . . . . . . . . . . . . . . . . . . . . 11
2.3 Documentao e planejamento . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Desvantagens do modelo artesanal . . . . . . . . . . . . . . . . . . . . 12
2.5 Buscando um novo caminho . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5.1 Entendendo o que a Gerncia de Configuraes . . . . . . . . 14
2.5.2 Automao e padronizao . . . . . . . . . . . . . . . . . . . . . 15
2.5.3 Vantagens associadas a Gerncia de Configuraes . . . . . . . 15
2.6 Conhecendo o Puppet na prtica . . . . . . . . . . . . . . . . . . . . . . 16
2.6.1 Caractersticas do Puppet . . . . . . . . . . . . . . . . . . . . . . 16
2.6.2 Funcionalidades do Puppet . . . . . . . . . . . . . . . . . . . . . 17
2.7 Plataformas suportadas . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.7.1 Sistemas Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.7.2 Sistemas BSD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.7.3 Sistemas Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.7.4 Sistemas Windows . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.8 Puppetlabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.9 Projetos Internos Puppetlabs . . . . . . . . . . . . . . . . . . . . . . . . 20
Contedo
4Linux www.4linux.com.br
2.10 Sintaxe Declarativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.11 Camada de Abstrao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.12 Idempotncia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.13 Mo na Massa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.13.1 Infraestrutura do Curso . . . . . . . . . . . . . . . . . . . . . . . 24
2.13.2 Instalando o Puppet na distribuio Debian . . . . . . . . . . . . 26
2.13.3 Instalando o Puppet na distribuio Ubuntu . . . . . . . . . . . . 27
2.13.4 Instalando o Puppet na distribuio CentOS . . . . . . . . . . . . 28
2.13.5 Instalando o Puppet na distribuio OpenSuSE . . . . . . . . . . 29
2.13.6 Instalando o Puppet em Ambiente Unix - Oracle Solaris . . . . . 30
2.14 Primeiros passos com o Puppet . . . . . . . . . . . . . . . . . . . . . . 31
2.14.1 Puppet Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.14.2 Puppet Man . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Pgina ii
Gerncia de Configuraes com Puppet
Captulo 2
Introduo a Gerncia de
Configuraes + Instalao do
Puppet
2.1 Introduo terica

Hoje em dia com a crescente adoo das tecnologias de virtualizao e computao
em nuvem, nosso ambiente de servidores tende a crescer rapidamente, normalmente
uma nova demanda gera uma nova instncia ou uma nova mquina virtual, clientes
cada vez mais exigentes desejam ambientes dedicados e independentes, com isto,
um parque em que antes possua algumas mquinas fsicas, pode se tornar um
parque com dezenas, centenas ou milhares de instncias e mquinas virtuais, e
tudo isto pode acontecer em poucos meses.
Sabemos que criar mquinas virtuais relativamente fcil em qualquer hypervisor,
e da mesma forma, criar instncias em sistemas CLOUD IaaS tambm, so necessrios poucos minutos para executar essa demanda em ambas tecnologias. No
entanto, atualmente o grande desafio dos sysadmins encontrar a melhor forma de
administrar centenas ou milhares de servidores aps sua criao.
2.1 Introduo terica
Para um melhor entendimento, vamos imaginar que em poucos meses o parque de

servidores que uma equipe de sysadmins administra saltou de dezenas para centenas de servidores virtuais. A partir deste ponto, vamos avaliar os principais aspectos
e os desafios de se fazer a administrao destes servidores utilizando metodologias
tradicionais.
2.1.1 Trabalho Artesanal

A administrao tradicional um processo praticamente artesanal, normalmente
utiliza-se acesso secure shell (SSH) e shellscript para resolver demandas cotidianas, porm, imagine fazer isto em um parque hbrido com diversas distribuies linux
em arquiteturas com 32 e 64 bits, imagine tambm que estas distribuies linux esto em diferentes verses (Debian e Centos 5/6) e que temos ainda servidores com
sistemas operacionais UNIX (Solaris, AIX, HPUX) e at algumas distribuies BSD
(FreeBSD, OpenBSD).
Neste tipo de cenrio a complexidade do ambiente aumenta rapidamente, e com
isso, o sysadmin precisa encontrar a melhor forma de administrar este parque de
servidores.
A administrao artesanal de ambientes tem em suas principais caractersticas tarefas que so executadas de forma repetitiva. Executar tais tarefas em ambientes
pequenos bastante fcil, porm administrar ambientes hbridos em pleno crescimento uma tarefa bem mais complexa, principalmente se voc deseja e precisa
mant-lo padronizado.
Veja alguns exemplos de demandas comuns que devem ser aplicadas em praticamente todos os servidores de sua rede:
Adicionar, remover ou trocar senha de usurios;
Instalar, remover e atualizar pacotes;
Pgina 2
2.1 Introduo terica
Criar e modificar arquivos de configurao;

Iniciar e manter servios rodando mesmo aps um boot;
Veja que em um ambiente como este, provavelmente os scripts utilizados no vo
conseguir prever as excees e tratar todas as diferenas entre os diferentes sistemas operacionais, com isto, a equipe de sysadmins ter de investir muitas horas
na manuteno desses scripts e provavelmente ter de criar scripts para cada tipo
de sistema operacional. Isto ser cansativo e demorado, por esta razo natural
que algumas equipes partam para administrao usando SSH em Loop com auxlio
de programas como o ClusterSSH, deixando ento os scripts de lado. Neste caso,
a equipe provavelmente vai separar os servidores em grupos ou contextos como
RHEL, Debian, FreeBSD, OpenBSD, a partir da acessar e executar comandos em
Loop.
No entanto mesmo utilizando SSH em Loop esse tipo de demanda leva tempo
e nem sempre o resultado obtido o mesmo o que fora planejado pela equipe de
sysadmins, normalmente vrios ajustes precisam ser executados no meio do caminho para que a equipe consiga atingir o objetivo desejado fazendo o tratamento
de excees, as vezes at preciso alocar vrios analistas de foma simultnea para
resolver este tipo de tarefa repetitiva dentro do prazo estipulado.
Em algum momento a equipe que administra este parque vai perceber que as tcnicas que antes os ajudavam na resoluo de demandas, no funcionam a medida
que mais e mais servidores so criados. Isto significa que eles no conseguem dar
vazo as demandas e provavelmente vo se tornar o gargalo de muitos processos
na empresa em que trabalham.
Avaliando este cenrio, podemos dizer que a administrao manual no escala, e
alm de no escalar, gera uma grande sobrecarga em cima de sua equipe e principalmente nos membros mais experientes. Isto tende a aumentar o custo necessrio
para manter seu ambiente, afinal sobrecarga significa hora extra a noite, de madrugada, nos finais de semana e feriados, com isto, voc ser forado a ampliar sua
equipe e seus custos para dar conta das tarefas, tentando assim cumprir suas
metas.
Pgina 3
2.1 Introduo terica
2.1.2 Efeito Cascata
Quando uma metodologia ou tcnica de administrao de configurao no escalvel, voc comea a perceber algumas coisas, dentre elas:
Voc percebe que fica mais difcil encontrar problemas em seu parque;
Voc percebe que no to simples manter os sistemas funcionando;
Voc percebe que quase impossvel manter todos os seus sistemas operacionais Padronizados;
Voc percebe que sua produtividade diminui a medida que o ambiente cresce;
Voc percebe que a medida que sua produtividade diminui, voc no consegue mais documentar, planejar e entregar o que seu cliente solicita no tempo
acordado;
Trabalhar fora de expediente se torna a regra e no a exceo;
Sua equipe est sempre exausta e desmotivada;
No h tempo para se preocupar com segurana e performance;
Voc pode levar dias ou duas semanas para instalar um novo programa ou
servio em todas as instncias/VMs de seu parque (ex.: Um novo agente de
monitoramento).
Estas so as percepes mais comuns em ambientes que ainda utilizam metologia

artesanal de administrao de servidores e servios.
Pgina 4
2.1 Introduo terica
2.1.3 Ambiente no padronizado

Para entendermos melhor e aprofundarmos o que padronizao, qual sua importncia e os impactos em um ambiente de TI, vamos abordar alguns exemplos prticos.
Focando exclusivamente em ambientes Linux e Unix, no ter um parque padronizado
significa que voc no tem como garantir que as configuraes fundamentais de
seus sistemas estejam devidamente ajustadas em todos os seus servidores, dentre
as configuraes mais comuns podemos citar:
Configuraes de DNS;
Configuraes de Rota;
Configuraes de Hosts;
Configurao do Hostname;
Contas de usurios e privilgios (passwd/group/shadow/sudo);
Configurao padro de repositrios de pacotes (yum/apt/ports);
Configurao para atualizao de pacotes;
Conjunto de pacotes de monitoramento;
Conjunto de pacotes de administrao (htop, ccze, less, mtr,traceroute, nmap,
vim, iptraf, iperf, etc. . . );
Configuraes de editores padro do sistema (VIM/NANO/EMACS);
Configuraes de perfil de usurios (.bashrc, .bash_profile);
Pgina 5
2.1 Introduo terica
Configuraes de perfil de ambientes (profile, enviroment, bashrc, skel);

Configuraes de DATA/HORA (NTP);
Configuraes de MTA Local e Aliases (envio de mensagens de erros/alertas
para algum lugar);
Configuraes de rotinas no CRON;
Configuraes de LOGROTATE;
Configuraes de SYSLOG/RSYSLOG;
Configuraes de Firewall (Filtro de Pacotes)
Tuning de Kernel;
Hardening do OS;
Algumas destas configuraes no parecem ser questes to srias, mas se avaliarmos com mais cuidado, vamos entender que so na verdade questes crticas. Veja
abaixo as causas e os efeitos em 4 exemplos:
1. Se a sua data/hora esto erradas, isto pode gerar uma parada de alguns sistemas
ou mesmo arruinar uma tentativa de auditoria nos logs de um ou vrios servidores,
alm disto pode gerar dados incorretos em coletas de informaes e grficos de
monitoramento.
2. Um DNS configurado de forma errada pode afetar o funcionamento de um sistema
e dos servios que dependem de resoluo de DNS;
3. Um repositrio mal configurado pode instalar pacotes no homologados, em verses experimentais, isto pode afetar aplicaes em produo e causar grandes incidentes;
Pgina 6
2.2 Tratamento de demandas
4. Um logrotate mal configurado pode fazer seu disco encher rapidamente parando
aplicaes e servios de seus clientes;
Veja que a falta de um ambiente padronizado pode ser uma grande dor de cabea
para a equipe de Sysadmins, e normalmente por negligncia ou devido a sobrecarga,
comum ter parte dos servidores padronizados e parte fora dos mnimos padres.

Ns j falamos de padronizao e agora vamos entender o que so demandas repetitivas, para isto, vamos utilizar alguns exemplos bastante comuns.
2.2.1 Gerenciamento de usurios

Talvez um dos problemas mais bsicos que afligem Sysadmins que administram
grandes parques seja a gesto de contas de usurios nestes servidores.
Imagine que voc tenha um parque com 450 Servidores, agora vamos supor que no
incio da semana sua equipe recebe um novo administrador de sistemas.
Pense no trabalho que voc vai ter para criar o usurio do novo colaborador em todos
os servidores do parque, para isto voc precisa de pelo menos 5 passos, so eles:
Acessar um servidor via SSH
Se tornar root
Criar o usurio
Setar senha temporria
Pgina 7
Setar privilgios no SUDO

Para executar a criao do novo usurio em todos os servidores sero necessrias
2.250 aes repetitivas.
Se voc gastar 5 minutos por servidor isso dar um total de 2250 minutos ou 37.5
horas de trabalho repetitivo, desgastante e contnuo.
Alm disto, o novo Sysadmin precisar teoricamente acessar 450 servidores
para trocar sua senha.
Isto certeza de muito trabalho, no entanto, sabemos que as coisas no acontecem
desta forma, o mais comum criar o usurio do novo colaborador sob demanda nos
servidores em que ele precisa de acesso, conforme os problemas e as necessidades
vo surgindo durante o expediente de trabalho.
Outra coisa muito comum que encontramos em ambientes como este so contas de
colaboradores que j saram da empresa h muito tempo, estas contas alm de existirem podem e normalmente esto ativas, algo que um grave risco de segurana.
Normalmente estas contas ainda existem pois da mesma forma que difcil criar,
igualmente difcil e trabalhoso remov-las mesmo se formos usar SSH em Loop.
A parte da troca de senhas cai no mesmo problema, as vezes as senhas dos Syadmins so aquelas temporrias como mudar123, e uma troca de senha em 450
mquinas virtualmente invivel e desmotiva qualquer iniciativa ou voluntrio para
faz-lo.
claro que pode podemos configurar autenticao LDAP para os servidores LINUX,
mesmo assim voc vai ter que configurar arquivos referentes a PAM/NSSWITCH/NSSLDAP/LDAP em todos os 450 servidores.
E mesmo que voc tenha previsto esta configurao na IMAGEM padro dos servidores LINUX, se por ventura alguma configurao do LDAP muda, voc ter cerca
de 450 servidores para executar mudanas, e nestes casos as vezes s precisamos
ajustar uma nica linha com o IP de um novo servidor ou uma BASEDN LDAP.
Pgina 8
importante lembrar que apesar do uso de autenticao LDAP, caso o backend de

autenticao saia do ar, ser sempre necessrio ter um usurio coringa local
para fazer a administrao emergencial, nestes casos se for preciso trocar a senha
deste usurio coringa, voc passar pela mesma dor de cabea, seja o usurio root
ou seja outro usurio genrico (sysadmin/suporte).
Veja que invivel e cansativo administrar contas de usurios desta forma em um
parque com estas dimenses.
2.2.2 Gerenciamento de servios

A configurao de servios outro processo muito comum, dentre os mais comuns
temos o OpenLDAP, SAMBA, Apache (HTTPd), MYSQL, POSTGRESQL, ProFTPd
(FTP), POSTFIX (SMTP), CYRUS (IMAP/POP), dentre outros.
Se pedirmos para 2 Sysadmins instalarem qualquer um destes servios, teremos
procedimentos diferentes e ser extremante difcil entender e rastrear como a demanda foi atendida, quais foram os pacotes instalados, quais foram as dependncias
atendidas, quais foram os arquivos criados, alterados, modificados, se h alguma rotina no cron, se h algum script no init, se o script est configurado em algum runlevel
diferenciado, ou mesmo saber se est tudo pronto para rodar em produo.
Se formos replicar a instalao e a configurao do servio para outra mquina,
teremos de copiar arquivos, normalmente fazendo um SCP/RSYNC e isto vai nos
gerar um terceiro distinto processo de instalao e configurao do mesmo
servio.
Veja que no h como garantir um padro trabalhando deste jeito. Logo podemos
entender que configurar servios desta forma resulta em:
Dificuldade para identificar como o servio foi instalado;
Dificuldade para avaliar quais arquivos foram criados, modificados ou alterados;
Pgina 9
Dificuldade para replicar a configurao para outra mquina;

Falta de padronizao nas configuraes do mesmo servio em servidores diferentes em nosso parque;
Falta de documentao do processo de instalao e configurao do servio;
2.2.3 Mudanas no ambiente

Agora vamos complicar um pouco mais, imagine que a equipe de monitoramento
iniciou um projeto que visa substituir a atual ferramenta de monitoramento. Este
projeto prev a instalao do agente Zabbix em todos os 450 servidores do seu
parque, alm disto no podem esquecer de remover o agente antigo (NAGIOS) e as
suas configuraes.
O processo de instalao em um CentOS consiste em pelo menos 10 passos, so
eles:
Acessar o servidor via SSH
Adicionar um repositrio YUM
Atualizar ndices do YUM
Instalar o pacote zabbix-agent
Remover o arquivo /etc/zabbix/zabbix_agent.conf
Editar o arquivo /etc/zabbix/zabbix_agentd.conf
Modificar o contedo do arquivo /etc/zabbix/zabbix_agentd.conf
Reiniciar o processo zabbix-agent
Pgina 10
2.3 Documentao e planejamento
Remover o pacote nagios

Remover os traos de arquivos de configurao do nagios no sistema
So 4.500 aes que devem ser executadas em 450 servidores, levando em conta
que voc gaste 10 minutos por servidor, sero 4500 minutos ou 75 horas de trabalho
repetitivo, desgastante e contnuo para terminar esta demanda.
Veja que voc vai dedicar cerca de 75 horas de um Sysadmin para executar uma
tarefa repetitiva, e isto pode inclusive desmotivar o profissional aumentando a rotatividade de sua equipe.
2.2.4 Criao de novos ambientes

Eventualmente necessrio reinstalar um servidor ou mesmo criar servidor com as
mesmas caractersticas, este tipo de demanda bastante comum, e o tempo investido para realizar esta tarefa na administrao artesanal varia conforme a complexidade dos servios que devero ser instalados. Este tempo tambm depende do
conhecimento do profissional que executar a instalao, portanto, isto pode durar
horas, dias ou semanas para ser concludo, principalmente se o profissional especializado naquele tipo de sistema ou servio no estiver disponvel para ser alocado
para esta demanda.
2.3 Documentao e planejamento

Essa dupla provavelmente o principal problema de muitas organizaes de TI. comum infelizmente encontrar parques imensos com quase nada documentado,
locais onde mudanas no so planejadas e alteraes no so documentadas, podemos dizer inclusive que este tipo receita cria o que chamamos de ambientes caticos.
Pgina 11
2.4 Desvantagens do modelo artesanal
No caso de trabalhar em um ambiente deste tipo, voc vai ter que estudar o servio, os arquivos de configurao e mapear todo o ambiente afim de entender como
tudo funciona, s assim poder planejar e executar algum tipo de manuteno minimizando os riscos de sua mudana gerar um incidente nos servios e sistemas
envolvidos.
O principal problema que as vezes precisamos de vrios meses para entender
como funcionam certos ambientes, principalmente se acabamos de chegar nestes
locais caticos.
Se houvesse uma documentao bem-feita, seria muito mais simples planejar e executar manutenes neste tipo de local, porm, j vimos que em ambientes com
administrao artesanal muito difcil sobrar tempo para documentar ou planejar
mudanas uma vez que as equipes responsveis esto sempre sobrecarregadas
executando tarefas repetitivas.
Alm destas dificuldades, muito raro encontrar um Sysadmin ou mesmo gestores
que gostem ou que consigam compreender plenamente a importncia de se elaborar
uma boa documentao, algo que reflita as configuraes de seus sistemas ou servios, os processos e os procedimentos envolvidos em todo o ambiente produtivo.
Sem documentao e sem planejamento, a qualidade do que entregue e a qualidade do servio que produziu esta entrega sempre questionvel, afinal, no h
como saber como aquilo foi realmente executado e principalmente quanto tempo vai
ficar no ar.
2.4 Desvantagens do modelo artesanal

Falta de padronizao de seu ambiente;
Documentao inexpressiva ou inexistente.
Pgina 12
2.5 Buscando um novo caminho
Falta de planejamento para execuo de demandas;

Desconhecimento dos riscos envolvidos em mudanas;
Alto ndice de falhas humanas;
Re-trabalho;
Baixo ndice de disponibilidade de servios oferecidos;
Demora na aplicao de mudanas;
Demora na correo de problemas;
Equipe desmotivada;
Atividades repetitivas e desgastantes;
Equipe sobrecarregada;
Alto custo com horas extras;
Equipe com credibilidade baixa perante clientes e gestores;

A boa notcia que existe uma soluo que se bem aplicada poder tornar
seu ambiente confivel e sua administrao mais simples e eficiente, esta soluo
se chama Puppet.
O Puppet uma ferramenta de nova gerao que implementa modernos conceitos de Gerncia de Configurao com o objetivo de garantir a integridade e o pleno
Pgina 13
funcionamento de seus ambientes, sistemas e servios, fazendo isto de forma automatizada, centralizada e gil.
2.5.1 Entendendo o que a Gerncia de Configuraes
A gerncia de configuraes crtica para ambientes que esto crescendo ou que

sejam de natureza complexa e heterogenia, atravs dela que podemos trabalhar
provisionamento, automatizao, gerncia de mudanas, manipulao de configuraes e alm disto ao implant-la possvel iniciar tambm um processo sadio de
documentao dos ambientes envolvidos alm do planejamento de mudanas.
Hoje na prtica conseguimos identificar que a maioria dos incidentes em um

ambiente ocorre pela falta de gesto dos processos e principalmente por falta de
procedimentos claros de administrao. Ao analisar estes incidentes de forma crtica,
vamos descobrir que eles ocorrem em sua maioria devido a erro humano.
As vezes um Sysadmin instala um pacote em um servidor e nem imagina que isto

pode causar impacto em outra aplicao devido a dependncias que por ventura
podem remover ou desconfigurar algum arquivo de configurao de outro pacote
ou servio que esteja rodando em produo nesta mesma mquina. Este exemplo
muito comum e acontece em muitas empresas que ainda no tem processos e
procedimentos bem definidos.
Entenda que se este cliente utilizasse alguma ferramenta de gerncia de configuraes, o pacote removido seria reinstalado e os arquivos de configurao modificados
seriam corrigidos, o servio continuaria rodando, minimizando o downtime e o impacto do incidente que foi gerado pelo Sysadmin desatento.
Pgina 14
2.5.2 Automao e padronizao

A partir do momento em que comeamos a falar de Gerncia de Configuraes estamos falando tambm de padronizao e automatizao, estes trs conceitos andam
juntos e se amparam, no existe padronizao sem gerncia ou automao sem
padronizao.
Ao trabalhar com ambientes grandes e complexos, sejam ambientes virtualizados ou
computao em nuvem, voc tem que automatizar, do contrrio voc no conseguir
dar vazo as demandas e to pouco manter seu ambiente integro e disponvel.
2.5.3 Vantagens associadas a Gerncia de Configuraes

Temos certamente algumas vantagens ao trabalharmos com gerncia de configurao via Puppet, so elas:
Padronizao do seu parque;
Distribuio centralizada das configuraes;
Controle das configuraes em seus servidores;
Controle dos servios rodando em seus servidores;
Rastreamento das mudanas em seus servidores;
Histrico de todo o clico de vida de uma VM ou Instncia Gerenciada;
Documentao instantnea a partir da construo das configuraes;
Maior segurana e controle das aplicaes em produo;
Pgina 15
2.6 Conhecendo o Puppet na prtica
Facilidades para distribuir novas configuraes para todo o parque de forma

rpida, eficiente e centralizada;
Agilidade na criao de novos servidores;
Agilidade na configurao de servios em servidores existentes;
Utilizando o Puppet como tecnologia de gerncia de configuraes, conseguimos diminuir sensivelmente o tempo de mudanas em diversos projetos.
Mudanas como o exemplo do Zabbix que demandariam cerca de 75 horas contnuas de trabalho e retrabalho foram executadas em poucos minutos no mesmo
parque de 450 servidores.

O Puppet um framework Open Source que oferece recursos e ferramentas para
implantar um modelo nico de gerncia de configuraes em seu ambiente. Ele
funciona localmente ou em rede e pode gerenciar sistemas e servios em diferentes
plataformas.
2.6.1 Caractersticas do Puppet

Foi escrito em Ruby
extensvel em Ruby
Funciona em modo local/autnomo ou em rede
Em modo cliente e servidor usa API REST
Pgina 16
Em modo cliente e servidor prov comunicao segura usando SSL

Oferece camada de abstrao de recursos (RAL)
Idempotente
Oferece linguagem declarativa para expressar configuraes (DSL)
Projeto open-source sob Licena Apache
Cdigo fonte est disponvel no Github
2.6.2 Funcionalidades do Puppet

Dentre as principais funcionalidades do Puppet podemos citar:
Fatos
Manifests
Resource Types
Parmetros
Meta-parmetros
Variveis, Expresses, Condies, Casos e Seletores
Funes
Classes
Templates
Pgina 17
2.7 Plataformas suportadas
Definies
Mdulos
2.7 Plataformas suportadas

Atualmente o Puppet consegue gerenciar 19 tipos de sistemas operacionais.
2.7.1 Sistemas Linux

Red Hat Enterprise Linux, version 4 ou superior
CentOS, version 4 ou superior
Scientific Linux, version 4 ou superior
Oracle Linux, version 4 ou superior
Debian, version 5 (Lenny) ou superior
Ubuntu, version 8.04 LTS ou superior
Fedora, version 15 ou superior
SUSE Linux Enterprise Server, version 11 ou superior
Gentoo Linux
Mandriva Corporate Server 4
ArchLinux
Pgina 18
2.8 Puppetlabs
2.7.2 Sistemas BSD

FreeBSD 4.7 ou superior
OpenBSD 4.1 ou superior
2.7.3 Sistemas Unix

Mac OS X 10.5 (Leopard) e superior
Oracle Solaris 10 ou superior
AIX 5.3 ou superior
HP-UX
2.7.4 Sistemas Windows

Windows Server 2003 and 2008 (Puppet verso 2.7.6 e superior)
Windows 7 (Puppet verso 2.7.6 e superior)
2.8 Puppetlabs
Fundada em 2005 por Luke Kaines (criador do Puppet);
Oferece suporte corporativo e verso enterprise do Puppet;
Pgina 19
2.9 Projetos Internos Puppetlabs
Mantm uma equipe de desenvolvimento para a verso open source e enterprise;

Mantm toda a documentao da verso enterprise e open source;
Oferece eventos CamptoCamp e PuppetConf anualmente para entusiastas;
Mantm um repositrio de mdulos chamados Puppetforge com mais de 500
mdulos prontos para uso;
Oferece programa de afiliados para comercializar o Puppet Enterprise, treinamentos e consultoria de implantao.
No decorrer de nossos estudos entenderemos o que e como funciona cada um
destes recursos e funcionalidades.
2.9 Projetos Internos Puppetlabs

Puppet
Facter
Puppet Dashboard
Puppet Enterprise
PuppetDB
Hiera
Razor
Pgina 20
2.10 Sintaxe Declarativa
Mcollective
2.10 Sintaxe Declarativa

No puppet utilizamos uma linguagem declarativa com sintaxe simples e prtica para
declarar quais as configuraes cada node (servidor) gerenciado pelo Puppet deve
ter. A sintaxe natural para sysadmins e no programao, algumas partes da
sintaxe se aproxima muito de linguagens de script como bash script principalmente
no tratamento de excees usando expresses condicionais.
2.11 Camada de Abstrao

Podemos dizer que o Puppet composto por um conjunto de recursos (resources)
e provedores (providers), so atravs destes recursos que construiremos nossas
configuraes.
Um usurio pode ser considerado um recurso, um arquivo pode ser considerado
um recurso, um pacote pode ser considerado um recurso, um servio que est rodando pode ser considerado um recurso, uma rotina do cron pode ser considerada
um recurso, um alias de correio pode ser considerado um recurso, e at mesmo a
execuo de um comando pode ser considerado um recurso para o Puppet.
Cada recurso em sua essncia similar a uma classe com seus atributos. Um arquivo por exemplo, tem um caminho no filesystem (path), um dono (owner), um grupo
grupo dono (group) e permisses (mode), j um usurio tem nome (username), identificador do usurio (uid), identificador de grupo (gid), tipo de interpretador de comandos (shell) e diretrio pessoal (home).
Observe que temos recursos com contextos similares, portanto pela lgica poderamos agrup-los por tipos, indo alm, podemos observar que os atributos de alguns
Pgina 21
2.11 Camada de Abstrao
tipos so conceitualmente idnticos em alguns sistemas operacionais, tais como UID

ou PATH, e mesmo em implementaes diferentes seu funcionamento e objetivo no
muda, com isto, podemos entender que a descrio de um recurso no Puppet sofre
uma abstrao quanto a sua forma de implementao. Essas duas caractersticas
(agrupar e abstrair) formam no Puppet o que podemos chamar de camada de abstrao de recursos (Resource Abstraction Layer) ou RAL.
No Puppet voc no precisa se preocupar com a camada mais baixa de execuo de
comandos, voc simplesmente fala para ele Instale um pacote e o puppet vai verificar qual o sistema operacional, quais os gerenciadores de pacotes disponveis e
vai ento instalar o pacote para voc. Em outros sistemas de gerncia de configurao normalmente teramos que nos preocupar com isto e declarar de forma explcita
o comando, graas ao RAL isso no necessrio no Puppet.
O RAL divide recursos em resource types (tipos de recursos) e providers (provedores
dos recursos), com isto o Puppet nos permite descrever nossas configuraes de
uma forma abrangente, possibilitando que tais configuraes sejam aplicadas em
praticamente qualquer sistema operacional.
O Puppet usa o RAL tanto para ler quanto para modificar o estado dos recursos em
um sistema.
No caso da modificao do estado de um recurso, o Puppet o faz da seguinte
forma:
1. verifica o estado atual de um recurso usando o RAL;
2. compara os dados coletados (estado atual) com o estado declarado para o
recurso;
3. aplica mudanas necessrias no ambiente para que o estado do recurso
reflita o que foi declarado para ele;
Pode parecer complicado mas no , vamos dar um exemplo simples, imagine que
voc deseja instalar o pacote HTOP em dois servidores, um deles um Debian o ou-
Pgina 22
2.12 Idempotncia
tro um CentOS, no Debian usaramos o comando aptitude para instalar um pacote, j

no CentOS usaramos o comando yum, tanto aptitude quanto yum so gerenciadores de pacotes, no entanto, cada um funciona de um jeito, porm, graas ao RAL no
precisamos nos preocupar com isto, via Puppet ns apenas dizemos que queremos
instalar o HTOP e o Puppet far o resto para ns usando as ferramentas que estiverem disponveis em cada sistema operacional, isso a abstrao do como fazer,
ns s dizemos o que fazer.
2.12 Idempotncia
Em matemtica e cincia da computao, a idempotncia a propriedade em que
algumas operaes que podem ser aplicadas vrias vezes sem que o valor do resultado se altere aps a aplicao inicial. No Puppet isto significa que voc obtm
o mesmo resultado com a mesma configurao, no importa quantas vezes voc as
execute em um servidor.
No caso do pacote HTOP se rodarmos a configurao do Puppet que manda instalar
tal pacote, isto no significa que o Puppet vai rodar 10 vezes o comando aptitude
install htop, na verdade ele vai verificar se o pacote est instalado, se estiver ele no
vai fazer nada, se no estiver ele vai instalar. Neste caso especfico na primeira vez
ele instala e nas prximas 9 vezes ele no far nada pois o sistema j tem o pacote,
logo o que foi declarado igual a situao atual do sistema, e isto no vai mudar
mesmo que voc rode a configurao centenas de vezes.
2.13 Mo na Massa
Agora que j estudamos e entendemos o que administrao artesanal de servidores e servios, gerncia de configuraes, Puppet e suas caractersticas, vamos
aprofundar o entendimento desta ferramenta de automao.
Pgina 23
2.13 Mo na Massa
Separamos os principais e mais importantes recursos para apresent-los de forma

prtica com exerccios que sero executados durante o treinamento. Cada recurso
apresentado ter uma descrio, apresentao, exemplos e dicas de aplicao.
A melhor forma de aprender a utilizar o Puppet praticar, por isso, vamos colocar a
mo na massa a partir de agora.
2.13.1 Infraestrutura do Curso

Para ministrar este curso, foi criada uma infraestrutura utilizando o VirtualBox como
gerenciador das mquinas virtuais como mostra a figura abaixo:
Pgina 24
2.13 Mo na Massa
Para estes estudos vamos utilizar 13 mquinas virtuais, so elas:

Grupo: Puppet Configuration Manager
Help Desk Support Debian 7
Puppet Master Ubuntu 12.04
Puppet Dashboard Ubuntu 12.04
Grupo: Environment 1 - Production
Firewall Debian 7
Gateway CentOS 6
DMZ Server Debian 7
Datacenter Ubuntu 12.04
Mail Server Debian 7
Web Server CentOS 6
Grupo: Environment 2 - Development
Windows Server Windows Server 2008 R2
Unix Server Oracle Solaris 11.2
Grupo: Environment 3 - Testing
Zabbix Server Ubuntu 12.04
Pgina 25
2.13 Mo na Massa
DB Postgres OpenSUSE 13.1

Sugerimos o uso do VirtualBox para importao destas VMs, prefira sempre a arquitetura 64 bits.
imprescindvel que todas as VMs sejam importadas e estejam prontas para iniciarmos o prximo passo.
2.13.2 Instalando o Puppet na distribuio Debian

Considerando que estamos trabalhando com Debian Wheezy, siga os passos abaixo
para instalar o Puppet utilizando o repositrio oficial da Puppetlabs.
Executar na mquina Firewall
1 - Faa o download do pacote puppetlabs-release.
root@firewall :~ # wget http :// apt . puppetlabs . com / puppetlabs - release wheezy . deb
2 - Em seguida instale o pacote.
root@firewall :~ # dpkg -i puppetlabs - release - wheezy . deb
3 - Atualize os ndices e instale o Puppet.
root@firewall :~ # apt - get update
root@firewall :~ # apt - get install puppet
Pgina 26
2.13 Mo na Massa
4 - Para terminar comente a diretiva templatedir que est obsoleta nesta verso do
Puppet.
root@firewall :~ # vim / etc / puppet / puppet . conf
[ main ]
3
4
....
5
6
# templatedir = $confdir / templates
Repita a instalao do Puppet nas mquinas DMZ Server e Web Server, que
utilizam a distribuio Debian!
2.13.3 Instalando o Puppet na distribuio Ubuntu

Considerando que estamos trabalhando com Ubuntu verso 12.04 (Precise), siga os
passos abaixo para instalar o Puppet utilizando o repositrio oficial da Puppetlabs.
Executar na mquina Datacenter
1 - Faa o download do pacote puppetlabs-release
root@datacenter :~ # wget http :// apt . puppetlabs . com / puppetlabs - release

- precise . deb
2 - Em seguida instale o pacote
root@datacenter :~ # dpkg -i puppetlabs - release - precise . deb
Pgina 27
2.13 Mo na Massa
3 - Atualize os ndices e instale o Puppet
root@datacenter :~ # apt - get update
root@datacenter :~ # apt - get install puppet
Puppet.
root@datacenter :~ # vim / etc / puppet / puppet . conf
[ main ]
3
4
....
5
6
Repita a instalao do Puppet na mquina Zabbix Server que utiliza a distribuio Ubuntu!
2.13.4 Instalando o Puppet na distribuio CentOS

Considerando que estamos trabalhando com CentOS verso 6, siga os passos abaixo
para instalar o Puppet utilizando o repositrio oficial da Puppetlabs.
Executar na mquina Mail Server
1 - Faa o download do pacote puppetlabs-release
root@mailserver :~ # wget http :// yum . puppetlabs . com / puppetlabs - release

- el -6. noarch . rpm
Pgina 28
2.13 Mo na Massa
2 - Em seguida instale o pacote
root@mailserver :~ # rpm - ivh puppetlabs - release - el -6. noarch . rpm
3 - E para terminar instale o Puppet
root@mailserver :~ # yum install puppet
Puppet.
root@mailserver :~ # vim / etc / puppet / puppet . conf
[ main ]
3
4
....
5
6
Repita a instalao do Puppet na mquina Gateway que utiliza a distribuio

CentOS!
2.13.5 Instalando o Puppet na distribuio OpenSuSE

Considerando que estamos trabalhando com OpenSuSE verso 13.1, siga os passos
abaixo para instalar o Puppet utilizando o repositrio oficial da Puppetlabs.
Executar na mquina DB Postgres
Pgina 29
2.13 Mo na Massa
1 - Adicione o repositrio do Puppet para OpenSuSE.
root@dbpostgres :~ # zypper ar -f http :// download . opensuse . org /

repositories / systemsmanagement :/ puppet / openSUSE_13 .1 Puppet Repository
2 - Em seguida instale o Puppet
root@dbpostgres :~ # zypper install puppet
Voc quer rejeitar a chave , confiar temporariamente ou confiar

sempre ? [r/t/s /? exibe todas as op es ] ( r ) : s ( Enter )
Puppet.
root@dbpostgres :~ # vim / etc / puppet / puppet . conf
[ main ]
3
4
....
5
6
2.13.6 Instalando o Puppet em Ambiente Unix - Oracle Solaris

Siga os passos abaixo para instalar o Puppet disponvel no Oracle Solaris 11.2.
Executar na mquina Unix Server
1 - Logue com o usurio aluno e alterne para o usurio root.
Pgina 30
2.14 Primeiros passos com o Puppet
aluno@unixserver :~ $ su -
2 - Em seguida instale o Puppet
root@unixserver :~ # pkg install puppet
3 - Verifique a instalao do Puppet
root@unixserver :~ # pkg info -r puppet

Agora que o Puppet esta instalado vamos conhecer algumas opes do comando
puppet
Executar na mquina Firewall
1 - Primeiro vamos confirmar a instalao do Puppet atravs do seguinte comando:
root@firewall :~ # puppet agent -- configprint confdir
/ etc / puppet
O resultado indica que o Puppet esta instalado e seus arquivos de configurao esto
localizados no diretrio /etc/puppet
2 - Um outro comando que podemos executar descobrir se o Puppet armazenou o
FQDN da maquina:
Pgina 31
root@firewall :~ # puppet agent -- configprint certname
firewall . dexter . com . br
O resultado indica que o FQDN firewall.dexter.com.br sera usado no certificado

para comunicao com o Puppet Master.
3 - Outras opes que podem ser exploradas:
vardir
rundir
ssldir
ca_server
server
2.14.1 Puppet Help

O prprio Puppet fornece ajuda rpida, manuais e documentao para consultar
comandos, parmetros e flags. Para fornece ajuda rpida execute o seguinte comando
root@firewall :~ # puppet help
2
3
Available subcommands :
4
5
agent
The puppet agent daemon
apply
Apply Puppet manifests locally
ca
Local Puppet Certificate Authority management .
catalog
Compile , save , view , and convert catalogs .
cert
Manage certificates and requests
certificate
Provide access to the CA for certificate
10
management .
Pgina 32
11
certificate_request
12
certificate_revocation_list
Manage certificate requests .

Manage the list of revoked certificates
.
13
config
Interact with Puppet s configuration options .
14
describe
Display help about resource types
15
device
Manage remote network devices
16
doc
Generate Puppet documentation and references
17
facts
Retrieve and store facts .
18
file
Retrieve and store files in a filebucket
19
filebucket
Store and retrieve files in a filebucket
20
help
Display Puppet help .
21
inspect
Send an inspection report
22
instrumentation_data
Manage instrumentation listener accumulated
data .
23
instrumentation_listener
24
instrumentation_probe
25
key
Create , save , and remove certificate keys .
26
kick
Remotely control puppet agent
27
man
Display Puppet manual pages .
28
master
The puppet master daemon
29
module
Creates , installs and searches for modules on the
Manage instrumentation listeners .
Manage instrumentation probes .
Puppet Forge .
30
node
View and manage node definitions .
31
parser
Interact directly with the parser .
32
plugin
Interact with the Puppet plugin system .
33
queue
Queuing daemon for asynchronous storeconfigs
34
report
Create , display , and submit reports .
35
resource
The resource abstraction layer shell
36
resource_type
View classes , defined resource types , and nodes
from all manifests .

37
secret_agent
Mimics puppet agent .
38
status
View puppet server status .
O comando exibe uma lista de todos os subcomandos com uma rpida descrio.
Pgina 33
Caso queira exibir ajuda somente do subcomando apply use:
root@firewall :~ # puppet help apply
2.14.2 Puppet Man

O Puppet possui um comando prprio para exibir manuais dos subcomandos do
help:
root@firewall :~ # puppet man apply
Para maiores informaes use o comando man puppet-man
Pgina 34

Apostila Introdução A Gerência de Configurações + Instalação Do Puppet

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Apostila Introdução A Gerência de Configurações + Instalação Do Puppet

Uploaded by

Copyright:

Available Formats

4511

Gerncia de Configuraes com

Projetos na sua empresa

2.1 Introduo terica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1.1 Trabalho Artesanal . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1.2 Efeito Cascata . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1.3 Ambiente no padronizado . . . . . . . . . . . . . . . . . . . . .

2.2 Tratamento de demandas . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2.1 Gerenciamento de usurios . . . . . . . . . . . . . . . . . . . . .

2.2.2 Gerenciamento de servios . . . . . . . . . . . . . . . . . . . . .

2.2.3 Mudanas no ambiente . . . . . . . . . . . . . . . . . . . . . . . 10

2.10 Sintaxe Declarativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Gerncia de Configuraes com Puppet

2.1 Introduo terica

2.1 Introduo terica

Para um melhor entendimento, vamos imaginar que em poucos meses o parque de

2.1.1 Trabalho Artesanal

Gerncia de Configuraes com Puppet

2.1 Introduo terica

Criar e modificar arquivos de configurao;

Gerncia de Configuraes com Puppet

2.1 Introduo terica

2.1.2 Efeito Cascata

Estas so as percepes mais comuns em ambientes que ainda utilizam metologia

Gerncia de Configuraes com Puppet

2.1 Introduo terica

2.1.3 Ambiente no padronizado

Gerncia de Configuraes com Puppet

2.1 Introduo terica

Configuraes de perfil de ambientes (profile, enviroment, bashrc, skel);

Gerncia de Configuraes com Puppet

2.2 Tratamento de demandas

2.2 Tratamento de demandas

2.2.1 Gerenciamento de usurios

Gerncia de Configuraes com Puppet

2.2 Tratamento de demandas

Setar privilgios no SUDO

Gerncia de Configuraes com Puppet

2.2 Tratamento de demandas

importante lembrar que apesar do uso de autenticao LDAP, caso o backend de

2.2.2 Gerenciamento de servios

Gerncia de Configuraes com Puppet

2.2 Tratamento de demandas

Dificuldade para replicar a configurao para outra mquina;

2.2.3 Mudanas no ambiente

Gerncia de Configuraes com Puppet

2.3 Documentao e planejamento

Remover o pacote nagios

2.2.4 Criao de novos ambientes

2.3 Documentao e planejamento

Gerncia de Configuraes com Puppet

2.4 Desvantagens do modelo artesanal

2.4 Desvantagens do modelo artesanal

Gerncia de Configuraes com Puppet

2.5 Buscando um novo caminho

Falta de planejamento para execuo de demandas;

2.5 Buscando um novo caminho

Gerncia de Configuraes com Puppet

2.5 Buscando um novo caminho

2.5.1 Entendendo o que a Gerncia de Configuraes

A gerncia de configuraes crtica para ambientes que esto crescendo ou que

Hoje na prtica conseguimos identificar que a maioria dos incidentes em um

As vezes um Sysadmin instala um pacote em um servidor e nem imagina que isto