Problemas com Login no Patreon, Forçar HTTPS e Questões com S3 CDN (três)

Posso precisar dividir isso em três posts separados, mas eles estão relacionados, então começarei com um.

Há alguns dias, usei este tutorial (How to Scale a Discourse Deployment with a Load Balancer and Managed Database Cluster | DigitalOcean) praticamente palavra por palavra e migrei meu Discourse Droplet autônomo na Digital Ocean para dois Droplets dentro de um Load-Balancer, até agora tudo bem.

Em seguida, passei por este tutorial (Configure an S3 compatible object storage provider for uploads), mas depois de reconstruir o discourse pela linha de comando, meu site Discourse exibia apenas uma tela em branco. Olhei no Inspetor no navegador para descobrir que o navegador estava bloqueando todo o meu conteúdo porque ele estava sendo servido via HTTP e não HTTPS. Isso provavelmente ocorre porque o load balancer é SSL Terminated, então tudo o que é externo é HTTPS, mas os próprios servidores estão rodando em HTTP.

Neste ponto, quebrei completamente meus servidores novamente, tentando fazê-los funcionar com HTTPS dentro do Load-Balancer, mas simplesmente não foi possível. Não consegui fazer o Digital Ocean Space/CDN funcionar com S3/CDN de acordo com este tutorial (Configure an S3 compatible object storage provider for uploads). Passei por ele com uma lupa e inspecionei todos os aspectos várias vezes, mas não funcionou. A única maneira que consegui reconstruir o Discourse foi remover o parâmetro DISCOURSE_S3_ENDPOINT: https://sfo3.digitaloceanspaces.com do app.yml, mas então, mesmo tendo construído, não consegui fazer o servidor responder. Recebi um erro 503 de servidor não respondendo ou um erro regular de navegador de servidor não respondendo ou servidor desconectado. Diferiu com base nas configurações do Load-Balancer e DO Space/CDN que eu estava tentando. Tentei todas as combinações possíveis de configurações e nada me permitiu servir uma página.

Quando mantive o parâmetro DISCOURSE_S3_ENDPOINT, recebi o seguinte erro durante a reconstrução do Discourse, mas ele desapareceu quando comentei o parâmetro S3_ENDPOINT.
Aws::S3::Errors::InvalidAccessKeyId: Aws::S3::Errors::InvalidAccessKeyId

Todos os meus arquivos foram sincronizados com S3, então acho que é seguro assumir que a Chave de Acesso estava boa, e o problema foi causado pelo parâmetro S3_ENDPOINT de alguma forma.

Hoje, desisti de tentar fazer a tentativa anterior funcionar e restaurei um backup dos meus Droplets que estavam apenas balanceando carga com apenas HTTP e finalmente consegui fazer funcionar novamente fazendo este tutorial (Set up file and image uploads to S3), mas desta vez editei as configurações de S3 através do painel de Administração do Discourse em vez de editar o app.yml com as configurações do tutorial recomendado. Finalmente funcionou, mas a diferença importante é que omiti deliberadamente as configurações de CDN do S3. Confirmei que as imagens carregadas nas postagens estão sendo armazenadas no S3 e posso fazer backup do Discourse diretamente no S3, e é realmente tudo o que quero, mas agora tenho três problemas que me assombram, um é crítico e dois são ignoráveis, embora eu gostaria de confirmar isso aqui, se possível.

Então, o problema crítico é que os usuários não podem mais fazer login usando o botão de login do Patreon na página de login do Discourse. Esta mensagem é exibida:
Desculpe, ocorreu um erro ao autorizar sua conta. Por favor, tente novamente.

O URL é este:
https://mbp.community/auth/failure?message=invalid_credentials&origin=https%3A%2F%2Fmbp.community%2Flogin&strategy=patreon

Eu realmente apreciaria algum conselho sobre o que eu poderia tentar para fazer isso funcionar, mas novamente, estou me perguntando se isso ocorre porque internamente os servidores não estão rodando HTTPS. Como você pode ver no URL, externamente eles estão em HTTPS, então é difícil ter certeza. Acho que estou esperando que alguém aqui tenha experiência com o Digital Ocean Load-Balancing etc. com Discourse.

Os outros dois problemas estão sendo chamados agora no Console de Administração, como abaixo:

