Come installare e usare un container Docker Rocky Linux

Se ti serve un container Rocky Linux con Docker, il punto non è solo “farlo partire”: conviene capire che cosa stai isolando, quale immagine usare e come mantenere il contenitore ripetibile. Rocky Linux dentro Docker è utile soprattutto per testare script, pacchetti, compatibilità con tool RHEL-like e procedure di troubleshooting senza toccare l’host.

La scelta pratica è semplice: usi un’immagine base Rocky, avvii un container minimale, monti solo i volumi necessari e apri le porte solo se il servizio dentro il container deve essere raggiungibile dall’esterno. Se invece ti serve un ambiente interattivo per manutenzione o build, il container può restare senza servizi esposti e vivere solo come shell temporanea.

Perché usare Rocky Linux in un container

Rocky Linux è una base comoda quando lavori in contesti dove la compatibilità con il mondo Enterprise Linux conta più della leggerezza estrema. In pratica ti serve quando vuoi:

• replicare comportamenti di sistemi compatibili RHEL;
• testare pacchetti con dnf in un ambiente pulito;
• validare script di provisioning o playbook;
• avere una shell con userland prevedibile per debug;
• contenere dipendenze senza sporcare l’host.

Il limite va detto subito: un container non è una VM. Condivide il kernel dell’host, quindi non è il posto giusto per testare moduli kernel, stack di boot o differenze profonde tra kernel version. Se ti serve isolamento forte a livello sistema, meglio una VM. Se ti serve un filesystem Linux coerente e un set di tool affidabile, il container va benissimo.

Immagine Rocky Linux: cosa scegliere

La base più semplice è l’immagine ufficiale Rocky Linux su Docker Hub. In genere conviene partire da un tag specifico, non da latest, così eviti sorprese al prossimo pull. Per ambienti tecnici seri, fissare la major release è già un buon compromesso; fissare anche la minor release è ancora meglio quando vuoi ripetibilità stretta.

Prima di creare il container, verifica quali tag hai a disposizione e quale architettura supportano. Su host x86_64 o ARM la scelta del tag può cambiare il comportamento se l’immagine non è multi-arch o se il repository che usi ha varianti diverse.

Un controllo rapido dell’immagine base può essere questo:

docker pull rockylinux:9

Se vuoi vedere l’architettura effettiva dell’immagine scaricata, puoi ispezionarla con:

docker image inspect rockylinux:9 --format '{{.Architecture}}/{{.Os}}'

Atteso: qualcosa come amd64/linux o arm64/linux. Se non coincide con l’host, Docker può emulare, ma per debug e performance non è la strada migliore.

Avvio del container: il caso minimo

Per iniziare, crea un container interattivo e tienilo attivo con un comando innocuo. Questo è il modo più pulito per entrare nella shell e fare verifiche manuali senza dover costruire subito un’immagine personalizzata.

docker run -it --name rocky-test rockylinux:9 bash

Dentro il container puoi verificare subito release, kernel userland e tool disponibili:

cat /etc/rocky-release
uname -a
dnf --version

Qui il check importante è capire che uname -a mostra il kernel dell’host, non quello di Rocky, perché il kernel nel container non esiste come entità separata. /etc/rocky-release, invece, ti conferma la userland effettiva.

Se vuoi lasciare il container in background e poi entrarci quando serve, usa una shell che resti viva oppure un processo dummy. Per esempio:

docker run -d --name rocky-daemon rockylinux:9 sleep infinity

Poi accedi con:

docker exec -it rocky-daemon bash

Questo approccio è più comodo se vuoi riusare lo stesso ambiente per più test o lasciare installati pacchetti temporanei durante una sessione di troubleshooting.

Container effimero o ambiente persistente

La distinzione che conta davvero è tra container effimero e container usato come sandbox persistente. Nel primo caso lo distruggi a fine test e ricrei da zero. Nel secondo monti volumi e conservi dati o configurazioni. Per la maggior parte dei test tecnici, l’effimero è la scelta più sana: meno drift, meno sorprese, meno sporcizia.

Se devi salvare file di lavoro, monta una directory dell’host in un path del container. Ad esempio:

mkdir -p ~/lab/rocky-data

docker run -it --name rocky-lab \
  -v ~/lab/rocky-data:/data \
  rockylinux:9 bash

