1 20/04/2026 11 min

Perché Artifactory su Ubuntu 24.04 va trattato come un servizio critico

JFrog Artifactory non è solo un pacchetto da installare e dimenticare. Su Ubuntu 24.04 LTS entra in gioco come componente centrale della catena di build e distribuzione: se si ferma, si blocca il rilascio di artefatti, dipendenze e immagini. La scelta corretta non è quindi “come lo faccio partire”, ma “come lo metto in produzione senza costruirmi un punto unico di guasto fragile e opaco”.

Su una macchina pulita, il percorso più lineare è usare il pacchetto ufficiale JFrog, affidandosi a systemd per l’avvio, a un reverse proxy per l’esposizione esterna e a volumi separati per dati e log. Il punto delicato è che Artifactory non si comporta bene se lo tratti come una web app qualsiasi: richiede memoria, I/O affidabile e un minimo di disciplina su backup, aggiornamenti e permessi.

Prerequisiti reali: CPU, RAM, storage e rete

Prima di installare, verifica che il server abbia risorse coerenti con l’uso previsto. Per un ambiente piccolo di test o di team interno, 4 vCPU e 8 GB di RAM sono il minimo sensato; per un nodo usato da più pipeline e repository, 8 GB sono rapidamente stretti e 16 GB diventano la soglia più serena. Lo storage conta più della CPU: meglio un disco veloce e stabile, con spazio separato per i dati persistenti e i log, che una macchina potente ma collocata su un volume saturo.

Controlla anche la risoluzione DNS, l’ora di sistema e la raggiungibilità delle porte. Artifactory parla su HTTP/HTTPS, ma in molti scenari viene affiancato da un database esterno e da servizi di autenticazione. Se l’orario è fuori sync, i token e i certificati portano problemi difficili da diagnosticare. Se il DNS interno è incoerente, i repository remoti diventano instabili senza che il problema sia davvero “Artifactory”.

Verifica minima prima di procedere:

free -h per la RAM disponibile, df -h per lo spazio, timedatectl per l’orario, e resolvectl status per la risoluzione. Se una di queste basi è già fuori linea, fermati e correggi prima di installare.

Installazione del repository JFrog su Ubuntu 24.04

Su Ubuntu 24.04 conviene partire dal repository ufficiale, così tieni il controllo sugli aggiornamenti e non ti affidi a pacchetti vecchi o repackaged. Il flusso corretto è: aggiornare l’indice, installare i prerequisiti, aggiungere la chiave del repository e installare Artifactory. Evito i dettagli non verificabili del layout del pacchetto perché JFrog può cambiare nomi e dipendenze tra release; la regola è leggere sempre la documentazione della versione che stai installando e confrontarla con i file realmente presenti dopo l’installazione.

Sequenza tipica:

sudo apt update
sudo apt install -y ca-certificates curl gnupg apt-transport-https
curl -fsSL https://releases.jfrog.io/artifactory/api/gpg/key/public | sudo gpg --dearmor -o /usr/share/keyrings/jfrog.gpg
printf 'deb [signed-by=/usr/share/keyrings/jfrog.gpg] https://releases.jfrog.io/artifactory/artifactory-debs/ stable main\n' | sudo tee /etc/apt/sources.list.d/jfrog-artifactory.list
sudo apt update
sudo apt install -y jfrog-artifactory-cpp-ce

Il nome esatto del pacchetto può variare in base all’edizione e alla versione disponibile nel repository. Se il comando di installazione fallisce con “unable to locate package”, non improvvisare: verifica con apt-cache search artifactory quali pacchetti sono esposti dal repository configurato e allinea il nome del pacchetto alla release effettiva.

Dopo l’installazione, controlla l’esistenza dell’unità systemd e dei percorsi principali. In genere ti interessano almeno systemctl status, i file di configurazione sotto /var/opt o /opt a seconda del pacchetto, e il log iniziale del servizio. Non dare per scontato che il servizio sia attivo solo perché il pacchetto è stato installato: su sistemi moderni il demone può partire ma restare in errore per memoria insufficiente, porta occupata o permessi errati.

Avvio iniziale e verifica del servizio

Una volta installato, il primo controllo non deve essere il browser ma systemd e i log. Artifactory può sembrare “su” mentre sta ancora inizializzando il motore interno o tenta di collegarsi a dipendenze esterne. Il controllo minimo è questo:

