Get best of the week

O que há de novo no Red Hat OpenShift 4.2 e 4.3?


A quarta versão do OpenShift foi lançada relativamente recentemente. A versão atual 4.3 está disponível a partir do final de janeiro e todas as alterações nela são algo completamente novo, que não estava na terceira versão, ou uma atualização importante do que apareceu na versão 4.1. Tudo o que contaremos agora, você precisa conhecer, entender e considerar aqueles que trabalham com o OpenShift e planeja atualizar para a nova versão.

Com o lançamento do OpenShift 4.2, a Red Hat simplificou o Kubernetes. Novas ferramentas e plugins para a criação de contêineres, pipelines de CI / CD e implantações sem servidor apareceram. As inovações dão aos desenvolvedores a oportunidade de focar na escrita de código, em vez de litígios com o Kubernetes.

Na verdade, o que há de novo nas versões do OpenShift 4.2 e 4.3?

Mover para nuvens híbridas


Ao planejar uma nova infraestrutura de TI ou ao desenvolver um cenário de TI existente, as empresas estão cada vez mais considerando a abordagem de nuvem no fornecimento de recursos de TI, para os quais implementam soluções de nuvem privada ou usam o poder de provedores públicos de nuvem. Assim, as infraestruturas de TI modernas estão sendo cada vez mais construídas em um modelo de nuvem "híbrido", quando são usados ​​recursos locais e de nuvem pública com um sistema de gerenciamento 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 dos recursos de provedores como AWS, Azure e Google Cloud Platform ao cluster, juntamente com nuvens privadas no VMware e OpenStack.

Nova abordagem de instalação


Na versão 4, a abordagem para instalar o OpenShift mudou. A Red Hat fornece um utilitário especial para implantar um cluster OpenShift - openshift-install. O utilitário é o único arquivo binário escrito em Go. O Openshit-installer prepara um arquivo yaml com a configuração necessária para a implementação.

No caso de instalação usando recursos da nuvem, você precisará especificar as 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 acesso ao provedor de nuvem. Depois de preparar o arquivo de configuração, o cluster pode ser implantado com um comando.

Se estiver instalando em seus próprios recursos de computação, 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 - prepare o número mínimo de máquinas virtuais ou servidores físicos necessários para criar um cluster do Control Plane, configure serviços de rede. Após essa configuração, o cluster do OpenShift pode ser criado de forma semelhante com um comando do utilitário openshift-installer.

Atualizações de infraestrutura


Integração com CoreOS


Uma atualização importante é a integração com o Red Hat CoreOS. Agora os nós principais do Red Hat OpenShift podem funcionar apenas no novo sistema operacional. Este é um sistema operacional gratuito da Red Hat, projetado especificamente para soluções em contêiner. O Red Hat CoreOS é um Linux leve otimizado para rodar contêineres.

Se na versão 3.11 o sistema operacional e o OpenShift existiam separadamente, na versão 4.2 ele está inextricavelmente vinculado ao OpenShift. Agora, este é um único dispositivo - infraestrutura imutável.


Para clusters que usam RHCOS para todos os nós, a atualização da Plataforma OpenShift Container é um processo simples e bem automatizado.

Anteriormente, para atualizar o OpenShift, era necessário primeiro atualizar o sistema operacional subjacente no qual o produto estava sendo executado (na época era o Red Hat Enterprise Linux). Somente depois disso foi possível atualizar o OpenShift gradualmente, nó por nó. Não houve conversas sobre qualquer automação do processo.

Agora, como a OpenShift Container Platform controla totalmente os sistemas e serviços em cada nó, incluindo o SO, essa tarefa é resolvida pressionando um botão na interface da web. Depois disso, um operador especial é iniciado dentro do cluster OpenShift, que controla todo o processo de atualização.

Novo CSI


O segundo é o novo CSI, o controlador da interface de armazenamento, que permite conectar vários sistemas de armazenamento externos ao cluster OpenShift. Um grande número de fornecedores de drivers de armazenamento para o OpenShift são suportados com base nos drivers de armazenamento gravados pelos próprios fornecedores de armazenamento. Uma lista completa dos drivers CSI suportados pode ser encontrada neste documento: https://kubernetes-csi.imtqy.com/docs/drivers.html . Nesta lista, você pode encontrar todos os principais modelos de matrizes de disco dos principais fabricantes (Dell / EMC, IBM, NetApp, Hitachi, HPE, PureStorage), soluções SDS (Ceph) e armazenamento em nuvem (AWS, Azure, Google). O OpenShift 4.2 suporta o trabalho com drivers CSI da especificação CSI versão 1.1.

Malha de serviço RedHat OpenShift


Com base nos projetos Istio, Kiali e Jaeger - Red Hat OpenShift Service Mesh, além das tarefas habituais de rotear solicitações entre serviços, permite rastrear e visualizá-las. Isso ajuda os desenvolvedores a simplificar a interação, monitoramento e gerenciamento de aplicativos implementados no Red Hat OpenShift.


Visualização de um aplicativo com arquitetura de microsserviço usando o Kiali

Para simplificar a instalação, o serviço e o gerenciamento do ciclo de vida do Service Mesh, o Red Hat OpenShift fornece aos administradores um operador especial - Service Mesh Operator. Este é o operador Kubernetes, que permite implantar os pacotes Istio, Kiali e Jaeger reconfigurados no cluster, minimizando a carga administrativa de gerenciar aplicativos.

CRI-O em vez de Docker


O Docker de tempo de execução do contêiner padrão foi substituído pelo CRI-O. O CRI-O já podia ser usado na versão 3.11, mas na 4.2 tornou-se o principal. Não é bom nem ruim, mas vale a pena lembrar ao usar o produto.

