È possibile aggiornare alla versione più recente senza ricostruire l’intera cosa?
Sto pensando a uno scenario in cui due applicazioni Discourse sono virtualmente identiche e una volta che ho una nuova immagine pronta - da una delle due - potrei usarla per distribuire la seconda istanza Discourse, avendo tutta la configurazione/i parametri per il container.
Immagino che l’unica cosa che rimarrebbe da gestire per un tale container sia la migrazione del database pg?
Ha senso e, se possibile, come si fa, idealmente senza modificare alcun codice sorgente?
È possibile creare un’immagine, caricarla in un repository e quindi avviarla usando ./launcher start-cmd app per ottenere il comando docker per avviare il container (ma sostituirai il tuo repository di container con quello locale).
Eppure, poi devi migrare il database, precompilare gli asset e così via.
Se è il tempo di inattività che vuoi evitare, la configurazione a due container ti consente di creare un nuovo container mentre quello vecchio continua a funzionare e quindi gestisce le migrazioni e simili.
Se vuoi essere più cauto, puoi impostare SKIP_POST_DEPLOYMENT_MIGRATIONS nel tuo app.yml e quindi eseguire rake db:ensure_post_migrations db:migrate dopo l’avvio del nuovo container. Non farlo può migrare il database in modo tale che il vecchio container non possa più utilizzarlo. Non è spesso un problema, e poi, non per molto tempo.
Due applicazioni a cui penso sarebbero virtualmente identiche, ma non uguali.
Due app sarebbero siti diversi, il che significa database, volumi, porte, nomi diversi… ma avrebbero lo stesso, per così dire, discorso di base (+ stessi plugin, stessa qualsiasi cosa possa essere critica per quel nucleo/base).
Nel mondo ideale di Discourse - se tale non esiste ancora - per uno scenario del genere, una nuova immagine una volta costruita per la prima volta/una volta, potrebbe essere utilizzata anche direttamente con gli strumenti docker - e il DB o qualsiasi cosa debba essere “migrata” a tale nuova immagine/versione di Discourse, il processo di avvio di tale container “secondario” deciderebbe - forse con l’aiuto delle variabili d’ambiente - di controllare/eseguire le migrazioni necessarie dei DB.
Il vantaggio principale - a cui molti devono già aver pensato - è un’unica immagine per entrambi (o molti di più se alcune persone lo fanno) container/app.
Puoi farlo come ho descritto. C’è anche un nuovo schema in fase di sviluppo che rende possibile usare una singola immagine e non ricostruire. Non è supportato, quindi dovrai cercare bene qui o su github.