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

4511Gerncia de Configuraes com

Puppet

www.4linux.com.br

Projetos na sua empresacom a qualidade dos treinamentos

http://va.mu/FlyBServidor Java EE http://va.mu/Flx3

GED - ECMhttp://va.mu/Fl

x8Business Inteligence

http://va.mu/EuiTBPM

http://va.mu/EuhVPostgreSQL

http://va.mu/FlyDIntegrao Continua

http://va.mu/FNbLAlta Disponibilidade

http://va.mu/EukNMonitoramento

http://va.mu/FlxiInfraestrutura Web

http://va.mu/FlxrBackup

http://va.mu/FNYj

Groupwarehttp://va.mu/Flxl

Virtualizao

http://va.mu/FlxuAuditoria e Anlise

http://va.mu/FlxySegurana

http://va.mu/GcFvImplantao garantida

http://va.mu/FlxcEnsino Distncia

Contedo

2 Introduo a Gerncia de Configuraes + Instalao do Puppet 12.1 Introduo terica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2.1.1 Trabalho Artesanal . . . . . . . . . . . . . . . . . . . . . . . . . . 22.1.2 Efeito Cascata . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.3 Ambiente no padronizado . . . . . . . . . . . . . . . . . . . . . 5

2.2 Tratamento de demandas . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.1 Gerenciamento de usurios . . . . . . . . . . . . . . . . . . . . . 72.2.2 Gerenciamento de servios . . . . . . . . . . . . . . . . . . . . . 92.2.3 Mudanas no ambiente . . . . . . . . . . . . . . . . . . . . . . . 102.2.4 Criao de novos ambientes . . . . . . . . . . . . . . . . . . . . 11

2.3 Documentao e planejamento . . . . . . . . . . . . . . . . . . . . . . . 112.4 Desvantagens do modelo artesanal . . . . . . . . . . . . . . . . . . . . 122.5 Buscando um novo caminho . . . . . . . . . . . . . . . . . . . . . . . . 13

2.5.1 Entendendo o que a Gerncia de Configuraes . . . . . . . . 142.5.2 Automao e padronizao . . . . . . . . . . . . . . . . . . . . . 152.5.3 Vantagens associadas a Gerncia de Configuraes . . . . . . . 15

2.6 Conhecendo o Puppet na prtica . . . . . . . . . . . . . . . . . . . . . . 162.6.1 Caractersticas do Puppet . . . . . . . . . . . . . . . . . . . . . . 162.6.2 Funcionalidades do Puppet . . . . . . . . . . . . . . . . . . . . . 17

2.7 Plataformas suportadas . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.7.1 Sistemas Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.7.2 Sistemas BSD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.7.3 Sistemas Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.7.4 Sistemas Windows . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.8 Puppetlabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.9 Projetos Internos Puppetlabs . . . . . . . . . . . . . . . . . . . . . . . . 20

i

Contedo 4Linux www.4linux.com.br

2.10 Sintaxe Declarativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.11 Camada de Abstrao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.12 Idempotncia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.13 Mo na Massa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.13.1 Infraestrutura do Curso . . . . . . . . . . . . . . . . . . . . . . . 242.13.2 Instalando o Puppet na distribuio Debian . . . . . . . . . . . . 262.13.3 Instalando o Puppet na distribuio Ubuntu . . . . . . . . . . . . 272.13.4 Instalando o Puppet na distribuio CentOS . . . . . . . . . . . . 282.13.5 Instalando o Puppet na distribuio OpenSuSE . . . . . . . . . . 292.13.6 Instalando o Puppet em Ambiente Unix - Oracle Solaris . . . . . 30

2.14 Primeiros passos com o Puppet . . . . . . . . . . . . . . . . . . . . . . 312.14.1 Puppet Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.14.2 Puppet Man . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Pgina ii Gerncia de Configuraes com Puppet

Captulo 2

Introduo a Gerncia deConfiguraes + Instalao doPuppet

2.1 Introduo terica

Hoje em dia com a crescente adoo das tecnologias de virtualizao e computaoem nuvem, nosso ambiente de servidores tende a crescer rapidamente, normalmenteuma nova demanda gera uma nova instncia ou uma nova mquina virtual, clientescada vez mais exigentes desejam ambientes dedicados e independentes, com isto,um parque em que antes possua algumas mquinas fsicas, pode se tornar umparque com dezenas, centenas ou milhares de instncias e mquinas virtuais, etudo 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 ne-cessrios poucos minutos para executar essa demanda em ambas tecnologias. Noentanto, atualmente o grande desafio dos sysadmins encontrar a melhor forma deadministrar centenas ou milhares de servidores aps sua criao.

