Trabalhei em diferentes empresas que usam microsserviços. E eles os colocaram em contêineres. Agora, estou trabalhando com um projeto que, embora seja um monólito, ainda é mais conveniente executá-lo em um contêiner.
Por um lado, o Docker é uma ferramenta muito versátil, que pode ser usada de maneira fácil e eficaz para resolver um grande número de tarefas. É compreensível e parece que tudo é elementar. Mas, por outro lado, se você não gastar seu tempo e recursos para "bombear" o uso adequado, é provável que complique demais as coisas simples. E, é claro, você assumirá que está certo e o Docker é um lixo volumoso medíocre que não é adequado para resolver sua tarefa única.
Geralmente, em uma empresa padrão, o processo de trabalhar em qualquer tarefa é semelhante a este:
- Git push é feito com nosso commit
- Um sistema é acionado, seja Jenkins, TeamCity, etc.
- O pipeline / trabalho é iniciado, no qual as bibliotecas de terceiros são baixadas, o projeto é compilado, os testes são executados
- Uma imagem da janela de encaixe com o projeto montado (ADD ..) é criada e enviada ao registro da janela de encaixe remota
- De alguma forma, no servidor remoto, o puller docker é feito (chef, fantoche, manualmente via docker-compose) e o contêiner é iniciado.
Intuitivamente, sempre achei que tudo era muito complicado. Esse processo é orgulhosamente chamado de CI / CD, e estou cansado de pessoas tão inteligentes que não têm dúvida de que essa é a maneira mais fácil.
Para o usuário final, é assim: empurrando para o repositório git, o que estava no commit se desdobra em algum lugar.
O que eu NÃO gosto nessa abordagem.
- A única maneira de implantar o sistema em um servidor remoto é seguir todas as 5 etapas.
- Na etapa 3, você pode precisar de chaves de acesso a bibliotecas particulares. O processo pode ser longo se o armazenamento em cache das bibliotecas baixadas anteriormente não estiver configurado.
- Você precisa preparar o Dockerfile, decidir a imagem (DE ...), decidir como marcaremos a imagem e precisar acessar o repositório no qual enviaremos a imagem.
- Precisa de seu próprio repositório, configure https. Afinal, o cliente docker funciona apenas em https.
O quarto parágrafo, é claro, é feito uma vez e talvez não deva ser acrescentado.
Mas quantas vezes a palavra Docker já foi mencionada na fase de lançamento?
Pense nisso: por que estamos arrastando todo esse Docker com antecedência? Porque acredita-se que o contêiner é conveniente e “Bem, estava tudo bem, funciona. O que você está começando então? ”.
Portanto, para essas pessoas, posso dizer - os contêineres do docker não são uma panacéia e nem o único ambiente no qual seu aplicativo pode ser executado. Projeto escrito em python, php, js, swift, scala / java, etc. pode ser executado em:
- máquina virtual remota
- em um host local sem nenhum contêiner de virtualização e docker.
De repente :)
Vamos imaginar que estamos criando um serviço que será executado no nodeJS.
O resultado desse projeto (ou como chamo de 'artefato') será um conjunto de arquivos js (o próprio serviço) + node_modules (bibliotecas de terceiros usadas no serviço).
Suponha que tenhamos certeza de que o serviço está funcionando e que deseja executá-lo remotamente, para que nossos testadores possam testá-lo quanto à funcionalidade.
Como você gosta dessa idéia:
- Nós criamos .tar.gz com nosso projeto e o carregamos para ... repositório remoto de artefatos! (Além disso, esses repositórios são chamados de "repositório binário").
- Dizemos o URL pelo qual eles podem baixar nosso serviço e iniciar o teste.
Além disso, os testadores podem iniciar o serviço localmente em casa, se tiverem tudo, ou criar um Dockerfile, no qual haverá um download de artefato e apenas iniciar o contêiner. Bem, ou qualquer outra coisa.
Eu direi imediatamente se você não deseja que os testadores iniciem contêineres de encaixe e, em geral, "não é o trabalho deles" iniciar, use uma ferramenta que colete imagens assim que novos artefatos aparecerem no repositório binário (use gancho da web, persiga periodicamente a coroa).
Agora, nos repositórios binários, existem:
- Sonatype nexus
- Artifactory
O Nexus é fácil de usar, possui vários repositórios diferentes que você pode criar (npm, maven, raw, docker), então eu o uso.
Essa é uma ideia muito simples, por que não li sobre isso em nenhum lugar? Na Internet, você não pode contar artigos "como no git push em algum lugar em que um contêiner é implantado em algum tipo de kubernetes". A partir de algoritmos tão complexos, o cabelo fica arrepiado.
O objetivo deste artigo, por assim dizer - não é necessário, em um processo, montar o projeto e adicioná-lo à imagem da janela de encaixe.
Divida e governe!
Crie o projeto, publique artefatos em um local para download. (O registro do Docker não é o único local em que você pode armazenar seu projeto, escolher caminhos universais para entregar artefatos aos servidores).
Com uma ferramenta separada, entregue artefatos ao servidor em que seu projeto funcionará.
Tudo é muito simples, dê aos outros uma escolha: use o docker, execute no kubernetes ou use qualquer outra ferramenta para executar artefatos. Não há necessidade de impor o uso da tecnologia, apesar de lhe parecer muito conveniente e elegante.
Boa sorte no lançamento de seus projetos!