Get best of the week

Kubernetes, microsserviços, CI / CDs e Dockers para retrógrados: dicas de aprendizado

Parece que o tópico “por que precisamos do Kubernetes” já é irritante. Quero dizer: “todo mundo que precisa dele há muito tempo entende”, mas eu dividiria os trabalhadores técnicos (e quase técnicos) naqueles que “entenderam e sabem usar” e aqueles que “entenderam, mas querem saber como tornar o conhecimento relevante "

Talvez você seja um gerente que trabalha na mesma pilha nos últimos 10 anos; você pode ser um desenvolvedor que suporta a solução antiga ou escreve em um idioma familiar em um ambiente familiar. Talvez você tenha mudado do gerenciamento técnico para o organizacional, e de repente descobriu que tudo o que sabia não era mais relevante, e quero entender se existe um cenário relativamente simples de como isso pode ser percebido. Tentarei dar conselhos com base em minha própria experiência - de uma pessoa que percebeu que estar na gestão organizacional será em breve expressa pelas palavras "Kubernetes é uma tecnologia eficaz, devemos nos esforçar para sua aplicação", sem entender completamente o que está por trás com essas palavras e por trás de toda a cultura técnica que se desenvolveu recentemente.

Por que considero importante poder mudar o paradigma do pensamento tecnológico?

O mais difícil para quem trabalha em tecnologia há muito tempo é aceitar que a nova tendência se tornou permanente. Ao longo de 20 anos de trabalho, vi como as diferentes tecnologias surgiram e desapareceram, e algumas delas foram "super relevantes" por vários meses.

Li Joel Spolsky sobre como a Microsoft sistematicamente inventa uma nova pilha para desenvolvedores, a fim de geralmente impedir que eles olhem para outra coisa. Como o SRE, eu tinha um duplo medo de toda nova tecnologia: tudo que é novo é cru, tudo que é cru é instável. Bem, tudo instável levará a problemas na produção, e a estabilidade da produção é o principal.

Como programador e empreendedor, eu queria criar um produto mais rapidamente - preciso aprender tudo de novo, mudar as abordagens usuais, o que significa - implantar os recursos mais lentamente. Se algumas novas tecnologias forem adotadas rapidamente, tudo o que estiver relacionado ao desenvolvimento orientado a microsserviços (vamos chamá-lo de toda a pilha moderna) precisará ser ensinado. E todo ano para aprender mais; é muito mais fácil escrever da maneira antiga e entregar o produto mais rapidamente.

Mas o fato permanece: às vezes as novas tecnologias permanecem e mudam todo o paradigma. E aqui surge uma escolha: permanecer no antigo paradigma ou mudar para um novo. Os programadores da Cobol ainda podem conseguir um emprego, lembram os desenvolvedores perl sobre reservas, mas maneiras alternativas para essas pessoas estão se tornando cada vez menos. E então "retrógrado" em nome da estabilidade se torna uma limitação. Com toda a pilha moderna, se você não quiser se limitar, não é a hora que chegou, mas já estamos atrasados. E, se não queremos ficar presos no perl, precisamos aprender. Leva muito tempo. Vou tentar contar minha experiência passo a passo na aprendizagem.

Instruções de mergulho


Entenda como executar aplicativos na janela de encaixe. Antes de tudo, os veteranos devem entender que a maneira de "armazenar" e "iniciar" aplicativos mudou para sempre. Provavelmente, um desenvolvedor que aprendeu a desenvolver nos últimos anos não tem idéia de como executar um aplicativo em produção sem uma janela de encaixe. Provavelmente, a cabeça de um desenvolvedor não tem o conceito de "armazenar arquivos localmente", exceto em casos raros de armazenamento compartilhado, mas a principal coisa que um "veterano" precisa entender é: o docker é um novo exe. O formato exe pode ter suas desvantagens, mas ninguém realmente pensa nisso.

