Ese es el propósito de la configuración anterior; es muy útil tener el servidor de staging apuntando al mismo bucket, ya que esto facilita mucho mantenerlos sincronizados.
Sin embargo, no quieres que contribuya con ninguna copia de seguridad automáticamente (ni que elimine ninguna), de ahí que estén desactivadas con estas configuraciones:
Estoy de acuerdo en que la CDN necesita ser desactivada para tu sitio de staging. Yo no he tocado eso, pero una vez que averigües cómo hacerlo, por favor actualiza / añade a la wiki en el OP.
Gracias, Nathan. Vi una mención de que las copias de seguridad de S3 facilitaban las cosas, pero una copia de seguridad es diferente de los activos del sitio, así que no estaba seguro.
Ya he desactivado las copias de seguridad y los correos electrónicos, así que todo está bien ahí. Me pondré a señalar el servidor de ensayo al bucket existente y me aseguraré de que no esté utilizando la CDN.
Tengo planeado crear un espejo de mi producción de Discourse utilizando el método rsync.
Tengo un par de otros sitios web que se integran con Discourse, por lo que tener las versiones de desarrollo/prueba de esos sitios capaces de acceder e interactuar con una versión de desarrollo/prueba/staging de Discourse sería ideal.
Por lo tanto, solo lo encendería cuando fuera necesario, y restauraría una copia de seguridad de la base de datos de mi PROD en mi STAGING periódicamente, no diariamente y quizás tan poco como una vez al mes.
Si hago esto, ¿cómo evito que cambie algunas configuraciones al restaurar la base de datos?
Estos, por ejemplo, serían invaluables:
¿Hay alguna forma de restaurar una copia de seguridad de la base de datos y luego aplicar manualmente algunas configuraciones antes de iniciar Discourse? ¿Alguna otra idea, sugerencia, error?
Si mantienes copias de seguridad en S3 y las configuras a través de variables de entorno, entonces puedes crear fácilmente un nuevo sitio que pueda restaurar esa copia de seguridad. Simplemente crea una nueva VM, clona discourse, copia el yml, reconstruye y restaura. Puedes anular la configuración en la base de datos con variables de entorno como en la cita de tu publicación.
¿Me falta algún paso? Estoy bastante seguro de que esto funcionó hace aproximadamente un año. Pero ahora, aunque se puebla, no agrega ningún tema ni publicación más allá de la sección Acerca de la categoría… ¿ha cambiado algo?
Terminé restaurando una copia de seguridad antigua de una de mis instancias de Discourse donde había utilizado este método para poblar. Tuve que hacer esto, pero funcionó.
Hay algo que tienes que hacer para poder eliminar la base de datos. Si ejecutas la tarea de rake db:drop, te dirá qué es. Así que supongo que necesitarías sv stop unicorn y luego eliminar, crear y migrar la base de datos antes de ejecutar la tarea. O eso es lo siguiente que intentaría, pero tú tienes otra solución…
Estoy intentando poblar datos de prueba en mi servidor de staging, pero obtengo un error:
rake aborted!
Los comandos de la base de datos solo se admiten en el entorno de desarrollo
Esto es en una configuración multisitio, por lo que los comandos que estoy ejecutando son:
./launcher enter web_only
ALLOW_DEV_POPULATE=1 bundle install
RAILS_DB=instance-x ALLOW_DEV_POPULATE=1 rake dev:populate
Que he estado usando sin problemas hasta ahora, pero ahora obtengo este error. ¿Puedo establecer una variable de entorno para permitir comandos de base de datos en producción?
