Hola, acabo de configurar una nueva instalación de Discourse. ¡Gracias por todo el trabajo duro para que sea tan sencillo!
Idealmente, me gustaría hacer que mi servidor de Discourse sea desechable, de modo que si, por ejemplo, alguien lo elimina accidentalmente en la consola de EC2, no pierda ningún dato.
La funcionalidad de copia de seguridad/restauración incorporada es excelente, y ya he realizado algunas pruebas con ella. Estoy almacenando app.yml, uploads y backups en S3.
El siguiente paso sería mover la base de datos a Amazon RDS, para lo cual hay una excelente guía aquí.
Mi pregunta es: si hago esto, ¿debería estar teóricamente a salvo para terminar la instancia, y luego en un servidor nuevo simplemente clonar Discourse, obtener mi app.yml y ejecutar ./launcher rebuild app? ¿O hay otro estado más allá de postgres/uploads/app.yml? ¿Quizás en Redis?
Creo que eso es en gran parte cierto. Querrás asegurarte de no tener dos funcionando a la vez. Cuando construyas el nuevo contenedor, migrarás la base de datos, lo que podría hacerla inutilizable para el otro contenedor (puedes evitar esto con skip_post_deployment_migrations). Se considera que las cosas en Redis son etéreas y no se respaldan. No estoy muy seguro de cómo o si algunas de las cosas allí se restauran, pero probablemente no te importe.
@phil22 - He trabajado en una configuración similar a la que propones y es más sutil de lo que crees:
El equipo de Discourse lanza múltiples versiones al mes y, por lo tanto, necesitas mantener tu versión original al clonar a tu nuevo ec2. Normalmente, está bien actualizar la aplicación sin más, pero algunas versiones incluyen actualizaciones importantes de la base de datos (PG 12 → PG 13) y si no haces un seguimiento de esto y descuidas la actualización de tu RDS externo, podrías quedarte atascado.
Encontramos éxito al hacer que el ec2 utilice un volumen EBS que también está configurado para montarse dentro de tu contenedor de aplicaciones. Usando esto, almacenamos todo el contenido de la carpeta /shared. De esa manera, cuando tus instancias ec2 aparecen y desaparecen, tienes todo este contenido de la carpeta compartida persistido en EBS. Además, a veces cambias de opinión sobre el almacenamiento de archivos en s3. Tener un lugar alternativo para almacenar archivos subidos (como la carpeta /shared) es bueno en ese caso.
Siguiendo su consejo, creo que optaré por RDS, pero fijándolo a un commit específico del repositorio discourse_docker. Si bien suena a que eso hará las actualizaciones más complejas, espero que signifique que si tenemos un problema con el servidor, tendremos todo seguro en RDS y podremos recuperar el mismo estado de funcionamiento de manera bastante rápida sin una restauración manual.
(Creo que podríamos lograr lo mismo con EBS, pero con el cifrado de volúmenes y la magia de Unix para montar/desmontar el volumen entre instancias, me da un poco de miedo el proceso de automatizar eso).