Embarque na viagem das cooperativas do ano

Em Novembro de 2014 a Colivre, cooperativa de tecnologias livres, empresa na qual sou sócio ganhou o prêmio de cooperativa do ano 2014 na categoria de Inovação e Tecnologia, este prêmio nos deu o direito a uma viagem de integração entre as cooperativas vencedoras, nesta viagem a Colivre foi representada por mim e Daniela Feitosa, neste post faço um breve relato desta viagem.

No dia 24 de Março chegamos a Brasília, lá visitamos a OCB, fomos recepcionados por Fernanda Belisário e Gabriela Prado, elas nos deram boas-vindas e convidaram para assistir a uma palestra de Martha Gabriel sobre estratégia de marketing, Marta falou da importância de cuidar da sua marca, pegadas digitais, sombra e diversos outros conceitos de marketing.

No mesmo dia, à noite, houve o lançamento da Agenda Institucional do Cooperativismo 2015 com a presença de representantes da Ocergs-Sescoop/RS, sistema OCB, senadores, deputados, presidentes e superintendentes de unidades estaduais. A agenda apresenta as principais demandas do sistema cooperativo Brasileiro aos poderes Legislativo, Executivo e Judiciário para o ano de 2015.

No dia 25, já em Porto Alegre, visitamos a Escoop - Faculdade de Tecnologia do Cooperativismo, lá ouvimos uma bela apresentação do senhor presidente do Sistema Ocergs-Sescoop/RS, Vergilio Perius, explicou sobre o sistema cooperativista, explanou sobre o surgimento das cooperativas no Brasil e nos ensinou bastante sobre os 7 princípios do cooperativismo, dando destaque especial a importância da intercooperação.

Em seguida o coordenador Derli Schmidt detalhou o funcionamento e a missão da escola, mostrando os cursos disponíveis e a metodologia de ensino altamente preocupada com a qualidade do ensino, com um viés acadêmico, preocupada em produzir conhecimento inédito e de qualidade sobre cooperativismo no Brasil. Nossa visita foi noticiada no site da Ocergs/RS.

No dia seguinte, 26 de Março, visitamos a Sicredi Pioneira, fomos recebidos pelo senhor Mário José Konzen, vice-presidente da cooperativa, ele nos falou sobre o início do sistema Sicredi e a força do movimento cooperativista na cidade de Nova Petrópolis/RS, a “Capital Nacional do Cooperativismo”. Citou detalhes do programa “A união faz a vida”, uma iniciativa do Sicredi com o objetivo de promover práticas de educação focadas nos princípios da cooperação e cidadania.

Em seguida, Mário Konza, nos convidou a conhecer a Cooebompa, uma cooperativa escolar formada por alunos da Escola Bom Pastor, uma iniciativa interessantíssima que deixou todos os representantes das cooperativas campeâs com os olhos brilhando de emoção. Tivemos a oportunidade de assistir a Assembléia Geral Ordinária e ver um show de organização e determinação! O professor e coordernador do projeto, Everaldo Marini, faz um belo trabalho e merece todo o apoio possível para continuar com o projeto.

Da lá seguimos ao Memorial Padre Amstad, o senhor Mário nos falou da vida desde padre, criador do sistema de crédito cooperativo no Brasil.

Na sequência visitamos a Cooperativa Piá, uma cooperativa agropecuária de leite e frutas, o presidente, Gilberto Kny, relatou a história da cooperativa e destacou a preocupação com os seus associados, em sua maioria pequenos produtores. A nossa comitiva experimentou alguns dos produtos da Piá, como iogurte e leite achocolatado, todos acharam uma delícia, infelizmente não pude experimentar já que não consumo leite ou derivados. A Piá bem que poderia produzir algo à base de soja ou alguma alternativa ao leite.

Saindo da Cooperativa Piá fomos conhecer um dos produtores associados, conhecemos a fazenda “Sítio do Leite”, eles produzem leite e dizem que fazer parte da cooperativa facilita a vida pois não precisam se preocupar com a venda já que a Piá garante a compra de toda a produção.

Dia seguinte, 27 de Março, último dia de viagem, visitamos o CAS, Centro Admistrativo Sicredi, vimos o funcionamento da cooperativa, seus princípios e valores, conhecemos a Biblioteca do sistema e o Datacenter. O Datacenter ocupa um andar inteiro do prédio e tem uma infraestrutura impressionante, mantida inteiramente pela equipe do Sicredi.

