Lançamento do 1.6.1 Docker com várias correções de segurança

Após diversas notificações de vulnerabilidades urgentes, a equipe de segurança do Docker resolveu lançar rapidamente uma nova versão com soluções para os casos reportados.

Segue abaixo as falhas encontradas, que já foram resolvidas na versão 1.6.1:

[CVE-2015-3629] Symlink traversal on container respawn allows local privilege escalation

O libcontainer da versão 1.6.0 introduziu mudanças que facilitaram a fuga da montagem do namespace no respawn do container. Isso permite que imagens maliciosas possam escrever arquivos no sistema host, ou seja, que escape do container.

Descoberto por Tõnis Tiigi.

[CVE-2015-3627] Insecure opening of file-descriptor 1 leading to privilege escalation

O file descriptor passado pelo libcontainer para o processo com PID 1 do container foi encontrado com possibilidade de ser aberto antes de ser executado o chroot, sendo assim permitindo abertura insegura de symlink traversal. Isso permite que containers maliciosos possam escalar o privilégio localmente.

Descoberto por Tõnis Tiigi.

[CVE-2015-3630] Read/write proc paths allow host modification & information disclosure

Muitos caminhos abaixo de /proc estavam com permissão de escrita para o container, permitindo a manipulação de configurações globais do sistema. Esses caminhos incluíam /proc/asound, /proc/timer_stats, /proc/latency_stats, e /proc/fs.

Ao permite escrita no /proc/fs, verificou-se que volumes CIFS podem ser forçados a um “protocol downgrade attack” por um usuário root no sistema operacional dentro do container.

Descoberto por Eric Windisch do time de segurança do Docker

[CVE-2015-3631] Volume mounts allow LSM profile escalation

Ao permitir que volumes possam sobrescrever arquivos do /proc dentro de um namespace, um usuário pode específicar arbitrariamente politicas para o módulo de segurança do Linux, incluindo setar uma política de não-confinada sob o AppArmonr ou uma política “docker_t” que seria gerenciada pelo SELinux.

Descoberto por Eric Windisch do time de segurança do Docker

Todas as falhas foram corrigidas no Docker 1.6.1! Usuários que utilizam imagens inseguras estão encorajados a atualizar o seu docker urgentemente.

Atualizando seu Docker no Debian

É muito simples, basta executar os comandos abaixo:


# wget http://ftp.br.debian.org/debian/pool/main/d/docker.io/docker.io_1.6.1+dfsg1-1_amd64.deb
# dpkg -i docker.io_1.6.1+dfsg1-1_amd64.deb
# rm docker.io_1.6.1+dfsg1-1_amd64.deb


Monitorando automaticamente o Docker com Zabbix

Docker é uma ferramenta perfeita para criar automaticamente ambientes para novos serviços. Esse processo de criação é muito fácil e em alguns casos é feita automaticamente por outra ferramenta ou script.

Monitore para evitar surpresas

Problemas podem acontecer e a equipe de TI precisa estar preparada para descobrir isso antes que cause indisponibilidade.

Problema

Como o time de monitoramento poderá acompanhar esse rápido processo de criação e manter todos esses ativos no sistema de monitoramento? Nos precisamos monitorar automaticamente todos os containers.

Solution

Eu desenvolvi alguns scripts para listar containers, adicionar eles no Zabbix usando a funcionalidade LLD e monitorar todos esses novos hosts.

Infelizmente nos precisamos de acesso especial para monitorar essas informações no Docker, por conta disso eu usei sudo e job cron do root.

Abaixo os itens monitorados por essa solução:

• Porcentagem de CPU usado
• Porcentagem de memória usada
• Bytes enviados e recebidos por segundo
• Pacotes enviados e recebidos
• Pacotes enviados e recebidos, mas descartados
• Pacotes enviados e recebidos com erros

Quer conhecer a solução antes de testar? Olhe esse vídeo!

Eu testei no seguinte ambiente:

• python 2.7.9
• docker 1.6
• zabbix agent and server 2.4

Se você testar em um diferente, por favor me avise.

Lançamento do Docker 1.6

O Docker continua crescendo muito rápido e com pouco mais de 2 meses, lança uma nova versão recheada de novidades.

