4511

Gerência de Configurações com

Puppet

www.4linux.com.br
 Projetos na sua empresa
com a qualidade dos treinamentos

ence GED - ECM

Business Intelig lx8 BPM Servidor Java EE http://va.mu/Flx3
va.m u/ F http://va.mu/EuiT
http:// http://va.mu/FlyB

Integração Continua PostgreSQL Monitoramento Alta Disponibilidade

http://va.mu/FlyD http://va.mu/EuhV http://va.mu/EukN http://va.mu/FNbL

Virtualização Groupware Yj Backup Infraestrutura Web

http://va.mu/Flxl u/FN http://va.mu/Flxr http://va.mu/Flxi
http://va.m

Auditoria e Análise Segurança Ensino à Distância Implantação garantida

http://va.mu/Flxu http://va.mu/Flxy http://va.mu/Flxc http://va.mu/GcFv
Conteúdo

2 Introdução a Gerência de Configurações + Instalação do Puppet 1

2.1 Introdução teórica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2.1.1 Trabalho Artesanal . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1.2 Efeito Cascata . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.3 Ambiente não padronizado . . . . . . . . . . . . . . . . . . . . . 5
2.2 Tratamento de demandas . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1 Gerenciamento de usuários . . . . . . . . . . . . . . . . . . . . . 7
2.2.2 Gerenciamento de serviços . . . . . . . . . . . . . . . . . . . . . 9
2.2.3 Mudanças no ambiente . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.4 Criação de novos ambientes . . . . . . . . . . . . . . . . . . . . 11
2.3 Documentação e planejamento . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Desvantagens do modelo artesanal . . . . . . . . . . . . . . . . . . . . 12
2.5 Buscando um novo caminho . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5.1 Entendendo o que é a Gerência de Configurações . . . . . . . . 14
2.5.2 Automação e padronização . . . . . . . . . . . . . . . . . . . . . 15
2.5.3 Vantagens associadas a Gerência de Configurações . . . . . . . 15
2.6 Conhecendo o Puppet na prática . . . . . . . . . . . . . . . . . . . . . . 16
2.6.1 Características 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

i
Conteúdo 4Linux – www.4linux.com.br

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

2.11 Camada de Abstração . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.12 Idempotência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.13 Mão na Massa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.13.1 Infraestrutura do Curso . . . . . . . . . . . . . . . . . . . . . . . 24
2.13.2 Instalando o Puppet na distribuição Debian . . . . . . . . . . . . 26
2.13.3 Instalando o Puppet na distribuição Ubuntu . . . . . . . . . . . . 27
2.13.4 Instalando o Puppet na distribuição CentOS . . . . . . . . . . . . 28
2.13.5 Instalando o Puppet na distribuição 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

Página ii Gerência de Configurações com Puppet

Capítulo 2

Introdução a Gerência de
Configurações + Instalação do
Puppet

2.1 Introdução teórica

Hoje em dia com a crescente adoção das tecnologias de virtualização e computação

em nuvem, nosso ambiente de servidores tende a crescer rapidamente, normalmente
uma nova demanda gera uma nova instância ou uma nova máquina virtual, clientes
cada vez mais exigentes desejam ambientes dedicados e independentes, com isto,
um parque em que antes possuía algumas máquinas físicas, pode se tornar um
parque com dezenas, centenas ou milhares de instâncias e máquinas virtuais, e
tudo isto pode acontecer em poucos meses.

Sabemos que criar máquinas virtuais é relativamente fácil em qualquer hypervisor,

e da mesma forma, criar instâncias em sistemas CLOUD IaaS também, são ne-
cessários 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 após sua criação.

1
2.1 Introdução teórica 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 cente-
nas de servidores virtuais. A partir deste ponto, vamos avaliar os principais aspectos
e os desafios de se fazer a administração destes servidores utilizando metodologias
tradicionais.

2.1.1 Trabalho Artesanal

A administração tradicional é um processo praticamente artesanal, normalmente

utiliza-se acesso secure shell (SSH) e shellscript para resolver demandas cotidia-
nas, porém, imagine fazer isto em um parque híbrido com diversas distribuições linux
em arquiteturas com 32 e 64 bits, imagine também que estas distribuições linux es-
tão em diferentes versões (Debian e Centos 5/6) e que temos ainda servidores com
sistemas operacionais UNIX (Solaris, AIX, HPUX) e até algumas distribuições BSD
(FreeBSD, OpenBSD).

Neste tipo de cenário a complexidade do ambiente aumenta rapidamente, e com

isso, o sysadmin precisa encontrar a melhor forma de administrar este parque de
servidores.

A administração artesanal de ambientes tem em suas principais características ta-