1

2.1 Introduo terica 4Linux www.4linux.com.br

Para um melhor entendimento, vamos imaginar que em poucos meses o parque deservidores que uma equipe de sysadmins administra saltou de dezenas para cente-nas de servidores virtuais. A partir deste ponto, vamos avaliar os principais aspectose os desafios de se fazer a administrao destes servidores utilizando metodologiastradicionais.

2.1.1 Trabalho Artesanal

A administrao tradicional um processo praticamente artesanal, normalmenteutiliza-se acesso secure shell (SSH) e shellscript para resolver demandas cotidia-nas, porm, imagine fazer isto em um parque hbrido com diversas distribuies linuxem arquiteturas com 32 e 64 bits, imagine tambm que estas distribuies linux es-to em diferentes verses (Debian e Centos 5/6) e que temos ainda servidores comsistemas operacionais UNIX (Solaris, AIX, HPUX) e at algumas distribuies BSD(FreeBSD, OpenBSD).

Neste tipo de cenrio a complexidade do ambiente aumenta rapidamente, e comisso, o sysadmin precisa encontrar a melhor forma de administrar este parque deservidores.

A administrao artesanal de ambientes tem em suas principais caractersticas ta-refas que so executadas de forma repetitiva. Executar tais tarefas em ambientespequenos bastante fcil, porm administrar ambientes hbridos em pleno cresci-mento uma tarefa bem mais complexa, principalmente se voc deseja e precisamant-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 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 voconseguir prever as excees e tratar todas as diferenas entre os diferentes sis-temas operacionais, com isto, a equipe de sysadmins ter de investir muitas horasna manuteno desses scripts e provavelmente ter de criar scripts para cada tipode sistema operacional. Isto ser cansativo e demorado, por esta razo naturalque algumas equipes partam para administrao usando SSH em Loop com auxliode programas como o ClusterSSH, deixando ento os scripts de lado. Neste caso,a equipe provavelmente vai separar os servidores em grupos ou contextos comoRHEL, Debian, FreeBSD, OpenBSD, a partir da acessar e executar comandos emLoop.

No entanto mesmo utilizando SSH em Loop esse tipo de demanda leva tempoe nem sempre o resultado obtido o mesmo o que fora planejado pela equipe desysadmins, normalmente vrios ajustes precisam ser executados no meio do cami-nho para que a equipe consiga atingir o objetivo desejado fazendo o tratamentode excees, as vezes at preciso alocar vrios analistas de foma simultnea pararesolver este tipo de tarefa repetitiva dentro do prazo estipulado.

Em algum momento a equipe que administra este parque vai perceber que as tc-nicas que antes os ajudavam na resoluo de demandas, no funcionam a medidaque mais e mais servidores so criados. Isto significa que eles no conseguem darvazo as demandas e provavelmente vo se tornar o gargalo de muitos processosna empresa em que trabalham.

Avaliando este cenrio, podemos dizer que a administrao manual no escala, ealm de no escalar, gera uma grande sobrecarga em cima de sua equipe e princi-palmente nos membros mais experientes. Isto tende a aumentar o custo necessriopara manter seu ambiente, afinal sobrecarga significa hora extra a noite, de madru-gada, nos finais de semana e feriados, com isto, voc ser forado a ampliar suaequipe e seus custos para dar conta das tarefas, tentando assim cumprir suasmetas.

Gerncia de Configuraes com Puppet Pgina 3


2.1.2 Efeito Cascata

Quando uma metodologia ou tcnica de administrao de configurao no esca-lvel, 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 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 no conse-gue mais documentar, planejar e entregar o que seu cliente solicita no tempoacordado;

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 ouservio em todas as instncias/VMs de seu parque (ex.: Um novo agente demonitoramento).

Estas so as percepes mais comuns em ambientes que ainda utilizam metologiaartesanal de administrao de servidores e servios.


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 impor-tncia e os impactos em um ambiente de TI, vamos abordar alguns exemplos prti-cos.

Focando exclusivamente em ambientes Linux e Unix, no ter um parque padronizadosignifica que voc no tem como garantir que as configuraes fundamentais deseus sistemas estejam devidamente ajustadas em todos os seus servidores, dentreas 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);



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/alertaspara 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 avaliar-mos com mais cuidado, vamos entender que so na verdade questes crticas. Vejaabaixo as causas e os efeitos em 4 exemplos:

