Un’organizzazione no profit con cui collaboro ha un’installazione Discourse 2.9.0.beta1, la cui manutenzione è ricaduta su di me quando l’amministratore originale si è dimesso. Quando ho provato ad aggiornare le credenziali SMTP, ho scoperto che l’installazione non può né ricostruirsi né aggiornarsi in sicurezza, né tramite web né tramite riga di comando. (Se non avessi avuto un backup “hot” dell’istanza fatto prima dell’inizio del lavoro, questo sarebbe stato un brutto momento.) Il problema sembra verificarsi abbastanza in profondità in Ruby e posso catturare i log se dovessero sembrare utili.
Ho pensato che potesse essere semplicemente troppo vecchio per aggiornarsi con grazia, quindi ho provato invece un processo di ripristino, creando una nuova istanza Discourse fresca e poi caricandovi il backup più recente del forum, ma anche questo processo è fallito in modo inconcludente, con quelli che credo fossero errori di colonne del database prima che il processo di aggiornamento diventasse non responsivo.
Quale sarebbe il modo migliore per procedere da dove ci troviamo? Il forum è attualmente funzionante in questo momento, ma non posso né aggiornarlo né, apparentemente, utilizzare un backup. Dovrei continuare a provare il ripristino, dovrei raddoppiare i miei sforzi per aggiornare e catturare i log per iniziare, o c’è una terza opzione che non vedo?
Devi spostarti su una nuova macchina virtuale. È probabile che il tuo sistema operativo sia troppo vecchio per aggiornare Docker a una versione supportata.
È meglio spostarsi su una nuova VM che si troverà su hardware più recente, più veloce ed economico.
Il versionamento di Docker non sembrava giocare un ruolo nel motivo per cui le build Ruby sono fallite, ma suppongo sia possibile. I pull di Docker che facevano parte della ricostruzione non sembravano avere stati di errore eccezionali. Questo sembra che io possa provarlo, comunque. Grazie per la risposta!
La tua migrazione è stata complicata un po’ di più dal fatto che avevi i backup su S3 configurati nel database anziché nelle variabili d’ambiente come descritto in Configurare un provider di object storage compatibile con S3 per i caricamenti (anche se quello è per i caricamenti, quindi non dovresti usare l’impostazione use_s3, solo il bucket e la posizione di backup. MODIFICA: E poi il ripristino è fallito perché la tua EC2 non ha accesso in scrittura al bucket.
Avere un load balancer davanti al tuo sito cambia anche le cose rispetto a come sono per la maggior parte delle persone.
E poiché le tue credenziali sono per la EC2 anziché averle nel database o nel file YML, il ripristino non può essere completato.