Alguns conselhos com base nas configurações atuais do seu site

  • Seu site está usando SSL. Mas [force_https](https://mbp.community/admin/site_settings/category/all_results?filter=force_https) ainda não está habilitado em suas configurações de site.
  • O servidor está configurado para enviar arquivos para S3, mas não há CDN S3 configurado. Isso pode levar a custos caros de S3 e desempenho lento do site. Veja “Usando Armazenamento de Objetos para Uploads” para saber mais.

Então, não me importo de tentar ativar o force_https, mas estou preocupado que isso me bloqueie do meu servidor porque internamente os servidores com balanceamento de carga não estão rodando em HTTPS e, devido aos problemas que tive ontem, estou relutante em gastar mais doze horas batendo minha cabeça contra uma parede vendo inúmeras reconstruções de 15 minutos do Discourse apenas para não chegar a lugar nenhum. Novamente, se alguém souber que é seguro ativar o force_https com minhas configurações, por favor, me avise.

E o segundo problema, novamente, não correu bem através dos parâmetros adicionados ao arquivo app.yml, então estou relutante em tentar isso novamente também. Você pode confirmar que isso faria essencialmente o mesmo que os parâmetros adicionados ao arquivo app.yml? Se sim, vou apenas ignorar esta segunda mensagem. Pelo contrário, se for por algum motivo seguro tentar, me avise e farei um backup e darei uma chance.

Desculpe pelo post longo. Espero que você consiga descobrir o que estou tentando obter conselhos.

1 curtida

Então você realmente precisa de ajuda lá, porque tudo o que é realmente suportado aqui é uma instalação padrão.

Você espera mais de 200 mil visualizações de página por dia? Se não, um único droplet de 8 GB com CDN será muito mais fácil de gerenciar e provavelmente mais barato. E pelo que posso ver, há pelo menos algumas maneiras pelas quais essas instruções provavelmente não funcionarão para ninguém.

Primeiro, você configurou um redis externo como descrito na etapa 5? Se não, eu esperaria que as coisas estivessem pelo menos um pouco quebradas. Eles implicam que usar sticky irá “consertar” isso, mas realmente não irá. Então você pode esperar erros espúrios difíceis de diagnosticar. E eles não especificam uma maneira de garantir que todas as suas instâncias estejam executando exatamente a mesma versão do Discourse, então isso também provavelmente tornará as coisas quebradas.

Você realmente queria fazer isso primeiro, caso contrário, na verdade, essa configuração não pode funcionar, porque alguns uploads estarão em um servidor e outros em outro, e essas instruções não mencionam a palavra “upload”, então eu espero que se você estiver usando isso para mais do que testes, você tenha um pouco de bagunça em mãos e precisará sincronizar os uploads entre seus múltiplos droplets.

Ele afirma especificamente que o CDN do Digital Ocean não funciona com o Discourse.

Você usou um CDN diferente como recomendado? Bunny.net é bastante fácil e simples de configurar.

2 curtidas

Oh céus, não sei quem escreveu este guia, mas certamente não foi alguém muito familiarizado com o Discourse em escala.

O último passo diz que você pode adicionar mais backends ao balanceador de carga usando o recurso de snapshot do droplet, mas como o guia não menciona o uso de Object Storage para os uploads, fazer isso quebrará completamente os uploads de usuários. Além disso, se você seguir este guia, as atualizações se tornarão não triviais.

Meu conselho para @Martin_Bailey é que você não siga nada dali. Isso resultará apenas em uma instalação quebrada, como você descobriu.

Por favor, siga nosso guia de instalação oficial se quiser uma instalação rápida e sensata do Discourse. Sair desse caminho pode rapidamente se tornar um trabalho em tempo integral.

3 curtidas

Engraçado. Deixei um comentário lá descrevendo alguns dos problemas e linkando para o post do Rafael, mas ele foi excluído.

3 curtidas

Uau! OK, então eu pensei que tinha corrido bem, embora houvesse algumas coisas que notei que estavam incorretas, mas agora tenho uma instalação com balanceamento de carga. Claro, a primeira coisa que descobri foi que o upload de imagens estava quebrado, e é por isso que usei o S3 para armazenar imagens.

Como está, levará outra carga de trabalho para voltar a um único servidor, então há algo que posso fazer sobre o problema de login do Patreon? Ignorarei os outros dois problemas.

Obrigado pela sua ajuda de qualquer maneira. Vocês fazem um ótimo trabalho aqui.

Olá Jay, obrigado pela sua ajuda. Em resposta às suas perguntas…

Não estou esperando muitos usuários, pois é uma Comunidade Patreon fechada. Meu objetivo principal era poder atualizar um servidor sem que isso derrubasse o site. Na verdade, confirmei que isso é possível, então fiquei satisfeito com a configuração. Sim, eu fiz o passo cinco, então o estado está sendo armazenado em um droplet Redis externo.

A outra coisa que tive que descobrir, que me atrasou por um tempo, foi que também precisei adicionar o parâmetro abaixo ao app.yml, caso contrário, a reconstrução continuava falhando porque estava tentando se conectar ao Postgres na porta padrão, apesar de ter a porta real no parâmetro DISCOURSE_DB.

DISCOURSE_DB_BACKUP_PORT: 25060

Eu não pensei nos uploads até depois de ter tudo funcionando com base no primeiro tutorial, e inicialmente isso quebrou tudo quando tentei configurar o S3, mas foi porque as configurações de CDN do DO Space que vocês fornecem aqui não funcionam.

Afirma explicitamente que a CDN da Digital Ocean não funciona com o Discourse.

Eu sei, mas então o tutorial nos faz adicionar isto:
DISCOURSE_S3_ENDPOINT: https://sfo3.digitaloceanspaces.com

O que vem do DO Space, certo? Eu não tenho ideia, com base em tudo que li nesses tutoriais, como eu trabalharia com uma CDN diferente, mas não estou preocupado neste momento, pois cobrirei isso em um momento.

Não, eu não usei uma CDN diferente. Na verdade, estou bem sem usar uma CDN. Deixarei as configurações de CDN em branco. Como uma atualização adicional, com base no conselho que todos vocês gentilmente forneceram até agora, eu ia reverter para o meu backup da semana passada, mas pensei em tentar ativar a opção force_https primeiro, e ativá-la corrigiu o problema de login do Patreon, como eu suspeitava que poderia. Nada foi alterado no(s) servidor(es), então o problema de login do Patreon provavelmente foi causado por alguma lógica interna do Discourse, embora novamente, eu perceba (agora) que estou fazendo algo que você não recomenda ou suporta.

Portanto, neste ponto, minha configuração está praticamente como o primeiro tutorial recomenda, mas imagens e backups vão todos para o S3, sem uma CDN em vigor. Está funcionando muito bem. Agradeço que você esteja me recomendando usar apenas a instalação standalone, mas derrubar o site por 15 minutos toda vez que uma atualização sai é realmente doloroso. Ontem mesmo encontrei suas referências a data.yml e web_only.yml para uma configuração multisservidor, mas não consegui descobrir o que eu deveria fazer, então desisti disso.

Vou seguir com o que tenho por enquanto. Obrigado pela sua ajuda e por tudo que vocês fazem.

Ok pessoal, vocês venceram. :slight_smile:

Comecei a ver mais problemas com imagens não carregando novamente porque às vezes elas estavam sendo compartilhadas via http e não https. Vocês estão certos, é uma bagunça.

Acabei de reverter a maior parte disso, deixando o banco de dados Postgres no lugar, mas voltando para apenas um servidor droplet, sem balanceador de carga e com imagens/Redis armazenados localmente. Deixei o S3 no lugar para os backups do site. Adoro como isso funciona perfeitamente.

Acho que voltei para interrupções de 15 minutos a cada atualização, mas já gastei um total de uns cinco dias inteiros com isso, e não posso gastar mais tempo com isso, então fico feliz que todos vocês conseguiram me corrigir em relação ao tutorial original que segui. É quase como se eles quisessem que as pessoas pagassem por mais Droplets. :slight_smile:

Obrigado novamente pela ajuda.

Na verdade, se eu pudesse perguntar, existe um tutorial para nos ajudar a configurar o Discourse de forma que seja possível evitar essa interrupção de 15 minutos a cada atualização. Vi a nota sobre data.yml e web_only.yml, mas não tenho ideia do que preciso fazer para que isso aconteça.

Ter arquivos yml separados para data e web_only é proveniente da configuração de dois contêineres:

1 curtida

Isso funcionará e resolverá alguns problemas. E se você acabar sendo bloqueado por algum (outro) motivo, você sempre pode usar launcher enter app para voltar e desativar a configuração do site de volta do console Rails.

Como outros já disseram, é melhor seguir um guia diferente.

1 curtida

Oi pessoal,

Eu escrevi aquele artigo sobre DigitalOcean, parece que cometi alguns erros, desculpem!

Gostaria de atualizar o artigo para corrigir os problemas.

Então, gostaria apenas de fazer algumas perguntas para garantir que eu faça as coisas direito com a versão corrigida.

No artigo, eu disse que você poderia usar opcionalmente uma instância Gerenciada de Redis, meu pensamento na época era que o uso de sessões persistentes permitiria que você usasse o Redis integrado na imagem do Discourse. Isso está correto? Talvez isso não seja suficiente e uma instância externa de Redis deva ser um requisito obrigatório.

Concordo com o comentário do @Falco sobre Armazenamento de Objetos, isso foi uma falha minha. Posso atualizar o artigo para incluir instruções sobre como usar o DigitalOcean Spaces para lidar com uploads de imagens.

Suspeito que remover todo o estado dos Droplets seja a resposta para resolver os problemas de instalação, eu esperava que usar um Redis externo fosse opcional devido às sessões persistentes, mas posso estar enganado.

Concordo também que isso torna sua instalação do Discourse mais complicada de atualizar, acho que, no entanto, se você remover todo o estado dos Droplets, deverá ser capaz de atualizar apenas um Droplet, depois criar um snapshot dele e simplesmente substituir os outros Droplets por novos criados a partir dos snapshots (Um pouco como Deployments do Kubernetes, exceto que você faz a reimplantação manualmente).

Concordo também que provavelmente existem maneiras melhores de escalar o Discourse, ainda gostaria de corrigir o artigo para que as pessoas possam segui-lo se quiserem.

Obrigado,
Francis

Sou um cliente feliz da Digital Ocean e tenho um painel onde meus clientes inserem chaves de API e um nome de host e, em seguida, ele cria automaticamente um droplet, configura o Mailgun, aguarda a configuração dos registros DNS e, em seguida, instala o Discourse.

Não funciona nada como você sugere. Entrei em contato com a Digital Ocean no seu fórum (não encontrei outra maneira) para avisar e minha mensagem foi apagada. Então, 9 meses depois, você responde aqui.

Fazer isso corretamente é uma façanha bastante complicada, e os casos em que seria útil são bastante improváveis. Tenho um site com 100 mil pageviews por dia em um droplet de 8 GB. Quem você acha que é o público-alvo deste guia?

Sim, você precisa de redis externo, postgres e buckets S3 com um CDN, e o CDN da Digital Ocean não funciona, então seu guia precisaria guiá-los pela configuração do CDN de outra empresa. Acho que você não quer fazer isso. E isso é apenas para configurá-lo. Se eles quiserem fazer uma atualização, seria um conjunto totalmente diferente de procedimentos que ninguém mais no planeta saberia como ajudar.

A melhor coisa que você poderia fazer seria excluir esse guia completamente. Se você quiser ser um verdadeiro herói, poderia corrigir a instalação “1-click” para que não usasse seu próprio script proprietário para configurar o e-mail e assim por diante, para que fosse realmente uma instalação padrão. É bastante confuso ter que usar control-c para conseguir chegar onde o Discourse está, e como as pessoas que usaram o “1-click” não usaram as ferramentas padrão do Discourse, elas não sabem como usá-las quando chega a hora de uma atualização pela linha de comando. Seria muito, muito ótimo se você pudesse fazer isso.

Aqui você pode ver pessoas que o usaram e tiveram problemas: Search results for 'digital ocean one-click' - Discourse Meta

1 curtida

Não, pois o Redis não é um cache simples, mas lida com muitas contagens, limites de taxa, trabalhos em segundo plano, pub sub. Ter vários Redii resultará em contagens corrompidas e comportamento quebrado.

Isso resolveria, mas adicionar um Redis gerenciado, PostgreSQL gerenciado, Balanceador de Carga gerenciado, Armazenamento de Objetos, Registro de Contêiner também será mais caro do que apenas pagar por nossa hospedagem padrão e muito mais complicado de manter.

Nesse ponto, a interseção entre pessoas que querem pagar centenas de dólares por mês e não se importam se seu serviço cair por causa de um SPOF é bem pequena, e se torna mais uma configuração de hobby do que o que recomendaríamos para administradores de fóruns.

1 curtida