Sto per aggiornare il nostro server di produzione Discourse (che ospitiamo autonomamente su EC2 seguendo le istruzioni ufficiali di installazione) e vorrei confermare l’approccio consigliato.
Non abbiamo il pulsante di aggiornamento abilitato nell’interfaccia utente, quindi l’operazione verrà eseguita direttamente sull’istanza EC2. Credo che ci siano due modi principali per farlo:
Ricreare il nostro server EC2, che preleverà una copia fresca del repository GitHub discourse_docker e utilizzerà i modelli presenti, ad esempio web.template.yml fa attualmente riferimento all’immagine di base discourse/base:2.0.20260209-1300. Questo approccio rimuoverà il server attualmente in esecuzione e avvierà quello nuovo.
Accedere al server EC2 esistente ed eseguire i seguenti comandi per ricreare l’immagine corrente e riavviare il contenitore:
./launcher rebuild app
Ho due domande:
Quale approccio dovrebbe essere utilizzato per la manutenzione ordinaria?
Se eseguiamo il comando rebuild app, viene comunque prelevato il ramo main del repository discourse_docker?
Ho letto il sito https://releases.discourse.org e posso vedere che la versione 2026.3.0 non è ancora stata rilasciata. La mia comprensione è che non dovremmo utilizzare le ultime versioni del ramo main di un rilascio in produzione, poiché sono ancora in fase di sviluppo attivo.
Se desideri aggiornare all’ultima versione, è sufficiente eseguire manualmente l’aggiornamento dal pannello di amministrazione.
Se desideri aggiornare alla versione esr, specifica semplicemente esr alla fine di containers/app.yml.
Quindi, impostando la versione come esr, questo sovrascrive l’immagine di base utilizzata nei modelli?
Non vogliamo che l’aggiornamento sia abilitato nell’interfaccia di amministrazione, quindi avremo bisogno di un modo per farlo nell’istanza o semplicemente ricostruendo l’istanza e lasciando che il nostro AutoScaler la gestisca.
Se utilizziamo esr, come viene aggiornato quando viene applicata una correzione critica? Ancora una volta, dobbiamo semplicemente ricostruire tramite launcher/una nuova istanza EC2 su base mensile per incorporare eventuali aggiornamenti alla versione esr?
Hai letto Understanding Discourse release channels e Configure a supported tracking branch to get Discourse software updates? Descriverei la differenza più come avere accesso alle ultime modifiche immediatamente o riceverle con un po’ di ritardo. Quest’ultimo può essere molto utile per sviluppi personalizzati che devono essere adattati prima. Altrimenti, preferirei l’accesso alle ultime funzionalità e correzioni. Naturalmente, questo comporta il rischio di nuovi bug, ma anche la versione congelata tre settimane fa contiene bug che potrebbero essere già stati risolti nella versione più recente, ma solitamente non sono significativi al punto da giustificare il backporting all’ultima release.
Tieni inoltre presente che il downgrade non è supportato; quindi, se sei su una versione successiva all’ESR corrente, devi attendere la pubblicazione della prossima ESR.
Se attualmente stai utilizzando una versione significativamente obsoleta, potresti trarre beneficio dall’eseguire un git pull prima del comando del launcher.