Questo è un po’ il punto della configurazione sopra; è molto utile avere il server di staging che punta allo stesso bucket, poiché ciò rende molto più facile mantenerli sincronizzati.
Tuttavia, non vuoi che contribuisca automaticamente con alcun backup (o ne elimini alcuno), da cui il motivo per cui sono disattivati da queste impostazioni:
Concordo sul fatto che la CDN debba essere disattivata per il tuo sito di staging. Non ci ho ancora messo mano, ma una volta che avrai capito come farlo, aggiorna/aggiungi la wiki nell’OP.
Grazie, Nathan. Ho visto un accenno ai backup di S3 che rendevano le cose più facili, ma un backup è diverso dagli asset del sito, quindi non ero sicuro.
Ho già disattivato i backup e le email, quindi tutto a posto lì. Mi occuperò di puntare il server di staging al bucket esistente e mi assicurerò che non utilizzi la CDN.
Ho intenzione di creare uno specchio della mia produzione Discourse utilizzando il metodo rsync.
Ho un paio di altri siti web che si integrano con Discourse, quindi avere le versioni dev/test di quei siti in grado di raggiungere e interagire con una versione dev/test/staging di Discourse sarebbe ideale.
Pertanto lo accenderei solo quando necessario, e ripristinerei periodicamente un backup del database del mio PROD sul mio STAGING - non giornalmente e forse anche solo una volta al mese.
Se lo faccio, come posso impedire che alcune impostazioni vengano ripristinate quando faccio il ripristino del database?
Questi, per esempio, sarebbero inestimabili:
C’è un modo per ripristinare un backup del database e poi applicare manualmente alcune impostazioni prima di avviare Discourse? Altre idee, suggerimenti, insidie?
Se mantieni i backup su S3 e li configuri tramite variabili d’ambiente, puoi creare abbastanza facilmente un nuovo sito in grado di ripristinare quel backup. Basta avviare una nuova VM, clonare discourse, copiare lo yml, ricostruire e ripristinare. Puoi sovrascrivere le impostazioni nel database con variabili d’ambiente come nella citazione nel tuo post.
Mi manca un passaggio? Sono abbastanza sicuro che questo abbia funzionato circa un anno fa. Ma ora, anche se si popola, non aggiunge argomenti o post oltre alla sezione Informazioni della categoria… è cambiato qualcosa?
Ho finito per ripristinare un vecchio backup da una delle mie istanze di discourse in cui avevo precedentemente utilizzato questo metodo per popolare. Ho dovuto fare questo, ma ha funzionato.
C’è una cosa che devi fare per poter eliminare il database. Se esegui l’attività rake db:drop, ti dirà di cosa si tratta. Quindi immagino che dovresti eseguire sv stop unicorn e poi eliminare, creare ed eseguire la migrazione del database prima di eseguire l’attività. O questa è la prossima cosa che proverei, ma tu hai un’altra soluzione…
Sto cercando di popolare dati di test sul mio server di staging, ma ricevo un errore:
rake aborted!
I comandi del database sono supportati solo nell'ambiente di sviluppo
Questo avviene su una configurazione multisito, quindi i comandi che sto eseguendo sono:
./launcher enter web_only
ALLOW_DEV_POPULATE=1 bundle install
RAILS_DB=instance-x ALLOW_DEV_POPULATE=1 rake dev:populate
Che ho usato senza problemi finora, ma ora ricevo questo errore. Posso impostare una variabile d’ambiente per consentire i comandi del database in produzione?
