Existen varios trucos que pueden ayudar cuando estés configurando un servidor de staging.
¿Qué es un servidor de staging?
Un servidor de staging es esencialmente un clon de un sitio de producción. También reside en un servidor y funciona de manera idéntica. Se ejecuta dentro de un contenedor Docker, al igual que un sitio Discourse normal.
Existe para darte un lugar donde probar cosas arriesgadas, o para probar cosas que no puedes ocultar fácilmente a tus usuarios. Es muy útil para probar anuncios utilizando el Discourse Advertising Plugin (Ads), o si quieres hacer algo peculiar como una importación o fusión de foros.
Esto contrasta con un servidor de desarrollo, que normalmente se ejecuta en un lugar de fácil acceso (y aislado) para que un desarrollador pueda manipular el código de forma segura.
¿Qué necesito?
-
Todo lo que necesitas para una instalación estándar autoalojada.
-
Si tienes configuradas copias de seguridad S3, tu vida será mucho más fácil.
- De lo contrario, necesitarás una forma de mover archivos grandes hacia y desde un servidor a través de SSH.
Pasos
Configura tu servidor como desees
Normalmente en un servidor Ubuntu virtual alojado en Digital Ocean, pero puedes usar lo que te resulte más cómodo.
Instala Discourse
A través de esta guía (o quizás a través de dashboard.literatecomputing.com). Recomiendo usar credenciales de correo electrónico ‘basura’ (no necesitas ni quieres que el correo funcione).
Confirma que tu instalación funciona:
Establece una cuenta de administrador (si es necesario)
Configura una cuenta de administrador desde la línea de comandos. Esto evita la necesidad de autenticarse por correo electrónico.
./launcher enter app
rake admin:create
Esto no es estrictamente necesario, excepto para probar la instalación, ya que puedes restaurar desde una copia de seguridad desde la línea de comandos.
Edita app.yml y añade algunos ajustes
-
Es posible que desees hacer una copia del app.yml original (yo lo llamo
app.vanilla.yml) al que puedas revertir si estropeas algo. -
En la parte inferior de la sección
env, añade estas líneas:## Configuración específica del servidor de staging DISCOURSE_AUTOMATIC_BACKUPS_ENABLED: false DISCOURSE_LOGIN_REQUIRED: true DISCOURSE_DISABLE_EMAILS: 'yes' DISCOURSE_S3_DISABLE_CLEANUP: true DISCOURSE_ALLOW_RESTORE: true -
Si tienes copias de seguridad S3 (o similar) configuradas, añádelas también (con la configuración de tu sitio principal).
## Configuración S3 DISCOURSE_S3_ACCESS_KEY_ID: 'tu_clave' DISCOURSE_S3_SECRET_ACCESS_KEY: 'tu_secreto' DISCOURSE_BACKUP_LOCATION: 's3' DISCOURSE_S3_BACKUP_BUCKET: 'tu_ubicacion_de_copias_de_seguridad' DISCOURSE_S3_REGION: 'tu_region_s3' DISCOURSE_S3_DISABLE_CLEANUP: truey si también estás haciendo cargas S3:
DISCOURSE_ENABLE_S3_UPLOADS: true DISCOURSE_S3_UPLOAD_BUCKET: 'tu_ubicacion_de_cargas' -
Es posible que desees añadir los mismos plugins que tienes en tu sitio de producción mientras estás en ello.
-
Realiza una reconstrucción
./launcher rebuild app
Gestión del servidor de staging
Ahora tienes un servidor de staging conectado a tus copias de seguridad S3 (pero no las sobrescribirá), es fácil de restaurar y no puede enviar correos electrónicos a nadie bajo ninguna circunstancia. ¡Perfecto!
Puedes restaurar una copia de seguridad reciente en el servidor de staging y ponerte a trabajar. Si no te gusta lo que has hecho, simplemente restáuralo de nuevo.
Apagado o encendido
Si dejas tu servidor de staging ‘encendido’ durante períodos prolongados, corres el riesgo de que sea indexado por Google y de que tus usuarios inicien sesión accidentalmente en él. Como sus credenciales son un clon de tu sitio de producción, esto es muy posible.
Una forma sencilla de mitigar estas dos cosas es simplemente apagar Discourse:
./launcher stop app
Y para volver a encenderlo para que puedas usarlo:
./launcher restart app
Actualizaciones
Tendrás que asegurarte de actualizar/reconstruir tanto el servidor de staging como tu sitio de producción al mismo tiempo si quieres asegurar que las cosas permanezcan alineadas desde el punto de vista de los plugins y el código. Lo mismo ocurre con los cambios en app.yml.
Si no usas S3, tendrás que mover manualmente las copias de seguridad entre servidores. ¡Y son grandes!
Población de un servidor de prueba
Si quieres un servidor de staging, entonces deberías poblarlo con tus datos reales de tu foro real a través de una Restauración. A veces, son tus datos concretos los que causan el problema, y probar tu foro con otro conjunto de datos puede darte una falsa sensación de seguridad.
Sin embargo, si lo que quieres es un servidor de prueba para ver cómo es Discourse, quizás quieras comprobar las cosas con datos falsos, y si es así, puedes hacer esto:
./launcher enter app
ALLOW_DEV_POPULATE=1 bundle install
ALLOW_DEV_POPULATE=1 rake dev:populate
Esto poblará tu foro con algunos datos falsos para que puedas ver cómo se ven las cosas con los temas y plugins que desees. Si aún no has iniciado tu foro, esto te dará una idea de cómo podrían verse las cosas.
Gestión de la autenticación de dos factores
Si bien el nombre de usuario/contraseña de tu cuenta de tu sitio principal también debería funcionar bien en el sitio de staging, no es tan bonito con la 2FA. Si tienes un problema, desactiva la 2FA:
./launcher enter app
rake users:disable_2fa[<NOMBRE_DE_USUARIO>]
, pero ¿sería esta una buena oportunidad para usar 
