Installare e configurare Docker su Rocky Linux 8

Repository ufficiale e prerequisiti su Rocky Linux 8

Su Rocky Linux 8 conviene partire dal repository ufficiale Docker e non da pacchetti terzi o versioni prese a caso. La ragione è semplice: il ciclo di aggiornamento resta più prevedibile, i nomi dei pacchetti sono quelli attesi e la documentazione del vendor coincide con ciò che installi davvero. In pratica, riduci il rischio di incompatibilità tra docker-ce, containerd e il kernel della macchina.

Qui l’obiettivo è installare Docker Engine in modo pulito, verificare che il demone parta con systemd, abilitare l’avvio automatico e fare un primo controllo operativo. Se la macchina è in produzione o vicina alla produzione, considera l’installazione come un change controllato: controlla spazio disco, connessione ai repository e eventuali policy di sicurezza come SELinux o firewall prima di toccare il sistema.

Rocky Linux 8 deriva da RHEL 8, quindi la procedura è molto simile a quella di altre distro compatibili. Cambia poco a livello operativo, ma cambia abbastanza da sconsigliare istruzioni generiche prese da guide pensate per Debian o Ubuntu. Qui usiamo dnf, systemd e il repository Docker per EL8.

Prima di installare, verifica che il sistema sia aggiornato e che non ci siano vecchi pacchetti Docker confliggenti. Se hai installazioni precedenti di docker, docker-client, docker-common o simili, vanno rimossi prima di procedere. Questo evita sovrapposizioni di file e servizi che poi diventano difficili da diagnosticare.

sudo dnf -y update
sudo dnf -y remove docker \
  docker-client \
  docker-client-latest \
  docker-common \
  docker-latest \
  docker-latest-logrotate \
  docker-logrotate \
  docker-engine

Se il comando di rimozione non trova nulla, non è un problema: significa solo che il sistema è pulito. Se invece rimuove pacchetti esistenti, valuta l’impatto sulle applicazioni che li usavano prima di proseguire. In un change serio, la verifica preliminare si fa con rpm -qa | grep -i docker e con un controllo dei container eventualmente in esecuzione.

Aggiungere il repository Docker e installare i pacchetti corretti

Il pacchetto dnf-plugins-core serve per gestire repository aggiuntivi in modo pulito. Una volta installato, aggiungi il repository ufficiale Docker per CentOS/RHEL 8, che è compatibile con Rocky Linux 8. Non serve inventarsi file manuali se il repository è già definito dal vendor: meno superficie di errore, meno manutenzione futura.

sudo dnf -y install dnf-plugins-core
sudo dnf config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
sudo dnf repolist | grep -i docker

Il controllo con dnf repolist deve mostrare il repository Docker tra quelli abilitati. Se non compare, il problema è di rete, DNS, proxy o policy di uscita verso Internet. In quel caso non andare avanti a tentativi: prima verifica la raggiungibilità dell’URL del repo con curl -I e controlla eventuali filtri aziendali o un proxy configurato nel sistema.

curl -I https://download.docker.com/linux/centos/docker-ce.repo

Per l’installazione vera e propria, i pacchetti minimi sono docker-ce, docker-ce-cli, containerd.io, docker-buildx-plugin e docker-compose-plugin. Il plugin Compose è ormai la strada più lineare per gestire stack applicativi con file Compose moderni, senza dipendere da binari separati e versioni non allineate.

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

Se dnf segnala dipendenze mancanti o conflitti, il punto da verificare non è Docker in sé ma la base del sistema: repository attivi, releasever, pacchetti già installati da fonti esterne, oppure una macchina che non è veramente Rocky 8. Il comando utile per capire il contesto è cat /etc/os-release e, se serve, dnf repolist -v.

Avvio del servizio, abilitazione all’avvio automatico e primo test

Una volta installato il pacchetto, il demone non è detto che parta da solo. Su un server pulito, il passo successivo è abilitare e avviare il servizio Docker con systemd. Questo è il punto in cui si vede subito se il kernel, containerd e la configurazione base sono coerenti.

sudo systemctl enable --now docker
sudo systemctl status docker --no-pager

Lo stato atteso è active (running). Se trovi failed o activating bloccato, il primo log da leggere è quello di systemd. Su Rocky Linux 8 il comando più utile è journalctl -u docker -xe, perché ti mostra subito se il problema è nel socket, nel runtime o in una configurazione corrotta.

sudo journalctl -u docker -xe --no-pager

Il test più semplice resta docker run --rm hello-world. Non è un benchmark, ma è perfetto come prova funzionale: scarica un’immagine, crea un container, avvia il runtime e chiude tutto senza lasciare residui. Se questo test fallisce, hai un problema di rete verso Docker Hub, di DNS, di storage locale o di policy di sicurezza.