Sim, a abordagem de microsserviço se tornou o padrão. Como antes, o OOP parecia facilitar a criação de software de grandes equipes por grandes equipes; agora os microsserviços se tornaram o mesmo padrão. Eles são cultivados até pelas mesmas pessoas (ver Fowler) Isso é razoável: se a API do aplicativo for versionada, será mais fácil para as equipes individuais gravar aplicativos independentes do que um grande. Pode-se argumentar por que pequenos aplicativos devem ser gravados em microsserviços, mas em algum momento todos começaram a escrevê-los no estilo OOP - é tão familiar (veja exe acima). Há muito o que argumentar que a comunicação entre processos (especialmente a construída na pilha TCP) tem um milhão de falhas de desempenho (um serviço passa para o outro através do TCP em vez de apenas fazer uma chamada de assembler - você pode imaginar qual é a diferença produtividade?), mas permanece o fato de que os microsserviços têm as vantagens de desenvolver projetos de médio e grande porte e também se tornaram o padrão. Entenda como os microsserviços interagem entre si (HTTP API, grpc,interação assíncrona através da fila - um milhão de maneiras), como um bônus - entenda o que é uma malha de serviço. (Um momento de humor zangado: Deus, pessoal, eles tiveram a ideia de compartilhar o aplicativo, e descobriu que a comunicação entre os aplicativos divididos é uma piada difícil, então eles adicionaram outra camada para aliviar o horror entre os processos, o que é isso para nós?)

, .Portanto, reconciliamos que agora estamos lançando os aplicativos na janela de encaixe e que compartilhamos o aplicativo em microsserviços. Agora, precisamos gerenciar de alguma forma as janelas de encaixe em execução. Você pode fazer isso sozinho em servidores dedicados (e orientar, por exemplo, Docker Swarm ou criar o Kubernetes) ou pode usar os serviços que as nuvens fornecem - serviços de contêiner da AWS ou Kubernetes. Há uma grande vantagem em usar nuvens. De fato, você para de pensar na camada que está sendo executada abaixo do gerenciador de contêineres (o SRE agora ri, mas vamos admitir - quando tudo está estável, na maioria dos casos não subimos nos nós GKE). Assim, de fato, o gerente de contêiner, cujo padrão Kubernetes se tornou, está se transformando em um sistema operacional. Possui gerenciadores de pacotes, você pode "instalar software" nele, executar "exe-shniki" nele - janelas de encaixe,tem kronjoby. Kubernetes é um novo sistema operacional.

Entenda como os contêineres do docker precisarão ser entregues. O layout de um site simples agora leva 5 minutos, e as pessoas consideram isso a norma. Precisamos coletar a janela de encaixe, testá-lo, colocá-lo no registro e no gerenciador de janelas (vamos falar mais sobre o Kubernetes). Essa é a selvageria (?) A que todos estão acostumados, é otimizada e esse é o padrão. Os sistemas de CI / CD tornaram-se o layout padrão e precisam ser tratados. Assim como no GitOps.

Entenda que a hospedagem local para a maioria dos aplicativos será coisa do passado (no Ocidente - já se foi).Era uma vez, a norma para comprar servidores, montá-los, trazê-los para o DC, colocar em colocation e switch. Mesmo para um projeto pequeno. Depois vieram servidores dedicados. Quantas pessoas agora estão pensando em atormentar, comprar e coletar ferro em projetos de pequeno e médio porte? Os dedicados - no Ocidente agora e na Federação Russa em breve - serão substituídos por nuvens. Isso é discutido há cem anos, eu uso a AWS desde 2008 e há problemas, mas quando falamos sobre o serviço que assume o gerenciamento do Kubernetes (EKS, GKE, Kubernetes da Yandex ou Selectel), não entendo por que gerenciar Kubernetes e Dediks, se outros caras fazem isso? Não troco mais de coolers nos Dediks ... A questão da prevalência das distribuições locais do Kubernetes na Federação Russa é uma questão da taxa de câmbio do dólar,a lei sobre persas e "jovens" da hospedagem em nuvem russa. Cedo ou tarde, isso será decidido e no local se tornará a natureza selvagem que as empresas e grandes projetos carregados desejam. Com bases iguais. Se estivermos falando sobre a maioria dos aplicativos que não exigem carga super alta ou ajuste super poderoso, o PostreSQL / MongoDB / MySQL baseado em nuvem oferece um grande número de vantagens. Não há necessidade de pensar em ajuste, nem em backups. Crie um servidor de desenvolvimento a partir de um servidor de produção - alguns comandos no console da nuvem. Entendo que toda essa ideia possa causar raiva ao administrador: pessoal, eu sou o administrador, mas para a maioria das tarefas não ruins, o gerenciamento de banco de dados, no entanto, não é necessário. Talvez o AWS e o GKE sejam caros e inacessíveis para nós por causa da lei persa, mas esse é apenas um tempo adicional a atrasar: mais cedo ou mais tarde, Yandex ou Selectel terão os mesmos recursos,e o paradigma mudará.

