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 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



Considere como empacotar seu código para facilitar a implantação e a execução subseqüente. Deixe-me lembrá-lo de que estamos aqui agora:



Independentemente de você estar conversando com seus empregadores atuais ou futuros, você deve poder articular claramente o que é DevOps e por que é importante.
Forneça uma história consistente sobre a melhor maneira de fornecer código de maneira rápida e eficiente do laptop do desenvolvedor ao local de implantação do produto final com o lucro apropriado. Estudamos não um conjunto de ferramentas DevOps distintas e modernas, mas um conjunto de habilidades, guiadas pelas necessidades dos negócios e contando com ferramentas técnicas. Lembre-se de que o estudo de cada estágio do DevOps leva cerca de um mês de treinamento, o que totaliza seis meses.

Tutorial de virtualização


Lembra dos servidores físicos? Os mesmos servidores pelos quais você está esperando há semanas pela aprovação do pedido de compra, aprovação do processo de envio, aprovação pelo data center, conexão de rede, instalação do sistema operacional e patches? Estes são os servidores que entraram em nossas vidas.

Imagine que a única maneira de encontrar uma casa é construir uma nova casa. Afinal, você precisa morar em algum lugar? Portanto, espere até que seja construído, não importa quanto tempo leve! Parece ser legal, porque todo mundo fica em casa, mas oneroso, porque sua construção leva muito tempo. Seguindo essa analogia, um servidor físico é como um lar.

Com o tempo, esse processo se tornou irritante, e pessoas realmente inteligentes tiveram a ideia de virtualização. Eles decidiram rodar um monte de máquinas imaginárias em uma máquina física e fizeram cada uma delas fingir ser uma máquina real. Engenhoso!

Portanto, se você realmente precisa de uma casa, pode construir sua própria e esperar seis semanas. Ou você pode se mudar para um prédio de apartamentos e compartilhar recursos com outros residentes. Talvez não seja tão legal, mas bom o suficiente! E o mais importante, você não precisa esperar nada!

Isso continuou por algum tempo, e empresas como a VMWare ganharam muito capital nisso. Então, outras pessoas inteligentes decidiram que inserir várias máquinas virtuais em uma máquina física não é suficiente: você precisa de um pacote mais compacto de mais processos em menos recursos.

Então, uma casa ou até um apartamento é muito caro, então talvez tente alugar um quarto temporariamente? Além disso, posso entrar e sair a qualquer momento! Isso é o que o Docker representa essencialmente em dezembro de 2018.



Birth Docker


O Docker é uma nova tecnologia baseada em uma idéia muito antiga. O sistema operacional FreeBSD continha o conceito do mecanismo de virtualização da prisão, que data de 2000! Na verdade, tudo de novo é bem esquecido.

E então, e agora a idéia era isolar processos individuais no mesmo sistema operacional com base na virtualização no nível do sistema operacional, ou na “virtualização no nível do sistema”. Observe que isso não é o mesmo que virtualização completa, ou "virtualização completa", que executa máquinas virtuais lado a lado no mesmo host físico.

Na prática, isso significa que a crescente popularidade do Docker reflete com precisão o crescimento dos microsserviços, uma abordagem para o desenvolvimento de software na qual o software é dividido em muitos componentes separados. E todos esses componentes precisam de casa. Implantá-los individualmente como aplicativos Java independentes ou executáveis ​​binários é uma grande dor: a maneira como você controla um aplicativo Java é diferente da maneira como você controla um aplicativo C ++, e isso, por sua vez, é diferente de gerenciar um aplicativo Golang .

Em vez disso, o Docker fornece uma interface de gerenciamento única que permite aos programadores empacotar, implantar sequencialmente e executar vários aplicativos. Esta é uma vitória enorme, mas vamos falar dos prós e contras do Docker.

Benefícios do Docker


1. Isolamento do processo


O Docker permite que cada serviço tenha um processo completamente isolado. O serviço A vive em seu próprio contêiner pequeno, com todas as suas dependências, o serviço B também vive em seu próprio contêiner particular, com todas as suas dependências, e os dois serviços não entram em conflito.