sudo docker run --rm hello-world

Se il pull dell’immagine si blocca, verifica la connettività con curl -I https://registry-1.docker.io/v2/. Una risposta 401 Unauthorized è normale su quel endpoint: significa che il registry è raggiungibile. Se invece ottieni timeout o DNS failure, la causa è esterna a Docker e va risolta a livello di rete o risoluzione nomi.

Gestione del socket, gruppo docker e accesso non root

Di default Docker espone il socket Unix /var/run/docker.sock con permessi limitati. Il modo corretto per evitare di lanciare tutto come root è aggiungere l’utente amministrativo al gruppo docker. È comodo, ma non va trattato come una banalità: chi appartiene al gruppo Docker ha di fatto privilegi molto ampi sulla macchina.

In termini pratici, l’accesso al socket Docker equivale quasi sempre a capacità amministrative elevate. Non è un dettaglio cosmetico. Se il server è condiviso o in un contesto multi-tenant, questo gruppo va assegnato con criterio e solo agli operatori che davvero devono gestire container.

sudo usermod -aG docker $USER
newgrp docker
id

Dopo il login di nuovo o con newgrp docker, il comando id deve mostrare il gruppo docker. A quel punto puoi testare senza sudo:

docker ps
docker run --rm hello-world

Se il comando fallisce con permission denied sul socket, il problema è quasi sempre uno di sessione: l’utente è nel gruppo, ma la shell corrente non ha ancora ricaricato i gruppi. In alternativa, verifica i permessi di /var/run/docker.sock con ls -l /var/run/docker.sock. Il risultato atteso è un socket proprietà di root:docker o equivalente, con accesso coerente con la policy del sistema.

Configurazione base di daemon.json, log e rete bridge

La configurazione iniziale di Docker su Rocky Linux 8 si fa di solito in /etc/docker/daemon.json. Qui conviene essere sobri: imposta solo ciò che serve davvero, come il driver dei log, il formato del log, eventualmente un registry mirror o il subnet del bridge se hai conflitti con reti già presenti. Ogni opzione in più è un punto in più da mantenere.

Un esempio minimale e sensato per partire è questo. Non è obbligatorio, ma aiuta a evitare log senza rotazione o configurazioni ambigue quando il sistema cresce.

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

Dopo ogni modifica a daemon.json, fai sempre una validazione sintattica indiretta riavviando il servizio e leggendo i log. Docker non offre un lint completo del file come farebbe un parser dedicato, quindi il controllo reale è il riavvio di dockerd e il comportamento del servizio. Prima di applicare il cambio, conserva una copia del file: è il rollback più semplice e più veloce.

sudo cp -a /etc/docker/daemon.json /etc/docker/daemon.json.bak.$(date +%F_%H%M%S)
sudo systemctl restart docker
sudo systemctl status docker --no-pager
sudo journalctl -u docker -n 50 --no-pager

Se vuoi cambiare la subnet bridge predefinita perché collide con reti VPN o segmenti interni, fallo solo se hai già verificato quali range sono in uso sulla macchina e sulla rete. Un conflitto di subnet è uno dei problemi più fastidiosi da inseguire perché sembra un guasto intermittente, ma in realtà è una scelta di addressing sbagliata. Il dato da controllare è il campo Subnet in docker network inspect bridge e il routing locale con ip route.

SELinux, firewall e impatto sulla connettività dei container

Su Rocky Linux 8 SELinux è parte della normalità, non un accessorio. In molte installazioni Docker funziona subito, ma appena monti volumi o esponi servizi web conviene controllare i contesti. Il classico errore è vedere il container avviarsi correttamente ma l’applicazione non riuscire a leggere i file montati dal filesystem host.

Per i bind mount, il problema si risolve spesso con il labeling corretto o con l’opzione :Z o :z nei volumi, a seconda del caso d’uso. Non è una scorciatoia da usare a caso: :Z applica un contesto privato, :z uno condiviso. Se non sai quale usare, osserva il tipo di condivisione richiesto dall’applicazione e verifica i contesti con ls -Z.

ls -Z /srv/app
sudo semanage fcontext -l | grep -i docker

Per il firewall, Docker crea regole proprie e pubblica porte in modo dinamico, ma non devi dare per scontato che tutto sia aperto. Se usi firewalld, verifica che le porte pubblicate dai container siano accessibili dal segmento corretto. Il test più rapido è un curl dalla stessa macchina e poi da un host remoto autorizzato.

sudo firewall-cmd --list-all
curl -I http://127.0.0.1:8080