refas que são executadas de forma repetitiva. Executar tais tarefas em ambientes
pequenos é bastante fácil, porém administrar ambientes híbridos em pleno cresci-
mento é 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 pratica-
mente todos os servidores de sua rede:

• Adicionar, remover ou trocar senha de usuários;

• Instalar, remover e atualizar pacotes;

Página 2 Gerência de Configurações com Puppet

4Linux – www.4linux.com.br 2.1 Introdução teórica

• Criar e modificar arquivos de configuração;

• Iniciar e manter serviços rodando – mesmo após um boot;

Veja que em um ambiente como este, provavelmente os scripts utilizados não vão
conseguir prever as exceções e tratar todas as diferenças entre os diferentes sis-
temas operacionais, com isto, a equipe de sysadmins terá de investir muitas horas
na manutenção desses scripts e provavelmente terá de criar scripts para cada tipo
de sistema operacional. Isto será cansativo e demorado, por esta razão é natural
que algumas equipes partam para administração usando SSH em Loop com auxílio
de programas como o ClusterSSH, deixando então 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 vários ajustes precisam ser executados no meio do cami-
nho para que a equipe consiga atingir o objetivo desejado — fazendo o tratamento
de exceções, as vezes é até preciso alocar vários analistas de foma simultânea para
resolver este tipo de tarefa repetitiva dentro do prazo estipulado.

Em algum momento a equipe que administra este parque vai perceber que as téc-
nicas que antes os ajudavam na resolução de demandas, não funcionam a medida
que mais e mais servidores são criados. Isto significa que eles não conseguem dar
vazão as demandas e provavelmente vão se tornar o gargalo de muitos processos
na empresa em que trabalham.

Avaliando este cenário, podemos dizer que a administração manual não escala, e
além de não escalar, gera uma grande sobrecarga em cima de sua equipe e princi-
palmente nos membros mais experientes. Isto tende a aumentar o custo necessário
para manter seu ambiente, afinal sobrecarga significa hora extra a noite, de madru-
gada, nos finais de semana e feriados, com isto, você será forçado a ampliar sua
equipe — e seus custos — para dar conta das tarefas, tentando assim cumprir suas
metas.

Gerência de Configurações com Puppet Página 3

2.1 Introdução teórica 4Linux – www.4linux.com.br

2.1.2 Efeito Cascata

Quando uma metodologia ou técnica de administração de configuração não é esca-

lável, você começa a perceber algumas coisas, dentre elas:

• Você percebe que fica mais difícil encontrar problemas em seu parque;

• Você percebe que não é tão simples manter os sistemas funcionando;

• Você percebe que é quase impossível manter todos os seus sistemas operaci-
onais “Padronizados”;

• Você percebe que sua produtividade diminui a medida que o ambiente cresce;

• Você percebe que a medida que sua produtividade diminui, você não conse-
gue mais documentar, planejar e entregar o que seu cliente solicita no tempo
acordado;

• Trabalhar fora de expediente se torna a regra e não a exceção;

• Sua equipe está sempre exausta e desmotivada;

• Não há tempo para se preocupar com segurança e performance;

• Você pode levar dias ou duas semanas para instalar um novo programa ou
serviço em todas as instâncias/VM’s de seu parque (ex.: Um novo agente de
monitoramento).

Estas são as percepções mais comuns em ambientes que ainda utilizam metologia
artesanal de administração de servidores e serviços.

Página 4 Gerência de Configurações com Puppet

4Linux – www.4linux.com.br 2.1 Introdução teórica

2.1.3 Ambiente não padronizado

Para entendermos melhor e aprofundarmos o que é padronização, qual sua impor-

tância e os impactos em um ambiente de TI, vamos abordar alguns exemplos práti-
cos.

Focando exclusivamente em ambientes Linux e Unix, não ter um parque padronizado

significa que você não tem como garantir que as configurações fundamentais de
seus sistemas estejam devidamente ajustadas em todos os seus servidores, dentre
as configurações mais comuns podemos citar:

• Configurações de DNS;

• Configurações de Rota;

• Configurações de Hosts;

• Configuração do Hostname;

• Contas de usuários e privilégios (passwd/group/shadow/sudo);

• Configuração padrão de repositórios de pacotes (yum/apt/ports);

• Configuração para atualização de pacotes;

• Conjunto de pacotes de monitoramento;

• Conjunto de pacotes de administração (htop, ccze, less, mtr,traceroute, nmap,

vim, iptraf, iperf, etc. . . );

• Configurações de editores padrão do sistema (VIM/NANO/EMACS);

• Configurações de perfil de usuários (.bashrc, .bash_profile);

Gerência de Configurações com Puppet Página 5

2.1 Introdução teórica 4Linux – www.4linux.com.br

• Configurações de perfil de ambientes (profile, enviroment, bashrc, skel);

