Get best of the week

Como se tornar um engenheiro de DevOps em seis meses ou até mais rápido. Parte 6. Iniciando o Aplicativo

Como se tornar um engenheiro de DevOps em seis meses ou até mais rápido. Parte 1. Introdução
Como se tornar um engenheiro de DevOps em seis meses ou até mais rápido. Parte 2. Configuração
Como se tornar um engenheiro de DevOps em seis meses ou até mais rápido. Parte 3. Versões
Como se tornar um engenheiro de DevOps em seis meses ou até mais rápido. Parte 4.
Pacote de software Como se tornar um engenheiro de DevOps em seis meses ou até mais rápido. Parte 5. Implantação



A foto acima mostra a velocidade da implantação tradicional de aplicativos. E se você passou um mês treinando, agora está no estágio 5 do roteiro:



Pronto para lançar?


Portanto, temos nosso código escrito, empacotado e implantado em algum lugar. Decidi ignorar a implantação de código como artefatos imutáveis ​​da máquina (como EC2) e focar nos contêineres. Por quê?

Como criar uma AMI imutável no código fonte, copiá-la para qualquer lugar e depois executá-la é muito difícil. Este é um bom modelo, mas apenas se for absolutamente necessário. Portanto, peço que você considere se realmente precisa fazer exatamente isso e, caso contrário, tente reorganizar seus microsserviços em contêineres ou funções sem servidor.

Caso os contêineres não sejam possíveis, desde que você decida escrever, empacotar e implantar seu software como um aplicativo monolítico, considere o modelo imutável da AMI. Faça o mesmo se precisar executar seus próprios aplicativos que não são da nuvem ou software comercial entregue como está (como está). No entanto, este não é o tópico principal deste artigo.

Se empacotamos os contêineres cuidadosamente, como os lançamos?

Recipientes verdadeiramente funcionais


A coisa mais simples que você pode fazer é simplesmente executar o docker, executar o comando myImage e encerrá-lo. Mas isso não é uma boa ideia, porque essa solução não funciona se:

  • este recipiente de repente "morre";
  • você precisa ter mais de um contêiner para lidar com a carga
  • você precisa implementar uma implantação com zero tempo de inatividade;
  • Você deseja controle completo sobre seus microsserviços
  • você deseja usar o transportador de CI / CD para entregar rapidamente o produto aos clientes
    , etc.

Em outras palavras, o que acontece quando você precisa criar um verdadeiro aplicativo de nível corporativo distribuído? Obviamente, esse é um processo tão complexo que o comando docker run primitivo simplesmente não pode lidar com isso.

Observe que a tecnologia de comando docker-compose sofre de um conjunto muito semelhante de problemas. O Docker-compose, que permite executar muitos serviços com um único comando, não se destina a implantações de produção. Seu objetivo é a criação de protótipos locais, testes funcionais rápidos ou implantações em escala muito pequena (por exemplo, casa pessoal). Em resumo, é uma ferramenta para cargas de trabalho do usuário que não geram receita comercial.

Então, a orquestração de contêineres se apressa para o resgate!

Uma visão geral dos métodos de orquestração de contêineres


Como em tudo na vida, há mais de uma maneira de resolver o problema. O primeiro e mais óbvio é o Kubernetes . Nascido em um projeto interno do Google, o Kubernetes é o padrão de fato para a orquestração de contêineres.



Além disso, esta é a única opção se você executar seu aplicativo em:

  • data center privado;
  • Google Cloud
  • Microsoft Azure
  • qualquer outra nuvem pública.

No entanto, se você trabalha na AWS, você tem mais uma opção - ECS. Embora, estritamente falando, isso não seja totalmente verdade: você tem o Nomad da Hashicorp (são as mesmas pessoas que lhe deram Terraform) e o Docker Swarm da Docker. O problema é que existem muitas plataformas de nicho com implementação mínima; portanto, para o crescimento rápido da carreira, nós as ignoramos.
De qualquer forma, volte ao AWS Elastic Container Services (ECS). É um serviço de orquestração de contêineres totalmente gerenciado, bastante simples de começar, fortemente integrado ao restante do ecossistema da AWS. Ele faz apenas algumas coisas, mas as faz bem. Em resumo, isso é praticamente o oposto de Kubernetes, e se o ECS foi bom o suficiente para o McDonald's, então provavelmente é bom o suficiente para você também.

No entanto, puramente em termos de avanço imediato na carreira, não há dúvida de que o Kubernetes é a melhor escolha. Embora aposto que 99% das empresas que trabalham na AWS também satisfarão perfeitamente a ECS.

Então agora você pode fazer uma escolha. Se você é um novato completo nessa área, pode se moderar com o Kubernetes, porque fora da equipe de engenheiros de DevOps afins que podem apoiá-lo em sua jornada não é tarefa fácil! A imagem abaixo mostra como um futuro engenheiro de DevOps está explorando um sistema de acesso baseado nas funções do Kubernetes.



