Geralmente, um desenvolvedor se preocupa em satisfazer os requisitos de negócios. Ele / ela pode ter a experiência em uma pilha ou estrutura específica. Mas ele / ela deve se esforçar para aprender o docker e seus vários métodos de implantação (enxame, kube, mesos etc.)?
Simplificando, por que um desenvolvedor deve se preocupar com o docker?
PS: A pergunta principal desta publicação é a implicação em apresentar o docker à equipe de desenvolvimento
Respostas:
Provavelmente não é a resposta que você está procurando, mas mesmo assim uma resposta :)
Aprender sobre o docker e seus métodos de implantação pode realmente ser incluído nos requisitos de negócios, tornando-o parte do ambiente de projeto ou de equipe, como linguagem (s) de código, sistema de controle de versão, compiladores, infraestrutura de teste etc. - para trabalhar em a equipe ou o projeto que você precisa conhecer e usar tudo isso, não pode "criar o seu próprio" (na maioria dos casos).
As coisas ficam um pouco mais complicadas se, por "desenvolvedor", você realmente quer dizer a maioria ou mesmo a equipe de desenvolvimento inteira. Empurrar uma ferramenta no ambiente de desenvolvimento sem que um dos desenvolvedores o suporte realmente será muito difícil. Gaste tempo para criar um desses apoiadores primeiro a partir da liderança técnica da equipe.
Nota lateral: também pode não ser necessário que todo desenvolvedor da equipe se torne um especialista em estivadores. As receitas de uso pré-estabelecidas, envolvidas em comandos simples e prontos para cheatsheet, geralmente permitem que os desenvolvedores usem soluções baseadas no docker sem realmente saber muito sobre o seu funcionamento interno, o que pode ser bastante aceitável, especialmente em grandes equipes. Assim como poder contribuir com o código sem conhecer todos os detalhes sobre como o produto final está sendo construído.
Vou te dar minha perspectiva. Os desenvolvedores devem se preocupar com o docker, pois existem outros desenvolvedores que desejam usar o docker e que já construíram um conhecimento nele. Eles estão dispostos a assumir as funções de engenheiro de DevOps, além de desenvolvedor. Portanto, a parte Ops do DevOps é o que eles estão desenvolvendo agora.
Hoje em dia, você encontra mais e mais pessoas que podem desenvolver, orquestrar, automatizar testes, automatizar tarefas e criar ferramentas para monitorar e levar esse pacote completo à produção sozinho. Esses são os caras que estão empurrando o docker e outras ferramentas entre a comunidade de desenvolvedores.
Além disso, a maré do mercado é direcionada para virtualização, dimensionamento automático, automação, aprendizado de máquina e docker. Tornou-se muito imperativo usar o docker. As empresas estão dispostas a pagar 2x por um indivíduo que assume todas essas responsabilidades e, quando houver demanda por esses indivíduos, o fornecimento também começará. Isso é do ponto de vista de um empregado-empregador.
Tecnicamente, nas organizações em que trabalhei, existem equipes de desenvolvimento e DevOps separadas, embora trabalhem de perto para entregas. Os engenheiros e desenvolvedores do DevOps compartilham uma grande maioria de conjuntos de habilidades aqui e, portanto, às vezes há uma negociação de tarefas.
O mínimo que um desenvolvedor pode fazer é compartilhar seus binários, mas ele precisa entender que os binários serão usados para executar dentro de um contêiner de docker e, para isso, ele precisa entender como o docker funciona. Para kubes, enxames, mesos, etc., o desenvolvedor pode nem se importar com o que está sendo usado, mas os conceitos básicos do docker devem ser muito bem entendidos pelo desenvolvedor e deve haver uma mentalidade desde o início para criar o aplicativo fracamente acoplado para reutilização. micro-serviços. Se o aplicativo for criado a partir dessa mentalidade (que requer noções básicas de janela de encaixe), os engenheiros do DevOps poderão levá-lo a partir daí para dimensionar, orquestrar, testar, implantar e monitorar automaticamente.
Além disso, na maioria das vezes não existe um tamanho único para todos os tipos de coisas. Um desenvolvedor não sabe claramente como criar um aplicativo compatível com docker e um engenheiro de DevOps com razão não conhece os aspectos internos do processo de criação de aplicativos. Portanto, na maioria das vezes, as organizações preferem dar essas duas tarefas ao mesmo cara para acelerar as coisas. Se houver coisas separadas, é necessário um mecanismo de feedback contínuo da equipe do DevOps para a equipe do desenvolvedor para tornar os aplicativos mais futuristas e prontos para o docker / cloud / scaling.
Não se trata do Docker ou de qualquer outra tecnologia de contêiner por aí.
Contêineres como Docker, rkt etc. são apenas uma maneira de entregar seu aplicativo de maneira semelhante ao binário estático. Você está construindo sua implantação, que contém tudo o que precisa dentro e o usuário final não precisa de nada além de tempo de execução.
Essas soluções são semelhantes aos JARs gordos em Java, onde tudo o que você (em teoria) precisa é apenas de tempo de execução (JRE) pré-instalado e tudo Just Works ™.
A razão pela qual os desenvolvedores precisam entender (eles não precisam aprender a operar essa ferramenta, apenas porque isso é necessário) ferramentas de orquestração é que isso permite que você tenha algumas vantagens sobre a implantação "tradicional".
O EngineYard escreveu um bom artigo sobre isso. O ponto principal disso é que, quando seu servidor morre, você encolhe os ombros e espera como novo. Você os trata como gado, você tem dezenas, centenas, milhares deles correndo e, quando um deles cai, nem você nem seus clientes devem estar cientes disso.
As ferramentas de orquestração conseguem isso monitorando o status de todos os aplicativos (pods / jobs, qualquer que seja) no cluster e, quando vê que um dos servidores para de responder (fica inativo), move automaticamente todos os aplicativos que estavam sendo executados nesse servidor para outro lugar.
Graças à orquestração, você pode executar vários aplicativos em um servidor e o orquestrador rastreará recursos para você. Reorganizará os aplicativos quando necessário.
Graças à manipulação automática de failover nos orquestradores, você pode executar suas imagens personalizadas na nuvem como estão. Quando você precisar de atualização, basta criar uma nova imagem, definir sua configuração de inicialização para usar essa agora e apenas rolar. Tudo será tratado por você:
TL; DR O ponto principal não é sobre o Docker, mas sobre orquestração. O Docker é apenas uma versão estendida dos JARs tarball / fat necessários para a orquestração adequada.
Aqui estão, por exemplo, alguns argumentos de uma postagem de blog publicada em 2014 e intitulada de maneira a corresponder à sua resposta:
- Injeção muito mais flexível de novas tecnologias no meio ambiente
- ainda há um grande problema entre confirmar o código final testado e executá-lo nos servidores de produção final. O Docker simplifica bastante essa etapa final
- O Docker torna trivial manter o sistema operacional herdado, independentemente do tipo de Linux que você está executando
De: https://thenewstack.io/why-you-should-care-about-docker/
Se você estiver executando sua produção no contêiner do docker, é crucial que esse contêiner esteja sendo produzido pelos mesmos desenvolvedores que criaram o aplicativo em execução neles. Quem mais é o melhor lugar para saber qual dependência externa é necessária e assim por diante ...?
O pipeline também pode falhar a qualquer momento durante um CD, principalmente quando é a etapa de criação da imagem do docker, às vezes é um arquivo que está faltando ou uma lib necessária.
No trabalho, apresentamos todos os desenvolvedores ao docker, explicando-lhes o básico para construir o arquivo docker, a fim de veicular seu aplicativo. Também facilitamos o pipeline para que você possa adicionar apenas um nome e um dockerfile, e seu aplicativo será automaticamente criado no próximo impulso, independentemente da tecnologia que o esteja executando.
O início rápido do Docker é realmente uma ótima introdução, depois do que a equipe do devOps orienta o desenvolvedor na escolha da distribuição (muitos deles não sabem coisas assim alpine).
Nosso trabalho é fornecer a eles um acesso fácil às ferramentas, eles fazem o resto para que possam corrigi-lo quando algo estiver errado. O Docker realmente faz parte do processo de desenvolvimento e a equipe do devOps fornece a eles imagens do docker que atendem às nossas necessidades e que são fáceis o suficiente, de modo que leva apenas alguns minutos para criar um novo aplicativo e implantá-lo sem assistência.
O Docker recebe muitas menções da imprensa e do blog, o que leva os desenvolvedores a se interessarem em usá-lo. Para algumas pessoas, é o interesse de brincar com uma nova tecnologia ou entender como as coisas funcionam. Para outros, é um desejo adicionar palavras-chave ao currículo. De qualquer forma, quanto mais os desenvolvedores souberem como as coisas funcionam e como elas são implantadas, menos surpresas serão depois. Pelo que vi, há uma quantidade decente de interesse preexistente nisso, portanto não deve ser tão difícil incentivá-lo ainda mais.
Bem, se você já usou VMs para teste, pode tentar usar contêineres e docker é realmente um ótimo material para teste e é muito mais simples de usar em vez do LXC :)