O que é comum entre descascar ovos e DevOps?

Aqui está uma tradução do artigo de Patrick Lee Scott publicado em hackernoon.com. O autor oferece se familiarizar com vários princípios importantes que ajudarão você a desenvolver o DevOps.

imagem

Há alguns dias, tentei descascar um ovo de uma maneira estúpida, e minha namorada Angeli me perguntou por que eu estava fazendo isso.

Ela pegou outro ovo cozido e bateu em uma tábua, depois pressionou e rolou sobre a mesa. Demorou apenas 3 segundos para limpar. E eu levantei e tirei a concha pedaço por pedaço.

O que quero dizer com isso: exageramos a importância dos esforços.

As melhores soluções são simples e eficazes. É difícil limpar um parafuso enferrujado? Provavelmente sim. Mas somente se você não souber que isso pode ser feito com a Coca-Cola. Ainda complicado? Não. Você só precisa colocar o parafuso no copo e esperar.

Sem conhecer técnicas simples, você não pode aplicá-las. Em vez de implementar, você realiza experimentos; em vez de replicação, pesquisa.

Se na programação você usa algum tipo de abordagem repetidas vezes, porque permite simplificar o problema que está sendo resolvido, essa abordagem se torna um modelo ou a chamada melhor prática.

Apesar de nomes complexos e assustadores, como CQRS (Command Query Responsability Segregation) ou Event Sourcing (ES), essas práticas ajudam a resolver problemas. Especialmente aqueles que surgem ao construir sistemas distribuídos.

Se você observar o desenvolvimento como um todo, veremos que existem mais princípios universais, por exemplo, "Mantenha as coisas simples, estúpidas" (KISS) e "Não se repita" (DRY). Eu gostaria de falar sobre padrões e princípios semelhantes em relação ao DevOps.

O DevOps é frequentemente apresentado como a terra prometida, na qual os pássaros cantam e o sol brilha. Mas sem usar os métodos certos, o DevOps se transformará em um inferno e você furará todos os seus dedos com um casco (como eu).

Ao criar sistemas DevOps, encontrei várias soluções para mim, além de princípios universais como KISS e DRY. Embora eles não possam ser chamados de modelos, eles ajudarão você a limpar rapidamente o ovo. Estas soluções (em ordem aleatória):

  • Não faça o que os outros fizeram antes de você.
  • Deixe os desenvolvedores serem o mais produtivos possível.
  • Produção é um mito.
  • Transfira tudo para o cluster e faça backup do todo.
  • A VPN é muito complicada; as soluções são mais fáceis.
  • Organize, automatize e conquiste!

Lição 1. Não faça o que os outros fizeram antes de você


Se você tiver a oportunidade de comprar um produto acabado ou se tiver a ferramenta necessária e conveniente em domínio público, use-a.

Não reinvente a roda - compre-a.

Você sabia que pode usar o mesmo servidor de correio que o Craigslist usa? E o que é de graça? Precisa de um servidor de correio - não crie um novo, trabalhe com um já existente.

Eu gosto de procurar ferramentas em listas incríveis e auto-hospedadas ou usar o Helm Hub para isso.

Apesar do Helm ser uma ferramenta relativamente nova para encontrar software, este site já foi criado: https://v3.helm.sh/

Com o Helm, você pode procurar facilmente suas bicicletas prontas.

Vamos voltar no tempo em que eu estava apenas começando a programar. Na 9ª série, aprendi minha primeira língua "real" - QBasic. Antes disso, eu criava sites HTML e CSS há alguns anos. A Internet era nova e, embora as pessoas soubessem criar pacotes, elas não os compartilhavam, como nós somos agora. Normalmente, usava disquetes para armazenamento - seria ótimo encontrá-los junto com um jogo como o arkanoid, que escrevi no Java Swing na série 11 ...

Tudo o que eu usei então foi bibliotecas padrão, baby! Pelo menos aos 13 anos eu sabia apenas sobre eles. Embora eu tenha certeza de que alguns profissionais de java (Olá, Vlad e Nick!) Já eram legais. ;)

Agora está tudo errado. Hoje você pode encontrar bibliotecas de interface do usuário inteiras. Você pode encontrar uma biblioteca para lidar de forma elegante e fácil com datas com um único comando.

Seria ótimo se houvesse uma ferramenta para usar e instalar subsistemas totalmente funcionais, certo? Precisa de um banco de dados? instalar banco de dados

Boas notícias: essa ferramenta existe! Com o Helm, você também pode instalar subsistemas totalmente funcionais, empacotados e prontos para uso.

