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

arquitetura

Normalmente a arquitetura utilizada é do tipo cliente/servidor. Os clientes contactam de tempos em tempos um único servidor central via chamadas https ou XMLRPC para baixarem o catálogo com as suas “receitas” ou definições. O catálogo baixado contém a especificação da lista de recursos sendo gerenciados pelo puppet para aquele servidor, ou seja, quais são os pacotes instalados, quais os arquivos de configuração de determinado serviço, o usuário que precisa estar instalado, a senha desse usuário, a entrada no /etc/hosts e por aí vai.

Mediante uma configuração, os clientes podem enviar para o servidor central (puppetmaster) um relatório contendo uma descrição da sua execução. Este relatório contém a informação de todos os recursos que sofreram algum tipo de alteração e o tempo de duração da atualização.

Para armazenar as receitas dos servidores é recomendado utilizar um sistema de controle de versão, exemplificado na figura pela caixa de texto SVN. Desta forma, tem-se um backup de todas as definições de todos os servidores em caso de falha no servidor central. Outra vantagem, é que desta forma é possível o versionamento de todo um conjunto de configurações presente na infraestrutura.

Assim termino este post, espero ter conseguido explicar um pouco dos conceitos por trás de um sistema de gerência de configuração, em especial do puppet. Aqui na empresa que trabalho ele foi o sistema de gerência de configuração adotado, pois possui uma documentação bem estruturatada e clara, e a comunidade está bem ativa.

Procurarei escrever outros posts sobre o puppet com mais exemplos no futuro.