A quarta versão do OpenShift foi lançada relativamente recentemente. A versão atual, 4.3, está disponível desde o final de janeiro, e todas as suas mudanças são ou algo completamente novo que não existia na terceira versão, ou uma grande atualização do que apareceu na versão 4.1. Tudo o que vamos mencionar agora é essencial para quem trabalha com OpenShift e planeja migrar para a nova versão.
Com o lançamento da versão OpenShift 4.2, a Red Hat simplificou o trabalho com Kubernetes. Novas ferramentas e plugins foram introduzidos para a criação de containers, pipelines CI/CD e implantações serverless. As inovações permitem que os desenvolvedores se concentrem na escrita de código, em vez de se perderem com Kubernetes.
O que, de fato, é novo nas versões OpenShift 4.2 e 4.3?
Movimento em direção a nuvens híbridas
Ao planejar uma nova infraestrutura de TI ou ao desenvolver o cenário de TI existente, as empresas estão cada vez mais considerando a abordagem em nuvem para fornecer recursos de TI, implementando soluções de nuvem privada ou utilizando a capacidade de provedores de nuvem pública. Assim, as infraestruturas de TI modernas estão cada vez mais sendo construídas com um modelo de nuvem híbrida, onde são utilizados tanto recursos on-premises quanto recursos de nuvem pública com um sistema de gestão comum. O Red Hat OpenShift 4.2 foi especificamente projetado para facilitar a transição para o modelo de nuvem híbrida e permite conectar facilmente ao cluster recursos de provedores como AWS, Azure e Google Cloud Platform, juntamente com o uso de nuvens privadas em VMware e OpenStack.
Nova abordagem para instalação
Na 4ª versão, a abordagem para instalação do OpenShift mudou. A Red Hat fornece uma ferramenta especial para implantar clusters OpenShift – openshift-install. A ferramenta consiste em um único arquivo binário, escrito em Go. O openshift-installer prepara um arquivo yaml com a configuração necessária para a implantação.
No caso de instalação usando recursos de nuvem, será necessário fornecer informações mínimas sobre o futuro cluster: zona DNS, número de nós worker, configurações específicas para o provedor de nuvem e dados de conta para acesso ao provedor de nuvem. Após a preparação do arquivo de configuração, o cluster pode ser implantado com um único comando.
No caso de instalação em recursos computacionais próprios, por exemplo, ao utilizar nuvem privada (vSphere e OpenStack são suportados) ou ao instalar em servidores bare metal, será necessária a configuração manual da infraestrutura – preparar o número mínimo de máquinas virtuais ou servidores físicos necessários para criar um cluster Control Plane, configurar os serviços de rede. Após essa configuração, o cluster OpenShift poderá ser criado da mesma forma com um comando da ferramenta openshift-installer.
Atualizações na infraestrutura
Integração com CoreOS
Uma atualização chave é a integração com o Red Hat CoreOS. Agora, os nós mestres do Red Hat OpenShift podem operar apenas no novo sistema operacional. Este é um sistema operacional gratuito da Red Hat, projetado especificamente para soluções de contêineres. O Red Hat CoreOS é um Linux leve, otimizado para executar contêineres.
Se na versão 3.11 o sistema operacional e o OpenShift existiam separadamente, na 4.2 eles estão intrinsecamente ligados ao OpenShift. Agora, trata-se de um appliance único — infraestrutura imutável.
Para clusters que utilizam RHCOS para todos os nós, a atualização da OpenShift Container Platform é um processo simples e bem automatizado.
Antes, para atualizar o OpenShift, era necessário primeiro atualizar o sistema operacional base em que o produto estava em execução (na época, era o Red Hat Enterprise Linux). Somente após isso era possível atualizar o OpenShift gradualmente, nó por nó. Não havia qualquer automação no processo.
Atualmente, já que a OpenShift Container Platform controla completamente os sistemas e serviços em cada nó, incluindo o sistema operacional, essa tarefa é resolvida com um clique na interface web. Após isso, um operador especial é iniciado dentro do cluster OpenShift, gerenciando todo o processo de atualização.
Novo CSI
O segundo ponto é o novo CSI — controlador de interface de armazenamento, que permite conectar diferentes sistemas de armazenamento externos ao cluster OpenShift. Um grande número de provedores de drivers de armazenamento é suportado para o OpenShift com base em drivers de armazenamento, que são desenvolvidos pelos próprios fabricantes de sistemas de armazenamento. Uma lista completa dos drivers CSI suportados pode ser encontrada neste documento: . Esta lista contém todos os principais modelos de arrays de disco de fabricantes líderes (Dell/EMC, IBM, NetApp, Hitachi, HPE, PureStorage), soluções SDS (Ceph) e armazenamento em nuvem (AWS, Azure, Google). O OpenShift 4.2 suporta o uso de drivers CSI da especificação CSI versão 1.1.
RedHat OpenShift Service Mesh
Baseado em projetos como Istio, Kiali e Jaeger, o Red Hat OpenShift Service Mesh, além das tarefas habituais de roteamento de solicitações entre serviços, permite também o rastreamento e visualização. Isso ajuda os desenvolvedores a simplificar a interação, monitoramento e gestão de aplicações implantadas no Red Hat OpenShift.
Visualização de uma aplicação com arquitetura de microserviços utilizando Kiali
Para simplificar ao máximo os processos de instalação, prestação de serviços e gerenciamento do ciclo de vida do Service Mesh, o Red Hat OpenShift disponibiliza aos administradores um operador especial – Service Mesh Operator. Esse operador Kubernetes permite implantar pacotes reconfigurados de Istio, Kiali e Jaeger no cluster, reduzindo ao máximo a carga administrativa da gestão de aplicações.
CRI-O em vez de Docker
O runtime de contêiner Docker padrão foi substituído pelo CRI-O. A utilização do CRI-O já era possível na versão 3.11, mas na 4.2 ele se tornou o principal. Não é bom nem ruim, mas deve ser levado em conta ao utilizar o produto.
Operadores e implantação de aplicações
Os operadores são uma nova entidade no RedHat OpenShift que surgiu na quarta versão. Este é um método de empacotamento, implantação e gestão de aplicações Kubernetes. Pode ser concebido como um plugin para aplicações implantadas em contêineres, gerenciado por meio da API Kubernetes e ferramentas kubectl.
Os operadores Kubernetes ajudam a automatizar qualquer tarefa relacionada ao gerenciamento e ao ciclo de vida da aplicação que você implanta em seu cluster. Por exemplo, um operador pode automatizar atualizações, backups e escalonamento da aplicação, alterar configurações etc. A lista completa de operadores pode ser vista em .
O OperatorHub está disponível diretamente na interface web do console de gerenciamento. Trata-se de um catálogo de aplicações para OpenShift, suportado pela Red Hat. Ou seja, todos os operadores aprovados pela Red Hat terão cobertura de suporte do fornecedor.
Portal do OperatorHub no console de gerenciamento do OpenShift
Imagem base universal
Este é um conjunto padronizado de imagens do sistema operacional RHEL que podem ser usadas para criar seus aplicativos em contêineres. Existem conjuntos mínimo, padrão e completo. Eles ocupam muito pouco espaço, suportam todos os pacotes e linguagens de programação necessários instalados.
Ferramentas de CI/CD
No RedHat OpenShift 4.2, há a possibilidade de escolher entre Jenkins e OpenShift Pipelines com base em Tekton Pipelines.
OpenShift Pipelines é baseado no Tekton, que oferece melhor suporte a abordagens Pipeline as Code e GitOps. Nos pipelines do OpenShift, cada etapa é executada em seu próprio contêiner, portanto, os recursos são utilizados apenas durante a execução da etapa. Isso dá aos desenvolvedores controle total sobre os pipelines de entrega de módulos, plug-ins e controle de acesso, sem um servidor centralizado de CI/CD para gerenciar.
OpenShift Pipelines está atualmente em fase de Preview para desenvolvedores e está disponível como operador no cluster OpenShift 4. Naturalmente, os usuários do OpenShift ainda podem usar o Jenkins no RedHat OpenShift 4.
Atualizações na gestão para desenvolvedores
No 4.2, o OpenShift recebeu uma atualização completa na interface web tanto para desenvolvedores quanto para administradores.
Nas versões anteriores do OpenShift, todos trabalhavam em três consoles: catálogo de serviços, console de administrador e console de trabalho. Agora, o cluster está dividido apenas em duas partes — console de administrador e console de desenvolvedor.
O console de desenvolvedor recebeu melhorias significativas na interface do usuário. Agora, ele exibe de forma mais conveniente a topologia de aplicativos e suas construções. Isso facilita para os desenvolvedores a criação, implantação e visualização de aplicativos em contêiner e recursos de cluster. Permite que eles se concentrem no que é importante.
Portal do desenvolvedor no console de gerenciamento do OpenShift
Odo
O Odo é uma ferramenta de linha de comando voltada para desenvolvedores que simplifica o desenvolvimento de aplicativos no OpenShift. Usando uma interação no estilo git push, este CLI ajuda desenvolvedores que não estão familiarizados com Kubernetes a criar aplicativos no OpenShift.
Integração com ambientes de desenvolvimento
Os desenvolvedores agora podem criar, depurar e implantar seus aplicativos no OpenShift, sem sair do seu ambiente de desenvolvimento de código favorito, como Microsoft Visual Studio, JetBrains (incluindo IntelliJ), Eclipse Desktop, etc.
Extensão de Implantação do Red Hat OpenShift para Microsoft Azure DevOps
Foi lançado o complemento Red Hat OpenShift Deployment para o Microsoft Azure DevOps. Agora, os usuários desse conjunto de ferramentas DevOps podem implantar suas aplicações no Azure Red Hat OpenShift ou em qualquer outro cluster OpenShift diretamente do Microsoft Azure DevOps.
Transição da terceira versão para a quarta
Como se trata de um novo lançamento e não de uma atualização, não é tão simples apenas instalar a quarta versão sobre a terceira. A atualização da terceira para a quarta versão não será suportada.
Mas há uma boa notícia: a Red Hat oferece ferramentas para a migração de projetos da versão 3.7 para a 4.2. Você pode migrar cargas de trabalho de aplicações usando a ferramenta Cluster Application Migration (CAM). A CAM permite gerenciar a migração e minimizar o tempo de inatividade da aplicação.
OpenShift 4.3
As principais novidades descritas neste artigo surgiram na versão 4.2. Na recentemente lançada versão 4.3, as mudanças não são tão significativas, mas ainda há algumas novidades. A lista de alterações é bastante extensa, e aqui mencionamos as mais relevantes, na nossa opinião:
Atualização da versão do Kubernetes para 1.16.
A versão foi atualizada em dois níveis, na OpenShift 4.2 estava na 1.14.
Criptografia de dados no etcd
A partir da versão 4.3, agora é possível criptografar dados no banco etcd. Após a ativação da criptografia, será possível criptografar os seguintes recursos da OpenShift API e Kubernetes API: Secrets, ConfigMaps, Routes, tokens de acesso e autorizações OAuth.
Helm
Adicionada suporte para a versão 3 do Helm – gerenciador de pacotes popular para Kubernetes. Atualmente, o suporte está no status TECHNOLOGY PREVIEW. Em versões futuras do OpenShift, o suporte ao Helm será ampliado para total. A ferramenta helm cli é fornecida junto com o OpenShift e pode ser baixada do console web de gerenciamento do cluster.
Atualização do Project Dashboard
Na nova versão, o Project Dashboard fornece informações adicionais na página do projeto: status do projeto, utilização de recursos e cotas para o projeto.
Exibição de vulnerabilidades para quay no console web
Foi adicionada ao console de gerenciamento a função de exibir vulnerabilidades conhecidas para imagens nos repositórios Quay. É suportada a exibição de vulnerabilidades para repositórios locais e externos.
Facilitada a criação do operatorhub offline
Para o caso de implantação de um cluster OpenShift em uma rede isolada, cujo acesso à internet é limitado ou ausente, a criação de um "espelho" para o repositório OperatorHub foi simplificada. Agora, isso pode ser feito com apenas três comandos.
Autores:
Viktor Puchkov, Yuri Semenyukov
Fonte: habr.com
