OpenShift 4.0 - preparando-se para o hiper salto

Esta é a primeira de uma série de nossas publicações dedicadas a melhorias e adições na próxima atualização da plataforma Red Hat OpenShift para a versão 4.0, que ajudará você a se preparar para a transição para a nova versão.



Quais ferramentas você pode dispor para criar melhores produtos de software e como eles melhorarão a segurança e tornarão o desenvolvimento mais fácil e confiável?

Desde o momento em que os representantes da recém-formada comunidade Kubernetes se reuniram no outono de 2014 no escritório do Google em Seattle, já era possível dizer que o projeto Kubernetes estava destinado a mudar fundamentalmente as abordagens modernas para o desenvolvimento e a implementação de software. Ao mesmo tempo, os provedores de serviços de nuvem pública continuaram investindo ativamente no desenvolvimento de infraestrutura e serviços, o que facilitou e simplificou o trabalho com TI e a criação de software, e os tornou incrivelmente acessíveis, o que poucos poderiam imaginar no início da década.

Obviamente, o anúncio de cada novo serviço em nuvem foi acompanhado por numerosas discussões de especialistas no Twitter, e foram realizadas disputas em vários tópicos - incluindo o final da era do código aberto, o declínio da TI no lado do cliente (TI local), a inevitabilidade de um novo monopólio de software na nuvem e como o novo paradigma X substituirá todos os outros paradigmas.

No entanto, a realidade é que nada desaparece e hoje é possível observar o crescimento exponencial dos produtos finais e métodos de desenvolvimento, o que está associado ao surgimento constante de novos softwares em nossas vidas. E, apesar do fato de que tudo ao redor mudará, ao mesmo tempo, em essência, tudo permanecerá inalterado. Os desenvolvedores de software continuarão a escrever código de erro, os engenheiros de manutenção e os especialistas em confiabilidade continuarão a andar com os pagers e receberão alertas automáticos no Slack, os gerentes continuarão operando os conceitos de OpEx e CapEx e, sempre que ocorrer uma falha, o gerente sênior o desenvolvedor suspira tristemente com as palavras: "Eu disse" ...

Com a crescente complexidade dos projetos, novos riscos aparecem e, hoje, a vida das pessoas depende tanto do software que os desenvolvedores são simplesmente obrigados a tentar fazer melhor seu trabalho.

Kubernetes é uma dessas ferramentas. Está em andamento o trabalho para integrá-lo a outras ferramentas e serviços em uma única plataforma dentro da estrutura do Red Hat OpenShift, o que tornaria o software mais confiável, fácil de gerenciar e seguro para os usuários.

Com isso dito, surge a pergunta: como tornar o trabalho com o Kubernetes mais fácil e mais conveniente?

A resposta pode parecer surpreendentemente simples:

  • Automatize momentos complexos ao implantar na nuvem ou fora dela
  • concentre-se na confiabilidade enquanto oculta a complexidade;
  • Continue trabalhando na liberação de atualizações simples e seguras
  • alcançar capacidade de controle e auditoria;
  • esforçar-se para fornecer inicialmente alta segurança, mas não à custa da usabilidade.

A próxima versão do OpenShift deve levar em conta a experiência dos criadores e a experiência de outros desenvolvedores que implementam software em larga escala nas maiores empresas do mundo. Além disso, é necessário levar em consideração toda a experiência acumulada de ecossistemas abertos que hoje formam a base do mundo moderno. Nesse caso, é necessário abandonar a antiga mentalidade de um desenvolvedor amador e passar para uma nova filosofia de um futuro automatizado. Deve ser uma "ponte" entre as maneiras antigas e novas de implantar software e fazer pleno uso de toda a infraestrutura disponível - não importa se é atendido pelo maior provedor de nuvem ou está sendo executado em pequenos sistemas na periferia.

Como alcançar esse resultado?


Na Red Hat, é costume fazer um trabalho chato e ingrato por um longo tempo, a fim de preservar a comunidade estabelecida e impedir o fechamento de projetos nos quais a empresa participa. A comunidade de código aberto consiste em um grande número de desenvolvedores talentosos que criam as coisas mais extraordinárias - divertida, educacional, descobrindo novas oportunidades e simplesmente lindas, mas, é claro, ninguém espera que todos os participantes se movam na mesma direção ou busquem objetivos comuns. O uso dessa energia, seu redirecionamento na direção certa, às vezes é necessário para o desenvolvimento de áreas que seriam úteis para nossos usuários, mas, ao mesmo tempo, devemos monitorar o desenvolvimento de 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 - uma abordagem de código aberto mais segura e confiável. A empresa trabalhou no desenvolvimento dessas idéias e sua implementação, implementando nossa filosofia - tentando obter uma operação segura de todos os softwares. Todo esse trabalho se baseia no Kubernetes, Linux, nuvens públicas, nuvens privadas e nos milhares de outros projetos subjacentes ao nosso moderno ecossistema digital.

A nova versão do OpenShift 4 será compreensível, automatizada e mais natural

A plataforma OpenShift funcionará com os melhores e mais confiáveis ​​sistemas operacionais Linux, com suporte a hardware bare-metal, virtualização conveniente, programação automática da infraestrutura e, é claro, contêineres (que são essencialmente apenas imagens do Linux).

A plataforma deve estar segura desde o início, mas, ao mesmo tempo, oferecer a possibilidade de iterações convenientes para os desenvolvedores - ou seja, ter flexibilidade e confiabilidade suficientes, enquanto ainda permite aos administradores auditar e facilitar o gerenciamento.

Ele deve permitir a execução do software "na forma de um serviço" e não levar à expansão descontrolada 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 há necessidade de romper a selva de configurações de hardware e software, e todas as complicações aleatórias serão uma coisa do passado.