1. Se a sua data/hora esto erradas, isto pode gerar uma parada de alguns sistemasou 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 demonitoramento.

2. Um DNS configurado de forma errada pode afetar o funcionamento de um sistemae dos servios que dependem de resoluo de DNS;

3. Um repositrio mal configurado pode instalar pacotes no homologados, em ver-ses experimentais, isto pode afetar aplicaes em produo e causar grandes inci-dentes;


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

4. Um logrotate mal configurado pode fazer seu disco encher rapidamente parandoaplicaes e servios de seus clientes;

Veja que a falta de um ambiente padronizado pode ser uma grande dor de cabeapara 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 repe-titivas, para isto, vamos utilizar alguns exemplos bastante comuns.

2.2.1 Gerenciamento de usurios

Talvez um dos problemas mais bsicos que afligem Sysadmins que administramgrandes parques seja a gesto de contas de usurios nestes servidores.

Imagine que voc tenha um parque com 450 Servidores, agora vamos supor que noincio 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 todosos 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


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 necessrias2.250 aes repetitivas.

Se voc gastar 5 minutos por servidor isso dar um total de 2250 minutos ou 37.5horas de trabalho repetitivo, desgastante e contnuo.

Alm disto, o novo Sysadmin precisar teoricamente acessar 450 servidorespara trocar sua senha.

Isto certeza de muito trabalho, no entanto, sabemos que as coisas no acontecemdesta forma, o mais comum criar o usurio do novo colaborador sob demanda nosservidores em que ele precisa de acesso, conforme os problemas e as necessidadesvo surgindo durante o expediente de trabalho.

Outra coisa muito comum que encontramos em ambientes como este so contas decolaboradores que j saram da empresa h muito tempo, estas contas alm de exis-tirem 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 Syad-mins so aquelas temporrias como mudar123, e uma troca de senha em 450mquinas virtualmente invivel e desmotiva qualquer iniciativa ou voluntrio parafaz-lo.

claro que pode podemos configurar autenticao 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 configurao na IMAGEM padro dos servi-dores LINUX, se por ventura alguma configurao do LDAP muda, voc ter cercade 450 servidores para executar mudanas, e nestes casos as vezes s precisamosajustar uma nica linha com o IP de um novo servidor ou uma BASEDN LDAP.


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

importante lembrar que apesar do uso de autenticao LDAP, caso o backend deautenticao saia do ar, ser sempre necessrio ter um usurio coringa local para fazer a administrao emergencial, nestes casos se for preciso trocar a senhadeste usurio coringa, voc passar pela mesma dor de cabea, seja o usurio rootou seja outro usurio genrico (sysadmin/suporte).

Veja que invivel e cansativo administrar contas de usurios desta forma em umparque com estas dimenses.

2.2.2 Gerenciamento de servios

A configurao de servios outro processo muito comum, dentre os mais comunstemos 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, teremosprocedimentos diferentes e ser extremante difcil entender e rastrear como a de-manda foi atendida, quais foram os pacotes instalados, quais foram as dependnciasatendidas, 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 runleveldiferenciado, 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 nosgerar um terceiro distinto processo de instalao e configurao do mesmoservio.

Veja que no h como garantir um padro trabalhando deste jeito. Logo podemosentender 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;


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 di-ferentes 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 monitoramentoiniciou um projeto que visa substituir a atual ferramenta de monitoramento. Esteprojeto prev a instalao do agente Zabbix em todos os 450 servidores do seuparque, alm disto no podem esquecer de remover o agente antigo (NAGIOS) e assuas configuraes.

O processo de instalao em um CentOS consiste em pelo menos 10 passos, soeles:

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


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 contaque voc gaste 10 minutos por servidor, sero 4500 minutos ou 75 horas de trabalhorepetitivo, desgastante e contnuo para terminar esta demanda.

Veja que voc vai dedicar cerca de 75 horas de um Sysadmin para executar umatarefa repetitiva, e isto pode inclusive desmotivar o profissional aumentando a rotati-vidade de sua equipe.

2.2.4 Criao de novos ambientes

