RHEL 9 oferece as mais recentes tecnologias de containers para desenvolvimento e produção

Há três anos, com o lançamento do Red Hat Enterprise Linux 8 (RHEL 8), nós oferecemos um novo conjunto de ferramentas de container com um novo conceito chamado Application Streams. Essas novas ferramentas de container permitiram que os usuários do RHEL encontrassem, executassem, criassem e compartilhassem containers. Para saber por que o RHEL migrou do Docker para o Podman (e o caminho que levamos para chegar lá), leia RHEL 8 habilita containers com as ferramentas artesanais de software. 

Em nossa versão anterior, Quais são as novidades com as ferramentas de container do Red Hat Enterprise Linux 8.5?, apresentamos vários dos recursos e funcionalidades básicos necessários para chegar ao RHEL 9.

Com o lançamento do RHEL 9, continuamos a oferecer as mesmas ferramentas de container baseadas no Pod Manager (podman), Buildah, Skopeo, Udica, CRIU e outros serviços do Linux. O RHEL 9 continua com a filosofia de oferecer o que acreditamos ser a melhor ferramenta para a tarefa, facilitando o upgrade do RHEL 8 para o RHEL 9 para os usuários de container. Este artigo se aprofunda nas tecnologias e mudanças mais recentes na forma como o RHEL 9 empacota ferramentas de container.

• RHEL 8.6 e RHEL 9.0: o que mudou?

• Gerenciamento centralizado de mapeamentos de identidade

• Suporte a NFS para armazenamento de container

• Stack de rede avançado para Podman 4.0

• Certificado portátil e container de assinatura

• crun se torna o ambiente de execução de containers padrão no RHEL 9.0

• Grupo de controle v2 (cgroup 2) se torna o padrão no RHEL 9 e no Podman

RHEL 8.6 e RHEL 9.0: o que mudou?

Primeiro, comecemos com algumas informações básicas sobre o RHEL. O RHEL 8.6 e o RHEL 9.0 são o que chamamos de lançamentos sincronizados. Eles foram lançados aproximadamente na mesma época e continuarão em sincronização até que o RHEL 8 chegue à versão 8.10 e entre na fase de suporte de manutenção, enquanto o RHEL 9 continuará a receber novas funcionalidades. Isso oferece aos usuários aproximadamente dois anos de atualizações de funcionalidades em ambas as plataformas e uma janela para fazer upgrade. O ciclo de vida do RHEL foi criado intencionalmente para facilitar o upgrade, o que também se aplica às ferramentas de containers.

Observe no desenho abaixo que as seguintes versões do RHEL 8 e 9 estão sincronizadas:

• RHEL 9 Alpha -> RHEL 8.4

• RHEL 9 Beta -> RHEL 8.5

• RHEL 9.0 GA -> RHEL 8.6

• RHEL 9.1 -> RHEL 8.7

• RHEL 9.2 -> RHEL 8.8

• RHEL 9.3 -> RHEL 8.9

• RHEL 9.4 -> RHEL 8.10 

Essa sincronização entre o RHEL 8 e o 9 simplifica os upgrades e se estende para as versões do Podman, Buildah e Skopeo. É isso mesmo, as versões rápidas e estáveis do Podman, Buildah e Skopeo estão alinhadas entre si. Por exemplo, observe que a versão mais recente do Podman é a mesma entre o RHEL 8 e o 9:

No RHEL 8

cat /etc/redhat-release  Red Hat Enterprise Linux versão 8.6 (Ootpa) [root@lance ~]# podman --version podman versão 4.0.2

No RHEL 9

cat /etc/redhat-release  Red Hat Enterprise Linux versão 9.0 (Plow) podman --version podman versão 4.0.2

A sincronização de softwares importantes como o Podman entre as principais versões do RHEL simplifica os upgrades, mas ainda há ainda algumas alterações das quais você precisa estar ciente. No RHEL 8.X, nós oferecemos dois fluxos de aplicações: um para oferecer aos desenvolvedores acesso às versões mais recentes do Podman, Buildah e Skopeo, além de um segundo fluxo estável para oferecer às equipes de operações um ciclo de vida de suporte de dois anos. 

Application Streams do RHEL 8

Havia alguns desafios com a metodologia usada no RHEL 8. Primeiro, não observamos uma grande aceitação do fluxo estável, o que quebrou nossa suposição inicial quando lançamos o RHEL 8. Lançamos os fluxos rápidos e estáveis no RHEL 8 pensando que as pessoas queriam acesso a uma API de container estável (Podman) enquanto ainda consumiam os bits mais recentes do sistema operacional (kernel do Linux, systemd etc.). Historicamente, esse tem sido o desejo dos sistemas operacionais baseados em containers.