Entre as novidades desse lançamento temos: Label para containers, cliente Docker para Windows, driver para log. Isso sem contar com os lançamentos do compose 1.2, Swarm 0.2 e machine 0.2. Vamos detalhar um pouco esse mega release.

Label para containers

Esse recurso é muito interessante a nível de organização e agrupamento. Uma vez que as tags tem um papel quase como “versionamento”, as labels assumem a marcação que pode incluir “assuntos”, “funcionalidades”, “ambiente” e afins nos containers. Pode parecer pouca coisa para quem usa o Docker para uma situação específica, mas para grandes soluções é uma ajuda e tanto.

Quer aprender a usar? Leia aqui.

Cliente Docker para Windows

Finalmente parece que a Microsoft conseguiu entrar em alguma tendência no momento certo, pois está apostando fortemente no Docker. A demonstração disso foi a submissão de 70 pull requests. Assim como no MAC, O Windows somente poderá ser utilizado como cliente remoto que deve ser conectar a um Docker “Server”, que ainda é só pode ser instalado nativamente apenas no GNU/Linux.

Muitos amantes do GNU/Linux podem ficar tristes com essa declaração, mas a grande funcionalidade do Docker que é “Faça uma vez, rode em qualquer lugar” talvez dependa desse suporte nativo mais amplo da Microsoft. Isso levando em consideração que ela cumpra sua promessa de manter a compatibilidade.

Você pode ler mais sobre isso no blog da Azure.

Driver para log

Tem havido um número crescente de propostas para uma API de registro que lhe permitiria enviar logs de containers para outros sistemas, como Syslog ou um terceiro. Esse novo driver de log  segue o mesmo conceito de storage e exec já presente no Docker.

A opção docker run –log-driver tem três possibilidades:

json-file (padrão): Que é basicamente o que já usado no Docker atualmente. Todos os logs dos containers são armazenados na pasta /var/lib/docker/containers/<Containers ID>/<container id>-json.log

syslog: Como o próprio nome já revela, é uma forma de enviar esse log via syslog do host “hospedeiro”. Veja como funciona:

# docker run -d –log-driver=syslog gomex/debian:padrao echo “Hello”
c2ed7a98583c82a90111ffba5fb89e73dcd6e681a03c921da538a84ffd7216d0

No /var/log/syslog estará assim:

Apr 17 23:29:18 gondor docker[15432]: c2ed7a98583c: Hello

Perceba que temos tanto o nome aplicação docker como o ID resumido do container, o que é o suficiente para fazer uma boa gerência desse log. Ótimo para quem deseja minimizar o máximo de processos em execução no container, mas não abre mão de um log centralizado e organizado.

none: Como o próprio nome também já revela, é uma forma de não gerar log do container para o host “hospedeiro”. Essa opção é ótima para containers que geram logs desnecessários.

Outros lançamentos

A comunidade Docker promoverá alguns Meetups para apresentação das novidades do Swarm, Compose e Machine. Não perca!

Referência:

https://blog.docker.com/2015/04/docker-release-1-6/

Docker poderia substituir o gerenciador de pacotes?

A utilização de containers, que tem hoje o Docker como principal representante, tem aumentado rapidamente com sua facilidade e portabilidade de liberação de aplicações prontas. Com base nisso, fica a seguinte pergunta: “Poderia a tecnologia de containers, como o Docker, ser utilizada para resolver o nosso antigo problema com gerenciador de pacotes? Alguns acreditam que containers podem ser um caminho para resolver a “dor de cabeça” no gerenciamento de dependência e incompatibilidade entre distribuições e versões do mesmo sistema.

Gerenciamento de pacotes no GNU/Linux sempre foi uma dor de cabeça para algumas situações.

No campo do “sim”: O pessoal do CoreOS, que são criadores de uma distribuições GNU/Linux, que gira inteiramente em torno de containers, e não dos pacotes, como unidade básica de modularidade.