O princípio é o mesmo do NPM e Gradle, mas os pacotes que gerenciamos no Helm são chamados de gráficos. Os gráficos marcam os contêineres para que sejam executados no Kubernetes de várias maneiras.

Acontece uma solução chave na mão, comprando uma bicicleta. Os gráficos são a roda, e os contêineres com descrições que correm dentro do Kubernetes são rodas.

O que é interessante nos gráficos é a capacidade de compactar serviços e executá-los em qualquer cluster Kubernetes e até compartilhá-los com outras pessoas, se você quiser.

Isso significa que você pode descrever todo o ambiente usando o código:

- name: backup repository: http://jenkins-x-chartmuseum:8080 version: 0.0.2 - name: monitor repository: http://jenkins-x-chartmuseum:8080 version: 0.0.3 - name: marketing-site repository: http://jenkins-x-chartmuseum:8080 version: 1.1.10 - name: denormalizer-service repository: http://jenkins-x-chartmuseum:8080 version: 1.0.0 - name: mongo repository: https://kubernetes-charts.storage.googleapis.com/ version: 1.0.0 

Precisa atualizar seu site de marketing para a 1.2.0? Basta fazer alterações e confirmar.

Lição 2. Deixe os desenvolvedores serem o mais produtivos possível.


Uma vez, sentei-me à mesa, olhei para o meu código e tentei rastrear o bug. Os usuários reclamam dele há várias semanas e, finalmente, eu tive um pouco de tempo livre para ficar por aqui.

Tada-a-am! Encontrei! Fixed!

Sentei-me atrás de uma divisória no meu local de trabalho em uma sala iluminada pelo sol e gritei para os outros: "Eu consertei o bug!"

Na próxima terça-feira, quando os usuários virem o lançamento, eles certamente apreciarão meus esforços! Mas, para isso, teremos que fazer as malas e tentar mudar o lançamento do local ... Talvez tenhamos sucesso se nada acontecer ...

Bem, tudo bem, se o lançamento ainda chegar na próxima terça-feira, os usuários definitivamente apreciarão!

Era assim que eu fazia a implantação no meu primeiro emprego na faculdade, como programador júnior.

Desde então, muita coisa mudou.

Agora eu uso o desenvolvimento baseado em tronco e implanto módulos muitas vezes por dia. Quando eu enviar uma solicitação de recebimento, o bot publicará um comentário correspondente com o código de revisão com o ambiente coletado após a aprovação dos testes e a compilação.

Hoje você não precisa gritar pela partição do escritório.

Quanto mais liberdade você der aos programadores - a liberdade de controlar as partes da infraestrutura de que precisam - mais fácil será trabalhar como engenheiro de DevOps.

Na primeira lição, vimos que, para atualizar na produção, basta alterar um dígito e confirmar. Em um mundo ideal no qual agrupamos aplicativos em gráficos, cada programador de uma equipe tem a oportunidade de influenciar como a ferramenta funciona no estágio de produção. O Kubernetes entende os gráficos como descrições de contêineres, e é por isso que eles descrevem os requisitos de recursos.

A lógica é mais ou menos assim: não consigo adivinhar quanta memória ou quais configurações de CPU serão necessárias para um novo serviço (e acho que não sou o único). Portanto, também implanto monitoramento e alertas com regras de acordo com as quais minha equipe e eu seremos informados no Slack de que essas configurações precisam ser aprimoradas. Ou seja, o sistema informará você sobre as configurações necessárias quando implantá-lo. Eu ficava sentado por horas, enviando solicitações através do Prometheus e ajustando as configurações, assim como costumava escolher o shell. E agora eu aprendi a fazer tudo com sabedoria.

Já posso ouvir você dizer: "Parece muito complicado!" Não. Basta definir o gráfico.

Se você pode automatizar ou simplificar algo - vá em frente. Por exemplo, e se você pudesse atribuir um caminho DNS simplesmente implantando o serviço com o rótulo "expor: true"? É aqui que os operadores aparecem. Esta é uma ferramenta Kubernetes mais avançada e você deve conhecê-la. Mas não vamos nos aprofundar muito nos detalhes.

Lição 3. Produção é um mito


Esta foi uma revelação real para mim. Eu tive que olhar as coisas de um ângulo diferente, então ouça com atenção.

Por mais de dez anos, pensei que no mundo existem apenas alguns tipos de ambientes. No cenário mais simples, há preparação e produção do ambiente. Primeiro implantado no preparo, depois testado, passou para o próximo estágio, implantado, testado e assim por diante. Assim que tudo estiver preso - o filho está integrado - você poderá entrar em produção.

