Come installare Jenkins su AlmaLinux 8 e Rocky Linux

Jenkins su AlmaLinux 8 e Rocky Linux si installa senza strane magie, ma conviene farlo con ordine: prima Java, poi repository ufficiale, poi servizio e solo dopo esposizione verso l’esterno. Il punto non è “far partire Jenkins”, ma farlo partire in modo ripetibile, aggiornabile e con un profilo di rischio ragionevole per un nodo che spesso finisce davanti a pipeline, credenziali e accessi amministrativi.

Su queste distro il pacchetto gira bene, ma c’è un dettaglio che cambia spesso rispetto a guide vecchie: Jenkins non deve essere trattato come un’app qualsiasi da mettere online e dimenticare. Va considerato un componente sensibile, perché gestisce job, token, chiavi SSH, integrazioni con Git e spesso anche segreti dei deployment. Quindi l’installazione va letta come una piccola messa in produzione, non come un semplice yum install.

Scelta della base: Java, repository e porta di ascolto

Jenkins distribuisce il proprio repository RPM e richiede una versione Java supportata. Oggi la scelta più lineare su AlmaLinux 8 e Rocky Linux è usare OpenJDK 17, che evita incompatibilità inutili con versioni più vecchie e resta allineato al ciclo attuale del progetto. La porta predefinita è la 8080, ma in ambienti seri quasi mai la si espone direttamente senza un reverse proxy davanti.

Se il nodo è nuovo, verifica prima lo stato del sistema e la presenza di aggiornamenti pendenti. Non è un passaggio “bello da vedere”, è un modo per evitare di installare Jenkins sopra una base già incoerente.

sudo dnf update -y

Se il server è dietro proxy aziendale o in una rete con DNS filtrato, il download del repository può fallire. In quel caso il problema non è Jenkins, è connettività verso pkg.jenkins.io e verso i mirror della distribuzione. Prima di andare avanti, conviene testare risoluzione e raggiungibilità.

getent hosts pkg.jenkins.io
curl -I https://pkg.jenkins.io/redhat-stable/

Installazione su AlmaLinux 8 e Rocky Linux

La sequenza sotto è quella più pulita per un’installazione standard. Usa il repository stabile ufficiale, importa la chiave GPG del repository e installa Jenkins insieme a Java.

sudo rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io-2023.key
sudo curl -o /etc/yum.repos.d/jenkins.repo https://pkg.jenkins.io/redhat-stable/jenkins.repo
sudo dnf install -y java-17-openjdk jenkins

Se il comando di import della chiave fallisce, non forzare il repository a occhi chiusi. Prima verifica che il sistema riesca a scaricare il file e che il percorso sia corretto. Un repository non verificato è un rischio che non vale la pena introdurre su un servizio di automazione.

Dopo l’installazione, controlla che il servizio sia stato registrato da systemd e che il file di configurazione sia stato creato. Il file principale su queste distro è /etc/sysconfig/jenkins, utile per la porta, la JVM e alcuni parametri di avvio.

systemctl status jenkins --no-pager
rpm -ql jenkins | head
ls -l /etc/sysconfig/jenkins

Il servizio non si avvia da solo in modo affidabile se non lo abiliti. L’abilitazione all’avvio è una scelta da fare solo dopo aver verificato che il nodo sia pronto a gestire il carico e le dipendenze esterne, altrimenti rischi un boot con Jenkins acceso ma non raggiungibile per DNS, firewall o storage.

sudo systemctl enable --now jenkins

Primo avvio e password iniziale

Al primo avvio Jenkins genera una password temporanea di sblocco. Il file da leggere è quasi sempre /var/lib/jenkins/secrets/initialAdminPassword. Se il file non esiste, il servizio non ha completato correttamente la bootstrap phase oppure il volume dati non è montato come previsto.

sudo cat /var/lib/jenkins/secrets/initialAdminPassword

Apri poi la UI su http://IP_DEL_SERVER:8080 oppure sul nome host se il DNS è già a posto. Se la pagina non risponde, il problema è quasi sempre uno di questi: servizio non attivo, firewall locale, ascolto su un indirizzo inatteso o blocco upstream su rete/cloud.

