Ho esportato una versione un po’ vecchia del container Discourse e i file Docker di Discourse da un’istanza in esecuzione e li ho importati su un server diverso.
Ho bisogno di cambiare il nome host di Discourse per farlo corrispondere al nuovo server.
C’è un modo per rendere effettivo il nuovo DISCOURSE_HOSTNAME: senza una ricostruzione?
Se devo ricostruire, questo scaricherà l’ultima versione dal branch main e sovrascriverà la versione corrente che ho? perché ho bisogno di eseguire esattamente la versione corrente.
Dovresti cambiare delle cose nella configurazione di Let’s Encrypt, che è (almeno in parte) il motivo per cui devi ricostruire.
Perché non aggiornare? È quello che devi fare davvero. Quanto è vecchio?
Ma potresti riuscire a bloccare discourse_docker (noto anche come /var/discourse e la versione di Discourse su cui ti trovi. Potrebbe anche essere necessario bloccare tutti i plugin.
Devo avere la stessa versione su quell’istanza per testare l’aggiornamento all’ultima versione, quindi se avrà successo, eseguirò l’aggiornamento in produzione.
Se hai qualcos’altro che gestisce la risoluzione HTTPS, potresti essere in grado di evitare la ricostruzione e fare solo le altre cose in Cambia il nome del dominio o rinomina il tuo Discourse.
HTTPS è gestito su un load balancer, ma quel link dice che devo ricostruire dopo aver modificato app.yml.
Quindi, se fisserò le versioni, per discourse_docker, dovrei effettuare il checkout dell’hash del commit corrente?
E per l’app Discourse all’interno del container, dovrei anche impostare il suo hash del commit corrente usando version: <commit_hash> in app.yml?
È una buona scommessa che se installi la versione corrente sul server di test e ripristini il database su di esso, potrai aggiornare il server di produzione.
Quello che proponi è probabilmente un lavoro di diverse ore, ha un sacco di piccoli pezzi confusi che saranno molto difficili da descrivere in un forum, e non dimostrerà nulla che il ripristino del database di produzione sul nuovo server non farà.
Basta puntare il server di staging e il server di produzione allo stesso bucket di backup S3, eseguire il backup della produzione e ripristinarlo sul server di staging. D’ora in poi, saranno in parità e potrai aggiornare staging e produzione in rapida successione.
Ho attivato una ricompilazione ma ho ottenuto questo:
I, [2023-04-07T19:17:58.707365 #1] INFO -- : cd /var/www/discourse & gem install bundler --conservative -v $(awk '/BUNDLED WITH/ { getline; gsub(/ /,""); print $0 }' Gemfile.lock)
ERROR: Could not find a valid gem 'bundler' (= 2.3.4), here is why:
Unable to download data from https://rubygems.org/ - Net::OpenTimeout: execution expired (https://rubygems.org/specs.4.8.gz)
Tuttavia, posso fare il curl di rubygems.org dall’host.
Sì, il comando di ricostruzione e anche l’aggiornamento avviato dalla GUI hanno dato lo stesso errore.
Tentativo di nuovo del fetcher a causa di errore (4/4): Bundler::HTTPError Impossibile recuperare le specifiche da https://rubygems.org/ a causa di un errore sottostante <Net::OpenTimeout: execution expired (https://rubygems.org/specs.4.8.gz)>
Si è verificato un errore durante l'installazione della versione bloccata di bundler (2.4.4), riesegui con il flag `--verbose` per maggiori dettagli. Continua a utilizzare bundler 2.3.6.
Recupero dell'indice delle origini da https://rubygems.org/
Impossibile recuperare le specifiche da https://rubygems.org/ a causa di un errore sottostante
<Net::OpenTimeout: execution expired (https://rubygems.org/specs.4.8.gz)>
Docker Manager: AGGIORNAMENTO FALLITO