Essa suposição acabou sendo falsa. Em vez disso, os usuários do RHEL buscavam principalmente acesso ao fluxo de ferramentas de container estável em conjunto com o suporte estendido de atualização (EUS) de dois anos para o RHEL na totalidade. Acontece que as pessoas que usam o RHEL querem acesso a um sistema operacional inteiro e com um ciclo de vida mais longo. Sendo assim, mudamos como lançamos as ferramentas de container no RHEL 9. 

RHEL 9 Rolling Application Stream e EUS

No RHEL 9, também oferecemos duas maneiras de consumir ferramentas de container: uma voltada para a velocidade de movimentação e a outra com foco na estabilidade. Desenvolvedores e usuários que querem acesso às melhores e mais recentes versões do Podman, Buildah e Skopeo podem usar um Application Stream, o qual é lançado a cada 12 semanas (assim como o RHEL 8). Por design, esse fluxo é mantido em sincronia com o fluxo rápido no RHEL 8 (até a versão 8.10, quando o RHEL 8 desacelera o desenvolvimento), facilitando o upgrade/downgrade entre as versões principais. 

Se os usuários do RHEL 9 precisarem de acesso a um fluxo estável com suporte por dois anos com backports de segurança, eles poderão acessá-lo por meio do RHEL Extended Update Support (EUS), embora esta seja uma subscrição separada. Por design, cada versão das ferramentas de container nas versões EUS do RHEL 9 é mantida sincronizada com um fluxo estável correspondente no RHEL 8. Mais uma vez, isso facilita o upgrade do RHEL 8 para o RHEL 9, mantendo uma versão consistente do Podman e reduzindo as chances de introduzir regressões.

É importante observar que o RHEL 8 continuará a ser entregue exatamente como foi projetado. Ele não será convertido para a metodologia usada no RHEL 9. Se seus desenvolvedores, administradores ou arquitetos planejaram um lançamento do RHEL 8 com base em fluxos estáveis, você pode continuar contando com eles e não precisa de EUS.

Observe também que, no RHEL 8.6, o módulo container-tools:2.0 ficou obsoleto, e você deve migrar para uma versão mais recente (3.0, 4.0 etc.) para continuar a receber patches de segurança. Para saber mais informações, consulte a página RHEL Application Streams Life Cycle. 

Gerenciamento centralizado de mapeamentos de identidade

O Podman sem raiz é uma excelente tecnologia. Ele aprimora a segurança dos containers ao executá-los como um usuário não raiz, da mesma forma que os processos normais são executados em um sistema. Isso significa que uma carga de trabalho de ataque precisaria escapar de uma camada extra de segurança, primeiro passando pelos controles do container e, depois, descobrindo uma maneira de se tornar raiz. Isso é ótimo para grandes frotas de laptops/desktops, em ambientes de HPC e até mesmo para desenvolvedores em servidores compartilhados.

No entanto, historicamente, gerenciar inúmeros usuários sem raiz em grandes frotas de estações de trabalho do RHEL, nós de HPC ou servidores compartilhados tem sido muito difícil, porque um administrador precisava gerenciar arquivos /etc/subuid e /etc/ sugid manualmente em cada nó.

Agora não mais. Com o RHEL 9, introduzimos uma funcionalidade no gerenciamento de identidades (IdM) com a qual os administradores podem gerenciar facilmente os usuários sem raiz do Podman em uma frota de usuários e nós do RHEL. Os usuários podem atribuir subuids/subgids a um único usuário ou a todos os usuários em um servidor de diretório. É muito conveniente. Para mais informações, consulte o Capítulo 29. Gerenciamento manual de intervalos de subID.

Suporte a NFS para armazenamento em container

Como mencionado, o Podman sem raiz é um ótimo recurso e, muitas vezes, os administradores têm muitos usuários em muitos nós (estações de trabalho, HPC, servidores de desenvolvedor compartilhados etc.). Nesses cenários, os usuários querem levar seus dados com eles. Por exemplo, se fizerem um "podman pull" em um nó, eles querem que essa imagem fique disponível em qualquer nó do cluster. Uma maneira fácil de conduzir isso com processos normais é com o NFS, mas isso não funcionou com o Podman/containers.

