Image mode do Red Hat Enterprise Linux: guia rápido

O componente image mode do Red Hat Enterprise Linux (RHEL) usa as mesmas ferramentas, habilidades e padrões que as aplicações em containers para oferecer um sistema operacional mais fácil de criar, lançar e executar. Este post explica os conceitos por trás do image mode e apresenta aos usuários o básico para empacotar sistemas operacionais em imagens de container da Open Container Initiative (OCI).

Com as etapas e processos abaixo, você entende melhor os conceitos do image mode do RHEL do ponto de vista prático por meio da criação e implantação de uma imagem personalizada.

Requisitos:

1. Todos os comandos são executados em um sistema registrado do RHEL 9.x em um laptop, máquina virtual (VM) etc., com pelo menos 10 GB de espaço em disco disponível. Mais espaço em disco pode ser necessário dependendo do tamanho e da quantidade de imagens que serão criadas.
2. Uma conta da Red Hat com subscrições de produção ou de desenvolvedor (há subscrições de desenvolvedor gratuitas disponíveis).

Um registro de containers: este exemplo usará o quay.io como o registro onde o conteúdo será publicado. No entanto, você pode utilizar outro serviço de registro hospedado ou executar um registro no local. Aqui você cria uma conta do quay.io com rapidez e facilidade.

Introdução

Comece confirmando se seu sistema está registrado para receber o conteúdo do RHEL.

$ sudo subscription-manager register

Depois, instale o Podman. Recomendamos que você use a versão mais recente disponível, mas qualquer opção a partir da v4.* é aceita. Outras ferramentas de container como o Docker ou soluções de pipeline podem funcionar em um ambiente de produção. Os conceitos deste exemplo são baseados no Podman, mas não se esqueça de que outras ferramentas podem ser melhores para seu ambiente.

$ sudo dnf -y install podman

Agora, faça a autenticação usando registry.redhat.io. Para começar, acesse https://access.redhat.com/terms-based-registry e clique em "New service account". Depois, clique no nome da nova entrada e copie/cole as instruções "docker login” no terminal, substituindo o comando do Docker pelo Podman. As instruções completas estão aqui se você precisar de mais informações. A conversão de imagens de container em imagens de disco com o image builder exige privilégios elevados com o Podman. Prossiga e faça a autenticação no registro com e sem o sudo.

$ podman login registry.redhat.io
#repeat with sudo
$ sudo podman login registry.redhat.io

Há duas diferenças importantes entre as imagens de container do bootc e os containers de aplicações:

• As imagens do bootc usam o OSTree dentro do container.
• Uma imagem do bootc tem kernel e outros pacotes suficientes para inicializar uma máquina física ou virtual.

As base images dos containers de aplicações costumam incluir um conjunto muito pequeno de pacotes não relacionados ao gerenciamento de hardware. Além disso, ao contrário do Red Hat Universal Base Image (UBI), as imagens do bootc do RHEL são distribuídas com os mesmos termos de licenciamento que essa solução.

Extraia a base image  rhel-bootc.

$ podman pull registry.redhat.io/rhel9/rhel-bootc:9.4

Crie um Containerfile

Agora, confira um exemplo de Containerfile. Talvez você o conheça como Dockerfile. Vamos começar de um jeito simples e instalar um stack LAMP. Salve o texto abaixo em um novo arquivo chamado Containerfile:

FROM registry.redhat.io/rhel9/rhel-bootc:9.4

#install the lamp components
RUN dnf module enable -y php:8.2 nginx:1.22 && dnf install -y httpd mariadb mariadb-server php-fpm php-mysqlnd && dnf clean all

#start the services automatically on boot
RUN systemctl enable httpd mariadb php-fpm

#create an awe inspiring home page!
RUN echo '<h1 style="text-align:center;">Welcome to image mode for RHEL</h1> <?php phpinfo(); ?>' >> /var/www/html/index.php

Você acabou de descrever um sistema operacional simples que executará um servidor web na porta 80, além de ter um banco de dados e o PHP disponíveis. Agora, crie a imagem de container:

Crie uma imagem

$ podman build -f Containerfile -t quay.io/[my_account]/lamp-bootc:latest

Observação:

-t marca a imagem com uma tag. Esse exemplo considera que o quay.io é o registro usado. Você precisa ajustar essa definição com base no registro usado.

-f instrui o Podman a usar o Containerfile.

Teste a imagem

Agora, teste rapidamente a imagem que acabamos de criar. Por ser um container, essa imagem é rápida de executar. Além disso, podemos verificar se há digitação incorreta porque esses erros são emitidos. Para simplificar, dê a imagem o nome abreviado "lamp":

