Cosa serve per installare Docker su RHEL 8

Su RHEL 8 Docker non si installa “e basta”: prima va chiarito cosa serve davvero per farlo funzionare in modo pulito, sostenibile e senza conflitti con i componenti già presenti nel sistema. Il punto non è solo aggiungere un repository e lanciare un `dnf install`, ma verificare compatibilità, dipendenze, policy di sicurezza e impatto sullo storage.

Il tema è pratico: Docker Engine su RHEL 8 usa il pacchetto `containerd.io`, il repository ufficiale di Docker e alcune impostazioni di sistema che spesso vengono date per scontate. Se manca anche solo uno di questi pezzi, l’installazione può andare a buon fine ma il demone non parte, i container non persistono come previsto o le policy SELinux bloccano tutto al primo accesso ai volumi.

Prerequisiti reali prima di toccare il sistema

La prima domanda non è “come installo Docker”, ma “su quale base sto lavorando”. Su RHEL 8 serve una macchina aggiornata, con accesso ai repository necessari, privilegi amministrativi e una scelta chiara tra Docker Engine e la stack nativa di Red Hat basata su Podman. Se l’obiettivo è seguire la strada Docker, conviene dichiararlo subito e evitare installazioni miste fatte a metà.

Ti servono almeno questi elementi:

• RHEL 8 registrato e aggiornato, con `dnf` funzionante.
• Accesso root o `sudo` per installare pacchetti e gestire servizi systemd.
• Connettività verso `download.docker.com` oppure un mirror interno equivalente.
• Spazio libero sufficiente in `/var/lib/docker` o su un mount dedicato, se prevedi immagini e volumi non banali.
• Consapevolezza che Docker e Podman risolvono problemi simili ma non sono intercambiabili al 100% a livello operativo.

Se il sistema è un host di produzione, la valutazione dello storage è già parte della messa in opera. Docker tende a consumare spazio in modo rapido con build cache, layer e log dei container. Su macchine piccole, il rischio non è teorico: il primo sintomo può essere un filesystem pieno e non un errore di installazione.

Repository da usare e pacchetti da installare

Per RHEL 8, la via standard è il repository ufficiale Docker. Non conviene pescare pacchetti casuali da fonti terze: il rischio di incompatibilità con `containerd`, versioni vecchie o dipendenze spezzate è alto, e la diagnosi dopo diventa più lunga del tempo risparmiato all’inizio.

La sequenza minima è questa:

sudo dnf -y install dnf-plugins-core
sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo
sudo dnf makecache

A questo punto puoi vedere cosa il repository espone davvero sul tuo sistema:

dnf list docker-ce docker-ce-cli containerd.io

Se i pacchetti non compaiono, il problema non è Docker ma la reachability del repository, la configurazione proxy o un blocco di rete verso l’esterno. In quel caso il controllo più rapido è verificare l’URL del repo e la risoluzione DNS:

curl -I https://download.docker.com/linux/rhel/docker-ce.repo
getent hosts download.docker.com

Il pacchetto da installare non è solo `docker-ce`: normalmente servono anche `docker-ce-cli`, `containerd.io`, `docker-buildx-plugin` e `docker-compose-plugin`. Il dettaglio importante è che `containerd.io` venga preso dal repository Docker, non da un mix incoerente di sorgenti diverse.

Installazione corretta con systemd

Una volta che il repository è visibile, l’installazione standard è lineare:

sudo dnf -y install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Dopo l’installazione, il servizio va avviato e abilitato all’avvio automatico:

sudo systemctl enable --now docker

La verifica non si fa guardando solo l’assenza di errori a schermo. Controlla lo stato del demone e l’eventuale output di bootstrap:

systemctl status docker --no-pager
journalctl -u docker -b --no-pager | tail -n 50

Se il servizio non parte, il log di `journalctl` è il primo posto dove cercare. Su RHEL 8 gli errori più comuni sono incompatibilità con `containerd`, problemi di cgroup o blocchi legati a SELinux e storage driver. Non saltare questo passaggio: avviare il servizio senza leggere i log significa perdere il 90% del contesto utile.

