Depois de fazer alguns testes, descobri que algumas das minhas postagens não exibem as imagens, mesmo antes de realizar qualquer operação de ‘remapeamento’.
Em vez disso, elas mostram um pequeno ícone da imagem, que revela o caminho da imagem quando passo o mouse sobre ele e exibe a imagem apenas quando cliquei nele.
E esse ícone também desaparece (e um espaço em branco ou marcador de lugar da imagem começa a aparecer no seu lugar) se eu selecionar ‘Reconstruir HTML’ no menu de três pontos ou mesmo se fizer qualquer operação de ‘rebake’ dentro do contêiner.
Se você não fez um remapeamento e seu bucket S3 ainda está funcional, nada deve ter mudado em relação ao que era antes. As imagens funcionavam antes de você começar por esse caminho?
Em teoria, você só perderá a conexão com esses arquivos de imagem se desligar seu bucket S3 ou fizer o remapeamento incorretamente.
Obrigado.
Percebi que o ícone das imagens mostra o caminho /bucket/uploads/optimized/folder/… (e como não há nenhuma imagem nesse caminho, a imagem não é exibida, apenas o ícone).
Mas quando clico nesse ícone de imagem, a imagem é exibida/servida da pasta ‘Orig’, ou seja, /bucket/uploads/original/…
Não sei como uma única imagem pode ter dois caminhos diferentes armazenados para ela?!!
De qualquer forma, agora o problema se resume a: como encontrar as postagens que têm imagens mapeadas para o caminho errado (sob ‘optimized’)? Assim, eu poderia corrigir/remapear seus endereços para o caminho correto sob ‘Original’.
Obrigado @nathank, @Pravi, @itsbhanusharma. Como confundi problemas/cenas diferentes, atualmente estou nesta situação:
Algumas das minhas postagens não exibem as imagens enviadas a elas; em vez disso, mostram um pequeno ícone com uma URL/endereço de bucket incorreto quando passo o mouse sobre eles. Ou, algumas exibem a imagem correta e o caminho do bucket corretos SOMENTE quando clico nesses pequenos ícones. E ainda há postagens cujas imagens não mostram nada, apenas um espaço branco em branco.
E se eu executar uma operação de remapeamento (remap wrongbucketurl correctbucketurl), então encontrei em uma postagem amostrada que, mesmo que por um momento o pequeno ícone tenha sido substituído pela imagem correta (fiquei feliz), no dia seguinte, essa imagem desapareceu completamente, sem ícone sequer. E apenas um espaço branco apareceu em seu lugar. Então tive que restaurar meu site para o dia anterior.
Quando executei este comando, o resultado foi este:
# rake posts:missing_uploads
Procurando por uploads ausentes em: default
19 uploads de postagens estão ausentes.
19 uploads estão ausentes.
6 de 7792 postagens são afetadas.
Já executei variações desse processo algumas dezenas de vezes e ainda não está funcionando.
Nossas imagens não estão sendo exibidas via S3 porque a gestão decidiu que não quer um bucket S3 com acesso público, então precisamos voltar para o armazenamento local.
Inicialmente, analisei os links quebrados e, a partir disso, consegui identificar os valores que precisava usar no remapeamento (eu achava), e várias imagens passaram a funcionar. Mas a maioria, diria que mais de 90%, ainda não funciona. E, ao contrário do que acontecia com os links quebrados do S3, onde pelo menos era possível inspecioná-los para começar a entender o que estava errado, agora só recebo isso:
Alguém sabe o que pode estar causando a falha nessas imagens? Estou preso nisso há dias. Achei inacreditável que: a) não haja como migrar de volta e b) alguém (não eu) tenha migrado nossa instância sem que houvesse como voltar.
Para ficar claro, segui o processo descrito acima pelo @nathank. Já tentei várias vezes, geralmente com pequenas variações nos caminhos da etapa de remapeamento, pois não está claro para mim se essas instruções são universais ou dependem da estrutura do seu diretório (o nosso tem várias subpastas que foram copiadas com sucesso do S3 usando a etapa de sincronização S3).
Agradeceria muito se alguém pudesse me ajudar, pois estou prestes a perder a cabeça.
Acho que o que você quer fazer é ativar o include_s3_uploads_in_backups oculto, fazer um backup e, em seguida, restaurá-lo (eu faria isso primeiro em um novo servidor de teste). É isso que acontece quando um cliente do CDCK cancela sua assinatura, e esses backups são restaurados em um novo site auto-hospedado sem nenhum problema.
NoMethodError: método não definido include_s3_uploads_in_backups=' para SiteSettings:Module de (pry):1:in pry’
Então percebi que talvez eu precisasse reativar os uploads S3, pois os tinha desativado, mas ainda assim obtive o mesmo erro.
Ah, usamos dois containers e estou executando isso no web_only. O comando Rails não é encontrado no container de dados, então presumo que essa seja a abordagem correta.
Executei isso e, em seguida, criei um novo backup. Restaurei a partir desse backup, mas não houve nenhuma alteração — a maioria das imagens ainda exibe o ícone quebrado mencionado acima. Tentei reconstruir os dois containers também, mas isso não fez diferença.
Ao baixar e inspecionar o arquivo zip do backup, todos esses arquivos estão definitivamente lá e, após a restauração, são visíveis no sistema de arquivos. No entanto, o Discourse simplesmente se recusa a reconhecê-los e exibi-los.
Para constar, eventualmente consegui fazer isso funcionar. Comecei do zero (ou seja, a partir de um snapshot da minha instância) e tenho quase certeza de que o processo que funcionou no final foi:
usar o console do rails para executar SiteSetting.include_s3_uploads_in_backups=true
criar um novo backup
restaurar a partir deste backup
usar discourse remap para atualizar as referências aos meus vários locais de arquivos S3 para um local local
rebakear os posts e reconstruir ambos os meus contêineres docker
Obrigado @pfaffman por me indicar o caminho certo aqui.
EDIT
Vou levantar isso também. Após minha postagem anterior, percebi que seis dos nossos tópicos ainda têm imagens quebradas (embora a grande maioria esteja OK agora).
São nossos seis posts mais antigos e todas as imagens originais tinham uma URL S3 diferente de todas as outras. Claramente, isso não é coincidência. Então, verifiquei se todos esses arquivos estavam no diretório uploads/default/original/1X, e todos estavam. Em seguida, executei um comando remap usando essa URL S3 exclusiva — e isso pareceu editar o número correto de posts. Depois, rebakeei e reconstruí os contêineres, mas esses tópicos ainda estão quebrados. Alguém tem ideia de por que um pequeno número falharia assim?
