Rebuilding sempre falha quando o limite diário do MAXMIND é atingido

Acabei de tentar uma reconstrução agora e falhou neste ponto:

 - dist/javascripts/media-optimization-worker.js: 5.01 kB (1.74 kB compactado)
 - dist/javascripts/pikaday/1.8.2/pikaday.js: 42.54 kB (9.67 kB compactado)
 - dist/javascripts/squoosh/mozjpeg_enc.js: 39.03 kB (10.81 kB compactado)
 - dist/javascripts/squoosh/squoosh_resize.js: 4.53 kB (1.28 kB compactado)
Concluído em 355.08s.

I, [2024-07-08T07:59:42.015855 #1]  INFO -- : cd /var/www/discourse & su discourse -c 'SKIP_EMBER_CLI_COMPILE=1 bundle exec rake themes:update assets:precompile'
Excluindo arquivos temporários
Empacotando ativos
I, [2024-07-08T07:59:57.247206 #1532]  INFO -- : Escrevendo /var/www/discourse/public/assets/break_string-cc617154cd957804f2f6a1f3bc68258c9cdca3d4b9a322bf777d145fed04790e.js
I, [2024-07-08T07:59:57.264957 #1532]  INFO -- : Escrevendo /var/www/discourse/public/assets/service-worker-9764e1cd771b38dbe65a0d1e42d89cb2cb5f72b266ab7316e55d3371cb0ac870.js
I, [2024-07-08T07:59:57.271269 #1532]  INFO -- : Escrevendo /var/www/discourse/public/assets/locales/i18n-3b40e842fd72b9bcc74ea83e094c823cd9ca535e4ecc5e78722e6f99d3656137.js
I, [2024-07-08T07:59:57.277082 #1532]  INFO -- : Escrevendo /var/www/discourse/public/assets/scripts/discourse-test-listen-boot-9b14a0fc65c689577e6a428dcfd680205516fe211700a71c7adb5cbcf4df2cc5.js
I, [2024-07-08T07:59:59.103776 #1532]  INFO -- : Escrevendo /var/www/discourse/public/assets/locales/ar-dfed7a58f30378bc60d7a2cc8d6347524f68b272ae012f0232604f730e442f91.js
I, [2024-07-08T08:00:00.112555 #1532]  INFO -- : Escrevendo /var/www/discourse/public/assets/locales/be-e12ac4c99df2289f422efd371dd3da766754aecb1189ea763fe003376aca9028.js
rake abortou!
Zlib::BufError: erro de buffer (Zlib::BufError)
1 curtida

Tenho uma pergunta. Você está usando S3? Suspeito que sim.

Não :baymax_no: Não S3 para mim.

1 curtida

Não sei se isso só acontece quando o limite diário é esgotado. Mas acontece o tempo todo aqui há 2-3 meses. Outras pessoas também parecem ter o mesmo problema:

Talvez fosse uma boa ideia fornecer os arquivos Maxmind de um diretório local? Eu baixo isso de qualquer maneira para outros usos, então já está lá.

E talvez fosse ainda melhor fornecer os arquivos Maxmind em um diretório compartilhado dentro do contêiner Discourse para ter sempre a versão atualizada? Como eu disse, eu baixo de qualquer maneira e atualizo os arquivos uma vez por dia.

1 curtida

Acho que o problema não está relacionado ao limite. Em outras palavras, ele também dá um erro quando uma chave ou ID de conta incorretos são inseridos. É assim que podemos resolver o problema aqui: em caso de erro, fazê-lo usar o banco de dados antigo e continuar a reconstruí-lo. Claro, é muito importante determinar a causa principal deste problema.

Tentei criar um exemplo dois dias atrás e ele deu um erro. Não tinha nada a ver com o limite porque foi minha primeira reconstrução naquele dia. Então criei uma nova chave e tentei e funcionou. Há uma situação aqui: quando você cria uma chave, leva um tempo para que ela se torne ativa. Se você a recriar imediatamente, ela dará um erro.

interessante :slight_smile:

Bem, minhas chaves são antigas, nunca as troquei depois de começar a usá-las. Por que está funcionando quando você cria uma nova chave? Você disse que leva um tempo até que ela fique ativa. Então deveria dar um erro?

Essa é uma boa ideia. Ou oferecer os arquivos de um diretório local, como eu sugeri. Tudo opcional. Mas realmente me incomoda que a reconstrução seja como uma loteria por muitas semanas agora…

1 curtida

Isso é contra os termos de uso da Maxmind, e é por isso que precisamos fazer com que todos forneçam as chaves de API para baixar os arquivos individualmente.

Atribuindo a mim mesmo para verificar qual é o problema quando o limite diário é atingido.

2 curtidas

Tive a reconstrução falhar e, em seguida, construí a imagem com as configurações do MaxMind desativadas. E então, dentro do contêiner, adicionei as configurações de volta e executei a tarefa do rake com sucesso.

Talvez seja possível reconstruir sem baixar o banco de dados e, em seguida, ter o banco de dados baixado quando o contêiner for iniciado?

Além disso, adicionei um PR que deve permitir que o bootstrap seja bem-sucedido (que foi mesclado) mesmo que o download falhe, mas ele ainda está causando a falha do bootstrap.

2 curtidas

Sim, acho que você está certo. Maxmind não é um recurso crítico, então não há necessidade de fazer o bootstrap falhar quando não conseguimos baixar coisas.

6 curtidas

Acho que você não entendeu o que eu tentei dizer. Deixe-me tentar novamente:

Tenho um script que baixa os arquivos Maxmind a cada poucos dias. Com minhas próprias chaves de API, é claro. Os arquivos são usados no servidor para várias coisas, como estatísticas da web AWstats, plugins do WordPress e assim por diante.

Então, eu tenho os arquivos na máquina de qualquer maneira. Por que baixar os arquivos (novamente) quando eu reconstruo o container do Discourse?

Essa é uma ideia brilhante. :slight_smile:

1 curtida

Sim. Seria ótimo ter esses arquivos em armazenamento persistente, especialmente se pudessem ser compartilhados entre instâncias. Tenho vários sites do Discourse na mesma máquina atrás do traefik, então se todos pudessem compartilhar o mesmo mmdb, isso economizaria a manutenção e o download de várias cópias separadas. Mesmo em uma instalação padrão, eles poderiam persistir entre as compilações. Talvez isso já seja possível? Talvez apenas montar /var/www/discourse/vendor/data em algum lugar persistente?

Aha. Acho que é para isso que serve GlobalSetting.maxmind_backup_path. Então, acho que se você tiver um maxminddb por algum motivo, pode definir DISCOURSE_MAXMIND_BACKUP_PATH para algo que esteja disponível no container.

Além disso, por que precisamos do mmdb para pré-compilar assets?

2 curtidas

Então isso já está funcionando? Configurar DISCOURSE_MAXMIND_BACKUP_PATH em app.yml (como link interno de dentro do contêiner ou link absoluto no host Docker?) desativará um download do Maxmind durante a reconstrução?

Está no código. Eu nunca o usei. Parece que se você incluir um caminho lá, ele o encontrará. Não me lembro, mas acho que é um caminho para o diretório.

Ok, eu poderia tentar. Tenho várias instâncias e uma é apenas para testes.

Posso ver se os arquivos foram retirados localmente ou foram baixados?

Então algo como /var/discourse/maxmind no host Docker?

Desculpe. Não tenho muita certeza. Parece que ele quer um diretório, e você pode torná-lo o que quiser, então talvez você adicione um volume em seu app.yml como

  - volume:
      host: /data/
      guest: /data

e DISCOURSE_maxmind_backup_path=/data/mmdb (corrigindo maiúsculas/minúsculas para a variável de ambiente)

aqui está o código

Obrigado novamente. Criei /var/discourse/shared/discourse_test/data/mmdb e aqui está o que fiz em app.yml:

  ## A chave da conta MaxMind para pesquisa de endereço IP de geolocalização
  ## veja https://meta.discourse.org/t/-/137387/23 para detalhes
  DISCOURSE_MAXMIND_ACCOUNT_ID: 123456
  DISCOURSE_MAXMIND_LICENSE_KEY: abcdefg
  DISCOURSE_MAXMIND_BACKUP_PATH: /data/mmdb

## O contêiner Docker é sem estado; todos os dados são armazenados em /shared
volumes:
  - volume:
      host: /var/discourse/shared/discourse_test
      guest: /shared
  - volume:
      host: /var/discourse/shared/discourse_test/log/var-log
      guest: /var/log
  - volume:
      host: /var/discourse/shared/discourse_test/data
      guest: /data

Adicionei DISCOURSE_MAXMIND_BACKUP_PATH e um terceiro volume.

O diretório para DISCOURSE_MAXMIND_BACKUP_PATH está correto? O caminho é o caminho dentro do contêiner?

Preciso remover DISCOURSE_MAXMIND_ACCOUNT_ID e DISCOURSE_MAXMIND_LICENSE_KEY agora?

Desculpe, muito animado e também um pouco confuso. :wink:

Okaysss :smiley:

MaxMindDB de backup detectado (baixado: 2024-07-17 23:15:02 +0000) em /data/mmdb
Copiando MaxMindDB de /data/mmdb para /var/www/discourse/vendor/data
Ignorando o download do MaxMindDB, pois foi baixado pela última vez em 2024-07-17 23:15:02 +0000

Acho que é isso que eu (ou melhor, “nós”) queríamos ver. :smiley:

3 curtidas

Acho que você poderia ter pulado o volume extra e feito

DISCOURSE_MAXMIND_BACKUP_PATH: /shared/data

Mas se você tiver algum outro processo que mantém esse banco de dados atualizado em outro lugar, você pode montar esse diretório para ter apenas uma cópia local em seu disco e precisar atualizar apenas essa cópia.

2 curtidas

Acho que vou deixar assim. A meus olhos, é uma configuração mais clara que ainda pode ser compreendida em alguns meses. Também pode ser mais genérica e para mais casos de uso do que apenas o meu.

Estou copiando os três arquivos mmdb do Maxmind para esse diretório ao baixá-los. Apenas ajustei o script que estou usando (a propósito, para download estou usando geoipupdate, que também está disponível como um pacote para Debian (e muito provavelmente outras distribuições Linux)).

Acabei de reconstruir quatro contêineres diferentes do Discourse, todos sem nenhum erro! Isso não acontecia há meses aqui. Ótimo! :slight_smile:

3 curtidas

Este problema ainda persiste. Explicarei o incidente em detalhes:
Fiz uma atualização do admin, parou no meio. Então iniciei uma recompilação do painel ssh. Boom deu um erro, exemplo de erro abaixo.

Então criei uma nova chave maxmind e recompilar, deu erro novamente, mesmo erro. (interessante, talvez a chave não tenha sido ativada).

Então desabilitei a configuração maxmind no arquivo app.yml. Recompilei e a compilação foi bem-sucedida.

Os add-ons que usei estão na imagem, outras coisas que usei:

  • Cloudflare R2
  • servidor postgresql separado
  • cloudflare

Não consigo mais descobrir o que está causando o problema.

1 curtida