A quarta versão do OpenShift foi lançada há relativamente pouco tempo. A versão atual 4.3 está disponível desde o final de janeiro e todas as alterações nela contidas ou são algo completamente novo que não estava na terceira versão, ou uma grande atualização do que apareceu na versão 4.1. Tudo o que vamos contar agora precisa ser conhecido, compreendido e levado em consideração por quem trabalha com OpenShift e planeja migrar para uma nova versão.
Com o lançamento do OpenShift 4.2, a Red Hat facilitou o trabalho com o Kubernetes. Novas ferramentas e plug-ins surgiram para a criação de contêineres, pipelines de CI/CD e implantações sem servidor. As inovações dão aos desenvolvedores a oportunidade de se concentrarem em escrever código, e não em lidar com Kubernetes.
Na verdade, o que há de novo nas versões do OpenShift 4.2 e 4.3?
Movendo-se em direção às nuvens híbridas
Ao planear uma nova infraestrutura de TI ou ao desenvolver um cenário de TI existente, as empresas estão cada vez mais a considerar uma abordagem de nuvem para o fornecimento de recursos de TI, para a qual implementam soluções de nuvem privada ou utilizam o poder dos fornecedores de nuvem pública. Assim, as infraestruturas de TI modernas são cada vez mais construídas de acordo com um modelo de nuvem “híbrido”, quando são utilizados tanto recursos locais como recursos de nuvem pública com um sistema de gestão comum. O Red Hat OpenShift 4.2 foi especialmente projetado para simplificar a transição para um modelo de nuvem híbrida e facilita a conexão de recursos de provedores como AWS, Azure e Google Cloud Platform ao cluster, além de usar nuvens privadas em VMware e OpenStack.
Nova abordagem para instalação
Na versão 4, a abordagem de instalação do OpenShift mudou. A Red Hat fornece um utilitário especial para implantar um cluster OpenShift - openshift-install. O utilitário é um único arquivo binário escrito em Go. O Openshit-installer prepara um arquivo yaml com a configuração necessária para implantação.
No caso de instalação usando recursos de nuvem, você precisará especificar informações mínimas sobre o futuro cluster: zona DNS, número de nós de trabalho, configurações específicas para o provedor de nuvem, informações da conta para acessar o provedor de nuvem. Depois de preparar o arquivo de configuração, o cluster pode ser implementado com um comando.
No caso de instalação em seus próprios recursos computacionais, por exemplo, ao usar uma nuvem privada (vSphere e OpenStack são suportados) ou ao instalar em servidores bare metal, você precisará configurar manualmente a infraestrutura - preparar o número mínimo de máquinas virtuais ou servidores físicos necessários para criar um cluster do Control Plane, configurar serviços de rede. Após esta configuração, um cluster OpenShift pode ser criado de forma semelhante com um comando do utilitário openshift-installer.
Atualizações de infraestrutura
Integração CoreOS
A principal atualização é a integração com o Red Hat CoreOS. Os nós mestres do Red Hat OpenShift agora podem funcionar apenas no novo sistema operacional. Este é um sistema operacional gratuito da Red Hat projetado especificamente para soluções de contêiner. Red Hat CoreOS é um Linux leve otimizado para execução de contêineres.
Se no 3.11 o sistema operacional e o OpenShift existiam separadamente, no 4.2 ele está inextricavelmente ligado ao OpenShift. Agora, este é um dispositivo único – infraestrutura imutável.
Para clusters que usam RHCOS para todos os nós, atualizar o OpenShift Container Platform é um processo simples e altamente automatizado.
Anteriormente, para atualizar o OpenShift, primeiro era necessário atualizar o sistema operacional subjacente no qual o produto estava sendo executado (na época, Red Hat Enterprise Linux). Só então o OpenShift poderia ser atualizado gradualmente, nó por nó. Não se falava em automatização do processo.
Agora, como o OpenShift Container Platform controla totalmente os sistemas e serviços em cada nó, incluindo o sistema operacional, essa tarefa é resolvida pressionando um botão na interface web. Depois disso, um operador especial é lançado dentro do cluster OpenShift, que controla todo o processo de atualização.
Novo CSI
Em segundo lugar, o novo CSI é um controlador de interface de armazenamento que permite conectar vários sistemas de armazenamento externos ao cluster OpenShift. Um grande número de provedores de drivers de armazenamento para OpenShift são suportados com base em drivers de armazenamento escritos pelos próprios fabricantes de sistemas de armazenamento. Uma lista completa de drivers CSI suportados pode ser encontrada neste documento: . Nesta lista você encontra todos os principais modelos de disk arrays dos principais fabricantes (Dell/EMC, IBM, NetApp, Hitachi, HPE, PureStorage), soluções SDS (Ceph) e armazenamento em nuvem (AWS, Azure, Google). OpenShift 4.2 suporta drivers CSI da especificação CSI versão 1.1.
Malha de serviço RedHat OpenShift
Baseado nos projetos Istio, Kiali e Jaeger, o Red Hat OpenShift Service Mesh, além das tarefas habituais de roteamento de solicitações entre serviços, permite o seu rastreamento e visualização. Isso ajuda os desenvolvedores a comunicar, monitorar e gerenciar facilmente uma aplicação implantada dentro do Red Hat OpenShift.
Visualização de uma aplicação com arquitetura de microsserviços usando Kiali
Para simplificar ao máximo a instalação, a manutenção e o gerenciamento do ciclo de vida do Service Mesh, o Red Hat OpenShift fornece aos administradores um operador especial, o Service Mesh Operator. Este é um operador Kubernetes que permite implantar pacotes Istio, Kiali e Jaeger reconfigurados em um cluster, maximizando a carga administrativa de gerenciamento de aplicativos.
CRI-O em vez de Docker
O tempo de execução do contêiner padrão Docker foi substituído pelo CRI-O. Já era possível usar o CRI-O na versão 3.11, mas na 4.2 ele se tornou o principal. Não é bom nem ruim, mas é algo para se ter em mente ao usar o produto.
Operadores e implantação de aplicativos
Os operadores são uma nova entidade do RedHat OpenShift, que apareceu na quarta versão. É um método de empacotamento, implantação e gerenciamento de um aplicativo Kubernetes. Ele pode ser pensado como um plugin para aplicativos implantados em contêineres, conduzido pela API Kubernetes e pelas ferramentas kubectl.
Os operadores Kubernetes ajudam a automatizar quaisquer tarefas relacionadas à administração e ao gerenciamento do ciclo de vida do aplicativo que você implanta em seu cluster. Por exemplo, o operador pode automatizar atualizações, backups e dimensionamento da aplicação, alterar a configuração, etc. Uma lista completa de operadores pode ser encontrada em .
O OperatorHub pode ser acessado diretamente da interface da web do console de gerenciamento. É um diretório de aplicativos para OpenShift mantido pela Red Hat. Aqueles. todos os operadores aprovados pela Red Hat serão cobertos pelo suporte do fornecedor.
Portal OperatorHub no console de gerenciamento OpenShift
Imagem base universal
É um conjunto padronizado de imagens do RHEL OS que pode ser usado para construir seus aplicativos em contêineres. Existem conjuntos mínimos, padrão e completos. Eles ocupam muito pouco espaço e suportam todos os pacotes instalados e linguagens de programação necessários.
Ferramentas CI/CD
No RedHat OpenShif 4.2, tornou-se possível escolher entre Jenkins e OpenShift Pipelines baseados em Tekton Pipelines.
OpenShift Pipelines é baseado em Tekton, que é melhor suportado por Pipeline conforme abordagens de Code e GitOps. Nos pipelines OpenShift, cada etapa é executada em seu próprio contêiner, portanto, os recursos são usados apenas enquanto a etapa está em execução. Isso dá aos desenvolvedores controle completo sobre pipelines de entrega de módulos, plug-ins e controle de acesso sem um servidor central de CI/CD para gerenciar.
O OpenShift Pipelines está atualmente no Developer Preview e disponível como operador em um cluster OpenShift 4. Claro, os usuários do OpenShift ainda podem usar Jenkins no RedHat OpenShift 4.
Atualizações de gerenciamento de desenvolvedores
No OpenShift 4.2, a interface web foi completamente atualizada para desenvolvedores e administradores.
Nas versões anteriores do OpenShift, todos trabalhavam em três consoles: diretório de serviço, console do administrador e console de trabalho. Agora o cluster está dividido em apenas duas partes - console do administrador e console do desenvolvedor.
O console do desenvolvedor recebeu melhorias significativas na interface do usuário. Agora exibe de forma mais conveniente as topologias dos aplicativos e suas montagens. Isso torna mais fácil para os desenvolvedores criar, implantar e visualizar aplicativos em contêineres e recursos em cluster. Permite que eles se concentrem no que é importante para eles.
Portal do desenvolvedor no console de gerenciamento OpenShift
Odo
Odo é um utilitário de linha de comando orientado ao desenvolvedor que simplifica o desenvolvimento de aplicativos no OpenShift. Usando comunicação no estilo git push, esta CLI ajuda os desenvolvedores novos no Kubernetes a criar aplicativos no OpenShift.
Integração com ambientes de desenvolvimento
Os desenvolvedores agora podem construir, depurar e implantar seus aplicativos em OpenShift sem sair de seu ambiente de desenvolvimento de código favorito, como Microsoft Visual Studio, JetBrains (incluindo IntelliJ), Eclipse Desktop, etc.
Extensão Red Hat OpenShift Deployment para Microsoft Azure DevOps
A extensão Red Hat OpenShift Deployment para Microsoft Azure DevOps foi lançada. Os usuários deste conjunto de ferramentas DevOps agora podem implantar seus aplicativos 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 estamos falando de um novo lançamento, e não de uma atualização, você não pode simplesmente colocar a quarta versão em cima da terceira. A atualização da versão XNUMX para a versão XNUMX não será suportada..
Mas há boas notícias: a Red Hat fornece ferramentas para migrar projetos do 3.7 para o 4.2. Você pode migrar cargas de trabalho de aplicativos usando a ferramenta Cluster Application Migration (CAM). CAM permite controlar a migração e minimizar o tempo de inatividade do aplicativo.
turno aberto 4.3
As principais inovações descritas neste artigo surgiram na versão 4.2. As mudanças 4.3 lançadas recentemente não são tão grandes, mas ainda há algumas coisas novas. A lista de alterações é bastante extensa, aqui estão as mais significativas em nossa opinião:
Atualize a versão do Kubernetes para 1.16.
A versão foi atualizada em duas etapas ao mesmo tempo; no OpenShift 4.2 era 1.14.
Criptografia de dados no etcd
A partir da versão 4.3, tornou-se possível criptografar dados no banco de dados etcd. Depois que a criptografia estiver habilitada, será possível criptografar os seguintes recursos da API OpenShift e da API Kubernetes: segredos, ConfigMaps, rotas, tokens de acesso e autorização OAuth.
Capacete
Adicionado suporte para Helm versão 3, um gerenciador de pacotes popular para Kubernetes. Por enquanto, o suporte tem o status TECHNOLOGY PREVIEW. O suporte do Helm será expandido para suporte total em versões futuras do OpenShift. O utilitário helm cli vem com o OpenShift e pode ser baixado do console da web de gerenciamento de cluster.
Atualização do painel do projeto
Na nova versão, o Painel do Projeto fornece informações adicionais na página do projeto: status do projeto, utilização de recursos e cotas do projeto.
Exibindo vulnerabilidades para o cais no console da Web
Um recurso foi adicionado ao console de gerenciamento para exibir vulnerabilidades conhecidas para imagens nos repositórios do Quay. A exibição de vulnerabilidades para repositórios locais e externos é suportada.
Criação simplificada de operatorhub off-line
Para o caso de implantação de um cluster OpenShift em uma rede isolada, onde o acesso à Internet é limitado ou ausente, a criação de um “espelho” para o registro do OperatorHub é simplificada. Agora isso pode ser feito com apenas três equipes.
Autores:
Victor Puchkov, Yuri Semenyukov
Fonte: habr.com