Gustavo Soares

Dia desses precisei me aprofundar em como criar types e providers no Puppet. Providers são recursos fornecidos pelo Puppet para gerenciar diversos itens de configuração. Um exemplo é o package: provider para gerenciar pacotes. Ok, mas onde entra o “type” nisso? Ele entra para especificar (ou especializar) o tipo de pacote que se deseja gerenciar. O Puppet fornece alguns tipos por padrão: rpm, yum, gem e etc.

A primeira referência, que por sinal foi muito boa, foi o livro Pro Puppet do James Turnbull e do Jeff McCune. Pesquisando mais um pouco (aka, Google), cheguei no excelente link http://www.masterzen.fr/2011/11/02/puppet-extension-point-part-2 que resolvi compartilhar com vocês.

Foi tudo decidido em cima da hora e cá estou eu para participar da primeira conferência voltada para o Puppet: PuppetConf. Para vocês terem idéia, eu fiquei sabendo que iria vir na sexta-feira, dia 16/09/2011 e depois disso foi aquela correria para fazer inscrição, arrumar as passagens, hospedagem e o adiantamento. Cheguei hoje (quarta-feira, dia 21/09/2011) em Portland e amanhã já começa. Ainda bem que costumo me adaptar rápido ao fuso horário, espero que dessa vez não seja diferente.

Comecei a usar o puppet em 2009, e hoje 2 anos depois, é com muito entusiasmo que fico em poder assistir uma série de palestras dessa tecnologia que mudou a forma com que os servidores são instalados, configurados e mantidos na empresa que trabalho atualmente. Realmente considero o puppet uma ferramenta fantástica e juntamente com o Chef, eles são os big players do mercado para sistemas de gerência de configuração. Já escrevi alguns artigos aqui no blog sobre puppet.

A programação das palestras você encontra aqui. Pela descrição de algumas, vai ter momento que vou querer me dividir em 2!!

Para finalizar este post uma coincidência que aconteceu… Meu aniversário é no dia 6/11, o número do quarto que fiquei é o 611. E eu com isso, certo!? Você deve estar pensando… ))))

Resolvi escrever sobre uma dica MUITO útil para quem está utilizando o puppet e que com certeza irá evitar alguns problemas no futuro. Trata-se de uma forma para automatizar o teste de sintaxe dos seus arquivos puppet (*.pp) e os templates ERB antes que tais arquivos sejam enviados para o seu puppetmaster. Para fazer isso, você deve utilizar os hooks que tanto quanto o SVN quanto o GIT oferecem. Resumindo, hooks são mecanismos que tais sistemas de controle de versão oferecem para execução de qualquer comando antes ou após a atualização de código no repositório.

git-hooks e puppet

Como utilizo o git como repositório, daqui para frente vou me concentrar apenas nele. O git oferece hooks do tipo pre-commit, post-commit e update. Os primeiros dois hook são do tipo cliente, enquanto que último atua no lado do servidor, isto é, sempre que é feito um git push. Para configurar os hooks do tipo cliente, basta criar o diretório hooks dentro do diretório .git na raiz do projeto e criar os arquivos pre-commit e post-commit. Para habilitar ou desabilitar um determinado tipo de hook, basta adicionar ou remover a permissão de execução do script. Como estamos interessados em rodar um teste de sintaxe nos arquivos puppet e template o hook mais indicado seria o pre-commit, para evitar que sejam comitados códigos com o potencial de quebrar a execução do puppetmaster. O trecho abaixo é o conteúdo do arquivo que venho utilizando.

#!/bin/sh

syntax_errors=0
error_msg=$(mktemp /tmp/error_msg.XXXXXX)

if git rev-parse --quiet --verify HEAD > /dev/null
then
    against=HEAD
else
    # Initial commit: diff against an empty tree object
    against=4b825dc642cb6eb9a060e54bf8d69288fbee4904
fi

# Get list of new/modified manifest and template files to check (in git index)
cmd="git diff-index --diff-filter=AM --name-only --cached $against | egrep '\.(pp|erb)'"
echo "cmd: $cmd"
for indexfile in `git diff-index --diff-filter=AM --name-only --cached $against | egrep '\.(pp|erb)'`
do
    # Don't check empty files
    if [ `git cat-file -s :0:$indexfile` -gt 0 ]
    then
        echo "Arquivo alterado: $indexfile"
        case $indexfile in
            *.pp )
                # Check puppet manifest syntax
                git cat-file blob :0:$indexfile | puppet --color=false --parseonly --ignoreimport > $error_msg ;;
            *.erb )
                # Check ERB template syntax
                git cat-file blob :0:$indexfile | erb -x -T - | ruby -c 2> $error_msg > /dev/null ;;
        esac
        if [ "$?" -ne 0 ]
        then
            echo -n "$indexfile: "
            cat $error_msg
            syntax_errors=`expr $syntax_errors + 1`
        fi
    fi
done

rm -f $error_msg

if [ "$syntax_errors" -ne 0 ]
then
    echo "Error: $syntax_errors syntax errors found, aborting commit."
    exit 1
fi

O script acima irá rodar o teste de sintaxe apenas nos arquivos com extensão pp e erb, que são as extensões mais utilizadas para os arquivos puppet e os arquivos de template do puppet. É necessário ter o puppet instalado na sua máquina. Para isso, veja qual a versão do puppet que o seu servidor puppetmaster está rodando e instale-a com o comando: sudo gem install puppet -v [VERSÃO]

O exemplo de instalação do puppet que dei anteriormente, foi via rubygems, mas ela poderia ser feita de outras formas. (yum/macports/rpm/apt-get e etc).

É isso! Espero ter ajudado!