Com essa nova funcionalidade, o Podman agora pode armazenar dados em qualquer servidor NFS compatível com atributos estendidos (xattrs). Usuários não raiz/sem raiz podem extrair uma imagem uma vez e usá-la em qualquer lugar em que seu diretório pessoal esteja disponível. Isso é extremamente conveniente com estações de trabalho, nós de HPC ou até mesmo servidores de desenvolvimento compartilhados onde a CI/CD é feita. Para saber mais informações, consulte este artigo upstream: Novas funcionalidades para executar containers no NFS com o Podman sem raiz

Stack de rede avançada para o Podman 4.0

Na versão do RHEL 9 com o Podman 4.X, um novo stack de rede está disponível para os usuários. Ele vem com novas funcionalidades, como suporte aprimorado a IPv6, suporte aprimorado a containers em várias redes e desempenho aprimorado. 

O seguinte artigo fornece uma excelente visão geral: Novo stack de rede do Podman 4.0: o que você precisa saber.

Certificado portátil e container de assinatura

Com o lançamento do RHEL 8.4, introduzimos o UBI Micro, uma das menores e mais rápidas imagens de container do setor (Introdução ao UBI Micro da Red Hat).

Com o lançamento do RHEL 9, usamos essa tecnologia para criar uma imagem de container OpenSSL pequena (12,5MB) que pode ser usada em casos de uso criptográfico simples, como gerar solicitações de certificado SSL, verificar certificados SSL ou até mesmo assinar arquivos.

Isso oferece aos desenvolvedores uma maneira padronizada de realizar casos de uso de criptografia confiáveis, seja em produção ou em seus desktops/laptops. Como todas as Red Hat Universal Base Images, você e seus desenvolvedores podem usar e distribuir esse novo certificado portátil e container de assinatura onde precisarem.

Para saber mais informações, confira a lista no Red Hat Ecosystem Catalog

• ubi9/openssl 

• ubi8/openssl

crun se torna o ambiente de execução padrão de containers no RHEL 9.0

Em 2020, colaboradores da Red Hat introduziram o crun, um ambiente de execução de containers rápido, com pouca memória e em conformidade com OCI. No RHEL 9, estamos fazendo com que o crun seja o ambiente de execução de containers padrão. Tanto crun quanto runc serão compatíveis com todo o ciclo de vida do RHEL 9.

A mudança para crun como padrão simplifica muitas tarefas para os administradores em muitas tarefas de configuração de baixo nível, melhora o desempenho e o uso de memória e desbloqueia todos os tipos de casos de uso interessantes. Para saber mais informações, leia: Uma introdução ao crun, um ambiente de execução de containers rápido e com baixa memória

Grupo de controle v2 (cgroup 2) torna-se o padrão no RHEL 9 e no Podman

O projeto cgroup 2 se descreve como "um componente do kernel do Linux que fornece um mecanismo para isolar, medir e controlar a distribuição de recursos para um conjunto de processos em um servidor". Isso oferece aos administradores e softwares de infraestrutura, como Container Engines e Runtimes, um mecanismo poderoso para limitar os recursos usados por qualquer processo, sendo especialmente útil com containers. 

O cgroup 2 foi inicialmente compatível com o RHEL 8, mas o usuário precisava habilitá-lo e reinicializá-lo. Com o RHEL 9, o cgroup 2 é o mecanismo padrão pronto para uso, o que oferece um controle mais detalhado sobre containers sem raiz (Exclusivo: Containers sem raiz e cgroup v2 no Fedora 31). Para uma boa introdução ao cgroup 2,  consulte: Dominação mundial com cgroups no RHEL 8: boas-vindas, cgroups v2!

Conclusão

Há muitos recursos novos e excelentes de container no RHEL 9.0 com o Podman 4.0.2, mas muitos deles também estão disponíveis no RHEL 8.6. Não importa se você deseja ter o que há de melhor e mais recente ou aproveitar melhor uma instalação existente, o design e a arquitetura do fluxo de aplicações de ferramentas de container oferecem o que você precisa.

Com o RHEL 9, continuamos oferecendo acesso rápido às melhores e mais recentes versões do Podman, Buildah e Skopeo, mas agora também oferecemos acesso a um fluxo estável por meio de EUS. Tentamos facilitar ainda mais o uso do RHEL 9 para nossos clientes e esperamos que você goste. Adoraríamos ouvir seu feedback.

Sinta-se à vontade para falar com nosso novo gerente de produto da Container Tools, Mark Russell (https://www.linkedin.com/in/marrusl/), nosso gerente de produto do RHEL Server, Scott McCarty (@fatherlinux), nosso gerente de marketing técnico, Eric Hendricks (@itguyeric), ou escrever um tweet para nossa conta oficial do Red Hat Enterprise Linux, @rhel).