Operadores e implantar aplicativos


Operadores - uma nova entidade para o RedHat OpenShift, que apareceu na quarta versão. Este é um método para empacotar, implantar e gerenciar o aplicativo Kubernetes. Ele pode ser imaginado como um plug-in para aplicativos implantados em contêineres gerenciados usando a API Kubernetes e as ferramentas kubectl.

Os operadores Kubernetes ajudam a automatizar todas as tarefas relacionadas à administração e gerenciamento do ciclo de vida de um aplicativo implantado em seu cluster. Por exemplo, um operador pode automatizar atualizações, fazer backup e dimensionar um aplicativo, alterar a configuração etc. Uma lista completa de operadores pode ser encontrada em https://operatorhub.io/ .

O OperatorHub está disponível diretamente na interface da web do console de gerenciamento. É um catálogo de aplicativos para o OpenShift mantido pela Red Hat. Essa. todos os operadores aprovados pela Red Hat serão cobertos pelo suporte do fornecedor.


Portal OperatorHub no OpenShift Management Console

Imagem base universal


Este é um conjunto padronizado de imagens do SO RHEL que você pode usar para criar seus aplicativos em contêineres. Existem conjuntos mínimos, padrão e completos. Eles ocupam muito pouco espaço, suportam todos os pacotes instalados necessários e linguagens de programação.

Ferramentas de CI / CD


O RedHat OpenShif 4.2 tem a capacidade de escolher entre Jenkins e OpenShift Pipelines com base nos Tekton Pipelines.

O OpenShift Pipelines é baseado no Tekton, que é mais suportado pelo Pipeline à medida que o Code e o GitOps se aproximam. Nos pipelines do OpenShift, cada etapa é executada em seu próprio contêiner, portanto, os recursos são usados ​​apenas durante a execução da etapa. Isso fornece aos desenvolvedores controle completo sobre os pipelines de entrega do módulo, plug-ins e controle de acesso sem um servidor CI / CD central para gerenciamento.

No momento, o OpenShift Pipelines está no estágio Preview para desenvolvedores e está disponível como operador no cluster OpenShift 4. É claro que os usuários do OpenShift ainda podem usar o Jenkins no RedHat OpenShift 4.

Atualizações de gerenciamento para desenvolvedores


Na 4.2, o OpenShift atualizou completamente a interface da web para desenvolvedores e administradores.

Nas versões anteriores do OpenShift, todos trabalhavam em três consoles: um catálogo de serviços, um console do administrador e um 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 é mais conveniente exibir topologias de aplicativos e seus conjuntos. Isso facilita para os desenvolvedores criar, implantar e visualizar aplicativos em contêiner e recursos de cluster. Permite que você se concentre no que é importante para eles.


Portal do desenvolvedor no OpenShift Management Console

Odo


Odo é um utilitário de linha de comando orientado ao desenvolvedor que simplifica o desenvolvimento de aplicativos no OpenShift. Usando a interação do estilo git push, essa CLI ajuda os desenvolvedores novos do Kubernetes a criar aplicativos no OpenShift.

Integração com ambientes de desenvolvimento


Agora, os desenvolvedores podem criar, depurar e implantar seus aplicativos no OpenShift sem deixar 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


A extensão Red Hat OpenShift Deployment para Microsoft Azure DevOps apareceu. Agora, os usuários deste kit de ferramentas do DevOps podem implantar seus aplicativos no Azure Red Hat OpenShift ou em qualquer outro cluster do OpenShift diretamente do Microsoft Azure DevOps.

Transição da terceira versão para a quarta


Já que estamos falando de um novo lançamento, não de uma atualização, não é tão fácil pegar e colocar a quarta versão em cima da terceira. A atualização da terceira para a quarta versão não será suportada .

Mas há boas notícias: a Red Hat fornece ferramentas para mover projetos de 3.7 para 4.2. Você pode transferir cargas de trabalho de aplicativos com a ferramenta CAM (Cluster Application Migration). O CAM permite controlar a migração e minimizar o tempo de inatividade do aplicativo.

Openshift 4.3


As principais inovações descritas neste artigo apareceram na versão 4.2. No 4.3, lançado recentemente, as mudanças não são tão significativas, mas ainda há algo novo. A lista de mudanças é bastante extensa, damos o mais significativo em nossa opinião:

Atualize a versão do Kubernetes para 1.16.


A versão foi atualizada imediatamente para duas etapas, 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 ativada, será possível criptografar os seguintes recursos da API do OpenShift e da Kubernetes: Segredos, ConfigMaps, Rotas, tokens de acesso e autorização do OAuth.

Leme


Adicionado suporte para a versão Helm 3rd - um gerenciador de pacotes popular para o Kubernetes. Até o momento, o suporte tem o status de TECHNOLOGY PREVIEW. Nas versões futuras do OpenShift, o suporte do Helm será expandido para o máximo. O utilitário helm cli é fornecido com o OpenShift e pode ser baixado no console da Web de Gerenciamento de Cluster.

Atualização do painel do projeto


Na nova versão do Painel do Projeto, são fornecidas informações adicionais na página do projeto: status do projeto, utilização de recursos e cotas para o projeto.

Exibir vulnerabilidades para o cais no console da web


Adicionada a função de exibir vulnerabilidades conhecidas para imagens nos repositórios do Quay no console de gerenciamento. O mapeamento de vulnerabilidades para repositórios locais e externos é suportado.

Criação simplificada de operatorhub offline


No caso da implantação de um cluster OpenShift em uma rede isolada, da qual 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.

Autor: Yuri Semenyukov

More articles:


All Articles