Se la connessione locale funziona ma da fuori no, il problema non è Docker ma il perimetro: firewall host, security group cloud, ACL di rete o eventuale NAT. Se invece fallisce anche in locale, controlla che il container stia ascoltando sulla porta corretta e che il mapping sia stato pubblicato con -p o nel file Compose.

Docker Compose come base operativa per stack applicativi

Su sistemi Linux moderni, Compose è il modo più pratico per portare avanti stack con web server, app e database senza scrivere script ad hoc. Il plugin installato insieme a Docker consente di usare docker compose come comando nativo. Questo è utile sia per test locali sia per ambienti server dove vuoi una configurazione ripetibile.

Un file Compose minimale per verificare la catena di esecuzione può essere molto semplice. L’obiettivo non è fare un’app reale, ma confermare che networking, volumi e policy di restart funzionino come previsto.

services:
  web:
    image: nginx:stable
    ports:
      - "8080:80"
    restart: unless-stopped

Il controllo operativo è immediato:

docker compose up -d
docker compose ps
curl -I http://127.0.0.1:8080

Se il container parte ma la porta non risponde, verifica se la porta host è già occupata con ss -ltnp | grep 8080. Se invece il container va in restart loop, i log applicativi sono il punto giusto da leggere, non il demone Docker. Con Compose il problema sta spesso nel path dei volumi, nelle variabili d’ambiente o nella dipendenza da un database non ancora pronto.

Manutenzione iniziale: spazio, log, aggiornamenti e ordine operativo

Dopo l’installazione, il vero lavoro è non far degenerare la macchina. Docker tende a consumare spazio tra immagini, layer, volumi e log dei container. Su un server piccolo, il disco pieno arriva più in fretta di quanto ci si aspetti. Per questo vale la pena impostare subito un controllo periodico su spazio e uso del runtime.

docker system df
sudo du -sh /var/lib/docker
sudo journalctl -u docker --since "24 hours ago" --no-pager

Se vuoi ripulire, fallo con criterio. Le operazioni come docker image prune o docker system prune non sono da lanciare senza sapere cosa stai rimuovendo. In un ambiente con build frequenti o cache importanti, una pulizia aggressiva può peggiorare le prestazioni o cancellare immagini ancora utili. La regola è semplice: prima identifica cosa occupa spazio, poi rimuovi solo ciò che è davvero obsoleto.

Anche gli aggiornamenti vanno gestiti con disciplina. Docker, containerd e il kernel interagiscono tra loro; aggiornare tutto a caso in una finestra stretta non è una buona idea. Meglio aggiornare con dnf update in un change pianificato, verificare il servizio, testare un container semplice e solo dopo passare ai servizi reali.

sudo dnf -y update docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo systemctl restart docker
sudo docker run --rm hello-world

Se il server ospita applicazioni in produzione, documenta almeno tre cose: versione Docker, configurazione di /etc/docker/daemon.json e posizione dei volumi persistenti. Senza queste informazioni, un problema di storage o un rollback diventano troppo lenti da gestire. La documentazione minima non deve essere prolissa, ma deve permettere a chi arriva dopo di capire cosa c’è in esecuzione e dove stanno i dati.

Errori tipici e lettura rapida dei sintomi

Su Rocky Linux 8 i problemi più comuni dopo l’installazione sono quasi sempre riconducibili a quattro aree: repository non raggiungibile, servizio Docker non avviato, permessi sul socket e conflitti di rete o SELinux. La buona notizia è che si distinguono in pochi minuti se guardi i sintomi giusti.

Se docker ps restituisce un errore di connessione al socket, il demone non gira o non è accessibile. Se docker run fallisce sul pull, il problema è la rete o il registry. Se il container parte ma l’app non risponde, guarda porte, firewall, volumi e log dell’applicazione. Se il servizio Docker non si avvia dopo una modifica, il primo sospetto è /etc/docker/daemon.json o un conflitto con il runtime.

Un buon approccio operativo è questo: prima osserva, poi modifica. systemctl status docker, journalctl -u docker, docker info e un test con un container minimo danno già una fotografia abbastanza completa. Solo dopo si passa a tuning, policy di sicurezza o integrazione con stack più complessi.

docker info
systemctl is-enabled docker
systemctl is-active docker

Se il tuo obiettivo è usare Docker come base per ambienti applicativi affidabili, la parte importante non è solo installarlo. È lasciarlo in uno stato coerente: repository ufficiale, servizio attivo, accesso controllato, log leggibili, configurazione minima e verifiche ripetibili. Su Rocky Linux 8 questo si ottiene senza trucchi, ma con una sequenza ordinata di controlli.

Assunzioni: macchina Rocky Linux 8 aggiornata, accesso amministrativo via sudo, connettività verso i repository Docker, nessuna esigenza particolare di orchestrazione come Kubernetes al momento dell’installazione.