Presumo que não seja estritamente necessário fazer o download. A maioria das pessoas executa uma única instância na nuvem, que pode ou não ter um bucket S3 de backup. Baixar o backup seria a única maneira para esse grupo fazer um backup externo, como você mencionou.
Eu iria até mesmo além, criando um sistema de backup adicional em um provedor completamente diferente também, especialmente depois do que aconteceu recentemente com este desenvolvedor de código aberto. Independentemente de sua validade, é um ótimo aviso para ter um backup semanal ou mensal em um local/provedor de armazenamento totalmente separado.
Obrigado @pfaffman por adicionar isso, realmente indolor agora! (exceto por restaurar um backup grande que é sempre uma espera tensa e longa, qualquer que seja a configuração).
Aliás, acho que este caminho está incorreto: deveria ser web-only (por padrão), eu acho?:
Sim. web-only e isso é um pouco confuso quando em todos os outros contextos é web_only. Mas talvez quando algo é um diretório ou um contêiner-o-que-quer que seja uma coisa diferente.
O que eu sei… Acabei de perder 4 horas lutando com o SearXNG e isso deveria ser um trabalho de 5 minutos (eu realmente não gosto de coisas do docker)
editar e fora do tópico
Sério ele e ck são palavras banidas? Foi-nos ensinado na escola como uma palavra não ofensiva. Então, eles estavam errados, óbvio
Acho que isso pode ter sido adicionado quando as palavras monitoradas estavam sendo testadas e apenas nunca foram removidas.
Sim. Eu também fico confuso sobre isso com frequência. Na verdade, acho que é provavelmente por isso que uma vez, quando tentei apenas renomear as coisas para mudar de contêiner único para duplo, errei o traço/sublinhado e falhou.
E pior, tenho quase certeza que a culpa é minha. Recebi um erro quando criei a opção de dois contêineres no discourse-setup (talvez os contêineres não pudessem ter sublinhados?) Ruby gosta de sublinhados em nomes de arquivos, então talvez seja por isso que usei um sublinhado lá? Acho que é isso - e acho que web_only não pode funcionar como um nome de contêiner docker, pois eles também precisam ser nomes de host válidos.
Prefiro hifens em caminhos de diretório, então tudo bem como está, e sublinhado no nome do contêiner, honestamente, faz sentido, então deixe como está.
Aliás, acho que deveria haver um título ou um selo autodeclarado no meta para aqueles que usam a configuração de dois contêineres Depois de um ano aqui, acho que deveria ser obrigatório que suas instalações padrão fossem migradas.
Se não fosse por tanta documentação existente sobre a configuração de contêiner único, eu quase argumentaria que deveria ser o padrão, embora precisasse haver algumas ferramentas para informar às pessoas que o banco de dados pode precisar de atenção, ou algo assim.
Frequentemente vejo muitas pessoas insatisfeitas e, de outra forma, assustadas com instalações de dois contêineres. (Recentemente, alguém queria que a instalação de dois contêineres que eu criei quando fiz a instalação deles fosse movida para um único contêiner, por exemplo.) É tão raro que seja um problema, e a única vez que causa problemas, na verdade, economiza algum incômodo, pois facilita adiar uma atualização do Postgres até que você esteja pronto para fazê-la. Geralmente, você pode adiar uma atualização do PG por um bom tempo (exceto quando o plugin de IA foi adicionado ao núcleo e exigiu essa extensão).
Em alguns momentos no passado, o processo de build fazia chown em todos os arquivos, mas isso pode levar muito tempo, então acho que isso pode ter sido removido em algum momento (isso é mais um sentimento do que algo baseado em prestar atenção aos commits).
Na maioria das vezes. ./launcher fará um git pull (pelo menos eu pensei que sim, mas talvez não?) primeiro e você terá mais probabilidade de ter o preenchimento de tabulação funcionando para o docker do que para ./launcher.
Fui paciente e esperei pelo trabalho agendado (mas documentar isso é muito útil!) e isso parece ter funcionado, então muito obrigado pela sua ajuda @pfaffman
Sim. Costumava haver um chown que rodava a cada reconstrução, tenho certeza. Pode levar um tempo e é quase sempre supérfluo (exceto quando não é). Não tem nada a ver com um ou dois contêineres. Acho que tem a ver com a mudança de uma versão do Debian para a imagem base para outra versão e a nova versão tem mapeamentos de usuário diferentes do que a antiga.
Não tenho certeza do que é “esta”, mas tanto este tópico quanto aquele a que me refiro são para uma instalação padrão, então o docker_manager funciona normalmente.
O docker_manager não está relacionado ao processo de migração para outro servidor, pois você precisa construir um novo contêiner.
Ele deve forçá-lo a construir um novo aplicativo quando houver uma alteração na imagem base, o que acho que tem acontecido bastante ultimamente. Sinceramente, ainda não entendi completamente os mecanismos em jogo.
A forma como descobri isso foi após um bootstrap de web_only e substituir (destruir, iniciar), fui atualizar após uma única alteração de plugin, apenas para ser solicitado a reconstruir o aplicativo!
ele e ck são palavras banidas? Foi-nos ensinado na escola como uma palavra não ofensiva. Então, eles estavam errados, óbvio 
Depois de um ano aqui, acho que deveria ser obrigatório que suas instalações padrão fossem migradas. 