Eu segui esse padrão ano após ano e nunca duvidei. Sempre foi assim.

E esse esquema é outra maneira improdutiva de se livrar da casca.

Em essência, um gráfico é um gráfico de dependência. Ele pode ser usado para representar o ambiente e, em seguida, o processo de implantação na produção se resume à implantação de um único gráfico.

Se cada equipe, projeto ou grupo conectado por um contexto comum tiver seu próprio gráfico, aparecerão vários ambientes que permitem agrupar e atualizar todos os serviços em uma única transação.

Não tome a produção como um enorme ambiente abrangente, na verdade, é uma produção pequena.

Grandes mudanças são assustadoras em sua escala. E se você tiver vários ambientes de desenvolvimento pequenos, poderá isolar as alterações e tornar o sistema mais flexível.

Além disso, se tudo estiver organizado na forma de gráficos, as variáveis ​​serão definidas e poderão ser alteradas externamente, da mesma maneira. Por exemplo, para conectar um cluster kafka menos poderoso à pré-produção, onde não é necessário, basta alterar a configuração.

Lição 4. Transfira tudo para o cluster e faça backup de todo


Então, resolvemos a produção. O que fazer com os bancos de dados? Com Kafka? Com problemas de segurança?

Se você ler com atenção, lembre-se: escrevi que os bancos de dados podem ser incluídos no pacote de gráficos.

O Kubernetes possui uma API separada para executar bancos de dados e outros aplicativos com estado de forma conveniente - StatefulSets.

A essência do Kubernetes é melhorar a confiabilidade do lançamento de contêineres. Com ele e usando a ferramenta Velero (instalada via Helm Chart), você pode criar um backup de todo o cluster Kubernetes, juntamente com os discos conectados a ele, por exemplo, aqueles criados pelo StatefulSet, e restaurar tudo com um único comando. Além disso, é fácil configurar o backup automático em uma programação.

Backups, recuperação em uma equipe e o gerente do Kubernetes ajudarão você a implantar um cluster completamente novo e restaurar seu backup com apenas duas equipes. No máximo três, se você desejar primeiro criar um novo backup.

Em vez de pensar em servidores, você pode operar em clusters inteiros.

A pré-produção é irritante? Tire isso da vista - à distância de backup, recuperação e alteração de DNS.

Lição 5. A VPN é muito complicada, existem soluções mais fáceis


Você já usou uma VPN com prazer?

Na verdade Isso é possível?

O Google teve essa tentativa. Mas há alguns anos, a empresa anunciou que não usaria uma VPN. Eu acho que eles também não gostaram.

O Google mudou para redes sem confiança. Eles não têm uma chave mestra adequada para qualquer rede, mas na entrada de cada serviço há uma chave na forma de uma tela de login do SSO. Deseja fazer login no serviço de monitoramento? Faça login usando o nome de usuário e a senha da sua empresa.

Apenas uma pequena mudança é necessária: em vez de usar uma VPN para autorização, use um proxy.

A VPN também hospeda o link de gerenciamento Kubernetes na rede privada, enquanto o SSO não. Mas eles têm seu próprio mecanismo de autorização. No caso do Google Cloud e da AWS, trata-se de Gerenciamento de identidade e acesso (IAM) e a capacidade de incluir endereços IP na lista de permissões.

Se é possível trabalhar com arquitetura menos volumosa sem muita perda, por que não? Seja como o Google: mude da VPN para os sistemas "sem confiança".

Lição 6. Organizar, automatizar e conquistar


Ah, parece que a sistematização é muito tempo? Bobagem! No futuro, você economizará horas, dias e até semanas. Trabalhar!

A sistematização é a única maneira realista de recriar a infraestrutura mais de uma vez.

Se cada item de configuração puder ser aprimorado alterando e comprometendo algo no git, essencialmente toda a sua organização tecnológica é declarativa. Qualquer desenvolvedor com acesso ao git pode facilmente manter qualquer sistema em condições de funcionamento.

Para fazer isso, use vários repositórios pequenos. Os monorepos fazem as pessoas recuar e dependem de estruturas com importância artificial. Em vez disso, é melhor usar muitos repositórios pequenos que você pode vincular mais tarde.

Meu amigo Matt e eu estamos criando uma ferramenta chamada meta para ajudar a fazer isso no estágio de desenvolvimento. Helm faz isso na fase de produção: para ele tudo é um gráfico de dependência!

Conclusão


Não pegue a casca do ovo, pedaço por pedaço. Bata e role.

Source: https://habr.com/ru/post/pt457120/


All Articles