Il nodo vero: cgroup, storage driver e SELinux

Su RHEL 8 la compatibilità con i cgroup è un punto da controllare, soprattutto se la macchina è stata toccata da configurazioni manuali o boot parameters non standard. Docker si appoggia a `systemd` e alla gestione dei cgroup del kernel; se il sistema è stato alterato, il demone può partire male o i container possono fallire in modo intermittente.

Per capire come Docker vede il sistema, controlla il driver di storage e la configurazione attiva:

docker info | egrep 'Storage Driver|Cgroup Driver|Server Version|Runtimes'

Su RHEL 8 lo scenario più pulito è lasciare che Docker scelga la configurazione supportata dall’ambiente, senza forzare parametri vecchi presi da guide generiche. Se il driver di storage non è quello atteso, spesso il problema nasce da filesystem non adatti, da residui di installazioni precedenti o da configurazioni manuali in `/etc/docker/daemon.json`.

SELinux va trattato come componente del sistema, non come ostacolo da disattivare per comodità. Se i container usano bind mount e SELinux è in enforcing, i permessi devono essere coerenti. La soluzione corretta non è spegnere SELinux, ma etichettare i volumi in modo adeguato o usare il contesto corretto nel mount.

Esempio pratico di mount con label SELinux compatibile:

docker run -d --name web -v /srv/web:/usr/share/nginx/html:Z nginx:latest

Il flag `:Z` rietichetta il contenuto per uso esclusivo del container. Se invece devi condividere il volume tra più container, il discorso cambia e va valutato il contesto `:z`. Qui il dettaglio conta: usare il flag sbagliato è un classico modo per introdurre bug di accesso ai file senza che l’errore sia immediato.

Cosa serve davvero se Docker deve servire applicazioni in produzione

Installare il motore è solo il primo passo. Per usarlo in modo serio servono anche alcune scelte operative. La prima riguarda dove mettere i dati persistenti. Per default Docker usa `/var/lib/docker`, ma su sistemi con carico reale conviene spesso spostare la directory dati su un filesystem dedicato, con capacità e snapshot gestibili meglio.

Se vuoi cambiare `data-root`, il file da toccare è `/etc/docker/daemon.json`. Esempio minimale:

{
  "data-root": "/srv/docker"
}

Dopo la modifica serve un riavvio del servizio:

sudo systemctl restart docker
sudo docker info | grep 'Docker Root Dir'

Qui il rollback è semplice ma va pianificato: prima di cambiare `data-root`, assicurati di avere backup del contenuto esistente o di aver svuotato correttamente il vecchio path. Se Docker parte su un root directory vuoto mentre i dati veri sono rimasti altrove, i container sembrano spariti e la diagnosi diventa inutilmente confusa.

La seconda scelta riguarda l’accesso al demone. Aggiungere utenti al gruppo `docker` è comodo, ma equivale quasi a concedere privilegi elevati sulla macchina. Su un host condiviso o in un contesto più rigido, meglio usare `sudo` esplicito e limitare il gruppo a pochi amministratori fidati.

sudo usermod -aG docker nomeutente
newgrp docker

Il punto non è “si può fare”, ma “serve davvero”. Se la macchina è amministrata da più persone, il gruppo `docker` va considerato superficie sensibile. Chi ne fa parte può di fatto ottenere controllo esteso sul sistema tramite mount, socket e container privilegiati.

Verifiche dopo l’installazione: non fermarti a `docker version`

Una check-list minima deve includere almeno tre livelli: demone, esecuzione container e rete. Il comando `docker version` ti dice che client e server parlano; non ti dice che i container riescono a scaricare immagini, esporre porte o montare volumi senza errori.

Verifica operativa base:

docker run --rm hello-world
docker run --rm alpine:latest echo OK

