Existe algum motivo para usar o Puppet ao lado do Docker?

Question

Eu já experimentei o Ops parte do DevOps há algum tempo e foi muito divertido, mas eu não tenho tempo e motivo para experimentá-lo em qualquer projeto. Mas na semana passada eu comecei um novo trabalho, onde o chefe me perguntou se eu poderia configurar o servidor para fazer algo como o ambiente de preparação para projetos da empresa. Juntamente com isso, comecei a pensar em migrar o projeto para ser mais DevOps do que apenas dev.

Eu saí com o Docker, o que é ótimo e super fácil para mim. Mas há algum tempo atrás eu estava tentando Puppet, então a pergunta vem à minha mente: "Existe alguma razão para usar o Puppet with Docker?". O Docker parece fazer todas as coisas que o Puppet faria, mas de maneira mais fácil.

PS Algum tempo atrás, no Hacker News, havia Cônsul , que é uma boa configuração e descoberta de serviço, então até mesmo a configuração pode ser resolvida (e estou pensando sobre como implementar isso também).

    

Answer 1

O fantoche e o docker podem fazer muitas das mesmas coisas, mas eles os abordam de uma maneira diferente.

O Puppet gerencia arquivos + pacotes + serviços. (Chamado de trifeto). O Docker encapsula binários e arquivos de configuração dentro de um contêiner.

No momento da redação deste artigo, o docker ainda é instável e não deve ser usado na produção. Muitas das APIs provavelmente serão alteradas até que a versão 1.0 seja lançada.

Mesmo quando o docker se torna estável, será uma grande tarefa converter todos os processos e arquivos de configuração em contêineres docker.

O Puppet, por outro lado, é um produto estável e vem com todo um ecossistema de ferramentas (heira, mcollective, facter, razor). Essas ferramentas podem ser implementadas rapidamente e sem preocupação de quebrar coisas.

Eu sugiro os seguintes recursos.

Um vídeo sobre como gerenciar pilhas de aplicativos com o fantoche link

Um podcast sobre como o docker e o fantoche podem funcionar juntos link

Um artigo de blog sobre fantoches sobre como se integrar ao docker
link

Outro artigo do blog sobre coexistência de fantoches e janelas de encaixe link

Um módulo de fantoches para interagir com o docker link

Uma pequena correção na terminologia de devops. O Devops é mais uma metodologia de desenvolvimento de software , na qual os desenvolvedores e as operações cooperam, do que qualquer ferramenta específica.

Atualizar

Atualmente, minha empresa usa fantoches e janelas de encaixe. Aqui está uma grande apresentação dada no conf de fantoche 2014 sobre por que você usaria marionete vs docker. Dado por James Turnbull, um ex-empregador de puppetlabs e autor do livro de docas.

link

Também um bom tutorial em vídeo sobre o docker fornecido pelo sysadmincasts.com

link

Docker Pros:

• Pode acelerar a instância rapidamente
• Mais fácil de aprender do que fantoche
• Fácil de fazer 0 tempo de inatividade

Contrapartes Docker:

• Os contêineres têm um limite de 10 GB ao usar o backend devicemapper
• Pequenas alterações na configuração demoram muito tempo para reconstruir o contêiner
• Custa dinheiro para usar um registro do docker como o hub.docker.com, quay.io (o registro do docker auto hospedado é extremamente problemático e não tem nenhum GUI)
• Nenhum sistema init adequado. Algumas aplicações não são legais.
• Sem controle refinado sobre a rede
• Aplicativos que exigem subshells (olhando para você RVM + ruby) são muito complicados para trabalhar corretamente
• Não é possível gerenciar hosts do Windows, nenhum SLES ou outros sistemas operacionais menos populares
• Atualmente, a orquestração do docker é muito nova.
• Atualmente não é possível definir seu /etc/resolv.conf no momento da criação
• Vários bugs que temos para montar o / etc / localtime e / dev / urandom para mapear os diretórios localtime e urandom do host.
• O desempenho não é tão rápido (apesar de todas as afirmações de que o docker deve ser 99% da velocidade do bare metal, às vezes é 30% mais lento que outras máquinas).
• Pequenos contêineres ainda têm centenas de megabytes de sobrecarga. Nossos contêineres são todos de vários gigabytes.

Profissionais de fantoches:

• Fácil de dimensionar
• Funciona com servidores existentes (windows, linux, sles)
• Rápido para fazer pequenas alterações
• Comunidade strong de outros usuários e módulos de fantoches
• API padronizada para instalar pacotes em todas as plataformas

Contras de marionetes:

• Grandes infraestruturas se tornam muito complexas
• Dependências de módulo condicionais criam código spagetti
• Mais peso pesado

Atualmente, usamos o boneco para provisionar nossos contêineres docker. Os contêineres docker são usados para construções jenkins e são destruídos após cada construção. Funciona bem e nos proporciona um ambiente consistente. Isso significa que só precisamos escrever o código uma vez e depois reconstruir as máquinas do Ubuntu, Sles e Centos. A reconstrução dos contêineres leva de 15 a 30 minutos e ainda é um processo manual. O Docker é ótimo para girar em testes rápidos,

Portanto, em suma, o fantoche é ótimo para gerenciar sua infraestrutura existente. O Docker é bom se você tiver um greenfield que seja 100% linux com uma pilha de tecnologia que pode ser incluída em pequenas instâncias efêmeras. Enquanto algumas das funcionalidades se sobrepõem, elas não são mutuamente exclusivas.

    

Answer 2

O Docker ajuda você a provisionar e configurar inicialmente contêineres, mas ele executa comandos únicos na inicialização do contêiner.

O Puppet é mais strong quando você o executa como um daemon, ele garante que sua configuração permaneça como você especifica, por exemplo, se o serviço parar de ser executado, ele será iniciado novamente.

Uma das melhores coisas sobre os manifestos de configuração de fantoches (corretamente projetados) é que eles são idempotentes ; é suposto descrever o estado em que você quer estar e não necessariamente os passos para chegar lá.

Ele também permite que você abstraia e defina configurações e você pode parâmetros de exportação criados em um servidor ou contêiner e use-os em outro (por exemplo, coletando uma lista de nomes de nós de nós para um aplicativo de monitoramento).

Eu diria que eles definitivamente servem propósitos diferentes, mas relacionados. Atualmente estou olhando para usar manifestos de marionetes existentes para começar a configurar contêineres para que os ambientes de desenvolvimento são mais como ambientes de produção.