• Configurações de DATA/HORA (NTP);

• Configurações de MTA Local e Aliases (envio de mensagens de erros/alertas

para algum lugar);

• Configurações de rotinas no CRON;

• Configurações de LOGROTATE;

• Configurações de SYSLOG/RSYSLOG;

• Configurações de Firewall (Filtro de Pacotes)

• Tuning de Kernel;

• Hardening do OS;

Algumas destas configurações não parecem ser questões tão sérias, mas se avaliar-
mos com mais cuidado, vamos entender que são na verdade questões críticas. Veja
abaixo as causas e os efeitos em 4 exemplos:

1. Se a sua data/hora estão erradas, isto pode gerar uma parada de alguns sistemas
ou mesmo arruinar uma tentativa de auditoria nos logs de um ou vários servidores,
além disto pode gerar dados incorretos em coletas de informações e gráficos de
monitoramento.

2. Um DNS configurado de forma errada pode afetar o funcionamento de um sistema

e dos serviços que dependem de resolução de DNS;

3. Um repositório mal configurado pode instalar pacotes não homologados, em ver-

sões experimentais, isto pode afetar aplicações em produção e causar grandes inci-
dentes;

Página 6 Gerência de Configurações com Puppet

4Linux – www.4linux.com.br 2.2 Tratamento de demandas

4. Um logrotate mal configurado pode fazer seu disco encher rapidamente parando
aplicações e serviços de seus clientes;

Veja que a falta de um ambiente padronizado pode ser uma grande dor de cabeça
para a equipe de Sysadmins, e normalmente por negligência ou devido a sobrecarga,
é comum ter parte dos servidores padronizados e parte fora dos mínimos padrões.

2.2 Tratamento de demandas

Nós já falamos de padronização e agora vamos entender o que são demandas repe-
titivas, para isto, vamos utilizar alguns exemplos bastante comuns.

2.2.1 Gerenciamento de usuários

Talvez um dos problemas mais básicos que afligem Sysadmins que administram
grandes parques seja a gestão de contas de usuários nestes servidores.

Imagine que você tenha um parque com 450 Servidores, agora vamos supor que no
início da semana sua equipe recebe um novo administrador de sistemas.

Pense no trabalho que você vai ter para criar o usuário do novo colaborador em todos
os servidores do parque, para isto você precisa de pelo menos 5 passos, são eles:

• Acessar um servidor via SSH

• Se tornar root

• Criar o usuário

• Setar senha temporária

Gerência de Configurações com Puppet Página 7

2.2 Tratamento de demandas 4Linux – www.4linux.com.br

• Setar privilégios no SUDO

Para executar a criação do novo usuário em todos os servidores serão necessárias

2.250 ações repetitivas.

Se você gastar 5 minutos por servidor isso dará um total de 2250 minutos ou 37.5
horas de trabalho repetitivo, desgastante e contínuo.

Além disto, o novo Sysadmin precisará — teoricamente — acessar 450 servidores

para trocar sua senha.

Isto é certeza de muito trabalho, no entanto, sabemos que as coisas não acontecem
desta forma, o mais comum é criar o usuário do novo colaborador sob demanda nos
servidores em que ele precisa de acesso, conforme os problemas e as necessidades
vão surgindo durante o expediente de trabalho.

Outra coisa muito comum que encontramos em ambientes como este são contas de
colaboradores que já saíram da empresa há muito tempo, estas contas além de exis-
tirem podem e normalmente estão ativas, algo que é um grave risco de segurança.
Normalmente estas contas ainda existem pois da mesma forma que é difícil criar, é
igualmente difícil 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 Syad-
mins são aquelas temporárias como “mudar123”, e uma troca de senha em 450
máquinas é virtualmente inviável e desmotiva qualquer iniciativa ou voluntário para
fazê-lo.

É claro que pode podemos configurar autenticação LDAP para os servidores LINUX,
mesmo assim você vai ter que configurar arquivos referentes a PAM/NSSWITCH/NS-
SLDAP/LDAP em todos os 450 servidores.

E mesmo que você tenha previsto esta configuração na IMAGEM padrão dos servi-
dores LINUX, se por ventura alguma configuração do LDAP muda, você terá cerca
de 450 servidores para executar mudanças, e nestes casos as vezes só precisamos
ajustar uma única linha com o IP de um novo servidor ou uma BASEDN LDAP.

Página 8 Gerência de Configurações com Puppet

4Linux – www.4linux.com.br 2.2 Tratamento de demandas

É importante lembrar que apesar do uso de autenticação LDAP, caso o backend de

autenticação saia do ar, será sempre necessário ter um usuário coringa — local —
para fazer a administração emergencial, nestes casos se for preciso trocar a senha
deste usuário coringa, você passará pela mesma dor de cabeça, seja o usuário root
ou seja outro usuário genérico (sysadmin/suporte).