Ainda no Sicredi, seguimos para um almoço em grupo e partimos para o aeroporto de volta para casa chegando ao fim desta viagem ao mundo cooperativista na presença de ótimas pessoas, dedicadas a criar um mundo melhor, mais humano, mais justo, mais cooperativo.

Deixo um agradecimento especial ao sistema OCB pela ótima organização do evento e pelo convite, Belmira Oliveira, Fernanda Belisário, Gabriela Prado, Igor Vianna, Patricia Resende e Sheila Malta Santos.

Muito obrigado!

Agradeço também a todos os membros da nossa comitiva, representantes das cooperativas campeâs, foram momentos de muito aprendizado:

• Leonel Fernandes e Celio Humberto da Coopatos
• Amauri Weber e Michael Bueno da Sicredi Vale do Piquiri
• Shirley Rodrigues e Ana Paula Ramos da Querubim Saúde
• Édio Signor e Daniel Cremonese da Coopercarga
• Irinaldo Barreto e Márcio Antônio da Coopertransc

Um agradecimento especial a Sheila Malta Santos (OCB) pela imagem utilizada no título deste post, este desenhado foi criado por ela durante o vôo de ida ao evento.

Valeu Sheila, ficou muito bom!

O porquê de escolhermos o Puppet

Na organização que trabalho foi colocada a demanda de implantar um ferramenta de gerência de configuração, pois nosso ambiente sofre de uma grande carência em documentar suas mudanças, proporcionar uma documentação atualizada, isso sem falar na velocidade de atendimento de novas demandas ser prejudicada pela necessidade de atividade repetitiva/operacional majoritariamente manual.

Depois de uma longa etapa de analise preliminar iniciamos a comparação entre três soluções que poderia atender nossas expectativas: Chef, Puppet e Salt.

Escolher nem sempre é uma tarefa fácil

Dentre vários critérios analisados, levantamos cinco pontos que julgamos ser os mais relevantes para nossa realidade:

• Complexidade de instalação
• Curva de aprendizado
• Orquestrador
• Dashboard
• Quem utiliza

Com base nisso, instalamos cada solução, testamos o que ela poderia fazer para nos ajudar e refletirmos com base nos pontos já informados acima. Segue abaixo o resultado da nossa análise.

Complexidade de instalação

Puppet

A instalação dos pacotes puppetmaster(servidor) e puppet(clientes) na sua versão open-source não revelou-se muito complicada. Sua documentação oficial orienta inicialmente instalar o pacote puppetlabs-release com a versão referente ao sistema operacional. A única ressalva com relação à essa etapa é a escolha do pacote para o servidor, pois o puppetmaster é recomendável somente para ambiente menores, com pouca carga, pois seu servidor web embutido (webrick) suporta poucos nós clientes para um ambiente mais escalável deve-se optar pelo puppetmaster-passenger.

Apesar de orquestrador ser um critério analisado mais adiante, a complexidade de sua instalação está dentro do escopo desse critério. Embora a documentação oficial não faça nenhuma recomendação explicita ao uso do MCollective como orquestrador na versão Opensource, na Enterprise ela já vem embutida, somando isso ao fato dele já possuir plugins nativos para o Puppet pesou na escolha dessa ferramenta para a tarefa de orquestração.

Na versão Opensource do Puppet, o orquestrador não é configurado por padrão, houve um esforço maior na sua instalação e configuração. Há dependência da instalação e configuração de um Midleware, sistema de mensageira (Apache ActiveMQ).

Tivemos dificuldade com relação a falta de orientação para cenários mais complexos, por exemplo, com relação a questão de segurança na comunicação do midleware.

Salt

Basta instalar os pacotes salt-master(servidor) e salt-minion(clientes), fazer uma simples configuração para que os nós clientes reconheçam o master, posteriormente o master autenticar chaves publicas dos clientes e o ambiente já estará pronto para ser utilizado.

O orquestrador faz parte da solução Salt, sendo assim, a facilidade na instalação apresentada até então abrange também o orquestrador.

Chef

Sua instalação, com a exceção do cliente (chef-client), foi dificultada por alguns fatores.

• Na topologia cliente-servidor, o chef se diferencia das demais em virtude dele ser composto por 3 itens: Server; Workstation e Nodes, que apesar da documentação oficial explicar a função de cada um deles, a mesma não dá uma orientação sobre sua instalação.
• Com relação ao pacote para servidor (chef-server), no site oficial é disponibilizado apenas para Ubuntu e RHEL, e eles não demonstram nenhum interesse manter uma versão para o Debian no lado do servidor.

