Guida rapida alla modalità immagine per Red Hat Enterprise Linux

Per offrire un sistema operativo più semplice da creare, distribuire ed eseguire, la modalità immagine per Red Hat Enterprise Linux (RHEL) utilizza gli stessi strumenti, competenze e modelli delle applicazioni containerizzate. In questo articolo illustreremo i concetti su cui si fonda la modalità immagine e le nozioni necessarie per fornire i pacchetti dei sistemi operativi tramite immagini dei container realizzate con lo standard Open Container Initiative (OCI).

Seguendo i passaggi e i processi illustrati, potrai mettere in pratica i concetti alla base della modalità immagine per RHEL, creando e distribuendo un'immagine personalizzata.

Requisiti

1. Tutti i comandi vengono eseguiti su un sistema  RHEL 9.x con sottoscrizione  (con laptop, macchina virtuale e altri componenti funzionanti) e uno spazio su disco minimo di 10 GB. A seconda delle dimensioni e della quantità di immagini create potrebbe essere necessario più spazio su disco.
2. Un account Red Hat con sottoscrizioni per i sistemi di produzione e per sviluppatori ( qui sono disponibili le sottoscrizioni gratuite per sviluppatori).

Un registro dei container: per il nostro esempio utilizziamo quay.io per la pubblicazione del contenuto del registro, ma puoi scegliere di utilizzare un servizio di registro in hosting o eseguire un registro in locale.  Qui puoi creare un account quay.io in modo semplice e rapido.

Per iniziare

Inizia confermando che il tuo sistema dispone della sottoscrizione per ricevere i contenuti RHEL.

$ sudo subscription-manager register

Ora possiamo installare Podman. È consigliabile utilizzare l'ultima versione disponibile, ma qualsiasi versione 4.* o successiva può andar bene. In un ambiente di produzione possono funzionare anche altri strumenti per container, come Docker o strumenti per il flusso dei container. In questo esempio illustriamo come utilizzare Podman, ma è bene ricordare che altri strumenti potrebbero essere più adatti al tuo ambiente.

$ sudo dnf -y install podman

Passiamo ora all'autenticazione, che eseguiremo tramite register.redhat.io. Visita  https://access.redhat.com/terms-based-registry e fai clic su "New service account". Seleziona il nome della nuova voce quindi copia e incolla le istruzioni "docker login" nel terminale, sostituendo il comando docker con podman. Se ti occorrono ulteriori informazioni,  qui trovi le istruzioni complete. Per convertire l'immagine del container in un'immagine disco con il generatore di immagini è necessario disporre di privilegi elevati in Podman. Esegui l'autenticazione nel registro con e senza sudo.

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

Le immagini dei container Bootc differiscono tecnicamente dai container delle applicazioni per due aspetti importanti:

• Le immagini bootc utilizzano  OSTree all'interno del container.
• Un'immagine bootc ha un kernel e un numero sufficiente di altri pacchetti per avviare una macchina fisica o virtuale.

In genere, le immagini di base dei container delle applicazioni contengono un set minimo di pacchetti non correlati alla gestione dell'hardware. Inoltre, a differenza dell'immagine Red Hat Universal Base Image (UBI), le immagini bootc di RHEL sono distribuite con le stesse condizioni di licenza di RHEL.

Eseguiamo il pull dell'immagine di base rhel-bootc.

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

Creazione di un Containerfile

Esaminiamo ora un esempio di Containerfile, anche noti come Dockerfile. Per iniziare, installiamo uno stack lamp. Salva il testo seguente in un nuovo file denominato 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

Abbiamo descritto un semplice sistema operativo che esegue un web server sulla porta 80 e che dispone di un database e di un php. Ora costruiamo l'immagine del container:

Creazione di un'immagine

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

Nota:

-t aggiunge i tag all'immagine. L'esempio presuppone che il registro utilizzato sia quay.io. Se utilizzi un registro differente, modifica l'esempio.

-f indica a Podman di utilizzare il Containerfile creato.

Test dell'immagine

Dopo aver creato l'immagine, eseguiamo un rapido test. Poiché la nostra immagine è un container, è veloce da eseguire e possiamo verificare la presenza di eventuali errori in quanto verrà generato un messaggio di errore. Per semplicità, assegniamo all'immagine un nome abbreviato (lamp):

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

Il container viene avviato e non è necessario preoccuparsi dell'accesso in questo momento. Apri un browser e verifica di poter visualizzare la pagina web pubblicata all'indirizzo http://[your_ip_address]:8080. Se la pagina non viene caricata, controlla le regole del firewall. Se utilizzi un sistema locale, l'indirizzo di loopback dovrebbe funzionare correttamente. Nell'esempio viene avviato systemd. In altri scenari di test, è più efficiente avviare semplicemente un'applicazione. La rapidità dei test e delle convalide è uno degli aspetti più importanti dell'utilizzo dei container per definire le immagini del sistema operativo.

Puoi eseguire la shell nell'istanza del container in esecuzione con podman exec, utilizzando il nome impostato in precedenza.

$ podman exec -it lamp /bin/bash

Arresta l'istanza utilizzando lo stesso nome:

$ podman stop lamp

Invio dell'immagine a un registro

A questo punto, esegui l'autenticazione accedendo a quay.io, invia l'immagine al registro e configura il repository in modo che sia pubblicamente accessibile.

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