OpenShift 4: plataforma NoOps que não requer manutenção


Esta publicação descreveu as tarefas que ajudaram a moldar a visão da empresa para o OpenShift 4. A equipe tem a tarefa de simplificar ao máximo as tarefas diárias de operação e manutenção de software, tornando esses processos fáceis e sem esforço, tanto para especialistas em implementação quanto para desenvolvedores. Mas como alguém pode abordar esse objetivo? Como criar uma plataforma para o lançamento de software que requer intervenção mínima? O que NoOps significa neste contexto?

Se você tentar ignorá-lo, 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 aplicativo (APIs).
  • Não implemente software - deixe um provedor fazer isso em vez de você.
  • Você não deve adotar imediatamente a criação de uma grande estrutura - comece escrevendo pequenos fragmentos 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.

A tarefa, como antes, é acelerar as iterações no desenvolvimento de software, oferecer a oportunidade de criar produtos melhores e, assim, o desenvolvedor não pode se preocupar com os sistemas nos quais o software é executado. Um desenvolvedor experiente está ciente de que, se você se concentrar nos usuários, a imagem pode mudar rapidamente, portanto você não deve investir muito esforço na criação de software se não tiver confiança absoluta em sua necessidade.

Para profissionais envolvidos na manutenção e operação, a palavra "NoOps" pode parecer um pouco intimidadora. Porém, ao se comunicar com os engenheiros de operação, torna-se óbvio que os padrões e métodos utilizados por eles visando garantir a confiabilidade da confiabilidade (Site Reliability Engineering, SRE) têm muito em comum com os padrões descritos acima:

  • Não gerencie sistemas - automatize seus processos de gerenciamento.
  • Não implemente software - crie um pipeline para sua implantação.
  • Tente não combinar todos os seus serviços e não permita que a falha de um deles leve à falha de todo o sistema - disperse-os por toda a infraestrutura usando ferramentas de automação e conecte-os, proporcionando a possibilidade de controle e monitoramento.

Os especialistas em SRE sabem que algo pode dar errado e terão que rastrear e corrigir o problema - portanto, automatizam a rotina e determinam antecipadamente as tolerâncias a erros para estarem prontos para priorizar e tomar decisões quando ocorrer um problema. .

O Kubernetes do OpenShift é uma plataforma projetada para resolver duas tarefas principais: em vez de forçá-lo a lidar com máquinas virtuais ou APIs do balanceador de carga, trabalhar com abstrações de ordem superior - com 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, use as ferramentas já disponíveis na plataforma. Portanto, o ingrediente secreto do OpenShift 4 não representa realmente nenhum segredo - você só precisa tomar os princípios do SRE e dos conceitos sem servidor como base, e levá-los à sua conclusão lógica, para ajudar desenvolvedores e engenheiros de manutenção:

  • Automatize e padronize a infraestrutura usada pelos aplicativos
  • Reúna os processos de implantação e desenvolvimento sem limitar os próprios desenvolvedores
  • Garantir que o lançamento, a auditoria e a segurança de um centésimo serviço, função, aplicativo ou pilha inteira não sejam mais difíceis que o primeiro.

Mas qual é a diferença entre a plataforma OpenShift 4 e seus antecessores e a abordagem "padrão" para resolver esses problemas? Como o dimensionamento é alcançado para as equipes de implementação e operação? Devido ao fato de o rei nesta situação ser um cluster. Então

  • Tornamos compreensível o propósito dos clusters (Caro nuvem, criei esse 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 rastreie e corrija problemas
  • Falha * de cada * aspecto ou elemento do sistema; os mecanismos de recuperação correspondentes são uma parte comum da vida
  • Toda a infraestrutura deve ser configurada por meio da API.
  • Use o Kubernetes para iniciar o Kubernetes. (Sim, sim, isso não é um erro de digitação)
  • As atualizações devem ser instaladas fácil e naturalmente. Se demorar mais de um clique para instalar a atualização, obviamente você está fazendo algo errado.
  • O monitoramento e a depuração de qualquer componente não devem ser um problema e, portanto, o rastreamento e os relatórios em toda a infraestrutura também devem ser simples e convenientes.

Deseja ver os recursos da plataforma em ação?


Uma versão preliminar do OpenShift 4 ficou disponível para os desenvolvedores. Com um instalador fácil de usar, você pode executar um cluster da AWS sobre o Red Had CoreOS. Para usar a versão de visualização, você precisa apenas de uma conta da AWS para fornecer a infraestrutura e um conjunto de contas para acessar as imagens da versão de visualização.

  1. Para começar, vá para try.openshift.com e clique em "Introdução".
  2. Entre na sua conta Red Hat (ou crie uma nova) e siga as instruções para configurar seu primeiro cluster.

Após uma instalação bem-sucedida, consulte nossos tutoriais de treinamento do OpenShift para saber mais sobre os sistemas e conceitos que tornam a plataforma OpenShift 4 uma ferramenta tão simples e conveniente para iniciar o Kubernetes.

E na conferência do DevOpsForum 2019 , um dos desenvolvedores do OpenShift, Vadim Rutkovsky, realizará uma master class “Aqui você precisa mudar todo o sistema: repare os clusters quebrados do K8s junto com os serralheiros certificados” - ele quebrará dez clusters e mostrará como repará-los.

A entrada para a conferência é paga, mas usando o código promocional #RedHat - 37% de desconto.

Esperamos por você no dia 20 de abril, em uma aula master no Hall # 2 às 17:15 e no nosso estande - o dia todo. Informações úteis sobre o produto, reunião com especialistas, camisetas, chapéus, adesivos da Red Hat - tudo está como sempre! :-)

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


All Articles