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
docker
project-management
orchestration
Abhay Pai
fonte
fonte
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.
fonte
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".
Gado, não animais de estimação
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.
Melhor utilização de recursos
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.
Infraestrutura imutável
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ê:
Operações mais simples
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.
fonte
Aqui estão, por exemplo, alguns argumentos de uma postagem de blog publicada em 2014 e intitulada de maneira a corresponder à sua resposta:
De: https://thenewstack.io/why-you-should-care-about-docker/
fonte
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.
fonte
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.
fonte
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 :)
fonte