Dentro troverai i file in /data. Questo è il punto giusto per scambiare script, log di test, tarball o output di build. Evita di montare directory troppo ampie dell’host se non serve: riduci superficie di errore e rischio di scritture indesiderate.

Se devi verificare rapidamente che il mount funzioni, esegui:

echo test > /data/prova.txt
ls -l /data/prova.txt

Dal lato host, il file deve comparire nella directory montata. Se non compare, controlla il path assoluto e i permessi del filesystem dell’host.

Installare pacchetti nel container Rocky

Una delle ragioni più comuni per usare Rocky in Docker è testare dnf. Su un container minimale, il primo passo è aggiornare la cache e installare solo ciò che serve. Non partire con pacchetti superflui: in un ambiente di test, ogni dipendenza extra aumenta il rumore diagnostico.

dnf -y update

dnf -y install vim curl tar procps-ng iproute

Se il container è molto minimale e la rete non è pronta, il problema di solito non è Rocky ma la connettività del container o la configurazione DNS del demone Docker. Per falsificare rapidamente l’ipotesi, prova:

cat /etc/resolv.conf
curl -I https://dl.rockylinux.org

Se curl fallisce ma il DNS risolve, la rete container è il primo sospetto. Se il DNS non risolve, il problema può stare nella configurazione del daemon Docker o nel resolver dell’host. In un laboratorio serio, conviene sempre verificare prima la catena rete/DNS invece di inseguire pacchetti mancanti.

Per installare tool di diagnostica utili senza appesantire troppo, una selezione sensata è:

dnf -y install bash-completion less findutils grep sed gawk net-tools bind-utils

bind-utils ti dà dig e host, utili per capire subito se il problema è DNS o applicazione. procps-ng e iproute servono per vedere processi, socket e interfacce dal container. Se devi fare troubleshooting di servizio, questi strumenti fanno risparmiare tempo.

Esporre una porta: quando ha senso

Un container Rocky non espone nulla per magia. Se dentro fai girare un servizio, devi pubblicare la porta esplicitamente. Questo vale per un web server, un demone di test o una semplice app di verifica. Per un ambiente di laboratorio, la regola è: apri solo la porta che ti serve, e solo per il tempo necessario.

Per esempio, se installi un web server e vuoi raggiungerlo dall’host:

docker run -d --name rocky-web -p 8080:80 rockylinux:9 sleep infinity

Dentro il container installi e configuri il servizio, poi lo avvii. Per verificare il mapping porta:

docker port rocky-web

Atteso: 80/tcp -> 0.0.0.0:8080 o equivalente. Se non vedi la porta, il mapping non è stato creato. Se la porta c’è ma il servizio non risponde, il problema è dentro il container, non nel publish Docker.

In scenari di test web, ricordati che un container base non include un server HTTP già pronto. Devi installarlo tu, oppure usare un’immagine costruita ad hoc. La scelta dipende dal tipo di prova: diagnostica manuale o ambiente ripetibile da team.

Creare un’immagine personalizzata con Dockerfile

Quando devi riusare spesso lo stesso setup, passare dal comando docker run a un Dockerfile è la mossa giusta. Ti evita di reinstallare pacchetti a ogni avvio e rende il risultato condivisibile. In pratica, documenti lo stato del container invece di lasciarlo nascere da una sequenza manuale di comandi.

Un esempio minimale per un’immagine Rocky con tool base e un utente non root:

FROM rockylinux:9

RUN dnf -y update && \
    dnf -y install curl vim procps-ng iproute bind-utils && \
    dnf clean all && \
    rm -rf /var/cache/dnf

RUN useradd -m labuser
USER labuser
WORKDIR /home/labuser
CMD ["bash"]

Qui ci sono due dettagli importanti. Primo: pulire la cache di dnf riduce dimensione e rumore. Secondo: l’utente non root è una buona abitudine anche nei container, soprattutto se il contenitore viene usato da più persone o se monti volumi con file sensibili.

Per buildare e avviare:

docker build -t rocky-lab:9 .
docker run -it --rm rocky-lab:9

L’opzione --rm è comoda se il container è solo di test: a fine sessione sparisce e non accumula residui. Se invece vuoi conservarlo, togli --rm e usa un nome fisso.