Veja que é inviável e cansativo administrar contas de usuários desta forma em um

parque com estas dimensões.

2.2.2 Gerenciamento de serviços

A configuração de serviços é 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 serviços, teremos

procedimentos diferentes e será extremante difícil entender e rastrear como a de-
manda foi atendida, quais foram os pacotes instalados, quais foram as dependências
atendidas, quais foram os arquivos criados, alterados, modificados, se há alguma ro-
tina 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 produção.

Se formos replicar a instalação e a configuração do serviço para outra máquina,

teremos de copiar arquivos, normalmente fazendo um SCP/RSYNC e isto vai nos
gerar um terceiro — distinto — processo de instalação e configuração do mesmo
serviço.

Veja que não há como garantir um padrão trabalhando deste jeito. Logo podemos
entender que configurar serviços desta forma resulta em:

• Dificuldade para identificar como o serviço foi instalado;

• Dificuldade para avaliar quais arquivos foram criados, modificados ou alterados;

Gerência de Configurações com Puppet Página 9

2.2 Tratamento de demandas 4Linux – www.4linux.com.br

• Dificuldade para replicar a configuração para outra máquina;

• Falta de padronização nas configurações do mesmo serviço em servidores di-

ferentes em nosso parque;

• Falta de documentação do processo de instalação e configuração do serviço;

2.2.3 Mudanças 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 instalação do agente Zabbix em todos os 450 servidores do seu
parque, além disto não podem esquecer de remover o agente antigo (NAGIOS) e as
suas configurações.

O processo de instalação em um CentOS consiste em pelo menos 10 passos, são

eles:

• Acessar o servidor via SSH

• Adicionar um repositório 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 conteúdo do arquivo /etc/zabbix/zabbix_agentd.conf

• Reiniciar o processo zabbix-agent

Página 10 Gerência de Configurações com Puppet

4Linux – www.4linux.com.br 2.3 Documentação e planejamento

• Remover o pacote nagios

• Remover os traços de arquivos de configuração do nagios no sistema

São 4.500 ações que devem ser executadas em 450 servidores, levando em conta
que você gaste 10 minutos por servidor, serão 4500 minutos ou 75 horas de trabalho
repetitivo, desgastante e contínuo 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 rotati-
vidade de sua equipe.

2.2.4 Criação de novos ambientes

Eventualmente é necessário reinstalar um servidor ou mesmo criar servidor com as

mesmas características, este tipo de demanda é bastante comum, e o tempo inves-
tido para realizar esta tarefa na administração artesanal varia conforme a comple-
xidade dos serviços que deverão ser instalados. Este tempo também depende do
conhecimento do profissional que executará a instalação, portanto, isto pode durar
horas, dias ou semanas para ser concluído, principalmente se o profissional especi-
alizado naquele tipo de sistema ou serviço não estiver disponível para ser alocado
para esta demanda.

2.3 Documentação e planejamento

Essa dupla é provavelmente o principal problema de muitas organizações de TI. É co-

mum — infelizmente — encontrar parques imensos com quase nada documentado,
locais onde mudanças não são planejadas e alterações não são documentadas, po-
demos dizer inclusive que este tipo receita cria o que chamamos de ambientes caó-
ticos.

Gerência de Configurações com Puppet Página 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 ser-
viço, os arquivos de configuração e mapear todo o ambiente afim de entender como
tudo funciona, só assim poderá planejar e executar algum tipo de manutenção mi-
nimizando os riscos de sua mudança gerar um incidente nos serviços e sistemas
envolvidos.

O principal problema é que as vezes precisamos de vários meses para entender

como funcionam certos ambientes, principalmente se acabamos de chegar nestes
locais caóticos.

Se houvesse uma documentação bem-feita, seria muito mais simples planejar e exe-
cutar manutenções neste tipo de local, porém, já vimos que em ambientes com
administração artesanal é muito difícil sobrar tempo para documentar ou planejar
mudanças uma vez que as equipes responsáveis estão sempre sobrecarregadas
executando tarefas repetitivas.

Além destas dificuldades, é muito raro encontrar um Sysadmin ou mesmo gestores

que gostem ou que consigam compreender plenamente a importância de se elaborar
uma boa documentação, algo que reflita as configurações de seus sistemas ou ser-
viços, os processos e os procedimentos envolvidos em todo o ambiente produtivo.

Sem documentação e sem planejamento, a qualidade do que é entregue e a qua-

lidade do serviço que produziu esta entrega é sempre questionável, afinal, não há
como saber como aquilo foi realmente executado e principalmente quanto tempo vai
ficar no ar.

2.4 Desvantagens do modelo artesanal

