Automação de Infraestrutura com Puppet

Let the computer do the repetitious, the mundane – it will do a better job of it than we would. We’ve got more important and more dificult things to do.
Trecho retirado do livro Programador Pragmatico.

O profissional de desenvolvimento de software conta com um grande trunfo em sua manga que é frequentemente negligenciado, um trunfo que vem sendo utilizado vastamente por outras áreas em que sua complexidade é maior do que a encontrada na área de software. Com a automação pode ser alcançado o que economia chama de lucro, pois um profissional aumenta sua produtividade e a qualidade do que é produzido. Estes dois parametros trarão uma enorme mudança em sua carreira, então a partir deste momento se torne um profissional que se vale deste trunfo e se destaca dos demais, simplesmente aplicando em seu trabalho o que de melhor fazemos: automatizar tarefas.

Durante os ultimos anos vemos as práticas DevOps se tornando cada vez mais a cultura dos desenvolvedores e administradores. Neste artigo faremos uma comparação da utilização de uma das tecnologias de escrita de infraestrutura como código criada pela empresa Puppet, o produto escolhido se chama puppet-agent e vamos escrever em uma dsl de mesmo nome, que tenta tornar este processo tão simples como listar quais software serão utilizados.

#####Aplicamos esta prática em dois cenários:

#####Windows:

Neste cenário o cliente utiliza Windows, embora esta arquitetura seja compatível com ambientes linux o cliente tinha mais experiência com Windows e o utilizava em todos ambientes do desenvolvimento à produção. Para prover serviços de mapa e hospedar a aplicação web map é utilizado IIS 7.5, Geoserver, Postgresql e Postgis. Nós escolhemos o puppet-agent e o script será aplicado em uma maquina existente preparada para receber as instalações oriundas do script puppet.

O primeiro passo é instalar o puppet para poder executar o script, que como dito é uma dsl simples

A script que criamos é composta por resources, cada resource tem funções como: instalação de pacote, execução de comandos shell, agendamento de tarefas, administração de serviços, criação de usuários, operações no sistema de arquivos e etc.

Os resources podem ser combinados de forma a determinar qual é o resource requerido para que um outro seja executado, ou assim que determinado resource for executado ele pode notificar outro para que este seja executado.

Uma dificuldade ao utilizar o puppet para instalação de sistemas é que o windows não possui um gestor de pacotes, os instaladores são individuais e distribuídos individualmente por cada fornecedor. Desta forma o processo de instalação exige que em alguns casos seja utilizado o processo de instalação headless que é disponibilizado pela ferramenta de empacotamento utilizada pela empresa que provê o instalador do software. Infelizmente por não haver uma padrão isto é o que mais dá trabalho durante a redação do script.

Após as instalações é necessário configurar as aplicações instaladas, iniciar serviços ou agendar tarefas.

Basicamente utilizamos o resources exec, que permite executar comandos shell, o file, que permite copiar arquivos e o scheduled_task para agendar tarefas.

Com o exec nós configuramos o postgres, executamos os scripts sql de criação das feições espaciais, com o file copiamos arquivos, como por exemplo o diretório data_dir do geoserver e com o scheduled_task configuramos a tarefa de execução do geoserver.

Utilizamos também o Hiera para criar um arquivo de configuração externo e permitir que o script fosse executado independente dos diretórios em que os arquivos existiriam ou do local em que desejamos instalar.

A grande desvantagem foi o tempo que levamos para montar este script. É bastante trabalhoso e em por utilizarmos o windows neste cenário, tivemos pouca documentação disponível principalmente para as instalações headless de cada instalador. Porém quando este desafio foi ultrapassado a grande vantagem foi conseguir instalar com pouquissima dificuldade quatro maquinas diferentes, uma maquina na cloud (Windows Server 2012 R2 ) e três estações de trabalho com Windows 7. O primeiro grande beneficio é que temos a certeza que todas as maquinas possuem a mesma versão e configuração e uma vantagem é que nossa equipe é distribuída e podemos contar com o apoio de outros desenvolvedores que não estejam geográficamente perto e eles conseguirão replicar o ambiente com rapidez e poderão efetivamente apoiar o desenvolvimento do software.

#####Linux:

Montar a maquina servidora de um web map escrito em python e javascript, que consulta um banco de dados geográfico.

De cara podemos dizer que só há vantagens ao utilizar vagrant e puppet para montar ambientes em Linux (dist Ubuntu) não tivemos um décimo das dificuldades apresentadas no Windows e o tempo transcorrido para redigir os scripts foi muito menor.

O maior desafio que encontramos é que algumas versões disponíveis por padrão nos repositórios do apt-get podem estar com uma grande defasagem, o que pode induzir ao erro ao usar uma versão antiga que contém bugs que já foram resolvidos, porém uma vez que você configura o repositório correto do pacote e instala as versões mais recentes o restante é muito prático.

Nós utilizamos postgres e postgis e é excelente ter um repositório de pacotes, fizemos todas as configurações, criação do database e configuração da extensão postgis.

Uma novidade foi utilizar um provider diferente ao utilizar o resource package, pois utilizamos o pip3 para instalação dos pacotes python, porém não tivemos problema algum.