Eventualmente necessrio reinstalar um servidor ou mesmo criar servidor com asmesmas caractersticas, este tipo de demanda bastante comum, e o tempo inves-tido para realizar esta tarefa na administrao artesanal varia conforme a comple-xidade dos servios que devero ser instalados. Este tempo tambm depende doconhecimento do profissional que executar a instalao, portanto, isto pode durarhoras, dias ou semanas para ser concludo, principalmente se o profissional especi-alizado naquele tipo de sistema ou servio no estiver disponvel para ser alocadopara esta demanda.

2.3 Documentao e planejamento

Essa dupla provavelmente o principal problema de muitas organizaes de TI. co-mum infelizmente encontrar parques imensos com quase nada documentado,locais onde mudanas no so planejadas e alteraes no so documentadas, po-demos dizer inclusive que este tipo receita cria o que chamamos de ambientes ca-ticos.


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-vio, os arquivos de configurao e mapear todo o ambiente afim de entender comotudo funciona, s assim poder planejar e executar algum tipo de manuteno mi-nimizando os riscos de sua mudana gerar um incidente nos servios e sistemasenvolvidos.

O principal problema que as vezes precisamos de vrios meses para entendercomo funcionam certos ambientes, principalmente se acabamos de chegar nesteslocais caticos.

Se houvesse uma documentao bem-feita, seria muito mais simples planejar e exe-cutar manutenes neste tipo de local, porm, j vimos que em ambientes comadministrao artesanal muito difcil sobrar tempo para documentar ou planejarmudanas uma vez que as equipes responsveis esto sempre sobrecarregadasexecutando tarefas repetitivas.

Alm destas dificuldades, muito raro encontrar um Sysadmin ou mesmo gestoresque gostem ou que consigam compreender plenamente a importncia de se elaboraruma boa documentao, algo que reflita as configuraes de seus sistemas ou ser-vios, os processos e os procedimentos envolvidos em todo o ambiente produtivo.

Sem documentao e sem planejamento, a qualidade do que entregue e a qua-lidade do servio que produziu esta entrega sempre questionvel, afinal, no hcomo saber como aquilo foi realmente executado e principalmente quanto tempo vaificar no ar.

2.4 Desvantagens do modelo artesanal

Falta de padronizao de seu ambiente;

Documentao inexpressiva ou inexistente.


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 tornarseu ambiente confivel e sua administrao mais simples e eficiente, esta soluose chama Puppet.

O Puppet uma ferramenta de nova gerao que implementa modernos concei-tos de Gerncia de Configurao com o objetivo de garantir a integridade e o pleno


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

funcionamento de seus ambientes, sistemas e servios, fazendo isto de forma auto-matizada, centralizada e gil.

2.5.1 Entendendo o que a Gerncia de Configuraes

A gerncia de configuraes crtica para ambientes que esto crescendo ou quesejam de natureza complexa e heterogenia, atravs dela que podemos trabalharprovisionamento, automatizao, gerncia de mudanas, manipulao de configura-es e alm disto ao implant-la possvel iniciar tambm um processo sadio dedocumentao dos ambientes envolvidos alm do planejamento de mudanas.

Hoje na prtica conseguimos identificar que a maioria dos incidentes em umambiente ocorre pela falta de gesto dos processos e principalmente por falta deprocedimentos 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 istopode causar impacto em outra aplicao devido a dependncias que por venturapodem remover ou desconfigurar algum arquivo de configurao de outro pacoteou servio que esteja rodando em produo nesta mesma mquina. Este exemplo muito comum e acontece em muitas empresas que ainda no tem processos eprocedimentos bem definidos.

Entenda que se este cliente utilizasse alguma ferramenta de gerncia de configura-es, o pacote removido seria reinstalado e os arquivos de configurao modificadosseriam corrigidos, o servio continuaria rodando, minimizando o downtime e o im-pacto do incidente que foi gerado pelo Sysadmin desatento.


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 esta-mos falando tambm de padronizao e automatizao, estes trs conceitos andamjuntos e se amparam, no existe padronizao sem gerncia ou automao sempadronizao.

Ao trabalhar com ambientes grandes e complexos, sejam ambientes virtualizados oucomputao em nuvem, voc tem que automatizar, do contrrio voc no conseguirdar 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 configura-o 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;


2.6 Conhecendo o Puppet na prtica 4Linux www.4linux.com.br

Facilidades para distribuir novas configuraes para todo o parque de formarpida, 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, conse-guimos diminuir sensivelmente o tempo de mudanas em diversos projetos.