• Falta de padronização de seu ambiente;

• Documentação inexpressiva ou inexistente.

Página 12 Gerência de Configurações com Puppet

4Linux – www.4linux.com.br 2.5 Buscando um novo caminho

• Falta de planejamento para execução de demandas;

• Desconhecimento dos riscos envolvidos em mudanças;

• Alto índice de falhas humanas;

• Re-trabalho;

• Baixo índice de disponibilidade de serviços oferecidos;

• Demora na aplicação de mudanças;

• Demora na correção 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 notícia é que existe uma solução que — se bem aplicada — poderá tornar
seu ambiente confiável e sua administração mais simples e eficiente, esta solução
se chama Puppet.

O Puppet é uma ferramenta de nova geração que implementa modernos concei-

tos de Gerência de Configuração com o objetivo de garantir a integridade e o pleno

Gerência de Configurações com Puppet Página 13

2.5 Buscando um novo caminho 4Linux – www.4linux.com.br

funcionamento de seus ambientes, sistemas e serviços, fazendo isto de forma auto-

matizada, centralizada e ágil.

2.5.1 Entendendo o que é a Gerência de Configurações

A gerência de configurações é crítica para ambientes que estão crescendo ou que

sejam de natureza complexa e heterogenia, é através dela que podemos trabalhar
provisionamento, automatização, gerência de mudanças, manipulação de configura-
ções e além disto ao implantá-la é possível iniciar também um processo sadio de
documentação dos ambientes envolvidos além do planejamento de mudanças.

Hoje — na prática — conseguimos identificar que a maioria dos incidentes em um

ambiente ocorre pela falta de gestão dos processos e principalmente por falta de
procedimentos claros de administração. Ao analisar estes incidentes de forma crítica,
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 aplicação devido a dependências que por ventura
podem remover ou desconfigurar algum arquivo de configuração de outro pacote
ou serviço que esteja rodando em produção nesta mesma máquina. Este exemplo
é muito comum e acontece em muitas empresas que ainda não tem processos e
procedimentos bem definidos.

Entenda que se este cliente utilizasse alguma ferramenta de gerência de configura-

ções, o pacote removido seria reinstalado e os arquivos de configuração modificados
seriam corrigidos, o serviço continuaria rodando, minimizando o downtime e o im-
pacto do incidente que foi gerado pelo Sysadmin desatento.

Página 14 Gerência de Configurações com Puppet

4Linux – www.4linux.com.br 2.5 Buscando um novo caminho

2.5.2 Automação e padronização

A partir do momento em que começamos a falar de Gerência de Configurações esta-

mos falando também de padronização e automatização, estes três conceitos andam
juntos e se amparam, não existe padronização sem gerência ou automação sem
padronização.

Ao trabalhar com ambientes grandes e complexos, sejam ambientes virtualizados ou

computação em nuvem, você tem que automatizar, do contrário você não conseguirá
dar vazão as demandas e tão pouco manter seu ambiente integro e disponível.

2.5.3 Vantagens associadas a Gerência de Configurações

Temos certamente algumas vantagens ao trabalharmos com gerência de configura-

ção via Puppet, são elas:

• Padronização do seu parque;

• Distribuição centralizada das configurações;

• Controle das configurações em seus servidores;

• Controle dos serviços rodando em seus servidores;

• Rastreamento das mudanças em seus servidores;

• Histórico de todo o clico de vida de uma VM ou Instância Gerenciada;

• Documentação instantânea a partir da construção das configurações;

• Maior segurança e controle das aplicações em produção;

Gerência de Configurações com Puppet Página 15

2.6 Conhecendo o Puppet na prática 4Linux – www.4linux.com.br

• Facilidades para distribuir novas configurações para todo o parque de forma

rápida, eficiente e centralizada;

• Agilidade na criação de novos servidores;

• Agilidade na configuração de serviços em servidores existentes;

Utilizando o Puppet como tecnologia de gerência de configurações, conse-

guimos diminuir sensivelmente o tempo de mudanças em diversos projetos.
Mudanças como o exemplo do Zabbix que demandariam cerca de 75 horas contí-
nuas de trabalho — e retrabalho — foram executadas em poucos minutos no mesmo
parque de 450 servidores.

2.6 Conhecendo o Puppet na prática

O Puppet é um framework Open Source que oferece recursos e ferramentas para

implantar um modelo único de gerência de configurações em seu ambiente. Ele
funciona localmente ou em rede e pode gerenciar sistemas e serviços em diferentes
plataformas.

2.6.1 Características do Puppet

• Foi escrito em Ruby

• É extensível em Ruby

• Funciona em modo local/autônomo ou em rede

• Em modo cliente e servidor usa API REST

Página 16 Gerência de Configurações com Puppet

