Esta é a primeira publicação de uma série de materiais dedicados às mudanças, melhorias e adições na próxima atualização da plataforma Red Hat OpenShift para a versão 4.0, que ajudarão na transição para a nova versão.
Desde o momento em que representantes da comunidade Kubernetes em formação se reuniram pela primeira vez no outono de 2014 no escritório do Google em Seattle, já era possível prever que o projeto Kubernetes estava destinado a mudar radicalmente as abordagens modernas para o desenvolvimento e implementação de software. Ao mesmo tempo, provedores públicos de serviços em nuvem continuaram a investir ativamente no desenvolvimento de infraestrutura e serviços, o que facilitou enormemente o trabalho com TI e a criação de software, tornando-os incrivelmente acessíveis, algo que poucos poderiam imaginar no início da década.
Naturalmente, o anúncio de cada novo serviço em nuvem foi acompanhado por diversas discussões entre especialistas no Twitter, com debates sobre uma variedade de tópicos – incluindo o fim da era do código aberto, o declínio da TI local (on-premises IT), a inevitabilidade de um novo monopólio de software nas nuvens e como uma nova paradigma X substituirá todos os outros paradigmas.
Vale a pena mencionar que todas essas discussões foram bastante tolas.
A realidade é que nada desaparece e hoje podemos observar um crescimento exponencial de produtos finais e das formas como são desenvolvidos, relacionado ao surgimento constante de novos softwares em nossas vidas. E, apesar de que tudo ao nosso redor mudará, em essência, tudo permanecerá inalterado. Os desenvolvedores de software continuarão escrevendo código com erros, engenheiros de operações e especialistas em confiabilidade continuarão usando pagers e recebendo notificações automáticas no Slack, gerentes ainda estarão lidando com os conceitos de OpEx e CapEx, e sempre que ocorrer uma falha, o desenvolvedor sênior suspirará tristemente dizendo: 'Eu avisei'…
O que realmente deveríamos discutir, então, quais ferramentas podemos ter à nossa disposição para criar produtos de software de maior qualidade, e como elas permitem aumentar a segurança e tornar o desenvolvimento mais fácil e confiável. Com o aumento da complexidade dos projetos, surgem novos riscos, e hoje em dia as vidas das pessoas dependem tanto do software que os desenvolvedores têm a obrigação de se esforçar para fazer seu trabalho melhor.
Kubernetes é uma dessas ferramentas. Está em andamento um trabalho para integrar isso com outras ferramentas e serviços dentro do Red Hat OpenShift em uma única plataforma, que permitiria tornar o software mais confiável, fácil de gerenciar e seguro para os usuários.
Com isso em mente, a equipe do OpenShift se faz uma simples pergunta:
Como podemos tornar o trabalho com Kubernetes mais fácil e conveniente?
A resposta é surpreendentemente óbvia:
- automatizar pontos complexos no deployment na nuvem ou fora dela;
- focar na confiabilidade, ocultando a complexidade;
- continuar a trabalhar continuamente na liberação de atualizações simples e seguras;
- alcançar controle e possibilidade de auditoria;
- buscar garantir alta segurança desde o início, mas sem comprometer a usabilidade.
A próxima versão do OpenShift deve considerar tanto a experiência dos criadores quanto a experiência de outros desenvolvedores, que estão implementando software em larga escala nas maiores empresas do mundo. Além disso, ela deve levar em conta toda a experiência acumulada das ecossistemas abertos, que fundamentam o mundo moderno hoje. Ao fazer isso, é necessário deixar de lado a mentalidade anterior do desenvolvedor amador e passar para uma nova filosofia de futuro automatizado. Deve ser uma "ponte" entre os antigos e novos métodos de deployment de software e aproveitar ao máximo toda a infraestrutura disponível – não importa se é operada pelo maior fornecedor de nuvem ou executada em pequenos sistemas na periferia.
Como alcançar esse resultado?
Na Red Hat, é comum dedicar muito tempo ao trabalho árduo e ingrato para manter a comunidade formada e evitar o fechamento de projetos nos quais a empresa está envolvida. A comunidade open-source abriga um enorme número de desenvolvedores talentosos que criam as coisas mais extraordinárias – divertidas, educativas, que abrem novas possibilidades e simplesmente bonitas. No entanto, ninguém espera que todos os participantes sigam na mesma direção ou perseguam objetivos comuns. Às vezes, é necessário redirecionar essa energia na direção certa para desenvolver áreas que seriam úteis para nossos usuários, mas ao mesmo tempo, devemos acompanhar o crescimento de nossas comunidades e aprender com elas.
No início de 2018, a Red Hat adquiriu o projeto CoreOS, que compartilhava visões semelhantes sobre o futuro – mais seguro e confiável, criado com base em princípios de open-source. A empresa trabalhou para o desenvolvimento adicional dessas ideias e sua implementação, realizando nossa filosofia – esforçando-se para garantir a operação segura de todo o software. Todo esse trabalho é baseado em Kubernetes, Linux, nuvens públicas, nuvens privadas e milhares de outros projetos que sustentam nosso ecossistema digital moderno.
A nova versão do OpenShift 4 será intuitiva, automatizada e mais natural.
A plataforma OpenShift funcionará com os melhores e mais confiáveis sistemas operacionais Linux, com suporte de hardware bare-metal, virtualização conveniente, programação automática da infraestrutura e, claro, contêineres (que na verdade são apenas imagens do Linux).
A plataforma deve ser segura desde o início, mas ao mesmo tempo proporcionar iterações convenientes para os desenvolvedores – ou seja, deve ter flexibilidade e confiabilidade suficientes, enquanto ainda permite que os administradores realizem auditorias e garantam facilidade de gerenciamento.
Ela deve permitir que o software seja executado "como um serviço", sem levar ao crescimento descontrolado da infraestrutura para os operadores.
Isso permitirá que os desenvolvedores se concentrem na criação de produtos reais para usuários e clientes. Não será necessário atravessar a selva de configurações de hardware e software, e todas as complicações aleatórias ficarão no passado.
OpenShift 4: Plataforma NoOps, sem necessidade de manutenção
Em As tarefas foram descritas, ajudando a formar a visão da empresa em relação ao OpenShift 4. A equipe tem como objetivo simplificar ao máximo as tarefas diárias de operações e manutenção de software, tornando esses processos fáceis e descontraídos – tanto para os especialistas em implementação quanto para os desenvolvedores. Mas como podemos nos aproximar desse objetivo? Como criar uma plataforma para executar software que requer mínima intervenção? O que realmente significa NoOps nesse contexto?
Se tentarmos nos abstrair, para os desenvolvedores, os conceitos de "serverless" ou "NoOps" significam ferramentas e serviços que permitem ocultar o componente operacional ou minimizar esse fardo para o desenvolvedor.
- Trabalhe com interfaces de programação de aplicativos (API), não com sistemas.
- Não se preocupe com a implementação do software – deixe que o provedor faça isso por você.
- Não comece imediatamente com a criação de uma grande estrutura – comece escrevendo pequenos fragmentos que funcionem como "blocos de construção", tentando fazer com que esse código trabalhe com dados e eventos, e não com discos e bancos de dados.
A tarefa, como antes, é acelerar as iterações no desenvolvimento de software, garantindo a possibilidade de criar produtos de maior qualidade, e assim o desenvolvedor pode não se preocupar com os sistemas em que seu software está sendo executado. Um desenvolvedor experiente entende perfeitamente que, ao se concentrar nos usuários, a situação pode mudar rapidamente, portanto, não deve dedicar muito esforço à escrita de software se não tiver absoluta certeza de sua necessidade.
Para os especialistas envolvidos na manutenção e operação, a palavra "NoOps" pode soar um pouco assustadora. Mas, ao conversar com engenheiros de operações, fica claro que os padrões e técnicas que eles utilizam, voltados para garantir a confiabilidade (Site Reliability Engineering, SRE), estão muito em linha com os padrões descritos acima:
- Não gerencie sistemas – automatize os processos de gerenciamento deles.
- Não se preocupe em implementar software – crie um pipeline para sua implantação.
- Evite agrupar todos os seus serviços e não deixe que a falha de um leve à falha de todo o sistema – distribua-os pela infraestrutura, utilizando ferramentas de automação, e conecte-os, prevendo a possibilidade de controle e monitoramento.
Os especialistas em SRE sabem que algo pode dar errado, e eles terão que rastrear e resolver o problema – por isso, automatizam o trabalho rotineiro e definem previamente os desvios aceitáveis (error budgets) para estarem prontos para priorizar e tomar decisões quando surgirem problemas.
O Kubernetes no OpenShift é uma plataforma destinada a resolver duas principais questões: em vez de forçá-lo a lidar com máquinas virtuais ou APIs de balanceadores de carga, trabalha-se com abstrações de nível superior – com processos de implantação e serviços. Em vez de instalar agentes de software, pode-se executar contêineres, e ao invés de escrever sua própria pilha de monitoramento, usar as ferramentas já disponíveis na plataforma. Assim, o ingrediente secreto do OpenShift 4 não é realmente um mistério – basta adotar os princípios de SRE e as conceitos sem servidor, e levá-los a um nível lógico, em apoio aos desenvolvedores e engenheiros de operações:
- Automatizar e padronizar a infraestrutura utilizada pelas aplicações
- Conectar processos de implantação e desenvolvimento, sem limitar os próprios desenvolvedores
- Garantir que a execução, auditoria e segurança do centésimo serviço, função, aplicativo ou pilha inteira não sejam mais complexas do que as do primeiro.
Mas o que distingue a plataforma OpenShift 4 de suas antecessoras e da abordagem "padrão" para resolver problemas semelhantes? Como se alcança a escalabilidade para as equipes que implementam e operam? O rei nesta situação é o cluster. Então,
- Vamos tornar o propósito dos clusters claro (Nuvem cara, eu criei este cluster porque consegui)
- Máquinas e sistemas operacionais existem para servir o cluster (Sua Majestade)
- Gerencie o estado dos hosts a partir do cluster, minimizando suas derivações.
- Para cada elemento importante do sistema, é necessário um cuidador (mecanismo) que monitore e resolva problemas.
- A falha de *cada* aspecto ou elemento do sistema deve ter mecanismos de recuperação — isso é parte normal da vida.
- Toda a infraestrutura deve ser configurada por meio de API.
- Use Kubernetes para rodar Kubernetes. (Sim, isso não é um erro de digitação)
- As atualizações devem ser instaladas de forma fácil e despretensiosa. Se for necessário mais de um clique do mouse para instalar uma atualização, claramente estamos fazendo algo errado.
- O monitoramento e a depuração de qualquer componente não devem ser problemas e, consequentemente, o rastreamento e a elaboração de relatórios de toda a infraestrutura também devem ser simples e convenientes.
Quer ver as capacidades da plataforma em ação?
A versão preliminar do OpenShift 4 está disponível para desenvolvedores. Com um instalador fácil de usar, é possível iniciar um cluster na AWS sobre o Red Hat CoreOS. Para utilizar a versão preliminar, basta ter uma conta AWS para fornecer a infraestrutura e um conjunto de contas para acessar as imagens da versão preliminar.
- Para começar, visite e clique em “Get Started”.
- Entre na sua conta Red Hat (ou crie uma nova) e siga as instruções para configurar seu primeiro cluster.
Após a instalação bem-sucedida, consulte nossos materiais de formação. , para obter uma visão mais detalhada sobre os sistemas e conceitos que fazem da plataforma OpenShift 4 uma ferramenta tão simples e conveniente para implantar Kubernetes.
Experimente o novo lançamento do OpenShift e compartilhe sua opinião. Estamos nos esforçando para tornar o trabalho com Kubernetes o mais acessível e sem esforço possível – o futuro do NoOps começa hoje.
Agora, atenção!
Na conferência No dia 20 de abril, um dos desenvolvedores do OpenShift, Vadim Rutkovsky, realizará uma masterclass — quebrará dez clusters e fará com que os consertem. A conferência é paga, mas com o código promocional #RedHat, você recebe 37% de desconto.
A masterclass será das 17:15 às 18:15, e o estande funcionará durante todo o dia. Camisetas, chapéus, adesivos — como de costume!
Sala #2
«Aqui é preciso mudar todo o sistema: vamos consertar clusters k8s quebrados junto com mecânicos certificados».
Fonte: habr.com
