Atualmente estou no processo de migrar nosso servidor de uma implantação existente baseada em Bitnami (uma versão bem antiga) para a instalação oficialmente suportada na AWS usando a versão mais recente do Discourse. Esta nova instalação possui instâncias externas do Elasticache e RDS e também usará o S3 para backups e uploads.
Tenho 2 perguntas:
O servidor Discourse antigo está em uma versão bem antiga - ao fazer o backup/restauração no novo servidor Discourse, isso executará todos os comandos de atualização relevantes?
Se eu copiar o arquivo de backup para o novo contêiner Docker do Discourse no novo servidor e iniciar a restauração na linha de comando, os novos valores de bucket que configurei no meu config serão sobrescritos como parte da restauração ou meus novos valores serão usados? Eu presumo que meu novo banco de dados seja preenchido a partir do backup e, em seguida, quando eu sair do contêiner e executar ./launcher rebuild app, meus novos valores de S3 serão usados.
Se minhas suposições estiverem corretas, então, antes de realizar a restauração, presumo que devo copiar o conteúdo dos buckets S3 antigos para os novos?
Existem outras pegadinhas para fazer esse tipo de migração com um backup?
Talvez eu esteja perdendo algo, mas por que vocês estão estabelecendo novos buckets? Um novo bucket de backup com regras de ciclo de vida apropriadas parece aceitável, mas se a sua instância existente do Discourse estiver usando o bucket de upload do S3, você terá alguns problemas.
Não tenho 100% de certeza de que a migração do Bitnami funcionará sem problemas, então não queremos impactar nenhum dado existente caso precisemos abortar a migração
Mudamos a nomenclatura dos nossos buckets, então pensei que seria mais fácil ter 2 buckets totalmente novos para isso
O ponto 1 é o que me preocupa, então estou apenas sendo extra cauteloso.
Quais problemas você prevê com o novo bucket de uploads? O servidor antigo do Discourse será colocado em modo somente leitura. O plano é que, assim que o novo servidor estiver ativo e validado, desligaremos nosso servidor antigo, alteraremos o DNS para o novo servidor e, em seguida, limparemos o cache no CDN (Cloudfront) e depois o liberaremos para o público.
Eu não percebi que você iria copiar os dados dos buckets antigos. Dei uma olhada na AWS, parece ser simples. Se fosse eu, não mexeria em mudar os buckets antes de migrar para a AWS ou para um novo servidor em outro lugar.
[quote=“stevejr, post:1, topic:395948”]para a instalação oficialmente suportada na AWS usando a versão mais recente do Discourse.
[/quote]
Oficialmente suportada?? Não tenho tanta certeza sobre isso.
Sugiro fortemente que você atualize o Discourse antes de migrar para um novo servidor.
Na instância antiga, sugiro que você mova a configuração do S3 para o app.yml se ainda não estiver lá, antes de mover.
Estou muito curioso sobre como fazer esse tipo de instalação é uma proposta de valor agregado.
Com base nas inúmeras postagens sobre instalações não suportadas, parece que dá mais trabalho do que benefício, a menos que as pessoas as façam para aprendizado/experimentação.
Tal configuração pode ser uma instalação não suportada do ponto de vista do Discourse, mas da perspectiva de uma organização de TI corporativa, RDS e Elasticache podem ser padrão e a instalação padrão do Discourse seria a exceção.
Conforme mencionado por @RGJ, nossa infraestrutura empresarial usa serviços externos para coisas como cache, banco de dados, etc., daí o Elasticache e o RDS. Isso significa que podemos ter backup completo e redundância para esses serviços e também ajudar com os controles de segurança. Esta é uma instalação oficial/suportada do ponto de vista do Discourse - está apenas usando um conjunto diferente de modelos - usamos discourse_docker/samples/web_only.yml at main · discourse/discourse_docker · GitHub (talvez usar a palavra padrão tenha sido um pouco enganoso, desculpe).
Então, parece que devemos primeiro atualizar nossos nomes de bucket para a instalação existente e depois realizar a migração para o novo servidor. Atualizar a instalação existente para a versão mais recente é inviável - tivemos problemas com a atualização do Bitnami anteriormente, daí a mudança para o método de instalação oficial.
Posso perguntar, no entanto, que problemas provavelmente ocorrerão se realizarmos a restauração com os buckets existentes e depois atualizarmos o app.yml para referenciar os novos buckets - todas as variáveis de ambiente DISCOURSE_ não têm precedência sobre qualquer configuração no banco de dados (se aplicável)? Ou há algo mais que possa causar um problema?
Porque se você fizer isso antes da migração e as coisas derem errado, você terá o problema na instância Bitnami mais antiga em vez da sua instância padrão recém-instalada. E, além da versão antiga, até mesmo a menção da palavra Bitnami fará com que você receba muito, muito menos suporte aqui no meta.
Mais uma pergunta, se me permite: quando eu executo a restauração a partir da linha de comando dentro do contêiner do Discourse, ele usa a configuração existente em /var/www/discourse/config/discourse.conf para os detalhes sobre a conexão com o banco de dados, conexão com o Redis, etc., ou ele sobrescreve essa configuração com o que está no arquivo de backup?
discourse.conf é gerado a partir de app.yml, não está incluído no arquivo de backup.
Geralmente, o que está em discourse.conf substitui as configurações do site.
Portanto, se você tiver setting_foo no seu banco de dados, poderá substituí-lo definindo DISCOURSE_SETTING_FOO em seu app.yml, o que gerará setting_foo em discourse.conf.
Apontar um contêiner do Discourse para um servidor postgresql e redis externo usando nossa imagem de contêiner com nossas ferramentas é uma instalação suportada.
RDS[1] é Postgresql, e Elasticache é Redis, isso está bom.
Isso deve funcionar bem, fazemos isso para pessoas que estão migrando para nossa hospedagem.
Minha preferência é manter o processo o mais simples possível, então, se você puder executar um backup completo (incluindo uploads) no servidor antigo e restaurá-lo no novo, isso permitirá que você teste totalmente a nova configuração sem nenhum impacto na antiga.
Farei o backup/restauração sem alterar os nomes dos buckets, conforme sugerido também por @RGJ. Como eu disse, minha preocupação era não impactar os dados existentes do servidor de forma alguma, mas se eu fizer o backup dos buckets existentes primeiro e garantir que o servidor existente esteja em modo Somente Leitura durante a migração, acho que a integridade dos dados enviados nos buckets estará muito bem protegida.