4Linux – www.4linux.com.br 2.6 Conhecendo o Puppet na prática

• Em modo cliente e servidor provê comunicação segura usando SSL

• Oferece camada de abstração de recursos (RAL)

• É Idempotente

• Oferece linguagem declarativa para expressar configurações (DSL)

• Projeto open-source sob Licença Apache

• Código fonte está disponível no Github

2.6.2 Funcionalidades do Puppet

Dentre as principais funcionalidades do Puppet podemos citar:

• Fatos

• Manifests

• Resource Types

• Parâmetros

• Meta-parâmetros

• Variáveis, Expressões, Condições, Casos e Seletores

• Funções

• Classes

• Templates

Gerência de Configurações com Puppet Página 17

2.7 Plataformas suportadas 4Linux – www.4linux.com.br

• Definições

• Módulos

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

Página 18 Gerência de Configurações 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 versão 2.7.6 e superior)

• Windows 7 (Puppet versão 2.7.6 e superior)

2.8 Puppetlabs

• Fundada em 2005 por Luke Kaines (criador do Puppet);

• Oferece suporte corporativo e versão enterprise do Puppet;

Gerência de Configurações com Puppet Página 19

2.9 Projetos Internos Puppetlabs 4Linux – www.4linux.com.br

• Mantém uma equipe de desenvolvimento para a versão open source e enter-

prise;

• Mantém toda a documentação da versão enterprise e open source;

• Oferece eventos CamptoCamp e PuppetConf anualmente para entusiastas;

• Mantém um repositório de módulos chamados Puppetforge com mais de 500

módulos prontos para uso;

• Oferece programa de afiliados para comercializar o Puppet Enterprise, treina-

mentos e consultoria de implantação.

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

Página 20 Gerência de Configurações 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 prática para
declarar quais as configurações cada node (servidor) gerenciado pelo Puppet deve
ter. A sintaxe é natural para sysadmins e não é programação, algumas partes da
sintaxe se aproxima muito de linguagens de script como bash script – principalmente
no tratamento de exceções usando expressões condicionais.

2.11 Camada de Abstração

Podemos dizer que o Puppet é composto por um conjunto de recursos (resources)

e provedores (providers), são através destes recursos que construiremos nossas
configurações.

Um usuário pode ser considerado um recurso, um arquivo pode ser considerado

um recurso, um pacote pode ser considerado um recurso, um serviço que está ro-
dando 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
execução de um comando pode ser considerado um recurso para o Puppet.

Cada recurso em sua essência é similar a uma classe com seus atributos. Um ar-
quivo por exemplo, tem um caminho no filesystem (path), um dono (owner), um grupo
grupo dono (group) e permissões (mode), já um usuário tem nome (username), iden-
tificador do usuário (uid), identificador de grupo (gid), tipo de interpretador de coman-
dos (shell) e diretório pessoal (home).

Observe que temos recursos com contextos similares, portanto pela lógica podería-
mos agrupá-los por tipos, indo além, podemos observar que os atributos de alguns

Gerência de Configurações com Puppet Página 21

2.11 Camada de Abstração 4Linux – www.4linux.com.br

tipos são conceitualmente idênticos em alguns sistemas operacionais, tais como UID
ou PATH, e mesmo em implementações diferentes seu funcionamento e objetivo não
muda, com isto, podemos entender que a descrição de um recurso no Puppet sofre
uma abstração quanto a sua forma de implementação. Essas duas características
(agrupar e abstrair) formam no Puppet o que podemos chamar de camada de abs-
tração de recursos (Resource Abstraction Layer) ou RAL.

No Puppet você não precisa se preocupar com a camada mais baixa de execução de
comandos, você simplesmente fala para ele “Instale um pacote” e o puppet vai veri-
ficar qual é o sistema operacional, quais os gerenciadores de pacotes disponíveis e
vai então instalar o pacote para você. Em outros sistemas de gerência de configura-
ção normalmente teríamos que nos preocupar com isto e declarar de forma explícita
o comando, graças ao RAL isso não é necessário 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 configurações de
uma forma abrangente, possibilitando que tais configurações 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 modificação 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 mudanças necessárias no ambiente para que o estado do recurso

reflita o que foi declarado para ele;

Pode parecer complicado mas não é, vamos dar um exemplo simples, imagine que
você deseja instalar o pacote HTOP em dois servidores, um deles é um Debian o ou-

Página 22 Gerência de Configurações com Puppet

4Linux – www.4linux.com.br 2.12 Idempotência

tro um CentOS, no Debian usaríamos o comando aptitude para instalar um pacote, já

