Olá, acabei de configurar uma nova instalação do Discourse - obrigado por todo o trabalho árduo em torná-lo tão simples!
Idealmente, eu gostaria de tornar meu servidor Discourse descartável, de modo que, se, por exemplo, alguém o encerrar acidentalmente no console EC2, eu não perca nenhum dado.
A funcionalidade integrada de backup/restauração é ótima, e eu já fiz algumas execuções de teste com ela. Estou armazenando o app.yml, uploads e backups no S3.
O próximo passo seria mover o banco de dados para o Amazon RDS, para o qual existe um ótimo guia aqui.
Minha pergunta é: se eu fizer isso, em teoria, estarei seguro para encerrar a instância e, em um servidor novo, simplesmente clonar o Discourse, obter meu app.yml e executar ./launcher rebuild app? OU existe outro estado além do postgres/uploads/app.yml? Talvez no Redis?
Eu acho que isso é em grande parte verdade. Você vai querer ter certeza de que não tem dois rodando ao mesmo tempo. Ao construir o novo contêiner, você migrará o banco de dados, potencialmente tornando-o inutilizável para o outro contêiner (você pode evitar isso com skip_post_deployment_migrations). As coisas no Redis são consideradas etéreas e não são copiadas. Não tenho certeza de como ou se algumas das coisas lá são restauradas, mas você provavelmente não se importa.
@phil22 - Trabalhei em uma configuração semelhante à que você está propondo e é mais sutil do que você pensa:
A equipe do Discourse lança várias atualizações por mês e, portanto, você precisa permanecer com sua versão original ao clonar para sua nova ec2. Normalmente, tudo bem atualizar o aplicativo cegamente, mas algumas versões incluem grandes atualizações de banco de dados (PG 12 → PG 13) e, se você não acompanhar isso e negligenciar a atualização de seu RDS externo, poderá ficar preso.
Tivemos sucesso em fazer com que a ec2 usasse um volume EBS que também é configurado para ser montado dentro do seu contêiner de aplicativo. Usando isso, armazenamos todo o conteúdo da pasta /shared. Dessa forma, quando suas instâncias ec2 entram e saem, você tem todo esse conteúdo da pasta compartilhada persistido no EBS. Além disso, às vezes você muda de ideia sobre o armazenamento de arquivos no s3. Ter um local alternativo para armazenar arquivos carregados (como a pasta /shared) é bom nesse caso.
Seguindo seu conselho, acho que vou optar pelo RDS, mas fixando em um commit específico do repositório discourse_docker. Embora pareça que isso tornará as atualizações mais complexas, espero que signifique que, se tivermos um problema com o servidor, teremos tudo seguro no RDS e poderemos restaurar o mesmo estado de funcionamento de forma bastante rápida, sem um restauração manual.
(Acho que poderíamos alcançar a mesma coisa com o EBS, mas com criptografia de volume e mágica do Unix para montar/desmontar o volume entre instâncias, estou um pouco assustado com o processo de automação disso)