Além disso, se um contêiner falhar, somente esse contêiner sofrerá.

Os demais contêineres continuarão a funcionar. Esse mecanismo é benéfico para a segurança. Se o contêiner estiver comprometido, será muito difícil (mas não impossível!) Sair dele para quebrar o sistema operacional base.

Por fim, se o contêiner se comportar de maneira inadequada (consumir muito processador ou recursos de memória), você poderá reduzir o "raio de explosão" desse contêiner apenas sem afetar o restante do sistema.

2. Implantação


Pense em como os diferentes aplicativos são criados na prática. Se esse for um aplicativo Python, ele terá muitos pacotes Python diferentes. Alguns deles serão instalados como módulos pip, outros como pacotes rpm ou deb e outros como instalações simples do git-clone. Ou, se feito com o virtualenv, será um único arquivo zip de todas as dependências no diretório virtualenv.

Por outro lado, se for um aplicativo Java, ele terá um assembly Gradle Built, com todas as suas dependências estendidas e espalhadas nos locais apropriados.

Veja qual é o problema? Aplicativos diferentes, assemblies com idiomas diferentes e tempos de execução diferentes representam um problema quando se trata de implantar esses aplicativos para prod. Além disso, o problema é agravado se surgirem conflitos. E se o serviço A depender da biblioteca do Python v1 e o serviço B depender da biblioteca do Python v2? Há um conflito aqui, pois as v1 e v2 não podem coexistir na mesma máquina.

E então o Docker entra em jogo. Permite isolar completamente não apenas o processo, mas também as dependências. É possível ter vários contêineres trabalhando lado a lado no mesmo sistema operacional, cada um contendo suas próprias bibliotecas e pacotes que não são compatíveis com os outros.

3. Gerenciamento de execução do programa


Observo que a maneira como gerenciamos aplicativos diferentes depende do próprio aplicativo. O código Java é escrito de forma diferente no registro, é executado de forma diferente e é rastreado de maneira diferente do código Python. E o Python é diferente de Golang etc.

Com o Docker, obtemos uma interface de gerenciamento unificada que nos permite iniciar, controlar, centralizar logs, parar e reiniciar muitos tipos diferentes de aplicativos. Esse é um enorme ganho de produtividade, que reduz significativamente os custos operacionais dos sistemas operacionais de produção.

Desde dezembro de 2018, você não precisará mais escolher entre o lançamento rápido do Docker e a segurança das máquinas virtuais. Projeto de plataforma de virtualização leve do Fireckracker, introduzido pela Amazon, tentou combinar o melhor das duas soluções. No entanto, esta é uma nova tecnologia que está apenas se aproximando da fase de produção.



Nota: A plataforma Firecracker fornece ferramentas para criar e gerenciar ambientes e serviços isolados criados usando um modelo de desenvolvimento sem servidor. O código do projeto é escrito em Rust e distribuído sob a licença Apache 2.0.

O Firecracker oferece máquinas virtuais leves, chamadas microVMs. Para isolá-los completamente, são usadas tecnologias de virtualização de hardware, mas ao mesmo tempo, desempenho e flexibilidade são fornecidos no nível de contêineres comuns. A plataforma é baseada no VMM (Virtual Machine Monitor), que usa o hipervisor KVM integrado ao kernel do Linux. O VMM é baseado nas bases do projeto crosvm escrito em Rust , que o Google está desenvolvendo para lançar o Linux no ChromeOS. No final de 2018, as bases de código crosvm e Firecracker foram divididas, mas a Amazon planeja enviar correções para os componentes emprestados para montante.

No entanto, não importa o quão bom o Docker seja, ele também possui desvantagens.

Introdução ao Lambda


Em primeiro lugar, a execução do Docker ainda continua funcionando em servidores que precisam ser preparados, corrigidos etc. Em segundo lugar, o Docker não é 100% seguro. Pelo menos, não é tão seguro quanto uma máquina virtual. Há uma razão pela qual grandes empresas que trabalham com contêineres hospedados fazem isso dentro de máquinas virtuais, e não no metal puro. Eles precisam de tempos rápidos de lançamento de contêiner e segurança da máquina virtual!