Per distinguere rapidamente il livello applicativo dal livello rete, usa un controllo locale e uno remoto. Il primo dice se Jenkins è vivo; il secondo dice se è raggiungibile dall’esterno.

curl -I http://127.0.0.1:8080
ss -ltnp | grep 8080

Se il curl locale risponde con HTTP/1.1 200 o 403, il processo c’è. Se invece il socket non è in ascolto, guarda subito i log di systemd.

sudo journalctl -u jenkins -b --no-pager

Configurazione iniziale dal wizard

Il wizard iniziale propone il recupero plugin e la creazione dell’utente amministratore. Qui conviene essere selettivi. Non installare plugin a pioggia solo perché il wizard li suggerisce: ogni plugin in più è una superficie di manutenzione, e Jenkins ha una storia lunga di aggiornamenti che rompono compatibilità tra plugin vecchi e core nuovo.

Il criterio pratico è semplice: installa solo ciò che serve per sbloccare il primo flusso di lavoro, poi aggiungi il resto in modo controllato. Se devi integrare Git, credenziali SSH, pipeline e notifiche, parti da quello. Il resto arriva dopo, con un backup e una finestra di manutenzione minima.

Dopo aver creato l’utente admin, entra nella console e vai subito in Manage Jenkins per verificare il versioning della piattaforma, lo stato dei plugin e gli eventuali warning di compatibilità. È il momento giusto per scoprire eventuali problemi di permessi o di rete, non dopo aver affidato il server a una pipeline critica.

Firewall: aprire solo ciò che serve

Su AlmaLinux e Rocky il firewall predefinito è spesso firewalld. Se Jenkins deve essere raggiungibile direttamente su 8080, la porta va aperta esplicitamente. Se invece metti un reverse proxy davanti, la 8080 può restare privata e accessibile solo localmente o dalla rete di backend.

Per un test veloce puoi aprire temporaneamente la porta, ma in produzione la soluzione più pulita resta limitare l’accesso alla sola subnet amministrativa o al proxy.

sudo firewall-cmd --permanent --add-port=8080/tcp
sudo firewall-cmd --reload
sudo firewall-cmd --list-ports

Se la porta è aperta ma dall’esterno non risponde, il problema non è il firewall locale. A quel punto controlla security group cloud, ACL di rete, routing e eventuali policy del provider.

Reverse proxy con Nginx o Apache

Esporre Jenkins dietro Nginx o Apache è la scelta più sensata nella maggior parte dei casi. Ti permette di gestire TLS, redirect, header, limitazioni di accesso e log separati. Inoltre riduce l’esposizione del processo Java diretto su Internet, che non è mai una cattiva idea.

Con Nginx, un blocco minimo può essere questo. È una base, non un template universale: se usi WebSocket, path custom o autenticazione esterna, va adattato. Qui l’obiettivo è mostrare il percorso corretto, non vendere una configurazione “magica”.

server {
    listen 80;
    server_name jenkins.example.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 90;
    }
}

Se il sito deve stare dietro HTTPS, termina TLS sul proxy e lascia Jenkins in locale. In questo scenario il certificato si gestisce sul web server, non su Jenkins. È più semplice da ruotare, più facile da monitorare e meno fragile in caso di rinnovo automatico.

Quando il reverse proxy è attivo, controlla che Jenkins riconosca correttamente il contesto esterno. In Manage Jenkins o nella configurazione globale puoi impostare il prefisso URL, altrimenti alcuni link interni e callback potrebbero puntare alla porta 8080 o a un host sbagliato.

Hardening minimo prima di metterlo in rete

Jenkins non va trattato come un portale pubblico. Anche senza entrare in scenari avanzati, ci sono alcune misure minime che conviene applicare subito: aggiornamenti regolari, accesso amministrativo ristretto, TLS, backup dei job e protezione del file system dati.

Il primo controllo riguarda i permessi di /var/lib/jenkins. Deve appartenere all’utente jenkins e non essere aperto più del necessario. Se trovi permessi incoerenti, il servizio può partire ma fallire in modo intermittente su plugin, cache e file di configurazione.

ls -ld /var/lib/jenkins
sudo namei -l /var/lib/jenkins