Mudanas como o exemplo do Zabbix que demandariam cerca de 75 horas cont-nuas de trabalho e retrabalho foram executadas em poucos minutos no mesmoparque de 450 servidores.

2.6 Conhecendo o Puppet na prtica

O Puppet um framework Open Source que oferece recursos e ferramentas paraimplantar um modelo nico de gerncia de configuraes em seu ambiente. Elefunciona localmente ou em rede e pode gerenciar sistemas e servios em diferentesplataformas.

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


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


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


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;


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

Mantm uma equipe de desenvolvimento para a verso open source e enter-prise;

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 500mdulos prontos para uso;

Oferece programa de afiliados para comercializar o Puppet Enterprise, treina-mentos e consultoria de implantao.

No decorrer de nossos estudos entenderemos o que e como funciona cada umdestes recursos e funcionalidades.

2.9 Projetos Internos Puppetlabs

Puppet

Facter

Puppet Dashboard

Puppet Enterprise

PuppetDB

Hiera

Razor


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 paradeclarar quais as configuraes cada node (servidor) gerenciado pelo Puppet deveter. A sintaxe natural para sysadmins e no programao, algumas partes dasintaxe se aproxima muito de linguagens de script como bash script principalmenteno 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 nossasconfiguraes.

Um usurio pode ser considerado um recurso, um arquivo pode ser consideradoum recurso, um pacote pode ser considerado um recurso, um servio que est ro-dando pode ser considerado um recurso, uma rotina do cron pode ser consideradaum recurso, um alias de correio pode ser considerado um recurso, e at mesmo aexecuo de um comando pode ser considerado um recurso para o Puppet.

Cada recurso em sua essncia similar a uma classe com seus atributos. Um ar-quivo por exemplo, tem um caminho no filesystem (path), um dono (owner), um grupogrupo dono (group) e permisses (mode), j um usurio tem nome (username), iden-tificador do usurio (uid), identificador de grupo (gid), tipo de interpretador de coman-dos (shell) e diretrio pessoal (home).

Observe que temos recursos com contextos similares, portanto pela lgica podera-mos agrup-los por tipos, indo alm, podemos observar que os atributos de alguns


2.11 Camada de Abstrao 4Linux www.4linux.com.br

tipos so conceitualmente idnticos em alguns sistemas operacionais, tais como UIDou PATH, e mesmo em implementaes diferentes seu funcionamento e objetivo nomuda, com isto, podemos entender que a descrio de um recurso no Puppet sofreuma abstrao quanto a sua forma de implementao. Essas duas caractersticas(agrupar e abstrair) formam no Puppet o que podemos chamar de camada de abs-trao de recursos (Resource Abstraction Layer) ou RAL.

No Puppet voc no precisa se preocupar com a camada mais baixa de execuo decomandos, voc simplesmente fala para ele Instale um pacote e o puppet vai veri-ficar qual o sistema operacional, quais os gerenciadores de pacotes disponveis evai ento instalar o pacote para voc. Em outros sistemas de gerncia de configura-o normalmente teramos que nos preocupar com isto e declarar de forma explcitao comando, graas ao RAL isso no necessrio no Puppet.

O RAL divide recursos em resource types (tipos de recursos) e providers (provedoresdos recursos), com isto o Puppet nos permite descrever nossas configuraes deuma forma abrangente, possibilitando que tais configuraes sejam aplicadas empraticamente qualquer sistema operacional.

O Puppet usa o RAL tanto para ler quanto para modificar o estado dos recursos emum sistema.

No caso da modificao do estado de um recurso, o Puppet o faz da seguinteforma:

1. verifica o estado atual de um recurso usando o RAL;

2. compara os dados coletados (estado atual) com o estado declarado para orecurso;

3. aplica mudanas necessrias no ambiente para que o estado do recursoreflita o que foi declarado para ele;

Pode parecer complicado mas no , vamos dar um exemplo simples, imagine quevoc deseja instalar o pacote HTOP em dois servidores, um deles um Debian o ou-


4Linux www.4linux.com.br 2.12 Idempotncia

tro um CentOS, no Debian usaramos o comando aptitude para instalar um pacote, jno CentOS usaramos o comando yum, tanto aptitude quanto yum so gerenciado-res de pacotes, no entanto, cada um funciona de um jeito, porm, graas ao RAL noprecisamos nos preocupar com isto, via Puppet ns apenas dizemos que queremosinstalar o HTOP e o Puppet far o resto para ns usando as ferramentas que esti-verem 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 quealgumas operaes que podem ser aplicadas vrias vezes sem que o valor do re-sultado se altere aps a aplicao inicial. No Puppet isto significa que voc obtmo mesmo resultado com a mesma configurao, no importa quantas vezes voc asexecute em um servidor.