Fuçando a Internet (AKA Google ) dia desses achei um site que agrega os principais blogs sobre o puppet. Achei a idéia muito interessante e resolvi compartilhar o link aqui no blog. Segue o link: http://www.planetpuppet.org/

Acabou tem pouco tempo o keynote sobre a operação do Twitter aqui no Velocity. O keynote foi apresentado pelo Jonh Adams. Apesar dele não ter entrado no detalhe de muitas coisas, achei bem legal saber as tecnologias que eles vêm utilizando lá.

Algumas, inclusive já são adotadas na Globo.com, como por exemplo a utilização do puppet na gerência de configuração. E outras, em fases de teste piloto, como por exemplo o scribe, que testei mês passado como solução para agregar logs dos servidores. Só posso adiantar, que os testes foram bem promissores.

Alguns pontos chaves mencionados no keynote:

Utilize um sistema de gerência de configuração independente do tamanho da sua infraestrutura

A maior parte do acesso ao twitter hoje em dia vem da API, através de aplicativos de terceiros e não via web (novidade!!! )

A final da NBA (Lakers x Celtics) gerou um tráfego de 3085 TPS (Tweets por segundo )

Syslog não escala muito bem para um alto tráfeo de dados. Para a agregação de logs eles estão utilizando o Scribe do facebook.

Assim como o Facebook eles também utilizam uma solução com torrent para deploy nos servidores (ok… ambas empresas tem um número estúpido de servidores, imagino…)

Na média são escrito 750 tweets por segundo diariamente… faça as contas, e veja quanto isso dá em 1 dia

Utilizam apache atrás dos balanceadores de carga

Monitoração e extração de métricas forte dos dados para gerar gráficos e relatórios

Utilizam o Unicorn como engine de rails

Utilizam um banco de dados próprio para lidar com os grafos sociais (A segue B, que não segue B, mas que segue C e por aí vai…)

Utilizam uma solução com Hadoop para extrair informações relevantes dos logs

Tirei algumas fotos dos slides do Keynote do Twitter. Elas podem ser acessadas no meu flickr, no seguinte endereço: http://www.flickr.com/photos/gustavosoares/sets/72157624223796237/

Para mais infos, consultem também a página http://twitter.com/about/opensource

Fuiii!! vai começar uma palestra agora!!

Cheers!!

Gerência de configuração automatizada com alguma ferramenta (puppet, chef, cfengine, bcfg2) criada para tal propósito é uma atividade que (aposto) poucas empresas no Brasil utilizam, ao passo que lá fora está virando praticamente commodity, assim como soluções e/ou tecnologias utilizando hadoop.

A seguir vou listar algumas situações bem comuns de qualquer empresa de TI que não esteja terceirizando a sua infraestrutura e a minha resposta *provável* para a pergunta.

1. Preciso editar o meu /etc/hosts no servidor para adicionar um mapeamento para o apache funcionar, como faço?
   1. Essa é fácil! Para quem é “macho”, dá um vi no /etc/hosts ou então um gedit
2. Preciso instalar uma pacote rpm ou gem no meu servidor?
   1. Logo no servidor ou então uso o capistrano ou o fabric para rodar um yum install [PACOTE]
3. Minha aplicação roda com o usuário XPTO e por isso preciso criá-lo em todos os servidores envolvidos com o mesmo uid e gid, como faço?
   1. Hummm… ou posso logar em cada servidor e rodar o comando de criação de usuário, ou novamente, utilizar alguma solução com capistrano ou fabric para automatizar isso. Repare que esta solução, só cria o usuário. Se por um acaso, alguém der uma mãozada no servidor e alterar o uid do usuário, provavelmente você só vai tomar conhecimento disso quando sua aplicação tomar algum erro de escrita, execução ou leitura de algum arquivo.
4. Preciso garantir que a configuração dos meus servidores estejam íntegras ou que são equivalente aos servidores de desenvolvimento e qa, e aí, como faço?
   1. Bem, talvez essa questão seja a mais complicada. O mais comum é colocar as configurações em um diretório compartilhado entre os servidores, assim todos os servidores terão a mesma configuração. No entanto, novamente, isto não resolve o problema de você ficar sabendo  quando um determinado arquivo foi alterado. Normalmente, você vai ficar sabendo disso da pior forma possível…

Bem, as perguntas que eu poderia fazer, são praticamente infinitas, mas acho que já deu para ter uma idéia para que serve e qual o benefício de um sistema de gerência de configuração. Os mais utilizados hoje em dia são o puppet e chef, ambos escritos em ruby. A seguir mostro um exemplo de como instalar um pacote com o puppet o chef.

puppet

package { postfix: ensure => latest }

O recurso acima é bem intuitivo e bem claro. Ele está instalando a última versão do pacote postfix. Caso o pacote já esteja instalado, ele irá verificar se a versão instalada é a última versão. Obviamente, que este comportamento pode ser alterado. Uma observação… ao rodar o comando acima o puppet irá fazer uma inspeção do sistema operacional em uso, caso seja CentOS por exemplo, irá usar o yum ou o rpm para instalar o pacote. É possível, utilizar a definição package para gerenciar outros tipos de pacotes, como pacotes ruby por exemplo, ou seja, gem.

A definição do próprio puppet para um recurso é a seguinte:

The fundamental unit of modelling in Puppet is a resource. Resources describe some aspect of a system; it might be a file, a service, a package, or perhaps even a custom resource that you have developed. We’ll show later how resources can be aggregrated together with “defines” and “classes”, and even show how to organize things with “modules”, but resources are what we should start with first.

Each resource has a type, a title, and a list of attributes – each resource in Puppet can support various attributes, though many of them will have reasonable defaults and you won’t have to specify all of them.

chef

package “tar” do

version “1.16.1-1″

action :install

end

continue reading…