Se questi due test falliscono, il problema è già ben localizzato. `hello-world` verifica il path di esecuzione minimo; `alpine` con `echo` aggiunge un controllo un po’ più reale sul lifecycle del container. Se il pull dell’immagine fallisce, il nodo da guardare è la rete in uscita o il DNS del sistema.

Per la rete, controlla anche il firewall. Su RHEL 8 il backend tipico è `firewalld`, e non è raro che i container partano ma le porte pubblicate non siano raggiungibili dall’esterno. In quel caso la verifica è banale ma va fatta sul serio:

sudo firewall-cmd --list-ports
sudo firewall-cmd --list-services

Se usi una porta pubblicata, devi avere una regola coerente con il servizio esposto, altrimenti il container è sano ma dall’esterno sembra morto. È un errore classico: si dà la colpa a Docker quando il blocco è a livello di host firewall o security group esterno.

Docker su RHEL 8 e conflitto con Podman

Su RHEL 8 il tema non è solo tecnico ma anche di ecosistema. Podman è molto presente nell’ambiente Red Hat e spesso è la scelta naturale se vuoi restare allineato alla piattaforma. Docker può essere installato e usato, ma è bene sapere che il sistema non è “vuoto”: ci sono già strumenti container-oriented che possono coesistere o creare confusione se l’operatore non distingue i ruoli.

Se nel server sono già presenti pacchetti legati a container runtime diversi, valuta prima cosa deve fare la macchina. Se serve compatibilità con tooling Docker, il motore Docker ha senso. Se invece vuoi solo eseguire container in modo rootless o più vicino al modello nativo RHEL, Podman può essere più coerente. La scelta influenza anche il troubleshooting: non mescolare concetti e comandi senza una ragione chiara.

Un controllo utile è vedere cosa è installato davvero:

rpm -qa | egrep 'docker|podman|containerd|runc'

Se trovi versioni molto vecchie o pacchetti eterogenei, il rischio di conflitti aumenta. In quel caso la strategia prudente è fare pulizia documentata, non improvvisare rimozioni a caso. Prima si fotografa lo stato, poi si decide cosa tenere.

Installazione in ambienti controllati: proxy, mirror e repository interni

In molte installazioni reali il nodo non è il server, ma la rete aziendale. Se la macchina esce solo tramite proxy o non può raggiungere Internet, il repository Docker va replicato in una forma compatibile con il perimetro interno. In questi casi la checklist cambia: devi sapere se `dnf` usa proxy, se il certificato della CA interna è installato e se il mirror è aggiornato.

Controllo rapido del proxy per `dnf`:

grep -R "^proxy=" /etc/dnf/dnf.conf /etc/yum.conf 2>/dev/null

Se il repository interno è gestito via file `.repo`, verifica che il baseurl punti alla sorgente corretta e che il certificato TLS del mirror sia fidato dal sistema. Qui il problema tipico non è Docker ma la catena di trust del sistema operativo.

Se l’azienda usa un mirror privato, conserva una copia del file repo originale e documenta la differenza. È un dettaglio operativo che risparmia tempo al successivo aggiornamento o al passaggio di consegne.

Checklist finale di ciò che serve davvero

Riassumendo, per installare Docker su RHEL 8 in modo sensato servono questi ingredienti:

• Repository Docker ufficiale o mirror interno equivalente.
• `dnf-plugins-core` per aggiungere il repo.
• Pacchetti `docker-ce`, `docker-ce-cli`, `containerd.io` e plugin utili.
• Servizio `docker` abilitato con systemd.
• Verifica di SELinux, firewall, storage e rete in uscita.
• Decisione esplicita su utenti, privilegi e path dati persistenti.

Se manca uno di questi punti, l’installazione può sembrare completata ma non essere operativa. In pratica, il lavoro vero non è installare il pacchetto: è garantire che il runtime abbia un contesto coerente in cui vivere.

Assunzione: il lettore ha accesso amministrativo al server e vuole una installazione Docker supportabile su RHEL 8, non una prova temporanea su una macchina isolata.