Conclusão desse critério

Adotando a topologia cliente-servidor, visto que todas os softwares analisados permitem também a opção standalone, ou seja, em modo autônomo, o Salt demonstrou-se a mais simples, o Chef mais complexa, ficando o puppet com complexidade intermediária. A opção pelo modelo cliente-servidor foi feita em virtude da gerência centralizada e a possibilidade do acompanhamento das modificações nos agentes através de um painel (dashboard), item que será melhor detalhado mais adiante.

Curva de aprendizado

Antes de iniciarmos a discussão desse critério, faz-se necessário a contextualização de alguns aspectos sobre gerenciamento ou automação de configurações, referentes aos três softwares examinados.

Em todos eles, as configurações são codificadas estaticamente através de arquivos chamados: Manifest no Puppet, Formulas no Salt e Cookbooks no Chef. Nessa parte não houve muita dificuldade de compreensão, não necessitando de um conhecimento muito avançado à nível de programação ou de linguagem específica, apesar de que, no Chef os Cookbooks podem ser escritos também em Ruby puro.

O interessante é que em todos eles utilizam algum conceito de linguagens de Orientação à Objetos como por exemplo, suporte a funcionalidade de heranças.

Outro detalhe não menos importantes e bem intuitivo, consiste em que todos eles possuem utilitários responsáveis pela obtenção de informação dos agentes: Facter no Puppet, Grains no Salt e Ohai no Chef, com os quais descrevem as propriedades dos sistemas operacionais, permitindo filtros na definição de estados das configurações assim como na orquestração.

Nesse critério, houve um empate técnico, pois todas são semelhantes no que diz respeito às definições de gerenciamento ou automatização de configurações, com perspectiva bastante compreensíveis.

Orquestrador

Segundo o Guto Carvalho (slide 5 da palestra Orquestração com MCollective): “Orquestrar significa invocar ações de forma paralela ou não, em tempo real, em diversos servidores de um datacenter, fazendo isto de forma automatizada, eficiente e controlada”. Orquestração não é gerenciamento de configuração e sim um tipo diferente de automatização em que ambos se complementam. Diferencia-se da seguinte forma, enquanto que na gerência de configurações, os estados desejados de um sistema é modelado, na orquestração, as ações são executadas remotamente sob demanda.

Nesse critério somente o Puppet e o Salt serão discutidos, visto que o Chef não possui orquestrador integrado como no Salt, nem mesmo tem em sua documentação alguma menção à nenhum utilitário externo desse tipo, como o Puppet tem o MCollective como exemplo, no seu caso, o uso da ferramenta como o knife com ssh, a qual está mais para execução remota, seria o que mais se aproximaria de orquestração.

Puppet

O MCollective, orquestrador adotado pelo mesmo, é uma ferramenta bem simples de utilizar, com bastantes plugins disponíveis, inclusive para o próprio Puppet. Ele disponibiliza diversas funcionalidades, como instalação de pacotes, gerência de serviços, shell (interpretador de comandos) e etc, além de ser extensível através de protocolo RPC. A complexidade de sua instalação, pelo fato do mesmo ser um outro software(pacote), com configuração própria e necessidade de instalar um pacote agent e client para cada plugin disponível, somando-se a depência de um midlleware, no caso o ActiveMQ, que também demanda uma instalação separada.

Salt

No Salt, da mesma forma que o MCollective, seu orquestrador, disponibiliza uma infinidade de módulos, oferecendo funcionalidades como: instalação de pacotes, gerência de serviços, shell (interpretador de comandos) e etc. além de ser extensível. O fato de já vir integrado e configurado, inclusive com seu middleware (ZeroMQ) cuja a leveza de sua biblioteca serve como framework de concorrência, sem falar no fato da comunicação ser nativamente segura entre o master.

Conclusão desse critério

o Salt levou uma grande vantagem nesse item, por essa funcionalidade já vir integrada e utilizar técnicas que permitem escalabilidade e velocidade na execução remota de suas tarefas, com uma linguagem bastante homogênea em virtude de sua agregação, ao contrário do MCollective no Puppet, ficando em segundo lugar como opção nesse item.

Dashboard

Após toda contextualização sobre automatização ou gerenciamento de configurações e orquestração, esse item é de fundamental importância para o nosso ambiente. O envio de relatórios, classificação externa e acompanhamento do ciclo de vida dos ativos em tempo real, ou seja, toda a visibilidade do que acontece no nosso ambiente após aplicação de alguma nova configuração. Tudo isso é esperado em um Dashboard.