$ podman run -d --rm --name lamp -p 8080:80 quay.io/[my_account]/lamp-bootc:latest /sbin/init

O container será iniciado, e você não precisa se preocupar acessá-lo agora. Abra um navegador e confira se você pode ver a página da web acessando http://[your_ip_address]:8080. Se a página não carregar, verifique suas regras de firewall. Se você usa um sistema local, o endereço de loopback deve funcionar. Nesse exemplo, você iniciará o systemd. No entanto, em muitos cenários de teste, é mais eficiente iniciar uma aplicação. Acelerar os testes e as validações é uma das principais vantagens do uso de containers na definição de imagens de sistema operacional.

É possível utilizar o shell para acessar a instância de container em execução com podman exec, usando o nome que definimos acima.

$ podman exec -it lamp /bin/bash

Interrompa a instância usando o mesmo nome:

$ podman stop lamp

Envie para um registro

Em seguida, faça a autenticação acessando o quay.io, envie a imagem para o registro e configure o repositório para ser acessível ao público.

$ podman login quay.io
$ podman push quay.io/[my_account]/lamp-bootc:latest

Até este ponto, criamos uma imagem em camadas que pode ser implantada, e há várias maneiras de fazer a instalação dela em um host. Podemos usar o instalador do RHEL e iniciar um sistema bare metal (implantação via USB, PXE etc.) ou utilizar o image builder para converter a imagem de container em uma inicializável. Após esse container ser "instalado", as próximas atualizações serão aplicadas diretamente do registro de containers conforme publicadas. Portanto, o processo de instalação ocorre apenas uma vez.

Implantação via KVM/QEMU com uma imagem de disco Qcow2

Este exemplo usará o image builder para converter a imagem de container em um disco no formato Qcow2. Consideramos que a imagem está em um repositório acessível ao público. Consulte a documentação do image builder para ver como usar uma imagem de um repositório privado. Outros formatos de imagem estão disponíveis além do Qcow2.

Primeiro, crie um arquivo config.json que viabilize a configuração do disco resultante. Neste exemplo, o config.json inclui os usuários que você quer criar. Cole sua própria chave SSH e senha.

{
 "blueprint": {
   "customizations": {
     "user": [
       {
         "name": "cloud-user",
         "password": "changeme",
         "key": "ssh-rsa AAAAB3Nz..........",
         "groups": [
           "wheel"
         ]
       }
     ]
   }
 }
}

Em seguida, transmita o config.json com o container "lamp" para o image builder:

$ sudo podman run --rm -it --privileged \
-v .:/output \
-v $(pwd)/config.json:/config.json \
--pull newer \
registry.redhat.io/rhel9/bootc-image-builder:9.4 \
--type qcow2 \
--config /config.json \
quay.io/[my_account]/lamp-bootc:latest

Quando a imagem estiver pronta, ela poderá ser executada usando o libvirt (ou o QEMU diretamente):

virt-install \
 --name lamp-bootc \
 --memory 4096 \
 --vcpus 2 \
 --disk qcow2/disk.qcow2 \
 --import \
 --os-variant rhel9.4

Com a VM em execução, você consegue verificar se o site está funcionando. Basta acessar  http://[your_instance_ip_address] em um navegador.

Implantação na AWS com uma imagem de disco AMI

Neste exemplo, precisamos confirmar se o cloud-init está disponível no Containerfile "lamp" que criamos. É aí que o fluxo de trabalho do container nos ajuda, porque podemos criar uma imagem em camadas com facilidade para nosso caso de uso. Vamos demonstrar um build em camadas, mas fique à vontade para editar o Containerfile original e incluir o cloud-init se isso for mais fácil para você.

FROM quay.io/[my_account]/lamp-bootc:latest
#install cloud-init for AWS
RUN dnf install -y cloud-init && dnf clean all

Crie e envie a imagem:

$ podman build -f Containerfile -t quay.io/[my_account]/lamp-bootc-aws:latest
$ podman push quay.io/[my_account]/lamp-bootc-aws:latest

Você precisará do cloud-init para injetar usuários e chaves SSH. Assim, é possível pular a etapa relacionada ao config.json do exemplo do KVM acima. (A criação de uma configuração do cloud-init está fora do escopo deste documento). Ao usar o cloud-init, reforçamos a postura de segurança evitando a inclusão de credenciais codificadas na imagem. Agora, execute o image builder para criar a AMI:

$ sudo podman run --rm -it --privileged \
 --pull=newer \
 --security-opt label=type:unconfined_t \
 -v $XDG_RUNTIME_DIR/containers/auth.json:/run/containers/0/auth.json \
 -v $HOME/.aws:/root/.aws:ro \
 --env AWS_PROFILE=default \
 registry.redhat.io/rhel9/bootc-image-builder:9.4:latest \
 --type ami \
 --aws-ami-name lamp-bootc-aws \
 --aws-bucket bootc-bucket \
 --aws-region us-east-1 \
 quay.io/[my_account]/lamp-cloud-init-bootc:latest

Há outras opções disponíveis para configurar as propriedades da AWS. Acesse este link para ver mais detalhes.

Após a conclusão do processo de publicação, inicie a imagem e acesse http://[your_instance_ip_address] em um navegador. Você vai se surpreender!

Instalação no bare metal via Kickstart

Como você viu, há diversas maneiras de instalar o container. Esta seção fala sobre o uso do Kickstart, o qual é muito utilizado nas implantações bare metal por meio de unidades ISO, PXE e USB. Consideramos que você tenha certa familiaridade com os conceitos do Kickstart, pois este guia não entra em detalhes. Insira as informações relacionadas a usuários, senhas e chaves SSH no exemplo abaixo. É possível incluir outras opções, mas a seção %packages não é viável usando esse fluxo de trabalho porque estamos substituindo a instância pela imagem de container. Acesse este site para fazer o download do ISO de inicialização da versão 9.4 para sua arquitetura.

text
network --bootproto=dhcp --device=link --activate
# Basic partitioning
clearpart --all --initlabel --disklabel=gpt
reqpart --add-boot
part / --grow --fstype xfs
# Here's where we reference the container image to install - notice the kickstart
# has no `%packages` section!  What's being installed here is a container image.
ostreecontainer --url quay.io/[my_account]/lamp-bootc:latest
firewall --disabled
services --enabled=sshd
# optionally add a user
user --name=cloud-user --groups=wheel --plaintext --password=changemme
sshkey --username cloud-user "ssh-ed25519 AAAAC3Nza....."
# if desired, inject a SSH key for root
rootpw --iscrypted locked
sshkey --username root "ssh-ed25519 AAAAC3Nza....." #paste your ssh key here
reboot

Copie o arquivo de configuração para um servidor web, atualize a senha e a chave SSH, inicialize um sistema físico ou virtual usando a mídia de instalação e inclua o seguinte nos argumentos do kernel:

inst.ks=http://path_to_my_kickstart

Pressione Ctrl+X para inicializar usando essa opção.

Se um servidor HTTP não estiver disponível, use o módulo de servidor HTTP oferecido na maioria das instalações Python. No diretório que contém o arquivo do Kickstart, execute o seguinte:

$ python -m http.server

Outra abordagem é injetar o Kickstart no ISO do instalador. Esse método não utiliza um servidor HTTP para hospedar o arquivo do Kickstart. O pacote LoRAX inclui um utilitário chamado mksiso que pode incorporar esse arquivo a um ISO. Isso é útil para fazer a inicialização diretamente de um pen drive e evita a edição do menu associado. Execute o seguinte: mkksiso --ks /PATH/TO/KICKSTART /PATH/TO/ISO /PATH/TO/NEW-ISO

Envie uma atualização

Uma característica importante desse processo é que a instalação e a implantação acontecem apenas uma vez. Grande parte dos benefícios desse modelo são alcançados no Dia 2, quando as mudanças podem ser feitas por meio do envio de imagens ao registro. As atualizações automáticas são ativadas por padrão. É claro que essa configuração é simples de definir com base na sua janela de manutenção e pode ser desativada. Para testar, faça uma alteração no Containerfile e repita as etapas de criação e envio para disponibilizar a nova imagem no registro.&  O timer padrão da unidade systemd será acionado após uma hora de uptime. No entanto, você também pode executar "bootc upgrade" antes disso para realizar a atualização.

Próximas etapas

Agora que você conferiu um exemplo simples com o image mode do RHEL, recomendamos que explore alguns dos seus próprios casos de uso. Além disso, considere as possibilidades e vantagens operacionais que você pode alcançar ao usar ferramentas de container para gerenciar implantações de sistema operacional e controlar a versão delas. Não deixe de conferir nosso repositório de exemplos do bootc, que ajuda a viabilizar várias plataformas e cenários úteis. Também recomendamos que você confira a documentação completa quando quiser se aprofundar mais.