Vous êtes sur la page 1sur 40

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

4Linux www.4linux.com.br

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

Gerncia de Configuraes com Puppet

4Linux www.4linux.com.br

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.

Gerncia de Configuraes com Puppet

Pgina 3

2.1 Introduo terica

4Linux www.4linux.com.br

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

Gerncia de Configuraes com Puppet

4Linux www.4linux.com.br

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);

Gerncia de Configuraes com Puppet

Pgina 5

2.1 Introduo terica

4Linux www.4linux.com.br

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

Gerncia de Configuraes com Puppet

4Linux www.4linux.com.br

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.

2.2 Tratamento de demandas


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

Gerncia de Configuraes com Puppet

Pgina 7

2.2 Tratamento de demandas

4Linux www.4linux.com.br

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

Gerncia de Configuraes com Puppet

4Linux www.4linux.com.br

2.2 Tratamento de demandas

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;

Gerncia de Configuraes com Puppet

Pgina 9

2.2 Tratamento de demandas

4Linux www.4linux.com.br

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

Gerncia de Configuraes com Puppet

4Linux www.4linux.com.br

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.

Gerncia de Configuraes com Puppet

Pgina 11

2.4 Desvantagens do modelo artesanal

4Linux www.4linux.com.br

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

Gerncia de Configuraes com Puppet

4Linux www.4linux.com.br

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;

2.5 Buscando um novo caminho


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

Gerncia de Configuraes com Puppet

Pgina 13

2.5 Buscando um novo caminho

4Linux www.4linux.com.br

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

Gerncia de Configuraes com Puppet

4Linux www.4linux.com.br

2.5 Buscando um novo caminho

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;

Gerncia de Configuraes com Puppet

Pgina 15

2.6 Conhecendo o Puppet na prtica

4Linux www.4linux.com.br

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.

2.6 Conhecendo o Puppet na prtica


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

Gerncia de Configuraes com Puppet

4Linux www.4linux.com.br

2.6 Conhecendo o Puppet na prtica

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

Gerncia de Configuraes com Puppet

Pgina 17

2.7 Plataformas suportadas

4Linux www.4linux.com.br

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

Gerncia de Configuraes com Puppet

4Linux www.4linux.com.br

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;

Gerncia de Configuraes com Puppet

Pgina 19

2.9 Projetos Internos Puppetlabs

4Linux www.4linux.com.br

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

Gerncia de Configuraes com Puppet

4Linux www.4linux.com.br

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

Gerncia de Configuraes com Puppet

Pgina 21

2.11 Camada de Abstrao

4Linux www.4linux.com.br

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

Gerncia de Configuraes com Puppet

4Linux www.4linux.com.br

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.

Gerncia de Configuraes com Puppet

Pgina 23

2.13 Mo na Massa

4Linux www.4linux.com.br

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

Gerncia de Configuraes com Puppet

4Linux www.4linux.com.br

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

Gerncia de Configuraes com Puppet

Pgina 25

2.13 Mo na Massa

4Linux www.4linux.com.br

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

Gerncia de Configuraes com Puppet

4Linux www.4linux.com.br

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

Gerncia de Configuraes com Puppet

Pgina 27

2.13 Mo na Massa

4Linux www.4linux.com.br

3 - Atualize os ndices e instale o Puppet

root@datacenter :~ # apt - get update

root@datacenter :~ # apt - get install puppet

4 - Para terminar comente a diretiva templatedir que est obsoleta nesta verso do
Puppet.

root@datacenter :~ # vim / etc / puppet / puppet . conf

[ main ]

3
4

....

5
6

# templatedir = $confdir / templates

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

Gerncia de Configuraes com Puppet

4Linux www.4linux.com.br

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

4 - Para terminar comente a diretiva templatedir que est obsoleta nesta verso do
Puppet.

root@mailserver :~ # vim / etc / puppet / puppet . conf

[ main ]

3
4

....

5
6

# templatedir = $confdir / templates

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

Gerncia de Configuraes com Puppet

Pgina 29

2.13 Mo na Massa

4Linux www.4linux.com.br

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 )

3 - Para terminar comente a diretiva templatedir que est obsoleta nesta verso do
Puppet.

root@dbpostgres :~ # vim / etc / puppet / puppet . conf

[ main ]

3
4

....

5
6

# templatedir = $confdir / templates

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

Gerncia de Configuraes com Puppet

4Linux www.4linux.com.br

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

2.14 Primeiros passos com o 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:

Gerncia de Configuraes com Puppet

Pgina 31

2.14 Primeiros passos com o Puppet

4Linux www.4linux.com.br

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

Gerncia de Configuraes com Puppet

4Linux www.4linux.com.br

2.14 Primeiros passos com o Puppet

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.

Gerncia de Configuraes com Puppet

Pgina 33

2.14 Primeiros passos com o Puppet

4Linux www.4linux.com.br

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

Gerncia de Configuraes com Puppet