Nesse quesito apenas uma ferramenta externa atendeu nossas expectativas. O Foreman é a ferramenta ideal para nosso ambiente, pois consiste em um gerenciamento do ciclo de vida desde provisionamento, configuração para orquestração e monitoramento. Tem interação nativa com o Puppet e sua interface web oferece várias informações com gráficos e formatos bastantes intuitivos, assim como muito mais recursos que os prórpios painéis oferecidos pelos próprios projetos das três ferramentas observadas.

A documentação do Foreman mencionar suporte também para o Salt e Chef, mas com limitação de certos recursos, isso sem falar na interação nativa que ele tem apenas com o Puppet, a qual contribuiu para promovê-lo como opção mais vantajosa em comparação às outras duas ferramentas nesse item.

Quem usa

Observamos quais as organizações/empresas que usam todas as três soluções e chegamos a conclusão que o Puppet tem um conjunto de usuários mais próximos da nossa organização, além de ter um número de “grandes players” bem superior as outras.

Conclusão final

Com base em tudo que foi explanado até então, principalmente no que tange a quem usa a ferramenta e existência de um ótimo suporte ao Dashboard que atende nossas expectativas, fica evidente que a solução que mais atende nossa necessidade é de fato o Puppet, mesmo o Salt tendo demonstrado ser uma alternativa bem mais simples.

Fonte

Esse texto foi construído com base no relatório final apresentado pelo bolsista Péricles Júnior, que trabalha na Coordenação de Redes e Infraestrutura de Superintendência de Tecnologia da Informação da Universidade Federal da Bahia.

Criando imagens Docker (Dockerfile)

No artigo anterior sobre Docker, eu falei sobre como modificar uma imagem docker usando COMMIT, mas propositalmente não comentei que essa não é a melhor prática Evitei tocar nesse assunto para não frustrar o aprendizado, pois é necessário aprender como funciona o COMMIT, com DIFF e afins.

A melhor forma de modificar uma imagem Docker é recriando ela, ou seja, modificando seu Dockerfile, ou criando um Dockerfile com a imagem escolhida como base e nesse artigo falaremos sobre tudo isso.

Dockerfile

Dockerfile é um arquivo, que contém um conjunto de instruções necessárias para se criar uma imagem Docker, ou seja, com posse do Dockerfile de uma determinada imagem, basta modificar o que deseja e recriar a imagem “do zero”, isso pode demorar um pouco mais, mas essa imagem será muito mais “enxuta” e você terá controle total do seu estado, o que seria bem mais difícil no modelo de efetuar commit de um container.

Caso não tenha o Dockerfile, você pode usar uma imagem a sua escolha como base e então criar a sua imagem como uma camada acima.

Sintaxes básicas

FROM : É a imagem base. Normalmente é usada com nome de distribuição (Debian, Ubuntu e afins), pois não precisaremos criar toda estrutura, certo?

MAINTAINER : É onde se especifica o autor da imagem.

RUN : São as instruções que serão executadas para criação da imagem em questão.

ENTRYPOINT : Especifica o que o que será executado ao iniciar o container. Ele age como precedente a sintaxe CMD, ou seja, caso o ENTRYPOINT seja “top”, o CMD pode ser “-b” que nesse caso ele executaria o top em modo batch. Uma vez que o ENTRYPOINT não seja especificado, e um CMD seja usado, o ENTRYPOINT padrão é “/bin/sh -c“.

EXPOSE : Usado para informar qual porta o container docker irá “escutar”. Docker use essa informação para interconexão entre containers, ao utilizar links. EXPOSE não define qual porta será exposta para o hospedeiro ou tornar possível o acesso externo para portas do container em questão. Para expor essas portas utilize em tempo de inicialização da imagem a flag -p ou -P.

Para explicação mais exaustiva das sintaxes já explanadas e outras novas, acesse essa documentação.

Exemplo

Crie uma pasta com o comando abaixo:

# mkdir nginx


Entre nessa pasta:

# cd nginx

E então crie um arquivo chamado “Dockerfile” com o seguinte conteúdo:

FROM debian
MAINTAINER Rafael Gomes <gomex@riseup.net>
RUN apt-get update
RUN apt-get install -y nginx
ENTRYPOINT ["/usr/sbin/nginx"]
EXPOSE 80

Com esse Dockerfile, temos:

• Uma imagem com base na imagem do Debian, ou seja, não precisamos nos preocupar com o sistema básico.
• O autor dessa imagem sou eu
• Primeiro eu atualizo a base do apt-get e então instalo o nginx.
• Ao iniciar essa imagem ela executará o nginx automaticamente.
• A porta exposta para possível interconexão entre containers é a porta 80.

Nesse link tem um ótimo documento explicando as boas práticas na criação de um Dockerfile.

Criando a imagem

Com o Dockerfile preenchido, execute o comando abaixo para criar sua imagem:

# docker build -t gomex/nginx .

No lugar de “gomex” coloque o seu usuário da nuvem pública do docker e no lugar de “nginx” o nome da sua imagem.

Ao terminar, pode efetuar o push para a nuvem pública e assim proporcionar a distribuição da sua imagem:

# docker push gomex/nginx

Pronto! Agora já tem sua imagem prontinha, totalmente “enxuta” e disponível para que outra pessoa possa baixar e utilizar.

Por hoje é só pessoal, logo teremos mais artigos sobre Docker. Fiquem atentos.

Modificando e distribuindo “máquinas” Docker

Como relatei nesse artigo, um dos objetivos do Docker é sua facilidade para distribuição de imagens/”máquinas”, mantendo a sua portabilidade e simplicidade

Nesse texto, vou demonstrar como podemos modificar as imagens, que muitos chamam de máquina, e então distribuir via nuvem pública do Docker.

Iniciando a máquina

Para modificar uma imagem, precisamos que ela seja iniciada e então teremos a camada que chamados de container. Que é onde as mudanças são aplicadas. Para iniciar a “máquina” usa-se o comando abaixo:

# docker run -d -p 80:80 nginx

Agora vamos obter o número de identificação do container com o comando abaixo:

# docker ps

Modifique a máquina

Execute as modificações que deseja nessa “máquina”. Com o comando abaixo é possível acessar o shell da máquina recém iniciada.

# docker exec -it <id do container> bash

Verifique o que mudou

Para verificar quais arquivos de fato foram modificados nesse container. Execute o comando abaixo:

# docker diff <id do container>


Aplique a mudança

Agora que tem certeza sobre a mudança que será feita. Vamos criar uma nova imagem com base no estado desse container com o comando abaixo:

# docker commit <id do container> gomex/nginx-modificado


Atente que o termo “gomex” é meu usuário previamente registrado na nuvem pública do Docker. E tudo que vem depois da “/” é o nome da imagem que desejo criar. Com o comando abaixo será possível conferir que a máquina informada foi criada:

# docker images


Compartilhe

Agora vamos disponibilizar essa imagem para que outras pessoas possam baixar e usufruir da sua colaboração. Para isso usa-se o comando abaixo:

# docker push gomex/nginx-modificado

Acesse a nuvem pública do Docker e verá que sua imagem estará disponível para quem quiser baixar.

Docker facilitando o trabalho colaborativo.

Pronto! Por hoje é só Aguardem novas postagens sobre o Docker.

rrg: visualize the require hierarchy in Ruby projects

Yesterday I was hacking on some Ruby code and getting a weird error which I thought was caused by mutually recursive require statements (i.e. A requires B, and B requires A). Later I realized that this is not an issue in Ruby, since the intepreter keeps track of what has already been required and will not enter a loop. But during the investigation I came up with something that turned out to be useful.

rrg will read the source code of a Ruby project and generate a graph based on the require statements in the code; nodes represent the source files and an arrow from A to B means that A contains a `require ‘B’` statement.

From the README:

Just run rrg at the root of your project. rrg will parse the code inside lib/, and generate a graph description in the Graphviz format. You can pipe the output to Graphviz directly, or store it in a file and process it to generate an image.

If you call rrgv instead, it will automatically process the graph with Graphviz, generate a PNG image, and open it.

Let’s see some examples. First the classical “analysing itself” example, the require graph for rrg itself:

Not very interesting, since all of the logic is currently in the main binary and not on library code. But 1) when I do the refactorings I want to, there will be more library code and 2) while writing this I implemented also parsing scripts in bin/.

Now chake which is a slightly larger project:

An even larger (but still not that big) project, gem2deb:

Note that these visualizations may not be accurate representations of the actual source code. In Ruby, nothing stops one from implementing class A::B in lib/x/y.rb, but most reasonable code will make sure that filenames and the classes namespaces actually match.

If you are working on a sane codebase, though, visualizing graphs like this helps understand the general structure of the code and perceive possible improvements. The gem2deb graph gave me some ideas already and I didn’t even paid much attention to it yet.

Freeing myself from flickr

C#2

Vai passar... é só uma frase.