Entenda qual infraestrutura está agora escrita. Eu não gostava de IaaC quando ele era Chef e Puppet, mas, graças a Deus, eles foram substituídos por Terraform e Pulumi mais adequados para descrever o que você deseja criar no cluster e Ansible para trabalhar dentro. Entre e coloque algo na concha - agora selvageria absoluta. Sim, é mais rápido e mais conveniente, mas no novo paradigma é loucura: lembre-se de exe.

Curso de mergulho profundo


Como vejo uma maneira técnica específica para entender como trabalhar com uma pilha moderna?

1) Faça uma conta de teste na hospedagem em nuvem. Todos os provedores de hospedagem os fornecem. Comecei com o GKE, mas você pode, por exemplo, ter uma conta nos serviços de hospedagem russos, se espera que trabalhe, provavelmente, neste território.
Se o Terraform / Pulumi suportar sua nuvem, descreva a infraestrutura que você deseja criar neles. Se você possui habilidades de programação, recomendo o Pulumi: em vez de seu próprio Terraform SDL, você pode escrever em linguagens e construções familiares.

2) Encontre o aplicativo e coloque-o na janela de encaixe. O que há para embalar - a escolha é sua. De repente, descobri por mim mesmo como o NodeJS se generalizou e decidi fazer um estudo profundo de sua operação, então continuo trabalhando com o nó. Aqui, por exemplo, há um blog sobre o NodeJS , que pode ser criado, mas, em geral, tudo fica a seu critério.

3) Lide com as construções básicas (para, implantação, serviço) do K8S e implante o aplicativo com as mãos no cluster K8S.

4) Lide com o Helm, escreva um gráfico do Helm, implante um aplicativo Helm.
Faça um plano gratuito no CircleCI como um CI-ke, que não precisa ser definido, e configure: as configurações serão semelhantes a outros sistemas.

5) Corrija o aplicativo através do CI-ku.
IC separado (que o aplicativo cria) e CD. Crie um CD com o GitOps (veja, por exemplo, ArgoCD).

Qual é o próximo


Em algum lugar a partir de agora, você, em princípio, estará ciente das principais bases da pilha moderna.
Onde posso ir mais longe?

  • Se você está procurando um emprego / deseja trabalhar no Ocidente, pode ter um conhecimento mais profundo da computação em nuvem: envie um certificado do Google ou equivalente da AWS ao Cloud Architect ( recentemente recebemos três desses certificados no ITSumma ). Isso dará uma idéia dos recursos que oferecem o Cloud e os ajudará a navegar. Bom curso na linuxacademy .
  • Entregue à CKA: este é um tópico difícil, mas vale a pena. A preparação para o exame fornecerá um enorme pacote de conhecimentos.
  • Aprenda a programar se não souber como. Agora fui estudar a frente e estou impressionado com a mudança de tudo. Meu conhecimento terminou em algum lugar em 2012 ou mesmo antes, no jQuery, as pessoas riem. A frente agora se tornou mais complicada do que o back-end, há uma enorme quantidade de lógica de aplicativo e, ao mesmo tempo, paradigmas que são completamente incomuns para mim. Muito interessante!

E sou um pouco mais regular do que o blog aqui, mantenho meu canal de telegrama , assino :-)

More articles:


All Articles