Este é o primeiro de uma série de postagens sobre as mudanças, melhorias e adições na próxima atualização da plataforma Red Hat OpenShift 4.0 que ajudará você a se preparar para a transição para a nova versão.
Desde o momento em que a comunidade incipiente do Kubernetes se reuniu pela primeira vez no escritório do Google em Seattle, no outono de 2014, ficou claro que o projeto Kubernetes estava destinado a revolucionar a forma como o software é desenvolvido e implantado hoje. Ao mesmo tempo, os prestadores de serviços de nuvem pública continuaram a investir ativamente no desenvolvimento de infraestruturas e serviços, o que tornou o trabalho com TI e a criação de software muito mais fácil e acessível, e tornou-os incrivelmente acessíveis, o que poucos poderiam ter imaginado no início de a década.
É claro que o anúncio de cada novo serviço em nuvem foi acompanhado por inúmeras discussões entre especialistas no Twitter, e debates foram conduzidos sobre uma variedade de tópicos - incluindo o fim da era do código aberto, o declínio da TI local e a inevitabilidade de um novo monopólio de software na nuvem e como o novo paradigma X substituirá todos os outros paradigmas.
Escusado será dizer que todas essas disputas foram muito estúpidas
A realidade é que nada vai desaparecer e hoje podemos assistir a um crescimento exponencial dos produtos finais e da forma como são desenvolvidos, devido ao constante surgimento de novos softwares nas nossas vidas. E apesar de tudo ao redor mudar, ao mesmo tempo, em essência, tudo permanecerá inalterado. Os desenvolvedores de software ainda escreverão códigos com erros, os engenheiros de operações e especialistas em confiabilidade ainda andarão com pagers e receberão alertas automáticos no Slack, os gerentes ainda operarão em termos de OpEx e CapEx, e cada vez que ocorrer uma falha, quanto mais sênior o desenvolvedor suspirar tristemente com as palavras: “Eu te avisei”...
Oh sério deveria ser discutido, é quais ferramentas podemos ter à nossa disposição para criar melhores produtos de software e como elas podem melhorar a segurança e tornar o desenvolvimento mais fácil e confiável. À medida que os projetos se tornam mais complexos, surgem novos riscos e hoje a vida das pessoas depende tanto do software que os desenvolvedores simplesmente precisam tentar fazer melhor o seu trabalho.
Kubernetes é uma dessas ferramentas. Estão em andamento trabalhos para combinar o Red Hat OpenShift com outras ferramentas e serviços em uma única plataforma que tornaria o software mais confiável, mais fácil de gerenciar e mais seguro para os usuários.
Dito isso, a equipe do OpenShift faz uma pergunta simples:
Como você pode tornar o trabalho com Kubernetes mais fácil e conveniente?
A resposta é surpreendentemente óbvia:
- automatizar aspectos complexos de implantação na nuvem ou fora dela;
- concentre-se na confiabilidade enquanto esconde a complexidade;
- continuar trabalhando continuamente para lançar atualizações simples e seguras;
- alcançar controlabilidade e auditabilidade;
- esforce-se para garantir inicialmente alta segurança, mas não às custas da usabilidade.
A próxima versão do OpenShift deverá levar em conta 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, deve ter em conta toda a experiência acumulada de ecossistemas abertos que estão na base do mundo moderno de hoje. Ao mesmo tempo, é necessário abandonar a velha mentalidade do desenvolvedor amador e passar para uma nova filosofia de futuro automatizado. Ela precisa preencher a lacuna entre as formas antigas e novas de implantação de software e aproveitar ao máximo toda a infraestrutura disponível, seja ela hospedada pelo maior provedor de nuvem ou executada em pequenos sistemas na borda.
Como alcançar esse resultado?
Na Red Hat é costume fazer um trabalho chato e ingrato por muito tempo para preservar a comunidade estabelecida e evitar o encerramento de projetos nos quais a empresa está envolvida. A comunidade de código aberto contém um grande número de desenvolvedores talentosos que criam as coisas mais extraordinárias - divertidas, educacionais, que abrem novas oportunidades e simplesmente lindas, mas, é claro, ninguém espera que todos os participantes sigam na mesma direção ou busquem comum metas. Aproveitar esta energia e redireccioná-la na direcção certa é por vezes necessário para desenvolver áreas que beneficiariam os nossos utilizadores, mas ao mesmo tempo devemos monitorizar o desenvolvimento das nossas comunidades e aprender com elas.
No início de 2018, a Red Hat adquiriu o projeto CoreOS, que tinha visões semelhantes sobre o futuro - mais seguro e confiável, criado com base em princípios de código aberto. A empresa tem trabalhado para desenvolver ainda mais estas ideias e implementá-las, colocando a nossa filosofia em prática – tentando garantir que todo o software funciona de forma segura. 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á clara, 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 de infraestrutura e, claro, contêineres (que são essencialmente apenas imagens Linux).
A plataforma precisa ser segura desde o início, mas ainda permitir que os desenvolvedores façam iterações facilmente, ou seja, ser flexível e segura o suficiente, ao mesmo tempo que permite que os administradores a auditem e gerenciem facilmente.
Deverá permitir que o software seja executado “como um serviço” e não conduzir a um crescimento incontrolável da infra-estrutura para os operadores.
Isso permitirá que os desenvolvedores se concentrem na criação de produtos reais para usuários e clientes. Você não terá que percorrer a selva de configurações de hardware e software, e todas as complicações acidentais serão coisa do passado.
OpenShift 4: plataforma NoOps que não requer manutenção
В descreveu as tarefas que ajudaram a moldar a visão da empresa para o OpenShift 4. O objetivo da equipe é simplificar ao máximo as tarefas diárias de operação e manutenção de software, para tornar esses processos fáceis e descontraídos - tanto para especialistas envolvidos na implementação quanto para desenvolvedores. Mas como você pode se aproximar desse objetivo? Como criar uma plataforma para execução de software que requeira intervenção mínima? O que NoOps significa neste contexto?
Se você tentar abstrair, então para os desenvolvedores os conceitos de “sem servidor” ou “NoOps” significam ferramentas e serviços que permitem ocultar o componente “operacional” ou minimizar essa carga para o desenvolvedor.
- Trabalhe não com sistemas, mas com interfaces de aplicativos (APIs).
- Não se preocupe em implementar software – deixe o fornecedor fazer isso por você.
- Não comece imediatamente a criar uma estrutura grande - comece escrevendo pequenos pedaços que funcionarão como "blocos de construção", tente fazer esse código funcionar com dados e eventos, e não com discos e bancos de dados.
O objetivo, como antes, é acelerar as iterações no desenvolvimento de software, proporcionar a oportunidade de criar produtos melhores e fazer com que o desenvolvedor não precise se preocupar com os sistemas nos quais seu software é executado. Um desenvolvedor experiente está bem ciente de que focar nos usuários pode mudar rapidamente o quadro, então você não deve se esforçar muito para escrever software, a menos que tenha certeza absoluta de que é necessário.
Para profissionais de manutenção e operações, a palavra “NoOps” pode parecer um pouco assustadora. Mas ao se comunicar com engenheiros de campo, torna-se óbvio que os padrões e técnicas que eles utilizam visando garantir confiabilidade e confiabilidade (Site Reliability Engineering, SRE) têm muitas semelhanças com os padrões descritos acima:
- Não gerencie sistemas – automatize seus processos de gerenciamento.
- Não implemente software – crie um pipeline para implantá-lo.
- Evite agrupar todos os seus serviços e permitir que a falha de um deles cause a falha de todo o sistema – disperse-os por toda a sua infraestrutura usando ferramentas de automação e conecte-os de maneiras que possam ser monitoradas e monitoradas.
Os SREs sabem que algo pode dar errado e terão que rastrear e corrigir o problema – por isso, eles automatizam o trabalho de rotina e definem orçamentos de erros com antecedência para que estejam prontos para priorizar e tomar decisões quando surgir um problema.
Kubernetes no OpenShift é uma plataforma projetada para resolver dois problemas principais: em vez de forçá-lo a entender máquinas virtuais ou APIs de balanceador de carga, ele funciona com abstrações de ordem superior - processos e serviços de implantação. Em vez de instalar agentes de software, você pode executar contêineres e, em vez de escrever sua própria pilha de monitoramento, usar as ferramentas já disponíveis na plataforma. Portanto, o ingrediente secreto do OpenShift 4 realmente não é segredo - é apenas uma questão de pegar os princípios do SRE e os conceitos sem servidor e levá-los à sua conclusão lógica para ajudar desenvolvedores e engenheiros de operações:
- Automatize e padronize a infraestrutura que os aplicativos usam
- Vincule processos de implantação e desenvolvimento sem restringir os próprios desenvolvedores
- Garantir que o lançamento, a auditoria e a proteção do XNUMXº serviço, recurso, aplicativo ou pilha inteira não seja mais difícil do que o primeiro.
Mas qual é a diferença entre a plataforma OpenShift 4 e seus antecessores e a abordagem “padrão” para resolver tais problemas? O que impulsiona a escala das equipes de implementação e operações? Devido ao fato de o rei nesta situação ser o cluster. Então,
- Garantimos que o propósito dos clusters esteja claro (Querida nuvem, escolhi este cluster porque pude)
- Existem máquinas e sistemas operacionais para servir o cluster (Sua Majestade)
- Gerencie o estado dos hosts do cluster, minimize sua reconstrução (desvio).
- Para cada elemento importante do sistema, é necessária uma babá (mecanismo) que irá monitorar e eliminar problemas
- A falha de *todos* aspectos ou elementos de um sistema e mecanismos de recuperação associados são uma parte normal da vida
- Toda a infraestrutura deve ser configurada via API.
- Use o Kubernetes para executar o Kubernetes. (Sim, sim, isso não é um erro de digitação)
- As atualizações devem ser fáceis e descomplicadas de instalar. Se for necessário mais de um clique para instalar uma atualização, obviamente estamos fazendo algo errado.
- O monitoramento e a depuração de qualquer componente não devem ser um problema e, portanto, o rastreamento e a geração de relatórios em toda a infraestrutura também devem ser fáceis e convenientes.
Quer ver os recursos da plataforma em ação?
Uma versão prévia do OpenShift 4 foi disponibilizada para desenvolvedores. Com um instalador fácil de usar, você pode executar um cluster na AWS sobre o Red Had CoreOS. Para usar a visualização, você só precisa de uma conta da AWS para provisionar a infraestrutura e de um conjunto de contas para acessar as imagens de visualização.
- Para começar, vá para e clique em “Começar”.
- Faça login em 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, confira nossos tutoriais para obter uma compreensão mais profunda dos sistemas e conceitos que tornam a plataforma OpenShift 4 uma maneira tão fácil e conveniente de executar o Kubernetes.
Experimente a nova versão do OpenShift e compartilhe sua opinião. Estamos empenhados em tornar o trabalho com Kumbernetes o mais acessível e fácil possível – o futuro do NoOps começa hoje.
Agora atenção!
Na conferência Em 20 de abril, um dos desenvolvedores do OpenShift, Vadim Rutkovsky, dará uma master class - ele quebrará dez clusters e os forçará a consertá-los. A conferência é paga, mas com o código promocional #RedHat você ganha 37% de desconto
Master class das 17h15 às 18h15, e o estande fica aberto o dia todo. Camisetas, bonés, adesivos – o de sempre!
Salão #2
“Aqui todo o sistema precisa ser mudado: reparamos clusters k8s quebrados junto com mecânicos certificados.”
Fonte: habr.com