Il secondo controllo riguarda gli aggiornamenti. Jenkins e i plugin cambiano spesso, quindi devi avere una finestra di manutenzione e una strategia di rollback. Se il nodo è critico, fai snapshot o backup del volume dati prima di aggiornare core e plugin.

Un backup minimo utile include la directory dati e la configurazione del servizio. Prima di toccare il sistema, salva almeno questi elementi:

sudo tar -czf /root/jenkins-backup-$(date +%F).tgz /var/lib/jenkins /etc/sysconfig/jenkins

Se usi SELinux in enforcing, non disabilitarlo per comodità. La strada corretta è verificare che il contesto e le policy siano coerenti. In molti casi Jenkins funziona senza interventi, ma quando aggiungi proxy, mount o directory esterne, i problemi SELinux emergono subito. Il sintomo tipico è un servizio che legge bene i file locali ma non riesce a scrivere dove dovrebbe.

Verifiche operative dopo l’installazione

Dopo l’avvio iniziale, fai tre controlli semplici e concreti. Primo: il servizio deve essere attivo. Secondo: la porta deve ascoltare. Terzo: la UI deve rispondere con codice coerente. Se uno dei tre manca, non andare avanti con plugin e job.

systemctl is-active jenkins
ss -ltnp | grep 8080
curl -I http://127.0.0.1:8080

Se la UI risponde localmente ma non dall’esterno, il problema è quasi sempre nel layer di rete o nel proxy. Se invece il servizio risponde con errori 5xx, vai a leggere i log applicativi e di sistema. In caso di memoria insufficiente o heap troppo stretta, il problema può comparire subito dopo il bootstrap o durante il caricamento dei plugin.

Un controllo utile è anche quello sulla versione Java effettivamente usata dal processo. Su sistemi con più JDK installati, il servizio può partire con una versione diversa da quella che ti aspettavi.

java -version
ps -ef | grep jenkins | grep -v grep

Problemi tipici e lettura rapida del sintomo

Se Jenkins resta fermo su schermata bianca o non completa il wizard, guarda prima il log di journalctl e poi il file di log applicativo se presente. Spesso la causa è una combinazione di plugin incompatibili, memoria insufficiente o errore di permessi sul volume dati. La schermata bianca non è una diagnosi: è solo un effetto visibile.

Se la porta 8080 è chiusa ma il servizio è attivo, controlla il binding. In alcune configurazioni Jenkins può essere limitato a localhost o a un indirizzo specifico. Il comando ss -ltnp ti dice subito su quale interfaccia sta ascoltando.

Se il download dei plugin fallisce, il colpevole di solito è la rete in uscita. Prima di toccare Jenkins, prova a risolvere e raggiungere i domini esterni usati dal sistema. In ambienti con proxy, devi configurare anche le variabili di ambiente o le impostazioni di rete del processo, altrimenti il wizard va in timeout.

Se SELinux blocca scritture o letture, il sintomo può sembrare casuale. Non correggere il problema con un disable globale: identifica il percorso, verifica i contesti e applica la regola minima necessaria. Qui il vantaggio operativo è evidente: non abbassi la protezione dell’intero nodo per sistemare un solo servizio.

Aggiornamento e manutenzione nel tempo

Una volta installato, Jenkins va mantenuto come qualsiasi servizio critico. Aggiorna prima in ambiente non produttivo, controlla compatibilità plugin-core e conserva una copia del volume dati prima del salto di versione. La parte più costosa non è l’upgrade in sé, ma il recovery quando un plugin vecchio rompe il caricamento della UI o una pipeline storica.

La manutenzione minima sensata include monitoraggio del servizio, spazio disco, uso memoria e tempo di risposta della UI. Jenkins può sembrare stabile per mesi e poi degradare rapidamente quando la coda build cresce o quando il disco dei job si riempie di artefatti.

Se vuoi un’installazione che non ti costringa a rincorrerla ogni settimana, la regola è semplice: repository ufficiale, Java supportata, reverse proxy, backup prima degli upgrade e accesso limitato. È meno spettacolare di una guida “click and forget”, ma funziona davvero in produzione.