No entanto, isso é definitivamente possível, especialmente com ofertas gratuitas do Google e da AWS, tutoriais do YouTube / Udemy e preços spot da AWS. Se você escolher essa rota, recomendo que você comece com o nível gratuito de camada gratuita ou nível kops do Google Cloud Platform, que inicia instâncias pontuais da AWS. O Kubernetes (EKS) em execução na Amazon custa dinheiro e, embora seja adequado para cargas de trabalho de produtos, não é uma boa maneira de começar a aprender como executar aplicativos corretamente. E eu não sei o suficiente sobre o Azure para recomendá-lo.
No entanto, se você não é novo nesta área e realmente trabalha no ecossistema da AWS, meu conselho é o seguinte. Torne seus microsserviços em contêiner e implante-os no ECS para dormir tranqüilamente à noite e trabalhar em paralelo para criar uma plataforma Kubernetes de classe mundial. O fato é que mergulhar no Kubernetes é como "barbear os iaques", o que você nem imagina, e inevitavelmente o desviará da sua verdadeira missão - entregar produtos de forma rápida e eficiente aos clientes.

Nota: “Yak shaving” é um termo de programação que significa uma série de tarefas que devem ser concluídas antes que um projeto possa avançar para seu próximo marco. Foi cunhado por Carlin Vieri, inspirado no episódio "The Ren & Stimpy Show". O nome do termo sugere a aparentemente futilidade das tarefas executadas, mesmo que sejam necessárias para resolver um problema maior.

Você realmente precisa do Kubernetis? Não. E se você realmente quer trabalhar com ele? Então sim". Claro? O mercado diz: "ou Kubernetes ou vá para casa". Então, vamos dar uma rápida olhada no que você está assinando, entrando em contato com esse assunto.

Primeiro, apesar da impressão de tecnologia de ponta, a ideia do Kubernetes é relativamente antiga. Quando o Google removeu os invólucros do Borg (o antecessor do Kubernetes) em 2015, já era uma ideia bastante antiga.

Leia isto: "Fornecemos uma breve descrição da arquitetura e recursos do sistema Borg, decisões importantes de design, uma análise quantitativa de algumas de suas decisões políticas e uma análise qualitativa das lições aprendidas em dez anos de experiência trabalhando com ele". Leia isso novamente! Em 2015 (!), O Google compartilhou os detalhes do lançamento de um sistema semelhante ao Kubernetes, que na época tinha mais de dez anos.



No entanto, eles próprios não são tímidos. Aqui está a primeira frase na página inicial do Kubernetes: “O Kubernetes (K8s) é um sistema de código aberto para automatizar a implantação, dimensionamento e gerenciamento de aplicativos em contêiner. Ele agrupa os contêineres que compõem o aplicativo em blocos lógicos para facilitar o gerenciamento e a descoberta. O Kubernetes se baseia em seus 15 anos de experiência com as cargas de trabalho do Google, combinadas com as melhores idéias e práticas da comunidade. ”

Portanto, da próxima vez que você ouvir alguém apresentando o Kubernetes como uma nova idéia "quente", pronta para dominar o mundo, lembre-se de que ele representa uma tecnologia que tem agora pelo menos quinze anos. Isso não é um pouco inovador?
Em segundo lugar, pense no público-alvo. O Google está criando ferramentas para resolver os problemas do Google e do Google. Mais uma vez, a página inicial do Kubernetes diz claramente: "Escala planetária: projetada com os mesmos princípios que permitem ao Google lançar bilhões de contêineres por semana, o Kubernetes pode ser escalado sem aumentar a equipe de operações".

Por fim, um dos desenvolvedores originais do Kubernetes e seu defensor mais ativo, Kelsey Hightower, também destaca este ponto: “Kubernetes é para pessoas que constroem plataformas inteiras. Se você é um desenvolvedor que cria sua própria plataforma (AppEngine, Cloud Foundry ou um clone Heroku), o Kubernetes é o que você precisa. ”

Portanto, se você trabalha em escala planetária, lança bilhões de contêineres por semana ou cria uma nuvem para outros usuários, o Kubernetes é a escolha certa. E se não, então este não é o fim da história. E não me importo que sua avó tenha lido um monte de tweets de Kelsey durante o intervalo do almoço e depois tenha convertido o site de sua loja de flores em Kubernetes em uma semana usando CI / CD e Análise Automatizada de Canárias. Esta não é a ferramenta certa para você, a menos que a natureza do seu produto exija que você o use.

Mas isso realmente importa? Kubernetes = $$$. Então, suba de nível, aproveite sua jornada ao mundo do DevOps e compartilhe suas experiências comigo.
Nota do tradutor: o artigo # 7 sobre o monitoramento de aplicativos com base no ELK Stack ainda não foi publicado.

Para continuar em breve ...

Um pouco de publicidade :)


Obrigado por ficar com a gente. Você gosta dos nossos artigos? Deseja ver materiais mais interessantes? Ajude-nos fazendo um pedido ou recomendando aos seus amigos o VPS na nuvem para desenvolvedores a partir de US $ 4,99 , um analógico exclusivo de servidores de nível básico que foi inventado por nós para você: Toda a verdade sobre o VPS (KVM) E5-2697 v3 (6 núcleos) 10 GB DDR4 480 GB SSD 1 Gbps de US $ 19 ou como dividir o servidor? (as opções estão disponíveis com RAID1 e RAID10, até 24 núcleos e até 40GB DDR4).

Dell R730xd 2 vezes mais barato no data center Equinix Tier IV em Amsterdã? Somente nós temos 2 TVs Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV a partir de US $ 199 na Holanda!Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - a partir de US $ 99! Leia sobre Como criar um prédio de infraestrutura. classe c usando servidores Dell R730xd E5-2650 v4 que custam 9.000 euros por um centavo?

More articles:


All Articles