Come scegliere e verificare un’immagine Ubuntu per VPS

Definisci la compatibilità prima di creare la macchina

Elenca versioni Ubuntu, runtime e database supportati. Includi estensioni, immagini container, agenti di backup e monitoraggio. Distingui il supporto dichiarato dal produttore dalle verifiche svolte dal tuo gruppo.

1. Registra i requisiti di ogni componente.
2. Controlla la build richiesta da estensioni native, container e strumenti di recupero.
3. Restringi le versioni compatibili in base alla manutenzione residua.
4. Verifica immagine e architettura nella regione del provider.
5. Dopo la creazione esegui i controlli e prova l’applicazione prima di spostare dati o traffico.

Ubuntu 24.04 LTS è un esempio concreto: il rilascio ha introdotto Python 3.12 come predefinito, PHP 8.3 e PostgreSQL 16. Le versioni correttive cambiano con gli aggiornamenti. La compatibilità con versioni maggiori precedenti non implica compatibilità con queste. La tabella LTS riguarda il calendario; qui verifichi il tuo software.

Identifica il sistema ricevuto

Esegui questi comandi in sola lettura dentro il VPS e salva distribuzione, kernel in esecuzione e architetture prima di installare altro.

cat /etc/os-release
uname -r
dpkg --print-architecture
uname -m

Scorri la tabella per vedere le altre colonne →

Il kernel da solo non identifica rilascio o copertura di supporto. Un provider può usare kernel cloud specifici. Per un binario solo amd64 serve una build Arm o un’alternativa esplicitamente supportata, non l’ipotesi che giri nativamente su arm64.

Verifica l’inizializzazione dell’immagine

Molte immagini usano cloud-init per utenti, chiavi e rete. Verifica che esista prima di leggerne lo stato; l’assenza non è da sola un guasto, perché il provider può usare un altro metodo.

if command -v cloud-init >/dev/null 2>&1; then
    cloud-init status --long
else
    printf '%s\n' 'cloud-init non è installato; verifica il metodo di inizializzazione del provider.'
fi

Uno stato running indica un’inizializzazione ancora in corso. Error o degraded vanno investigati anche se SSH risponde. Se cloud-init è presente, leggi i log pertinenti.

sudo tail -n 50 /var/log/cloud-init.log
sudo tail -n 50 /var/log/cloud-init-output.log

Gli script di inizializzazione possono stampare segreti: rimuovili prima di condividere i log. Non usare cloud-init clean e non sostituire file di rete per nascondere un errore. La preparazione completata non dimostra la salute di applicazione, database e job di backup.

Esamina i pacchetti candidati

Aggiorna i metadati e controlla le versioni candidate dei componenti previsti. apt update aggiorna l’indice senza installare i pacchetti applicativi elencati. Registra versioni e repository.

sudo apt update
apt-cache policy python3 php postgresql
apt-cache policy python3.12 php8.3 postgresql-16

Installed: (none) significa che il pacchetto non è installato; Candidate: (none) che le fonti attuali non lo offrono. Controlla prima nome, architettura e componenti Ubuntu configurati, senza aggiungere un repository casuale.

I metapacchetti php e postgresql selezionano un’implementazione predefinita: controlla anche il pacchetto con versione. Per software già installato verifica eseguibile o servizio reale. python3 --version e php --version descrivono quegli eseguibili; i client di un database possono differire dal server.

Risolvi separatamente i vincoli di runtime e architettura

Supponi che un’applicazione richieda Python 3.10 e distribuisca un’estensione nativa solo amd64. Sono requisiti ipotetici. Un’immagine Ubuntu 24.04 arm64 predefinita non supera due controlli: Python è 3.12 e l’estensione ha un’altra architettura.

Passare ad amd64 risolve solo l’architettura. Un ambiente virtuale Python isola pacchetti con l’interprete che lo ha creato; non trasforma 3.12 in 3.10. Non sostituire il Python di sistema Ubuntu per adattarlo all’applicazione.

Puoi aggiornare l’applicazione o scegliere un runtime/container mantenuto separatamente con un piano di supporto. Verifica tutti i componenti nativi. Una Ubuntu più vecchia ha una propria finestra residua e non è una soluzione automatica.

In staging esercita l’estensione, un’operazione sul database, un job e un ciclo di backup/ripristino. Salva versioni e build. Un’installazione completata o una homepage che risponde non bastano.

Assegna la manutenzione di ogni livello

I container separano le dipendenze ma dipendono da kernel, storage e rete dell’host. Cerca una build supportata per la piattaforma. L’emulazione modifica prestazioni e supporto: non sostituirla silenziosamente a una build nativa.

Persisti i dati in volumi documentati o storage esterno e provane il recupero indipendentemente dai container. Fissa release o digest per riprodurre l’ambiente, pianificando gli aggiornamenti: un’immagine vulnerabile fissata per sempre rimane vulnerabile.

Distingui supporto del rilascio e copertura dei singoli pacchetti. Manutenzione standard e Ubuntu Pro hanno coperture diverse; repository esterni, binari e container hanno propri manutentori. Indica chi aggiorna ciascun livello.

Separa aggiornamenti ordinari e cambio di rilascio

Prima delle modifiche aggiorna i metadati, controlla pacchetti pendenti e servizi falliti. Questi comandi raccolgono informazioni, non avviano un avanzamento di distribuzione.

apt list --upgradable
systemctl --failed
if [ -f /var/run/reboot-required ]; then cat /var/run/reboot-required; fi

Applica gli aggiornamenti in una finestra adatta e ripeti i controlli dell’applicazione: i servizi possono riavviarsi. L’indicatore di riavvio è utile quando presente, ma la sua assenza non prova che ogni componente sia aggiornato.

Prova il cambio di rilascio su una copia o una macchina nuova. Rivedi runtime, repository, migrazione del database ed estensioni. Pianifica sincronizzazione finale e ritorno che consideri le scritture successive: uno snapshot precedente non contiene gli ordini arrivati dopo.

Lascia una scheda di configurazione ripetibile

Scorri la tabella per vedere le altre colonne →

Tieni i segreti fuori dalla scheda e versiona la configurazione non riservata. Ricostruisci separatamente quando cambiano dipendenze importanti. Per una prova pubblica segui la creazione della VM Oracle; quando l’immagine è adatta passa alla prima pubblicazione.

Domande e risposte