Permessi, SELinux e volumi: il punto dove si sbaglia spesso

Su host Linux con SELinux attivo, i problemi con i volumi sono classici: il file esiste, il mount è corretto, ma il processo nel container non riesce a leggere o scrivere. Prima di cambiare altro, controlla se il blocco è a livello di etichettatura SELinux. In molti casi il fix non è “aprire permessi a caso”, ma usare la label giusta sul mount.

Con Docker, spesso il suffisso :Z o :z sui bind mount risolve il problema di contesto SELinux, a seconda che il volume sia condiviso o esclusivo. Esempio:

docker run -it --rm \
  -v ~/lab/rocky-data:/data:Z \
  rockylinux:9 bash

Se il mount continua a fallire, verifica i log di audit sul host e il contesto del path con strumenti come ls -Z e, se serve, ausearch. Non dare per scontato che sia un problema Docker: su sistemi con SELinux il controllo accessi può bloccare anche un mount apparentemente banale.

Se l’host non usa SELinux, il tema si sposta su UID/GID e ownership del path montato. In quel caso, il container deve scrivere con un utente che abbia permessi coerenti sul filesystem dell’host. Per questo l’uso di un utente non root va pianificato, non improvvisato.

Gestione del container: ispezione, log, cleanup

Un container usato bene va anche osservato bene. Prima di modificarlo, ispeziona stato, mount, porte e comando di avvio. È il modo più veloce per capire se stai guardando il problema giusto.

docker ps -a

docker inspect rocky-lab --format '{{.State.Status}} {{.Config.Cmd}}'

docker logs rocky-lab

Se il container esce subito, docker logs spesso ti dice perché: comando errato, shell non trovata, servizio che termina, permessi, file mancanti. Per un container Rocky minimale, è normale che senza un processo in foreground il container si chiuda immediatamente. Non è un errore di Docker, è il comportamento atteso.

Per fermare e rimuovere in modo pulito un container di test:

docker stop rocky-lab
docker rm rocky-lab

Se hai usato --rm, la rimozione avviene automaticamente all’uscita. Se hai montato dati o hai fatto test con file persistenti, controlla prima cosa resta nel volume dell’host. Il container può sparire, ma il filesystem montato no.

Un flusso operativo sensato per l’uso quotidiano

Se vuoi un metodo pratico che non si rompe facilmente, la sequenza migliore è questa: scarica un tag preciso, avvia un container minimale, verifica rete e DNS, installa i tool necessari, monta eventuali volumi con attenzione, poi costruisci un’immagine solo quando il setup è stabile. È un ordine che riduce il numero di variabili aperte in ogni fase.

In un team operativo, questo approccio ha un vantaggio concreto: rende la procedura ripetibile. Chiunque può ricreare lo stesso Rocky container con gli stessi pacchetti e gli stessi mount, senza dover ricostruire il contesto da zero. Per troubleshooting e training è molto più utile di un container “magico” preparato a mano una volta sola.

Inoltre, se il tuo obiettivo è testare procedure di sistema, Rocky in container è un buon filtro iniziale, non un sostituto totale di una macchina reale. Ti serve per validare sintassi, pacchetti, script e dipendenze. Se il problema riguarda boot, systemd completo, hardware o kernel features, devi spostarti su VM o bare metal.

Esempio completo: container Rocky pronto per laboratorio

Questo esempio unisce i pezzi essenziali: immagine Rocky 9, shell interattiva, volume persistente e utente comodo per test. È una base ragionevole per molte attività di admin e supporto.

mkdir -p ~/lab/rocky-data

docker run -it --name rocky-demo \
  -v ~/lab/rocky-data:/data:Z \
  rockylinux:9 bash

Dentro il container, puoi preparare l’ambiente:

dnf -y install curl vim bind-utils procps-ng iproute

cat /etc/rocky-release
dig example.com
ip a

Se vuoi conservare una configurazione più strutturata, passa a un Dockerfile. Se invece il container serve solo per una verifica veloce, il comando diretto è più rapido e più onesto: crea poco, fai il test, distruggi tutto.

La regola finale è semplice: un container Rocky Linux funziona bene quando resta piccolo, leggibile e riproducibile. Appena inizi a trattarlo come una VM permanente senza governance, perdi il vantaggio principale del modello container.