Abbiamo quindi creato un'immagine a più livelli che possiamo distribuire e installare su un host in diversi modi, ad esempio utilizzando il programma di installazione di RHEL e avviando un sistema bare metal (da distribuire tramite USB, PXE, ecc.) oppure utilizzando il generatore di immagini per convertire l'immagine del container in un'immagine avviabile. Una volta "installato" il container, gli aggiornamenti futuri vengono applicati direttamente dal registro dei container mano a mano che vengono pubblicati, quindi il processo di installazione viene eseguito una sola volta.

Deployment tramite KVM/QEMU con un'immagine disco Qcow2

Questo esempio utilizza il generatore di immagini per convertire l'immagine del container in un disco con formattazione qcow2. Il nostro esempio presuppone che l'immagine si trovi in un repository pubblicamente accessibile. Consulta la  documentazione del generatore di immagini per informazioni su come utilizzare un'immagine di un repository privato. Sono disponibili anche altri formati di immagine oltre a qcow2.

Innanzitutto, crea un file config.json che consenta la configurazione del disco risultante. In questo esempio, config.json include gli utenti che intendi creare. Incolla la tua chiave SSH e la tua password nell'esempio.

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

Quindi, passa il comando  config.json insieme al container lamp al generatore di immagini:

$ 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 l'immagine è pronta, possiamo eseguirla tramite libvirt o direttamente con qemu

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

Con la VM in funzione, dovresti essere in grado di verificare che il sito sia in esecuzione visualizzando  http://[your_instance_ip_address] in un browser.

Deployment in AWS con un'immagine disco AMI

Per questo esempio, è necessario confermare la disponibilità di cloud-init nel Containerfile lamp creato in precedenza. Il flusso di lavoro dei container aiuta a creare facilmente un'immagine a più livelli per lo scenario di utilizzo desiderato. Quella che creiamo è una build a più livelli, ma puoi modificare il Containerfile originale per cloud-init, se è più semplice.

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

Crea e invia l'immagine:

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

Per l'inserimento di utenti e chiavi ssh utilizziamo cloud-init, che ci consente di saltare il passaggio config.json del precedente esempio KVM. La creazione di una configurazione cloud-init non rientra nell'ambito di questo documento. L'utilizzo di cloud-init migliora il livello di sicurezza evitando l'inclusione di credenziali hardcoded nell'immagine. Avvia quindi il generatore di immagini per creare l'immagine 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

Per configurare le proprietà per AWS sono disponibili altre opzioni. Consulta questo link per ulteriori dettagli.

Al termine del processo di pubblicazione, avvia l'immagine e sorprenditi visualizzando http://[your_instance_ip_address] in un browser.

Installazione su bare metal tramite Kickstart

Come abbiamo visto, esistono diversi metodi per installare il container creato. In questa sezione vediamo come utilizzare Kickstart, molto diffuso per i deployment bare metal che utilizzano ISO, PXE o unità USB. Questa guida non entra nei dettagli, quindi presupponiamo una certa familiarità con i concetti di Kickstart. Inserisci i dettagli relativi a utenti, password e chiavi ssh nell'esempio seguente. È supportata l'aggiunta di opzioni aggiuntive, ma tieni presente che la sezione %packages non è applicabile con questo flusso di lavoro perché stiamo sostituendo l'istanza con l'immagine del container. Scarica la versione 9.4 di Boot ISO per la tua architettura da questo sito.

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

Copia questo file di configurazione su un web server, aggiorna la password e la chiave SSH, avvia qualsiasi sistema fisico o virtuale utilizzando il supporto di installazione e aggiungi quanto segue agli argomenti del kernel:

inst.ks=http://path_to_my_kickstart

Premi ctrl-x per eseguire l'avvio con questa opzione.

Se un server HTTP non è immediatamente disponibile, puoi utilizzare il modulo server http disponibile nella maggior parte delle installazioni Python. Nella directory che contiene il file kickstart esegui:

$ python -m http.server

Un altro approccio, che non utilizza un server HTTP per l'hosting del file kickstart, inserisce il file kickstart nella ISO del programma di installazione. Il pacchetto lorax include un'utilità chiamata mkksiso che può incorporare questo file in una ISO. È utile per eseguire l'avvio direttamente da una chiavetta USB ed evita  di modificare il menu di avvio. Esegui: mkksiso --ks /PATH/TO/KICKSTART /PATH/TO/ISO /PATH/TO/NEW-ISO

Invio di un aggiornamento

Uno degli aspetti da sottolineare è che l'installazione  o il deployment sono attività una tantum. Il valore di questo modello si concretizza nella fase di manutenzione, quando sarà possibile apportare le modifiche durante l'invio delle immagini al registro. Gli aggiornamenti automatici sono attivi per impostazione predefinita, ma la loro configurazione in funzione delle finestre di manutenzione è semplice, e possono essere completamente disattivati. Per provarlo, apporta una modifica al Containerfile e ripeti i passaggi di invio della build & per rendere disponibile la nuova immagine nel registro.  Il timer predefinito per l'unità systemd si attiva dopo un'ora di attività, ma puoi anche eseguire il comando 'bootc upgrade' per avviare prima l'aggiornamento.

Passaggi successivi

Dopo aver sperimentato questo semplice esempio con la modalità immagine per RHEL, ti consigliamo di approfondire alcuni dei tuoi scenari di utilizzo per valutare le possibilità e l'efficienza operativa che potresti ottenere utilizzando gli strumenti per i container per il versioning e la gestione dei deployment dei sistemi operativi. Dai un'occhiata al nostro repository di esempi di bootc, dove potrai sperimentare una serie di piattaforme e scenari utili. Infine, quando sarà tempo di approfondire l'argomento, potrai consultare la  documentazione completa.