sudo systemctl enable --now artifactory
sudo systemctl status artifactory --no-pager
sudo journalctl -u artifactory -n 100 --no-pager

Se il servizio non sale, guarda prima i motivi banali: porta già occupata, Java non allineato, directory non scrivibili, spazio disco insufficiente. In produzione questi sono più frequenti di qualunque problema “esotico”. Il vantaggio di partire da systemd è che hai un punto di osservazione netto: stato, exit code, ultimi errori e dipendenza da risorse locali.

Per verificare che il processo ascolti davvero sulla porta attesa, usa ss -ltnp | grep -E ':(8081|8040|8082)\b' o la porta effettivamente configurata dalla tua release. Se la porta è aperta ma la UI non risponde, il problema è più in alto: reverse proxy, TLS, routing o inizializzazione applicativa.

Memoria JVM e tuning minimo sensato

Artifactory vive sopra la JVM, quindi la memoria non va lasciata al caso. Se la macchina ha 8 GB di RAM totali, non dare tutto ad Artifactory: il sistema operativo, la cache disco e gli altri processi hanno bisogno di margine. Una configurazione iniziale prudente può stare su 2-4 GB di heap, lasciando spazio al resto del sistema. Su host più generosi puoi salire, ma sempre osservando i sintomi e non per abitudine.

Il punto non è “più heap = meglio”. Se esageri, aumenti i tempi di garbage collection e rischi di peggiorare la latenza percepita. La metrica utile non è solo il consumo medio, ma la stabilità sotto carico: TTFB della UI, tempi di risposta delle API, code di upload e saturazione CPU durante GC. Se hai un carico reale, confronta prima e dopo l’adeguamento della memoria.

Se il pacchetto espone un file di configurazione JVM, cerca qualcosa di simile a /etc/default/artifactory, /var/opt/jfrog/artifactory/etc o un’unità systemd con variabili ambiente. Il contenuto cambia in base all’edizione, quindi il metodo giusto è ispezionare l’unità e i file effettivi:

systemctl cat artifactory
sudo find /etc /var/opt /opt -maxdepth 3 -type f \( -name '*artifactory*' -o -name '*jvm*' \)

Modifica solo dopo backup del file interessato. Se cambi parametri JVM, riavvia e osserva log e tempi di startup. Il rollback deve essere immediato: ripristino del file precedente e nuovo restart del servizio.

Database: quando lasciare il default e quando no

Per un laboratorio o un piccolo uso interno, il database embedded può essere accettabile solo per test rapidi o ambienti non critici. In produzione, invece, la scelta corretta è un database esterno supportato dalla versione di Artifactory che stai installando. Questo riduce il rischio di perdere metadati, semplifica backup coerenti e ti permette di separare il ciclo di vita dell’applicazione da quello del motore dati.

La cosa importante è verificare la matrice di supporto della tua release: non dare per scontato che qualunque PostgreSQL o MySQL “vada bene”. Alcune versioni hanno vincoli precisi su major release, driver e settaggi di connessione. Il controllo pratico è semplice: leggi la documentazione della release, poi confronta la stringa di connessione e i log all’avvio. Se il servizio parte ma i repository falliscono in scrittura, il problema può stare proprio lì.

In caso di database esterno, prepara almeno backup coerenti e monitoraggio di latenza, connessioni e spazio. Se il DB rallenta, Artifactory non degrada in modo elegante: le operazioni di upload, metadata lookup e indicizzazione risentono subito della latenza.

Reverse proxy e HTTPS: esporlo bene, non solo esporlo

Esporre Artifactory direttamente su Internet è una scelta che evita un passaggio, ma introduce più rischio di quanto sembri. Un reverse proxy come Nginx o Apache ti permette di terminare TLS, applicare header corretti, limitare l’accesso con policy di rete e tenere il backend su una porta locale. È la configurazione che preferisco quasi sempre, salvo casi molto particolari.

Con Nginx, il principio è tenere il proxy semplice e far passare i parametri giusti al backend. Serve soprattutto preservare host, protocollo e dimensione massima degli upload. Un esempio minimale, da adattare al tuo dominio e alla porta effettiva del servizio:

server {
    listen 443 ssl http2;
    server_name artifactory.example.com;

    client_max_body_size 0;

    location / {
        proxy_pass http://127.0.0.1:8081;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Host $host;
        proxy_read_timeout 900;
        proxy_send_timeout 900;
    }
}

Se usi certificati Let’s Encrypt o una PKI interna, il controllo da fare dopo il reload non è solo “il lucchetto è verde”. Devi verificare che l’app riconosca correttamente l’URL pubblico, altrimenti genera redirect errati, link assoluti sbagliati e callback non coerenti. Il test pratico è curl -Ik https://artifactory.example.com e il controllo della risposta per 200 o 302 attesi, oltre alla presenza degli header proxy corretti.

Firewall, porte e superficie d’attacco

La regola minima è esporre solo ciò che serve. Se il proxy termina TLS, il backend di Artifactory non deve essere raggiungibile dalla rete esterna. Con UFW o con un firewall di rete, consenti solo le porte necessarie: 443 verso il proxy, eventualmente 80 per il redirect e niente altro in ingresso dal mondo. Il resto resta locale o su segmenti interni controllati.

Controlla anche i permessi sui percorsi dati e sui file di configurazione. Un errore comune è lasciare directory scrivibili da utenti troppo ampi o montare storage con opzioni incoerenti. Prima di aprire il servizio a più utenti, verifica proprietario e gruppo dei path principali con ls -ld e, se necessario, correggi in modo conservativo. Nessuna correzione alla cieca: prima identifichi l’utente con cui gira il servizio, poi applichi il minimo privilegio utile.

Checklist di validazione dopo l’installazione

Quando la macchina risponde, non fermarti alla homepage. La validazione che conta è quella che intercetta i problemi più costosi da scoprire dopo. Esegui almeno questi controlli:

  1. Verifica lo stato del servizio con systemctl is-active artifactory e il risultato deve essere active.
  2. Controlla i log recenti con journalctl -u artifactory -n 50 --no-pager e cerca errori di database, permessi o memoria.
  3. Apri l’URL pubblico con curl -Ik https://artifactory.example.com e conferma codice HTTP e header.
  4. Prova un upload piccolo e un download di un artifact di test per verificare scrittura, lettura e metadata.
  5. Controlla spazio e crescita log con df -h e du -sh /var/log/* sui path pertinenti al tuo layout.

Se uno di questi passi fallisce, non passare subito all’ottimizzazione. Fermati al layer che ha fallito: rete, proxy, applicazione, database o storage. È il modo più veloce per non trasformare un problema localizzato in un audit infinito.

Backup e rollback: quello che serve prima del primo change

Prima di mettere Artifactory in produzione, prepara il rollback. Al minimo devi avere copia dei file di configurazione modificati, snapshot del volume dati e, se usi un database esterno, strategia di backup coerente con il suo motore. Un aggiornamento o un cambio di tuning senza rollback è solo un modo elegante per rimandare il problema.

Per i file locali, conserva una copia datata del contenuto prima di ogni modifica. Per esempio, se tocchi un file di configurazione, fai una copia con timestamp e annota il motivo del change. Per i volumi, usa snapshot se il tuo storage li supporta; per il database, verifica che il backup sia ripristinabile, non solo eseguibile. La differenza tra “abbiamo il backup” e “abbiamo testato il restore” è spesso la differenza tra un fermo breve e un incidente lungo.

Assunzione operativa: i nomi esatti dei pacchetti, dei path e delle variabili JVM possono cambiare tra edizioni e versioni di Artifactory; verifica sempre il pacchetto installato e i file realmente presenti sul sistema prima di applicare tuning o integrazioni.

Sequenza consigliata in ambiente reale

Se vuoi fare le cose senza sorprese, la sequenza che uso è questa: preparo il server, verifico risorse e time sync, installo il repository ufficiale, installo il pacchetto, confermo il servizio con systemd, adatto la JVM solo se i log o il carico lo richiedono, metto un reverse proxy con TLS, poi valido con test di upload e download. Questo ordine riduce il rischio di dover tornare indietro su più livelli contemporaneamente.

Il valore pratico di questa disciplina è semplice: quando qualcosa non torna, sai già se guardare DNS, edge, origin, app, DB o storage. Artifactory non è difficile da installare; è facile, invece, installarlo male e accorgersene solo quando la pipeline si blocca. La differenza la fa il controllo iniziale, non il click finale su “start”.