Mudei o nome porque não posso desligar o servidor original por horas, até testar que tudo está funcionando corretamente e trocar os servidores.
Você não precisa. Se você tiver um certificado curinga, basta fazer alterações locais no DNS via arquivo Hosts para configurar tudo e restaurar o backup em si.
Depois, basta ativar o DNS publicamente.
Não entendo o que você quer dizer.
Preciso manter o a.domain.com no ar enquanto faço os testes.
E preciso acessar a interface do Discourse da cópia que estou restaurando para verificar se tudo está correto.
Portanto, preciso de outro URL para acessar a cópia no outro servidor.
Então, simplesmente altero o nome do host no Discourse e no Nginx após a restauração.
Quando tudo estiver OK, altero o nome no novo servidor para a.domain.com, desligo o servidor antigo e aponto o DNS de a.domain.com para o novo servidor.
O acima não está correto. Você pode forçar sua máquina local a se conectar ao novo servidor usando o mesmo nome DNS, seja alterando o arquivo HOSTS no seu computador local ou inserindo manualmente uma entrada no seu DNS local.
Não tenho uma máquina local.
Ambos os servidores estão na internet ou são servidores em nuvem.
Uso SSH a partir de uma máquina Windows.
Talvez eu possa pegar o nome do host local para definir o IP da máquina, mas é mais complexo do que alterar o nome nos servidores.
Você acha que uma alteração no nome do host pode ser o problema?
Não deveria ser um problema…
Sim, começamos a ver esse problema de avatar personalizado novamente muito depois que o processo sidekiq teve tempo de reconstruir qualquer imagem de avatar e perfil adjacente, mas apenas na configuração com o proxy reverso nginx para um socket de domínio Unix.
Os ícones pequenos dos avatares estão corretos; mas eles não funcionam no cartão de perfil ou nas páginas de perfil (a menos que tenham sido armazenados em cache antes e o cache não tenha expirado).
Assim que fazemos o seguinte:
nginx -s stop; ./launcher start web-only
O problema com as imagens de avatar personalizado desaparece (em imagens não visualizadas anteriormente / armazenadas em cache no navegador).
E assim que fazemos o seguinte logo depois:
./launcher stop web-only; nginx
O problema com as imagens de avatar personalizado retorna para imagens ainda não visualizadas / armazenadas em cache.
Não há erros com HTTPS e isso definitivamente não é devido ao force_https (totalmente sem relação):
discourse=# select * from site_settings where name like '%http%';
id | name | data_type | value | created_at | updated_at
----+-------------+-----------+-------+----------------------------+----------------------------
79 | force_https | 5 | t | 2020-04-16 05:51:13.165124 | 2020-04-16 05:51:13.165124
(1 row)
Confirmamos esse problema no mobile (iOS, versão mais recente), no desktop, no Chrome (mais recente), no Safari (mais recente), etc.
Há algo estranho que acontece ao usar o nginx como proxy reverso para um socket Unix, o que afeta as imagens de avatar personalizado.
Até agora, lamentamos informar @ariznaf, não conseguimos isolar o problema e não temos uma solução.
“Parece que” na configuração proxy reverso nginx para um socket Unix, o aplicativo discourse (o contêiner) não está reconstruindo essas imagens de avatar personalizado como faz na configuração sem nginx como proxy reverso para um socket de domínio Unix.
Talvez o sidekiq não goste da configuração proxy reverso nginx para socket Unix e se recuse a agendar ou executar esse processo de reconstrução, rs? @riking?
Estranho.
Aqui está um acompanhamento:
Na configuração do proxy reverso usando sockets Unix que estamos discutindo:
No entanto, quando verificamos force_https:
Last login: Fri Apr 17 06:29:58 2020 from 159.192.216.252
# cd /var/discourse
# ./launcher enter data
# su postgres -c 'psql discourse'
psql (10.12 (Debian 10.12-1.pgdg100+1))
Type "help" for help.
discourse=# select * from site_settings where name like '%http%';
id | name | data_type | value | created_at | updated_at
----+-------------+-----------+-------+----------------------------+----------------------------
80 | force_https | 5 | t | 2020-04-18 03:33:10.641567 | 2020-04-18 03:33:10.641567
(1 row)
E, claro, como esperado, não há erro no certificado do navegador (o Chrome está satisfeito):
Portanto, minha suposição desinformada é que, nesta configuração, a configuração/método force_https está faltando essas imagens; pois tudo o mais está impecável, exceto esses avatares personalizados (e a imagem da página de perfil).
Essa é minha suposição acima do meu nível de conhecimento com o Discourse.
Atualização:
Após mais pesquisas, descobrimos que todas as nossas configurações de proxy reverso nginx para socket Unix estavam faltando grande parte dos arquivos em /shared/uploads. Essa etapa estava ausente nos vários tutoriais e documentos de como fazer que li sobre isso, então da próxima vez que eu vir uma wiki sobre esse tópico no meta, atualizarei o tutorial/wiki/como fazer para incluir essa etapa.
A única pequena complicação restante é um problema com o favicon:
Se alguém tiver uma maneira recomendada de corrigir isso, seria ótimo. Obrigado!
Refaça o upload. Essa é a solução mais rápida.
As pessoas esquecem que, ao usar um socket, desativaram o modelo HTTPS, então o Discourse não sabe que está atrás de SSL, a menos que force_https seja habilitado manualmente, daí minha sugestão de ontem.
Depois que force_https for habilitado, você pode refazer o upload dos ativos para corrigir seus caminhos.
Não tenho respondido a nada disso porque assumi que algum tipo de transferência de dados do servidor falhou (sem usar o recurso de backup integrado) e deixou os arquivos em /uploads/ de fora completamente, e não fazia ideia de como explicar isso de uma forma que você entendesse.
É… seguimos este guia para configurar o proxy reverso do nginx, mas isso era para uma configuração standalone e não mencionava os uploads porque não era necessário transferi-los no modo standalone:
E seguimos este guia para dois containers, que também não mencionou fazer nenhuma restauração de banco de dados ou transferir qualquer diretório de uploads:
Acho que conseguimos entender as coisas facilmente. Aqui está a pista que você estava perdendo para ajudar a explicar, para referência:
Os principais tutoriais sobre essa configuração omitem o fato de que você deve ou fazer uma restauração do banco de dados ou transferir manualmente seus uploads para o novo container, porque nós não incluímos isso.
Claro, faz todo o sentido agora que descobrimos isso 100% sozinhos (novamente!), porque não está nos tutoriais. LOL
Tudo fica fácil depois que você sabe qual é o problema.
PS: Para encerrar. Obrigado a todos que escreveram vários tutoriais. Eles foram de grande ajuda! Muito apreciado. Do nosso lado, essa configuração está concluída e não usaremos mais nenhuma configuração standalone em nenhum site Discourse no futuro. Nosso “padrão” normal será dois containers com um proxy reverso para um socket Unix. Isso funciona melhor para fazer atualizações e alternar containers em tempo real com quase zero de tempo de inatividade. Coisas boas!!
O Discourse é INCRÍVEL!!
Bem feito, Jeff @codinghorror e Sam @sam! BRAVO!
Isso é bastante fácil de fazer funcionar, mas como mencionei antes, não usamos o S3 e outros serviços de armazenamento em nuvem; preferimos manter as coisas “simples”, então nossos backups são apenas rsyncados para armazenamento fora do local. Preferimos assim… é uma coisa a menos para depurar e podemos “viver” sem o S3,
Não sei se isso é útil ou não. Mas a otimização de imagens tende a falhar se a tarefa que executa a otimização não conseguir acessar seu servidor por meio de seu nome de domínio na internet.
Isso pode explicar por que isso não está funcionando como esperado em uma configuração de proxy reverso mais complexa.
Obrigado, Kane.
Eu estava tentando (como você provavelmente sabe) outras alternativas ao método de backup padrão através da interface do Discourse.
Estou tentando isso porque tenho enfrentado problemas cada vez que tento restaurar usando o método de backup padrão, sempre seguindo as instruções dadas nos tutoriais oficiais deste site.
De qualquer forma, já declarei no início que estava fazendo essa restauração a partir de um backup criado usando a interface da UI e o procedimento padrão de backup e o procedimento de restauração recomendado.
A única diferença em relação a uma instalação padrão do Discourse standalone é que estamos usando o nginx como um proxy reverso, conectado ao Discourse através de um socket.
O principal problema que encontramos foi com os avatares, que aparentemente foram perdidos e substituídos pelo perfil padrão.
Você me disse que eles precisavam ser reconstruídos pelo trabalho do Sidekiq. Mas esse trabalho parece terminar imediatamente quando você o executa com sucesso (status OK), mas os avatares permanecem os mesmos.
Como os backups são muito importantes para nós (quem pode ignorá-los?), farei mais testes, tentando seguir as instruções com muito cuidado e tentando outras ideias mencionadas aqui.
Estamos felizes com o Discourse, gostamos muito dele. Apenas estamos tentando ter certeza de que temos um procedimento de restauração robusto, caso soframos algum tipo de ataque (tivemos um recentemente) ou falha no servidor.
Se quiser que façamos algum teste para tentar resolver esse problema ou fornecer alguma informação, ficarei feliz em fazer o meu melhor e fornecer essas informações.
Parece que o sistema não consegue acessar as miniaturas dos avatares, isso é certo.
Mas o resto do fórum está sendo servido corretamente; rotas, SSL e tudo está configurado corretamente, pelo menos pelo que consigo ver.
Se houvesse algum tipo de má configuração, você não conseguiria acessar o fórum Discourse e ver o restante do conteúdo; receberia erros 502 ou algo assim.
@neounix
Usamos o S3 porque é o método mais simples, pela interface, para ter backups fora do local.
Talvez o S3 não seja a melhor opção, não sei; de qualquer forma, onde os backups estão salvos não está relacionado ao problema, já que não se trata de não conseguir acessá-los e fazer a restauração.
A restauração foi feita corretamente.
@stephan
No app.yml, comentei o template do SSL e o template do Let’s Encrypt, bem como a seção expose com as portas.
A parte do SSL é feita pelo nginx, então não preciso que o socket seja criptografado, certo?
Isso está incorreto? Devo usar o template do SSL de qualquer forma?
Suponho que, se esse fosse o problema, eu não conseguiria ver nenhuma parte do fórum após a restauração, não apenas os avatares, mas quem sabe…
Vou fazer mais testes. Obrigado a todos pela ajuda.
@ariznaf … ei!
A maneira como resolvi esse problema em dois servidores diferentes foi copiar manualmente o diretório /shared/uploads da configuração original para as configurações socket-only. Depois disso, o problema desapareceu.
A maneira rápida de verificar foi comparar os tamanhos do diretório uploads, simplesmente assim (supondo que você esteja no diretório compartilhado):
du -sh uploads
Ao compará-los, foi quando descobri qual era o problema
Talvez você possa verificar também? Espero que isso ajude a isolar o seu problema.
PS: Não estou sendo negativo em relação ao S3. Cada um com o seu, como se diz…
Deixe-me ver se entendi corretamente.
Quando faço os backups, verifiquei se as uploads também são salvas (não as miniaturas, mas testei salvando-as também; agora estou salvando as miniaturas, então você não precisará esperar por uma nova geração).
Após a restauração, as uploads também são restauradas.
Você quer dizer que a restauração das uploads não está correta e que você precisa fazê-la manualmente?
Como você restaura as uploads manualmente?
Você baixou o backup e descompactou o diretório shared/standalone/uploads?
Se for esse o caso (vou tentar), parece claro para mim que há algum tipo de bug no processo de restauração.
Obrigado.
Estou procurando alternativas para fazer backups e armazená-los, mas as pessoas do Discourse insistem que a única maneira correta de fazê-lo é usando o backup padrão.
Olá @ariznaf,
Não restauramos pela interface de administração (fazemos apenas backup pela interface web, não restauramos). Fazemos o sftp do arquivo para o container (com os uploads incluídos e a restauração) e restauramos assim:
cat /shared/neo/bin/restoreneo
#!/bin/bash
echo "cd /var/www/discourse"
cd /var/www/discourse
echo "discourse enable_restore"
discourse enable_restore
echo "begin neo restore"
discourse restore unix-com-community7-2020-04-15-095302-v20200403100259.tar.gz
echo "discourse disable_restore"
discourse disable_restore
No entanto, quando criei uma nova configuração de nginx reverse proxy para socket unix outro dia, não restaurei do banco de dados porque o banco de dados já estava lá no container data (como mencionado nos tópicos de howto).
É por isso que precisei copiar manualmente os uploads para o novo container.
Sua situação parece diferente da nossa.
Espero que isso ajude.
Obrigado.
Parece que você está executando pelo mesmo procedimento que fazemos pela interface: ativando restaurações e restaurando a partir dos arquivos .tgz que contêm o banco de dados e os uploads.
Mas então você diz que, para que os avatares funcionem (usando sockets e proxy reverso do nginx), é necessário uma segunda restauração apenas dos uploads, está correto?
Ei @ariznaf… não exatamente…
No início, tínhamos um aplicativo independente. Separei esse aplicativo em dois containers diferentes (dados e apenas web) e depois fiz uma restauração a partir do arquivo de backup grande com os uploads.
Tudo correu bem…
Em seguida, criei um novo container, socket-only, e o configurei para usar um proxy reverso.
Eu NÃO fiz uma restauração no novo container socket-only (porque o container de dados já tinha os dados do banco de dados intactos), mas falhei em copiar manualmente os uploads (esse foi o meu erro). Se eu tivesse feito um processo de restauração normal, isso não teria sido necessário.
Mas não há motivo para fazer uma restauração manual do banco de dados novamente no novo container, pois essa é a razão para ter os dados em seu próprio containerzinho fofo. Então, nesta situação, os uploads devem ser copiados para o novo container. Na verdade, está bem feito.
Isso ajuda?
Não foi isso que eu disse. Eu disse que o backend não consegue se comunicar consigo mesmo através do nginx frontal. O que você está dizendo é o contrário.
Para otimizar um upload, o trabalho do Sidekiq o recupera usando http(s).
Não, você pode desabilitar o modelo SSL, mas precisará ativar manualmente o force_https.