Kelsey Hightower, Engenheiro Chef do CoreOS, diz que a empresa oferece “prova viva que não é apenas possível, como pode lidar melhor com designer de sistema e eficiência.” Contudo ele acredita que gerenciador de pacotes ainda é utilizável, “principalmente para construção de um sistema operacional a partir de um conjunto discreto de componentes que devem executar em conjunto. Esta é uma área onde os gerenciadores de pacotes do GNU/Linux brilham.” CoreOS não utiliza um gerenciador de pacotes típico, como apt ou yum, mas sim um sistema portage.

Kelsey alega que substituir inteiramente um sistema de gerenciador de pacotes de proposito genérico para o Docker ou outro gerenciador de container pode ser difícil, em parte porque o Docker não tem mecanismo para solucionar dependência. “Onde Docker brilha é no empacotamento e distribuição de aplicações” ele diz. (Docker se recusou a responder esse artigo, alegando restrição de tempo.)

Com ênfase maior da Red Hat em containers, é lógico que a empresa também poderá ver containers como um substituto para o gerenciamento de pacotes.

Lars Herrmann, gerente geral do “Red Hat Enterprise Linux” e “Red Hat Enterprise Virtualization” na Red Hat, acredita que é possível que o gerenciador de pacote seja substituído por containers, “mas esse não é o melhor caminho”.

Além da gerência de dependência, diz Herrmann em um email, que um gerenciador de pacote provem mais três outros “boons”: Instruções de onde será instalado o software em seu sistema, metadados estruturados para tornar fácil dizer o que e onde será instalado, e um mecanismo para verificar softwares instalados com base no metadado do gerenciador de pacotes.

Herrmann diz “Estes valores aplicam-se ainda em um mundo ‘container-centric’ ” O que significa que todas essas funções precisam ser replicados pelos containers. “Além disso, é preciso haver uma maneira fácil de ‘olhar’ para dentro desses containers, afim de verificar o que está lá dentro, e assim identificar quaisquer problemas conhecidos.”

Da mesma forma, o gerenciamento de pacotes abrange funções internas que os próprios containers ainda não lidam. De acordo com Herrmann, o Docker “agrega os pacotes para uma aplicação ou microservice inteiro; isso não ajuda obter os componentes certos para um container de forma funcional. Obviamente, essa tarefa não requer diretamente os gerenciadores de pacotes existentes, mas eles fazem um grande trabalho, então por que não usá-los?

Bryant Cantrill, CTO da Joyent (outra empresa até o pescoço no mundo do container) Também vê os containers e gerenciadores de pacotes servindo para funções separadas, desde que “uma imagem Docker está em uma camada de abstração mais elevado do que um pacote apt ou yum” Ele escreveu isso por e-mail.

Dito isso, ele acredita que o Docker poder tornar o empacotamento obsoleto, como o gerenciamento de pacote fez obsoleto a forma manual de desempacotar arquivos (como arquivos TAR) e assim se tornar um novo padrão de formato para aplicações. “Um engenheiro que conheço a muito tempo, coloca o Docker de forma diferente: Docker é ELF do século 21. (ELF é o ‘Executable and Likable Format‘ que é como o binário é representado em sistemas UNIX) De qualquer maneira, Docker parece prestes a se tornar o padrão de fato para a forma como se cria imagem para sistemas. Eu acho que isso é uma clara vitória tanto para desenvolvedores, como para os operadores de infraestrutura.”

Esse artigo é uma tradução livre do artigo “Could Docker replace package management?” da Infoworld. Encontrei esse artigo e achei interessante para levantar esse debate. Comentem, o que acham disso? Realmente o Docker, ou qualquer outro gerenciador de containers pode ser um sucessor do gerenciador de pacotes?

Minha opinião

Eu acho que containers é um bom caminho para “tornar” obsoleto o gerenciamento de pacotes, mas ainda não está pronto. As duas soluções vão coexistir durante algum tempo, mas realmente acho que o nível de abstração subirá um pouco mais em médio prazo, pois não acredito que teremos tempo para resolver manualmente instalações de dependência para soluções complexas.

Assim como hoje é possível compilar os pacotes manualmente, acho que no futuro continuaremos podendo instalar “da moda antiga”, mas o uso da solução de containers prontos, customizáveis e portáveis será quase uma necessidade. Talvez isso faça o conceito de distribuição perder relevância, mas é algo que ainda não tenho como certo em minha reflexão ainda e fica para outro texto.

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.