J’ai exporté une ancienne version du conteneur Discourse et les fichiers Docker de Discourse d’une instance en cours d’exécution et je les ai importés sur un serveur différent.
Je dois changer le nom d’hôte de Discourse pour qu’il corresponde au nouveau serveur.
Y a-t-il un moyen de rendre le nouveau DISCOURSE_HOSTNAME: effectif sans reconstruction ?
Si je dois reconstruire, cela récupérera-t-il la dernière version de la branche main et remplacera-t-il la version actuelle que j’ai ? car j’ai besoin d’exécuter exactement la version actuelle.
Vous devrez modifier des éléments dans la configuration de Let’s Encrypt, ce qui est (au moins en partie) la raison pour laquelle vous devez reconstruire.
Pourquoi ne pas mettre à niveau ? C’est ce que vous devez vraiment faire. Quel âge a-t-il ?
Mais vous pourriez faire en sorte d’épingler discourse_docker (alias /var/discourse et la version de Discourse sur laquelle vous êtes. Vous pourriez également avoir besoin d’épingler tous les plugins.
Si vous avez autre chose qui gère la résolution https, vous pourriez peut-être éviter la reconstruction et faire simplement les autres choses dans Change the domain name or rename your Discourse.
Je dois avoir la même version sur cette instance pour tester la mise à niveau vers la dernière version afin que si elle réussit, je procède à la mise à niveau en production.
Si vous avez autre chose qui gère la résolution https, vous pourriez éviter la reconstruction et faire le reste dans Changer le nom de domaine ou renommer votre Discourse.
HTTPS est géré sur un équilibreur de charge, mais ce lien dit que je dois reconstruire après avoir modifié app.yml.
Donc, si je fixe les versions, pour discourse_docker, je devrais extraire le hash de commit actuel ?
Et pour l’application Discourse à l’intérieur du conteneur, je devrais également définir son hash de commit actuel en utilisant version: <hash_de_commit> dans app.yml ?
Il est fort probable que si vous installez la version actuelle sur le serveur de test et que vous y restaurez la base de données, vous pourrez mettre à niveau le serveur de production.
Ce que vous proposez représente probablement plusieurs heures de travail, comporte un tas de petits détails confus qu’il sera très difficile de décrire sur un forum, et ne prouvera rien que la restauration de la base de données de production sur le nouveau serveur ne fera pas.
Pointez simplement le serveur de staging et le serveur de production vers le même bucket de sauvegarde S3, sauvegardez la production et restaurez-la sur le serveur de staging. À l’avenir, ils seront en parité et vous pourrez mettre à niveau staging et production en succession rapide.
J’ai déclenché une reconstruction mais voici ce que j’ai obtenu :
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)
Cependant, je peux faire un curl vers rubygems.org depuis l’hôte.
Oui, la commande de reconstruction et la mise à niveau initiée depuis l’interface graphique ont donné la même erreur.
Tentative de récupération du fetcher en raison d'une erreur (4/4) : Bundler::HTTPError Impossible de récupérer les spécifications depuis https://rubygems.org/ en raison d'une erreur sous-jacente <Net::OpenTimeout: execution expired (https://rubygems.org/specs.4.8.gz)>
Une erreur s'est produite lors de l'installation de la version verrouillée de bundler (2.4.4), relancez avec le drapeau --verbose pour plus de détails. Utilisation continue de bundler 2.3.6.
Récupération de l'index source depuis https://rubygems.org/
Impossible de récupérer les spécifications depuis https://rubygems.org/ en raison d'une erreur sous-jacente
<Net::OpenTimeout: execution expired (https://rubygems.org/specs.4.8.gz)>
Docker Manager : ÉCHEC DE LA MISE À NIVEAU
