Eu exportei uma versão um pouco antiga do container do Discourse e os arquivos docker do Discourse de uma instância em execução e os importei em um servidor diferente.
Preciso alterar o DISCOURSE_HOSTNAME: para corresponder ao novo servidor.
Existe uma maneira de tornar o novo DISCOURSE_HOSTNAME: eficaz sem uma reconstrução?
Se eu precisar reconstruir, isso buscará a versão mais recente do branch main e substituirá a versão atual que tenho? porque preciso executar exatamente a versão atual.
Você precisaria alterar coisas na configuração do Let’s Encrypt, que é (pelo menos em parte) o motivo pelo qual você precisa reconstruir.
Por que não atualizar? É isso que você realmente precisa fazer. Quão antigo ele é?
Mas você poderia se arranjar para fixar discourse_docker (também conhecido como /var/discourse e a versão do Discourse em que você está. Você também pode precisar fixar todos os plugins.
Preciso ter a mesma versão naquela instância para testar a atualização para a versão mais recente, para que, se for bem-sucedido, realizarei a atualização em produção.
Se você tem outra coisa fazendo a resolução https, talvez consiga evitar a reconstrução e apenas fazer as outras coisas em Alterar o nome do domínio ou renomear seu Discourse.
O HTTPS é tratado em um balanceador de carga, mas esse link diz que preciso reconstruir após modificar o app.yml.
Então, se eu fixar as versões, para discourse_docker, devo fazer o checkout do hash de commit atual?
E para o aplicativo Discourse dentro do contêiner, também devo definir seu hash de commit atual usando version: <hash_de_commit> em app.yml?
É uma boa aposta que, se você instalar a versão atual no servidor de teste e restaurar o banco de dados nele, poderá atualizar o servidor de produção.
O que você está propondo provavelmente levará várias horas de trabalho, tem um monte de pequenas partes confusas que serão muito difíceis de descrever em um fórum, e não provará nada que restaurar o banco de dados de produção para o novo servidor não fará.
Apenas aponte o servidor de staging e o servidor de produção para o mesmo bucket de backup S3, faça backup da produção e restaure-o no servidor de staging. Daqui para frente, eles estarão em paridade e você poderá atualizar o staging e a produção em rápida sucessão.
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)
No entanto, consigo fazer curl em rubygems.org a partir do host.
Sim, o comando de reconstrução e também a atualização iniciada pela GUI deram o mesmo erro.
Retentando o fetcher devido a erro (4/4): Bundler::HTTPError Não foi possível buscar especificações de https://rubygems.org/ devido a erro subjacente <Net::OpenTimeout: execution expired (https://rubygems.org/specs.4.8.gz)>
Ocorreu um erro ao instalar a versão bloqueada do bundler (2.4.4), execute novamente com a flag --verbose para mais detalhes. Continuando a usar o bundler 2.3.6.
Buscando índice de origem de https://rubygems.org/
Não foi possível buscar especificações de https://rubygems.org/ devido a erro subjacente
<Net::OpenTimeout: execution expired (https://rubygems.org/specs.4.8.gz)>
Docker Manager: FALHA AO ATUALIZAR