no CentOS usaríamos o comando yum, tanto aptitude quanto yum são gerenciado-
res de pacotes, no entanto, cada um funciona de um jeito, porém, graças ao RAL não
precisamos nos preocupar com isto, via Puppet nós apenas dizemos que queremos
instalar o HTOP e o Puppet fará o resto para nós usando as ferramentas que esti-
verem disponíveis em cada sistema operacional, isso é a abstração do ’como fazer’,
nós só dizemos ’o que fazer’.

2.12 Idempotência

Em matemática e ciência da computação, a idempotência é a propriedade em que

algumas operações que podem ser aplicadas várias vezes sem que o valor do re-
sultado se altere após a aplicação inicial. No Puppet isto significa que você obtém
o mesmo resultado com a mesma configuração, não importa quantas vezes você as
execute em um servidor.

No caso do pacote HTOP se rodarmos a configuração do Puppet que manda instalar

tal pacote, isto não 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 não
vai fazer nada, se não estiver ele vai instalar. Neste caso específico na primeira vez
ele instala e nas próximas 9 vezes ele não fará nada pois o sistema já tem o pacote,
logo o que foi declarado é igual a situação atual do sistema, e isto não vai mudar
mesmo que você rode a configuração centenas de vezes.

2.13 Mão na Massa

Agora que já estudamos e entendemos o que é administração artesanal de servi-

dores e serviços, gerência de configurações, Puppet e suas características, vamos
aprofundar o entendimento desta ferramenta de automação.

Gerência de Configurações com Puppet Página 23

2.13 Mão na Massa 4Linux – www.4linux.com.br

Separamos os principais e mais importantes recursos para apresentá-los de forma

prática com exercícios que serão executados durante o treinamento. Cada recurso
apresentado terá uma descrição, apresentação, exemplos e dicas de aplicação.

A melhor forma de aprender a utilizar o Puppet é praticar, por isso, vamos colocar a
mão 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 máquinas virtuais como mostra a figura abaixo:

Página 24 Gerência de Configurações com Puppet

4Linux – www.4linux.com.br 2.13 Mão na Massa

Para estes estudos vamos utilizar 13 máquinas virtuais, são 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

Gerência de Configurações com Puppet Página 25

 2.13 Mão na Massa 4Linux – www.4linux.com.br

• DB Postgres – OpenSUSE 13.1

Sugerimos o uso do VirtualBox para importação destas VMs, prefira sempre a arqui-
tetura 64 bits.

É imprescindível que todas as VM’s sejam importadas e estejam prontas para inici-
armos o próximo passo.

2.13.2 Instalando o Puppet na distribuição Debian

Considerando que estamos trabalhando com Debian Wheezy, siga os passos abaixo
para instalar o Puppet utilizando o repositório oficial da Puppetlabs.

Executar na máquina Firewall

1 - Faça o download do pacote puppetlabs-release.

1 root@firewall :~ # wget http :// apt . puppetlabs . com / puppetlabs - release -

wheezy . deb

2 - Em seguida instale o pacote.

1 root@firewall :~ # dpkg -i puppetlabs - release - wheezy . deb

3 - Atualize os índices e instale o Puppet.

1 root@firewall :~ # apt - get update

2 root@firewall :~ # apt - get install puppet

Página 26 Gerência de Configurações com Puppet

 4Linux – www.4linux.com.br 2.13 Mão na Massa

4 - Para terminar comente a diretiva templatedir que está obsoleta nesta versão do
Puppet.

1 root@firewall :~ # vim / etc / puppet / puppet . conf

2 [ main ]
3
4 ....
5
6 # templatedir = $confdir / templates

Repita a instalação do Puppet nas máquinas DMZ Server e Web Server, que
utilizam a distribuição Debian!

2.13.3 Instalando o Puppet na distribuição Ubuntu

Considerando que estamos trabalhando com Ubuntu versão 12.04 (Precise), siga os
passos abaixo para instalar o Puppet utilizando o repositório oficial da Puppetlabs.

Executar na máquina Datacenter

1 - Faça o download do pacote puppetlabs-release

1 root@datacenter :~ # wget http :// apt . puppetlabs . com / puppetlabs - release

- precise . deb

2 - Em seguida instale o pacote

1 root@datacenter :~ # dpkg -i puppetlabs - release - precise . deb

Gerência de Configurações com Puppet Página 27

 2.13 Mão na Massa 4Linux – www.4linux.com.br

3 - Atualize os índices e instale o Puppet

1 root@datacenter :~ # apt - get update

2 root@datacenter :~ # apt - get install puppet

4 - Para terminar comente a diretiva templatedir que está obsoleta nesta versão do
Puppet.

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

2 [ main ]
3
4 ....
5
6 # templatedir = $confdir / templates

Repita a instalação do Puppet na máquina Zabbix Server que utiliza a distri-

buição Ubuntu!

2.13.4 Instalando o Puppet na distribuição CentOS