Em terceiro lugar, ninguém realmente controla o Docker como tal. Em vez disso, quase sempre é implantado como parte de uma estrutura complexa de orquestração de contêiner, como Kubernetes, ECS, docker-swarm ou Nomad. Essas são plataformas bastante complexas que exigem pessoal especial para trabalhar (discutirei essas soluções com mais detalhes posteriormente).

No entanto, se eu sou apenas um desenvolvedor, quero escrever um código e pedir a alguém para executá-lo para mim. Docker, Kubernetes e outro jazz - eu realmente tenho que aprender tudo isso? Eu direi o seguinte: tudo depende das circunstâncias. Para pessoas que querem apenas que outra pessoa execute seu código, o armazenamento em nuvem do AWS Lambda e outras coisas semelhantes são uma ótima opção.

O AWS Lambda permite executar código sem provisionamento e gerenciamento de servidor. Você paga apenas pelo tempo de computação que consome e, quando seu código não funciona, não há cobrança.
Se você já ouviu falar em armazenamento sem servidor, é isso. Não há mais servidores de lançamento ou contêineres de gerenciamento! Basta escrever seu código, compactá-lo em um arquivo zip, enviá-lo para a Amazon e deixá-los lidar com sua dor de cabeça! Além disso, como os "lambdas" têm vida curta, não há nada para quebrá-los - os "lambdas" são bastante seguros em seu design. Muito bom?

Mas também há pontos negativos. Primeiro, as lambdas só podem funcionar por no máximo 15 minutos (a partir de novembro de 2018). Isso significa que processos de longa execução, como Kafka ou aplicativos de quebra de números, não podem funcionar no Lambda.

Em segundo lugar, "lambdas" são Funções como Serviço (funções como serviço). Isso significa que seu aplicativo deve ser totalmente decomposto em microsserviços e sincronizado com outros serviços PaaS complexos, como o AWS Step Functions . No entanto, nem todas as empresas estão nesse nível de arquitetura de microsserviço.

Terceiro, solucionar problemas de lambdas é muito difícil. São tempos de execução na nuvem e todas as correções ocorrem no ecossistema da Amazônia. Isso geralmente é bastante complexo e pouco intuitivo. Em suma, não há almoço grátis aqui.

Observo que, no final de 2018, também existem soluções de contêiner em nuvem sem servidor, como o AWS Fargate. Sua mecânica é muito parecida com a do Lambda. Se você está apenas começando a aprender esses serviços, recomendo experimentar o Fargate, que é uma maneira incrivelmente fácil de fazer com que os contêineres funcionem "corretamente". Além disso, em 13 de janeiro de 2019, os serviços em nuvem da AWS anunciaram uma redução significativa no preço do Fargate, tornando-o uma opção muito atraente para o lançamento de contêineres sem servidor.



Sumário


Docker e Lambda são as duas abordagens modernas mais populares baseadas na nuvem para empacotar, executar e gerenciar aplicativos. Eles geralmente são gratuitos, adequados para vários casos de uso e aplicativos.

Seja como for, o engenheiro moderno do DevOps deve ser bem versado em ambos. Portanto, o treinamento do Docker e do Lambda são bons objetivos de curto e médio prazo.
Observo que, até agora, lidamos com tópicos que os engenheiros de nível júnior e intermediário do DevOps deveriam conhecer. Nas seções a seguir, começaremos a discutir métodos mais adequados para engenheiros de nível médio e sênior de DevOps. Como sempre, não há maneiras fáceis de adquirir conhecimento!

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 baseado em nuvem para desenvolvedores a partir de US $ 4,99 , um analógico exclusivo de servidores básicos que foi inventado por nós para você: Toda a verdade sobre o VPS (KVM) E5-2697 v3 (6 núcleos) 10GB DDR4 480GB SSD 1Gbps de 10GB 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 construir infraestrutura classe c usando servidores Dell R730xd E5-2650 v4 que custam 9.000 euros por um centavo?

All Articles