Get best of the week

Como se tornar um engenheiro de DevOps em seis meses ou até mais rápido. Parte 5. Implantação

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



Atualize a memória


A imagem acima mostra como deve ser uma implantação típica de código. Deixe-me lembrá-lo de onde estamos agora, de acordo com o roteiro:



Se você passou um mês estudando cada seção, agora está com 4 meses. A essa altura, você já deve saber como fornecer a infraestrutura que funcionará com o seu software, como gerenciar corretamente as versões do software e como empacotá-las para implantação futura. Neste artigo, discutiremos como implantar corretamente seu código!

Implantação de código


Você percebeu que eu disse "como fazer", e não "como é fácil"? Não é só isso. Infelizmente, a implantação correta do código do ambiente de desenvolvimento para o ambiente de produção ainda é um processo doloroso, repleto de erros e falhas. Há muitas razões para isso, mas, na minha opinião, tudo se resume principalmente às diferenças entre o ambiente em que o código é criado e o ambiente em que é executado.

Minimizar essas diferenças é a melhor coisa que você pode fazer não apenas durante o processo de implantação, mas também durante sua execução após a implantação. Então, como reduzimos e / ou eliminamos as diferenças entre nossos ambientes de prod e não-prod?

E funciona no meu carro!


Se a sua infraestrutura de desenvolvimento estiver assim:



E a infraestrutura de produto estiver assim :



Considere o seu problema. Se você usar a infraestrutura como código e não configurar as coisas manualmente, poderá resolvê-lo em 90%. Caso contrário, não se desespere - você não está sozinho. Destaque a tarde, determine quais lacunas você tem (aprendizado, cultura, pessoas, processos etc.) e preencha-as metodicamente uma a uma.

O ponto principal é que você não conseguirá gerenciar uma pilha de tecnologia moderna se ainda estiver configurando as coisas manualmente. Este é um axioma. A primeira coisa que você precisa fazer é garantir que tudo relacionado ao prod seja o artefato com versão implementado pelo servidor de implementação.

Assumindo que tudo isso foi feito, terei a liberdade de afirmar que a melhor maneira de implantar código é não implantá-lo.

Abordagem de implantação moderna


É verdade que implantar código em máquinas é um eco dos anos 90. O maior problema ao implantar código em um conjunto de máquinas de produção é que, por definição, seus servidores prod (nos quais o código é executado) são diferentes dos servidores dev (onde esse código é gravado). Não é de surpreender que imediatamente após a implantação haja muitos problemas que nunca haviam sido notados antes, porque agora as condições mudaram!

Portanto, antes de implantar, você precisa garantir que o artefato de implantação seja o tempo de execução inteiro, não parte do código. Em outras palavras, implante seu código uma vez no ambiente de desenvolvimento, clone toda a máquina em que seu código está sendo executado e copie-o onde quer que esteja.



Isso é chamado de "implantação imutável" e é um modelo muito poderoso que poupa muitas horas de dor de cabeça após a implantação. Obviamente, se você executar contêineres, a mesma idéia se aplica: você implanta o mesmo contêiner em qualquer lugar. Você pode dizer: “pare! Meu produto é diferente do dev! ”E isso mesmo, porque nomes de usuário / senhas de banco de dados, cadeias de conexão, localizações de lixeiras S3 são coisas diferentes! Sim, são coisas muito diferentes.

A maneira de resolver esse problema é usar o princípio de configuração de aplicativo de 12 fatores. Uma aplicação de doze fatores armazena a configuração em env vars, ou variáveis ​​de ambiente env. As variáveis ​​de ambiente podem ser facilmente alteradas entre implantações sem alterar o código. Diferentemente dos arquivos de configuração, há menos probabilidade de salvá-los acidentalmente em um repositório de códigos e, diferentemente dos arquivos de configuração personalizados ou de outros mecanismos de configuração, como Java System Properties, eles são um padrão independente do idioma e do sistema operacional. Portanto, toda a sua configuração deve ser externalizada e transferida como variáveis ​​de ambiente para o seu computador.

Por exemplo, se você estiver na AWS, use o SSM como um repositório externo de parâmetros - ele se integra perfeitamente ao CloudFormation. Também é muito fácil definir variáveis ​​de ambiente diretamente dos comandos AWS ssm cli. Obviamente, outros provedores de nuvem têm mecanismos semelhantes.

Além disso, resista ao desejo de "consertar" suas máquinas de prod quando algo der errado. As máquinas devem ser imutáveis, o que significa que todas as correções que você faz devem vir do dev. Seu objetivo deve ser impedir o acesso a máquinas de produção. Nem acesso ssh, nem scp, nem prod - nunca a ninguém, nem a si mesmo, nem a hackers novatos.

