Salta ai contenuti
Sirio è in beta privata: sorgenti e installer vengono inviati via email a chi la prova. Chiedi di partecipare.

Aggiornamento delle immagini dei container

Sirio segnala quali container usano un’immagine più vecchia di quella a cui punta ora il loro tag sul registry, e li aggiorna dal pannello: scarica l’immagine e ricrea il container su di essa, mantenendo configurazione, volumi, reti e override. Non aggiorna mai nulla da solo.

Tutti i container, ogni 6 ore (il primo controllo parte un minuto dopo l’avvio di Sirio), oppure quando premi Controlla ora nella pagina Container (sezione Docker) o nel dettaglio di un container (scheda Configurazione). Per ogni riferimento distinto, come nginx:1.27, Sirio chiede al registry, tramite il daemon Docker, a quale digest punta ora il tag, e lo confronta con l’immagine che il container usa. Viene letto solo il manifest, mai i layer. Valgono le impostazioni del daemon per i registry (mirror, proxy, registry insicuri).

Un container mostra uno di questi stati:

Stato Significato
Aggiornato il container usa l’immagine a cui punta il suo tag
Aggiornamento disponibile il tag è andato avanti: il registry ha un’immagine più recente
Controllo non riuscito il registry non ha risposto, o ha rifiutato: l’errore dice perché
Non ancora controllato creato o ricreato dopo l’ultimo controllo
Non controllato uno dei casi qui sotto

Alcuni container non vengono mai controllati né aggiornati, di proposito:

  • I container distribuiti da una repository, cioè i progetti Compose avviati dal checkout di una pipeline. Il compose file appartiene alla repository, quindi quale immagine usano lo decidono la repository e la sua pipeline. Sirio non li tocca.
  • Le immagini fissate a un digest (nginx@sha256:…): non cambiano mai.
  • Le immagini costruite o caricate sull’host, o i container creati da un ID di immagine: non c’è un registry a cui chiedere.

Sirio non invia credenziali ai registry, quindi un registry privato mostra “Controllo non riuscito”. Le richieste anonime a Docker Hub hanno un limite per indirizzo IP, e i pull contano nello stesso limite. Il controllo fa una richiesta per riferimento, non per container, ogni 6 ore.

I container con un’immagine più recente hanno il badge aggiornamento nella lista e un avviso nel dettaglio. Entrambi aprono la finestra di aggiornamento. Serve il permesso containers.edit sul sito del container, o sulla sezione Docker per un container che non appartiene a nessun sito.

  1. Backup, facoltativo. Se il container appartiene a un sito con un piano di backup, e tu puoi eseguirlo (backups.run), puoi scegliere un piano da eseguire prima. Se il backup fallisce, il container resta com’è. L’esecuzione compare nello storico del piano con l’origine “aggiornamento immagine”.

  2. Pull. Docker scarica di nuovo l’immagine con lo stesso riferimento.

  3. Ricreazione. Se il pull ha portato un’immagine diversa:

    • Un container semplice viene ricreato dalla sua configurazione. Alla creazione Docker unisce alla configurazione del container i valori predefiniti dell’immagine (PATH, variabili di versione, CMD, label, healthcheck). Per questo Sirio prima toglie quello che coincide ancora con i valori della vecchia immagine, e li fornisce la nuova. Le impostazioni proprie del container restano. Il vecchio container viene rinominato e rimesso al suo posto se il nuovo non si crea o non parte.
    • Un container gestito da Compose viene ricreato da Docker Compose (up --force-recreate --no-deps) dal suo compose file e dal .env, come con “Ricarica variabili”. Compose gira con l’utente di Sirio, che deve poter leggere i file del progetto.

    In entrambi i casi gli override di ambiente e porte vengono riapplicati. Se il pull non ha portato nulla di nuovo, non viene ricreato nulla.

L’intero aggiornamento tiene il lock del sito, quindi aspetta che finisca un deploy o un backup dello stesso sito, e loro a loro volta aspettano lui. Una volta partito arriva fino in fondo anche se chiudi la pagina: il pannello potrebbe essere servito proprio dal proxy che si sta aggiornando. La vecchia immagine resta sull’host, senza tag. Eliminala da Immagini quando la nuova ti convince.

Ogni aggiornamento finisce nel registro attività come docker.container.image_update.

SIRIO_IMAGE_UPDATES_ENABLED=false ferma i controlli e toglie badge e azione di aggiornamento.