Não identifiquei desvantagens ao escrever o script puppet para uma maquina linux, basta ter atenção às versões que são instaladas pelos repositórios default do apt-get e na dúvida utilize o repositório da fornecedora do software.

Para não dizer que a experiência foi livre de problemas, perdemos um tempo para instalar corretamente o puppet, pois às maquinas ubuntu disponíveis não trazem mais esta instalação por padrão.

A grande vantagem neste caso é que a replicação para outros provider do vagrant se torna fácil, permitindo que eu utilize o virtualbox, vmware, amazon aws ou digital ocean.

Hubot e ChatOps

Vocês conhecem o projeto do github, o Hubot?

O hubot é um bot, capaz de te ajudar em diversas tarefas dentro da sua organização. Ele funciona recebendo comandos de uma sala, existente no seu sofware de mensagens instantâneas. Existem vários adaptadores, para programas, como Skype, slack e o mattermost, que é o software que usamos aqui.

Basicamente, você precisa de uma instância dele rodando em algum lugar e conectá-lo ao seu software de mensagens instatâneas.

Não vou entrar em detalhes aqui, pois o processo é diferente para cada software, mas é bastante fácil. Temos uma instância rodando no Heroku.

Deem uma conferida na documentação de como subir o bot, aqui.

Mas como vamos gerenciar nossos projetos?

Aqui na Sigma usamos o Gitlab como nosso gerenciador de repositórios. Não só repositórios, mas tudo mais que o Gitlab traz, de graça para você, como:

  • Usuários
  • Projetos
  • Issues
  • Milestones
  • Merge Requests (similar o Pull Request do Github)
  • Entre outras coisas bacanas!

O que fizemos foi criar um plugin para o Hubot, que escuta alguns comandos específicos, vai no Gitlab, faz as contas referentes ao andamento do projeto e responde no canal do Mattermost.

Bem bacana! Usamos isto para reportar para nosso clientes o andamento dos projetos e gerar gráficos como este aqui em baixo:

Burndown

O hubot, no entanto, pode escutar os seguintes comandos:

>

hubot gitlab search [termo]

hubot gitlab list projects (lista os projetos existentes no Gitlab)

hubot gitlab list milestones [project_id] (lista milestones do projeto)

hubot gitlab list issues [project_id] (list issues do projeto);

hubot gitlab progress [project_id] (gera a medida de progresso do projeto)

São poucos comandos no momento, mas estamos planejando expandir esse camarada. O bacana do hubot é que ele funciona muito bem com qualquer tipo de mensageiro instantaneo que possua um adaptador para ele, ou seja, isso pode ser aplicado mesmo se vocẽ não usa o slack ou o mattermost.

Um exemplo em funcionamento:

Gitlab Agile

É bem simples e dá estatísticas atualizadas!

Como sempre, publicamos nosso pacote no npm e ele é aberto em nosso Gitlab. O mesmo já foi puxado ~300 vezes, desde sexta-feira. É uma métrica e tanto para um projeto tão pequeno, mas acredito que deve ser útil para outras pessoas.

No nosso roadmap, ainda iremos implementar o cadastro de sprints, sua abertura e fechamento, bem como a geração inteira do gráfico através do hubot. Hoje só geramos as estatísticas, mas não é difícil gerar o gráfico completo.

E aí pessoal, curtiram? Fiquem a vontade para forkar, testar e adicionar novos comandos caso tenham interesse.

Template de história de Usuário

As histórias de usuários são ferramentas interessantes para se determinar quais são as funcionalidades reais de um sistema a ser construído.

Elas são breves, capturam as informações gerais e servem de documentação de alto nível para diversos outros produtos dentro da organização que constrói software.

Nós da SIGMA, construímos um pequeno template para ser impresso e que você pode levar com você para qualquer lugar. Este template será disponibilizado em nosso repositório, de forma gratuita.

O que são?

Histórias de Usuários são pequenos documentos que ajudam a descrever uma funcionalidade a ser implementada em determinado sistema.

Elas, através de uma única sentença, tentam capturar um requisito de negócio e seu valor para o negócio.

Estas histórias, geralmente são no seguinte formato:

  • Eu, como administrador do sistema, gostaria de delegar permissões a outros usuários, de forma que eles possam executar seu trabalho sem me incomodar;
  • Eu, como usuário, gostaria de abrir uma ocorrência, de forma que ela fique registrada e alguém possa resolver este problema;

As histórias, são geralmente escritas utilizando pequenos quadradinhos de papel com cola amarelos, ou os PostITs. No nosso caso, criamos um template para ser impresso e ser utilizado com papel e caneta.

Exemplo

Um exemplo prático completo, é o seguinte:

  • Título: Visualizar ocorrências em um mapa
  • Prioridade: A (na SIGMA usamos da letra A até a letra D para denotar prioridades, onde A é a prioridade mais alta e D a mais baixa);
  • Ação: Eu, como usuário do sistema, gostaria de visualizar as ocorrências em um mapa, de forma que eu possa otimizar a minha rota de atendimento;

Além desta seção básica, contendo estas informações, adicionamos uma área para você detalhar as tarefas necessárias para completar aquela história de usuário, bem como o número de pontos que cada tarefa e a história irão tomar.

Abraços!