Mas e se eu precisar de logs para corrigir o problema? Você adivinhou: suas revistas também devem ser externalizadas, idealmente enviadas para outro local, usando a pilha ElasticSearch / Logstash / Kibana (ELK) ou usando software comercial como SumoLogic ou Datadog.

Faça o que fizer, suas máquinas de produção são um "gado de trabalho" que é substituído ao menor sinal de problemas de saúde. Eles não são "animais de estimação" que precisam ser tratados para serem curados, gastando horas na solução de problemas.

Sei que essa analogia é usada com muita frequência e ouço pessoas que realmente se importam com o gado que isso não é totalmente verdade, mas a essência é a mesma - não "repare" suas máquinas de produção, apenas conserte seu desenvolvimento e reimplemente-o .

Mecânica de implantação de código


Então, você sabe o que fazer, mas não sabe como. Infelizmente, é aqui que Jenkins aparece. Se você não sabe, o Jenkins é um dos servidores de automação de implantação de código aberto mais populares.



Digo “infelizmente” porque Jenkins (e seu antecessor Hudson) estão ao nosso redor há quase dez anos, e isso é perceptível. É complicado de configurar e ainda mais difícil de manter. Ele vem com milhões de plugins de qualidade duvidosa. Esses plugins, em regra, quebram no momento mais inoportuno, deixando tudo para trás. De fato, verdadeiramente estáveis, as oficinas de Jenkins são raras e geralmente são vistas apenas nas maiores organizações.

Por que eu recomendo que você comece com Jenkins? Porque, apesar de todas as suas deficiências, ainda é extremamente popular e amplamente utilizado no campo de TI. Conhecer Jenkins, em particular como o arquivo Jenkins é estruturado , é uma enorme vantagem para as perspectivas de emprego e não pode ser esquecido. Ao explorar o Jenkins, certifique-se de usar o novo plug-in Pipeline BlueOcean e não o obsoleto pipeline de trabalhos Jenkins. Isso é fundamental se você deseja que seu pipeline de CI / CD viva dentro do código de repo GitHub / GitLab. Portanto, o próprio pipeline é um pedaço de código com versão!



De fato, é tão importante que vale a pena repetir novamente: tudo é código! Seu aplicativo, como é implantado, como é rastreado, como é configurado, etc. são todos os trechos de código com versão apropriada armazenados no GitHub / GitLab / Anywhere. O objetivo disso é criar um ambiente livre de inconsistências para os principais desenvolvedores (engenheiros de software que escrevem código funcional).

Por exemplo, eu devo ser capaz de:

  • escreva seu próprio pequeno microsserviço;
  • adicione todos os testes que considere necessários;
  • Adicionar Jenkinsfile
  • adicionar configuração de monitoramento como código;
  • especifique meus parâmetros no arquivo env.yaml;
  • salve tudo isso em um repositório;
  • faça o Jenkins detectar automaticamente o repositório especificado;
  • construa seu microsserviço;
  • teste-o;
  • Expandir (usando o método Canary ou Blue-Green);
  • organize o envio de uma mensagem para o seu e-mail quando isso for feito!

Esse é o objetivo, cuja conquista é a essência da missão principal dos engenheiros de DevOps.

Alternativas ao Jenkins


Como disse anteriormente, Jenkins existe há séculos e hoje existem outros, na minha opinião, as melhores alternativas, embora menos populares. Um deles é o AWS CodeDeploy . Ele tem limitações, mas os desenvolvedores fizeram melhorias significativas no ano passado e, se você trabalha na AWS, peço que tente o CodeDeploy.

A segunda alternativa é o módulo de integração contínua do GitLab CI. Se sua organização está executando o GitLab, você provavelmente deve começar a trabalhar com ele, pois está bem integrado ao restante do GitLab.

Por fim, o GitHub anunciou sua própria ferramenta para implantar aplicativos Actions , que é suportada por sua própria automação.

Na verdade, não acho que as ferramentas sejam tão importantes aqui. É importante saber que tudo, incluindo os pipelines de implementação de código, são artefatos com versão e nada vale a menos que venha do dev.

Independentemente disso, se você começar com o Jenkins, tente configurá-lo como um contêiner. Não é muito difícil e será uma excelente oportunidade para aprender como implantar um servidor de contêiner Jenkins com nós de trabalho expansíveis e contêineres Jenkins. De fato, você pode iniciar sem nenhuma orquestração de contêiner, que é o assunto do próximo artigo.

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