Considerando que estamos trabalhando com CentOS versão 6, siga os passos abaixo
para instalar o Puppet utilizando o repositório oficial da Puppetlabs.

Executar na máquina Mail Server

1 - Faça o download do pacote puppetlabs-release

1 root@mailserver :~ # wget http :// yum . puppetlabs . com / puppetlabs - release

- el -6. noarch . rpm

Página 28 Gerência de Configurações com Puppet

 4Linux – www.4linux.com.br 2.13 Mão na Massa

2 - Em seguida instale o pacote

1 root@mailserver :~ # rpm - ivh puppetlabs - release - el -6. noarch . rpm

3 - E para terminar instale o Puppet

1 root@mailserver :~ # yum install puppet

4 - Para terminar comente a diretiva templatedir que está obsoleta nesta versão do
Puppet.

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

2 [ main ]
3
4 ....
5
6 # templatedir = $confdir / templates

Repita a instalação do Puppet na máquina Gateway que utiliza a distribuição

CentOS!

2.13.5 Instalando o Puppet na distribuição OpenSuSE

Considerando que estamos trabalhando com OpenSuSE versão 13.1, siga os passos
abaixo para instalar o Puppet utilizando o repositório oficial da Puppetlabs.

Executar na máquina DB Postgres

Gerência de Configurações com Puppet Página 29

 2.13 Mão na Massa 4Linux – www.4linux.com.br

1 - Adicione o repositório do Puppet para OpenSuSE.

1 root@dbpostgres :~ # zypper ar -f http :// download . opensuse . org /

repositories / systemsmanagement :/ puppet / openSUSE_13 .1 Puppet -
Repository

2 - Em seguida instale o Puppet

1 root@dbpostgres :~ # zypper install puppet

2 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 versão do
Puppet.

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

2 [ 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 disponível no Oracle Solaris 11.2.

Executar na máquina Unix Server

1 - Logue com o usuário aluno e alterne para o usuário root.

Página 30 Gerência de Configurações com Puppet

 4Linux – www.4linux.com.br 2.14 Primeiros passos com o Puppet

1 aluno@unixserver :~ $ su -

2 - Em seguida instale o Puppet

1 root@unixserver :~ # pkg install puppet

3 - Verifique a instalação do Puppet

1 root@unixserver :~ # pkg info -r puppet

2.14 Primeiros passos com o Puppet

Agora que o Puppet esta instalado vamos conhecer algumas opções do comando
puppet

Executar na máquina Firewall

1 - Primeiro vamos confirmar a instalação do Puppet através do seguinte comando:

1 root@firewall :~ # puppet agent -- configprint confdir

2 / etc / puppet

O resultado indica que o Puppet esta instalado e seus arquivos de configuração estão
localizados no diretório /etc/puppet

2 - Um outro comando que podemos executar é descobrir se o Puppet armazenou o

FQDN da maquina:

Gerência de Configurações com Puppet Página 31

 2.14 Primeiros passos com o Puppet 4Linux – www.4linux.com.br

1 root@firewall :~ # puppet agent -- configprint certname

2 firewall . dexter . com . br

O resultado indica que o FQDN firewall.dexter.com.br sera usado no certificado

para comunicação com o Puppet Master.

3 - Outras opções que podem ser exploradas:

1 vardir
2 rundir
3 ssldir
4 ca_server
5 server

2.14.1 Puppet Help

O próprio Puppet fornece ajuda rápida, manuais e documentação para consultar

comandos, parâmetros e flags. Para fornece ajuda rápida execute o seguinte co-
mando

1 root@firewall :~ # puppet help

2
3 Available subcommands :
4
5 agent The puppet agent daemon
6 apply Apply Puppet manifests locally
7 ca Local Puppet Certificate Authority management .
8 catalog Compile , save , view , and convert catalogs .
9 cert Manage certificates and requests
10 certificate Provide access to the CA for certificate
management .

Página 32 Gerência de Configurações com Puppet

 4Linux – www.4linux.com.br 2.14 Primeiros passos com o Puppet

11 certificate_request Manage certificate requests .

12 certificate_revocation_list 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 Manage instrumentation listeners .
24 instrumentation_probe Manage instrumentation probes .
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
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 rápida des-
crição.

Gerência de Configurações com Puppet Página 33

 2.14 Primeiros passos com o Puppet 4Linux – www.4linux.com.br

Caso queira exibir ajuda somente do subcomando apply use:

1 root@firewall :~ # puppet help apply

2.14.2 Puppet Man

O Puppet possui um comando próprio para exibir manuais dos subcomandos do

help:

1 root@firewall :~ # puppet man apply

Para maiores informações use o comando man puppet-man

Página 34 Gerência de Configurações com Puppet