No caso do pacote HTOP se rodarmos a configurao do Puppet que manda instalartal pacote, isto no significa que o Puppet vai rodar 10 vezes o comando aptitudeinstall htop, na verdade ele vai verificar se o pacote est instalado, se estiver ele novai fazer nada, se no estiver ele vai instalar. Neste caso especfico na primeira vezele 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 mudarmesmo que voc rode a configurao centenas de vezes.

2.13 Mo na Massa

Agora que j estudamos e entendemos o que administrao artesanal de servi-dores e servios, gerncia de configuraes, Puppet e suas caractersticas, vamosaprofundar o entendimento desta ferramenta de automao.


2.13 Mo na Massa 4Linux www.4linux.com.br

Separamos os principais e mais importantes recursos para apresent-los de formaprtica com exerccios que sero executados durante o treinamento. Cada recursoapresentado ter uma descrio, apresentao, exemplos e dicas de aplicao.

A melhor forma de aprender a utilizar o Puppet praticar, por isso, vamos colocar amo na massa a partir de agora.

2.13.1 Infraestrutura do Curso

Para ministrar este curso, foi criada uma infraestrutura utilizando o VirtualBox comogerenciador das mquinas virtuais como mostra a figura abaixo:


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



DB Postgres OpenSUSE 13.1

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

imprescindvel que todas as VMs sejam importadas e estejam prontas para inici-armos o prximo passo.

2.13.2 Instalando o Puppet na distribuio Debian

Considerando que estamos trabalhando com Debian Wheezy, siga os passos abaixopara instalar o Puppet utilizando o repositrio oficial da Puppetlabs.

Executar na mquina Firewall

1 - Faa 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



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

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

2 [main]

3

4 ....

5

6 #templatedir=$confdir/templates

Repita a instalao do Puppet nas mquinas DMZ Server e Web Server, queutilizam a distribuio Debian!

2.13.3 Instalando o Puppet na distribuio Ubuntu

Considerando que estamos trabalhando com Ubuntu verso 12.04 (Precise), siga ospassos abaixo para instalar o Puppet utilizando o repositrio oficial da Puppetlabs.

Executar na mquina Datacenter

1 - Faa 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



3 - Atualize os ndices e instale o Puppet

1 root@datacenter :~# apt -get update

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


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

2 [main]

3

4 ....

5


Repita a instalao do Puppet na mquina Zabbix Server que utiliza a distri-buio Ubuntu!

2.13.4 Instalando o Puppet na distribuio CentOS

Considerando que estamos trabalhando com CentOS verso 6, siga os passos abaixopara instalar o Puppet utilizando o repositrio oficial da Puppetlabs.

Executar na mquina Mail Server

1 - Faa o download do pacote puppetlabs-release

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

-el -6. noarch.rpm



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


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

2 [main]

3

4 ....

5


Repita a instalao do Puppet na mquina Gateway que utiliza a distribuioCentOS!

2.13.5 Instalando o Puppet na distribuio OpenSuSE

Considerando que estamos trabalhando com OpenSuSE verso 13.1, siga os passosabaixo para instalar o Puppet utilizando o repositrio oficial da Puppetlabs.

Executar na mquina DB Postgres



1 - Adicione o repositrio 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 opes] (r): s (Enter)


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

2 [main]

3

4 ....

5


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.


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 instalao 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 opes do comandopuppet

Executar na mquina Firewall

1 - Primeiro vamos confirmar a instalao do Puppet atravs 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 configurao estolocalizados no diretrio /etc/puppet

2 - Um outro comando que podemos executar descobrir se o Puppet armazenou oFQDN da maquina:


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 certificadopara comunicao com o Puppet Master.

3 - Outras opes que podem ser exploradas:

1 vardir

2 rundir

3 ssldir

4 ca_server

5 server

2.14.1 Puppet Help

O prprio Puppet fornece ajuda rpida, manuais e documentao para consultarcomandos, parmetros e flags. Para fornece ajuda rpida 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.


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 rpida des-crio.


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 prprio para exibir manuais dos subcomandos dohelp:

1 root@firewall :~# puppet man apply

Para maiores informaes use o comando man puppet-man


Documents

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