Configuración de Discourse HA en entorno aislado de red

Gracias de antemano.
Estoy planeando configurar Discourse con alta disponibilidad en un entorno de producción. Los siguientes son mi plan de diseño y algunas condiciones del entorno.

  1. Configuración con 3 servidores de aplicaciones y 2 servidores de bases de datos Postgres. Siempre un servidor PG en modo de escritura y otro en modo de solo lectura.

  2. Estos 3 servidores de aplicaciones apuntarán al mismo servidor de base de datos.

  3. Cada instancia de la base de datos debe servir operaciones de solo lectura y escritura respectivamente.

  4. Los servidores de producción no tienen conectividad a Internet, pero puedo descargar imágenes de dockerHub.

  5. Tenemos nuestro propio servidor GitLab.

  6. ¿Es posible inicializar una imagen de Docker y esa imagen en múltiples servidores?

Por favor, ¿alguien puede ayudarme a hacer esta configuración? Si hay algún enlace o sugerencia, envíeme un mensaje privado.

2 Me gusta

Después de ejecutar ./launcher bootstrap app en algún lugar, necesitará guardar esa imagen de contenedor resultante (generalmente se hace enviándola a un registro) y luego descargarla y ejecutarla en sus tres servidores de aplicaciones.

También necesitará un servidor Redis central (y potencialmente réplicas para él). También le falta un balanceador de carga para dirigir las solicitudes a esos diferentes servidores de aplicaciones.

3 Me gusta

Gracias por la respuesta @Falco

Estamos utilizando el balanceador de carga HAProxy y el repositorio Nexus para almacenar artefactos.

1 me gusta

Hola @Falco
En mi entorno de producción, no tengo acceso a Internet, así que lo que estoy planeando es realizar el bootstrap en una máquina con acceso a Internet, llevando esa imagen de bootstrap a los servidores de producción. Mientras hago esto en la VM de producción, el contenedor no se inicia porque el servidor Unicorn busca un ID de proceso padre, por lo que no se está ejecutando.
¿Podrías ayudarme aquí? ¿Necesito copiar el directorio /var/discourse donde se realizó el bootstrap al servidor de producción?

¿Qué es “esto”? ¿El bootstrap o la ejecución de la imagen de contenedor previamente iniciada?

1 me gusta

Cuando ejecuto la imagen de contenedor previamente iniciada

¿Cómo guardaste y exportaste la imagen al servidor de producción?

¿Cómo, exactamente, estás intentando ejecutar esta imagen guardada en producción?

1 me gusta

imagen previamente inicializada enviando al repositorio Nexus y desde el repositorio Nexus extrayendo en el servidor de producción.

comando docker run generado desde ./launcher start-cmd app y ejecutando el mismo comando en el servidor de producción.

1 me gusta

¿Puedes compartir el registro de errores al iniciarlo en producción?

run-parts: executing /etc/runit/1.d/00-ensure-links
run-parts: executing /etc/runit/1.d/00-fix-var-logs
run-parts: executing /etc/runit/1.d/01-cleanup-web-pids
run-parts: executing /etc/runit/1.d/anacron
run-parts: executing /etc/runit/1.d/cleanup-pids
Cleaning stale PID files
run-parts: executing /etc/runit/1.d/copy-env
Started runsvdir, PID is 42
chgrp: invalid group: ‘syslog’
ok: run: redis: (pid 51) 0s
ok: run: postgres: (pid 56) 0s
supervisor pid: 53 unicorn pid: 75
config/unicorn_launcher: line 71: kill: (75) - No such process
config/unicorn_launcher: line 15: kill: (75) - No such process
(53) exiting
ok: run: redis: (pid 51) 7s
ok: run: postgres: (pid 101) 0s
supervisor pid: 96 unicorn pid: 103
config/unicorn_launcher: line 71: kill: (103) - No such process
config/unicorn_launcher: line 15: kill: (103) - No such process
(96) exiting
ok: run: redis: (pid 51) 14s
ok: run: postgres: (pid 127) 0s
supervisor pid: 120 unicorn pid: 129
config/unicorn_launcher: line 71: kill: (129) - No such process
config/unicorn_launcher: line 15: kill: (129) - No such process
(120) exiting
ok: run: redis: (pid 51) 22s
timeout: down: postgres: 0s, normally up, want up
ok: run: redis: (pid 51) 30s
timeout: down: postgres: 1s, normally up, want up
ok: run: redis: (pid 51) 37s
ok: run: postgres: (pid 174) 0s
supervisor pid: 165 unicorn pid: 176
config/unicorn_launcher: line 71: kill: (176) - No such process
config/unicorn_launcher: line 15: kill: (176) - No such process
(165) exiting
ok: run: redis: (pid 51) 48s
ok: run: postgres: (pid 196) 1s
supervisor pid: 191 unicorn pid: 198
config/unicorn_launcher: line 71: kill: (198) - No such process
config/unicorn_launcher: line 15: kill: (198) - No such process
(191) exiting
ok: run: redis: (pid 51) 54s
timeout: down: postgres: 1s, normally up, want up

¿Está utilizando PostgreSQL, Redis y Object Storage externos? Eso es lo esperado cuando se hace HA, y tanto sus servidores de producción como los servidores de compilación deben tener acceso a esos servicios externos.

Solo probando el escenario, bootstrap funcionando en un servidor y ejecutando la imagen de contenedor bootstrapeada en otro servidor con configuración independiente.

Esa es una forma segura de que no funcionará.

¿Alguna razón para mencionar el almacenamiento de objetos, no podemos usar el almacenamiento interno del servidor?

En la configuración de HA, ¿necesitamos copiar el directorio discourse que se inició en todos los servidores de aplicaciones?

¿Cómo vas a manejar múltiples servidores de aplicaciones y cargas de usuarios? ¿Una unidad de red compartida entre todos los servidores? Eso puede funcionar, pero nuestra solución oficial para eso es el Almacenamiento de Objetos usando la API S3.

No es necesario, siempre y cuando

Sí, estoy usando un servidor Postgres externo y un clúster de Redis

3 servidores de aplicaciones que se utilizan para el clúster de Redis junto con la aplicación.

Así que necesito usar un directorio/almacenamiento compartido para el directorio de compilación de discourse. Gracias @Falco, ahora está claro para mí.

Lamento molestarte @Falco, tengo una última consulta.

Al realizar el paso de reconstrucción, ¿afectará los datos existentes en la base de datos de Postgres? Si es así, ¿cómo se maneja?

Sí, hay migraciones que se ejecutarán durante una reconstrucción, que cambiarán tanto los datos como la estructura.

En un entorno HA, deberá seguir la guía que tenemos aquí: Introducing Post Deployment Migration

1 me gusta

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.