He cambiado el nombre porque no puedo apagar el servidor original durante horas hasta que haya comprobado que todo funciona correctamente y cambie los servidores.
No es necesario. Si tienes un certificado comodín, simplemente puedes realizar cambios locales en DNS a través del archivo Hosts para configurar todo y restaurar la copia de seguridad en sí.
Luego, solo tienes que cambiar la configuración de DNS públicamente.
No entiendo a qué te refieres.
Tengo que mantener a.domain.com en funcionamiento mientras realizo las pruebas.
Y necesito acceder a la interfaz de Discourse de la copia que estoy restaurando para verificar que todo esté correcto.
Por lo tanto, necesito otra URL para acceder a la copia en el otro servidor.
Así que simplemente cambio el nombre de host en Discourse y en Nginx después de la restauración.
Cuando todo esté bien, cambio el nombre en el nuevo servidor a a.domain.com, apago el servidor antiguo y apunto el DNS de a.domain.com al nuevo servidor.
Lo anterior no es correcto. Puedes obligar a tu máquina local a conectarse al nuevo servidor usando el mismo nombre DNS, ya sea modificando el archivo HOSTS en tu computadora local o agregando manualmente una entrada en tu DNS local.
No tengo una máquina local.
Ambos servidores están en internet, o son servidores en la nube.
Uso ssh desde una máquina Windows.
Quizás pueda tomar el nombre local del host para establecer la IP de la máquina, pero es más complejo que cambiar el nombre en los servidores.
¿Crees que un cambio en el nombre del host pueda ser el problema?
No debería ser un problema…
Sí, hemos vuelto a observar este problema con los avatares personalizados mucho después de que el proceso sidekiq tuviera tiempo de reconstruir cualquier imagen adjunta de avatar o perfil, pero solo en la configuración con nginx como proxy inverso a un socket de dominio unix.
Las miniaturas de los iconos pequeños funcionan bien; sin embargo, no se muestran correctamente en la tarjeta de perfil ni en las páginas de perfil (a menos que ya estuvieran en caché antes y la caché no haya expirado).
Tan pronto como hacemos esto:
nginx -s stop; ./launcher start web-only
El problema con las imágenes de avatares personalizados desaparece (en imágenes que no se han visto previamente / almacenadas en caché en el navegador).
Y tan pronto después de hacer esto:
./launcher stop web-only; nginx
El problema con las imágenes de avatares personalizados vuelve a aparecer en las imágenes que aún no se han visto / almacenado en caché.
No hay errores con HTTPS y esto definitivamente no se debe a force_https (totalmente sin relación):
discourse=# select * from site_settings where name like '%http%';
id | name | data_type | value | created_at | updated_at
----+-------------+-----------+-------+----------------------------+----------------------------
79 | force_https | 5 | t | 2020-04-16 05:51:13.165124 | 2020-04-16 05:51:13.165124
(1 row)
Hemos confirmado este problema en dispositivos móviles (iOS, última versión), en escritorio, en Chrome (última versión), en Safari (última versión), etc.
Hay algo extraño que ocurre al usar nginx como proxy inverso a un socket unix, lo cual afecta a las imágenes de avatares personalizados.
Por ahora, lamentamos informarte @ariznaf, que no hemos podido aislar el problema ni tenemos una solución.
“Da la sensación” de que en la configuración de nginx como proxy inverso a un socket unix, la aplicación discourse (el contenedor) no está reconstruyendo estas imágenes de avatares personalizados como lo hace en la configuración sin nginx como proxy inverso a un socket de dominio unix.
¿Quizás sidekiq no le gusta la configuración de nginx como proxy inverso a un socket unix y se niega a programar o ejecutar este proceso de reconstrucción, LOL? @riking?
Extraño.
Aquí tienes un seguimiento:
En la configuración del proxy inverso que estamos discutiendo, que utiliza sockets Unix:
Sin embargo, cuando verificamos force_https:
Last login: Fri Apr 17 06:29:58 2020 from 159.192.216.252
# cd /var/discourse
# ./launcher enter data
# su postgres -c 'psql discourse'
psql (10.12 (Debian 10.12-1.pgdg100+1))
Type "help" for help.
discourse=# select * from site_settings where name like '%http%';
id | name | data_type | value | created_at | updated_at
----+-------------+-----------+-------+----------------------------+----------------------------
80 | force_https | 5 | t | 2020-04-18 03:33:10.641567 | 2020-04-18 03:33:10.641567
(1 row)
Y, por supuesto, como era de esperar, no hay ningún error en el certificado del navegador (Chrome está feliz):
Así que mi suposición de inexperto es que en esta configuración, la opción / método force_https carece de estas imágenes; ya que todo lo demás es impecable, excepto estos avatares personalizados (y la imagen de la página de perfil).
Esa es mi suposición que está por encima de mi nivel con Discourse.
Actualización:
Después de más investigación, resulta que todas nuestras configuraciones de proxy inverso nginx a socket Unix carecían de la mayor parte de los archivos en /shared/uploads. Este paso faltaba en los diversos tutoriales y documentos de cómo hacerlo que leí sobre esto, así que la próxima vez que vea una wiki sobre este tema en Meta, actualizaré el tutorial / wiki / cómo hacerlo para incluir este paso.
El único pequeño problema restante es un problema con el favicon:
Si alguien tiene una forma recomendada de solucionar esto, sería genial. ¡Gracias!
Vuelve a subirlo. Esa es la solución más rápida.
La gente olvida que, al usar un socket, han desactivado la plantilla HTTPS, por lo que Discourse no sabe que está detrás de SSL a menos que se habilite manualmente force_https, de ahí mi sugerencia de ayer.
Una vez que force_https esté habilitado, puedes volver a subir los recursos para corregir sus rutas.
No he respondido a nada de esto porque asumí que algún error en la transferencia de datos del servidor (sin usar la función de copia de seguridad integrada) había omitido por completo la carpeta /uploads/ y no tenía ni idea de cómo explicarlo de una manera que pudieras entender.
Sí… seguimos esta guía para configurar el proxy inverso de nginx, pero esto era para una configuración independiente y no mencionaba las cargas porque no era necesario transferirlas en modo independiente:
Y seguimos esta guía para dos contenedores, que tampoco mencionaba realizar ninguna restauración de BD ni transferir ningún directorio de cargas:
Creo que podemos entender las cosas fácilmente. Aquí está la pista que te faltaba para ayudar a explicar, por referencia:
Los tutoriales principales sobre esta configuración omiten el hecho de que debes realizar una restauración de BD o transferir manualmente tus cargas al nuevo contenedor, ya que nosotros no lo incluimos.
Por supuesto, ahora tiene sentido después de resolverlo el 100% por nuestra cuenta (¡otra vez!) porque no está en los tutoriales. LOL
Todo es fácil después de saber cuál es el problema.
PS: Para cerrar. Gracias a todos los que escribieron varios tutoriales. ¡Fueron de gran ayuda! Muy apreciados. De nuestra parte, esta configuración está terminada y ya no usaremos ninguna configuración independiente en ningún sitio de Discourse en el futuro. Nuestro “predeterminado” normal será dos contenedores con un proxy inverso hacia un socket Unix. Esto funciona mejor para realizar actualizaciones y cambiar contenedores en tiempo real con casi cero tiempo de inactividad. ¡Cosas geniales!!
¡Discourse es GENIAL!!
¡Bien hecho Jeff @codinghorror y Sam @sam! ¡BRAVO!
Esto es bastante fácil de configurar, pero como mencioné antes, no usamos S3 ni otros servicios de almacenamiento en la nube; y preferimos mantener las cosas “simples”, por lo que nuestras copias de seguridad solo se rsyncan a un almacenamiento fuera del sitio. Preferimos hacerlo así… es una cosa menos que depurar y podemos “vivir” sin S3,
No sé si esto es útil o no, pero la optimización de imágenes suele fallar si el proceso que ejecuta la optimización no puede alcanzar tu servidor a través de su nombre de dominio de Internet.
Eso podría explicar por qué esto no funciona como se espera en una configuración de proxy inverso más compleja.
Gracias, Kane.
Estaba intentando (como probablemente sabes) otras alternativas al método de copia de seguridad estándar a través de la interfaz de Discourse. Lo hice porque he tenido problemas cada vez que intenté restaurar desde el método de copia de seguridad estándar, siempre siguiendo las instrucciones dadas en los tutoriales oficiales de este sitio.
De todos modos, al principio ya había indicado que estaba realizando esta restauración desde una copia de seguridad creada mediante la interfaz de usuario y siguiendo el procedimiento estándar de copia de seguridad y el procedimiento de restauración recomendado.
La única diferencia con una instalación estándar de Discourse independiente es que estamos usando nginx como proxy inverso, conectado a Discourse a través de un socket.
El principal problema que encontramos fue con los avatares, que aparentemente se perdieron y fueron sustituidos por el avatar predeterminado.
Me dijiste que debían ser reconstruidos por el trabajo de Sidekiq. Sin embargo, ese trabajo parece terminar inmediatamente al ejecutarse con éxito (estado OK), pero los avatares permanecen igual.
Dado que las copias de seguridad son muy importantes para nosotros (¿quién podría ignorarlas?), realizaré más pruebas, tratando de seguir las instrucciones con mucho cuidado y probando otras ideas mencionadas aquí.
Estamos muy contentos con Discourse, nos gusta mucho. Solo queremos asegurarnos de tener un procedimiento de restauración robusto, por si sufrimos algún tipo de ataque (hace poco tuvimos uno) o una falla del servidor.
Si deseas que realicemos alguna prueba para intentar solucionar este problema o proporcionarte más información, estaré encantado de hacer lo posible y compartir esos datos.
Parece que el sistema no puede acceder a las miniaturas de los avatares, eso es seguro.
Pero el resto del foro se sirve correctamente; las rutas, SSL y todo está configurado correctamente, al menos según lo que puedo ver.
Si hubiera algún tipo de mala configuración, no podrías acceder al foro de Discourse ni ver el resto del contenido; obtendrías errores 502 o algo similar.
@neounix
Usamos S3 porque es el método más sencillo desde la interfaz para tener las copias de seguridad fuera del sitio.
Quizás S3 no sea la mejor opción, no lo sé; de lo contrario, dónde tengas guardadas las copias de seguridad no está relacionado con el problema, ya que no se trata de no poder acceder a ellas ni de realizar la restauración.
La restauración se ha realizado correctamente.
@stephan
En app.yml he comentado la plantilla de SSL, la plantilla de Let’s Encrypt y la sección expose con los puertos.
La parte de SSL la maneja nginx, así que no necesito que el socket esté cifrado, ¿verdad?
¿Esto es incorrecto? ¿Debería usar la plantilla de SSL de todos modos?
Supongo que si este fuera el problema, no podría ver ninguna parte del foro después de la restauración, no solo los avatares, pero quién sabe…
Haré más pruebas. Gracias a todos por su ayuda.
@ariznaf … ¡hola!
La forma en que solucioné este problema en dos servidores diferentes fue copiar manualmente el directorio /shared/uploads desde la configuración original a las configuraciones socket-only. Después de hacerlo, el problema desapareció.
La forma rápida en que pude verificarlo fue comparando los tamaños del directorio uploads, simplemente así (asumiendo que estás en tu directorio compartido):
du -sh uploads
Al compararlos, fue entonces cuando descubrí cuál era el problema
¿Quizás tú también puedas comprobarlo? Espero que esto te ayude a aislar tu problema.
PD: No estoy en contra de S3. Como dice el refrán, cada uno a lo suyo…
Déjame ver si te he entendido correctamente.
Cuando hago las copias de seguridad, he verificado que se guardan también las subidas (no las miniaturas, pero he probado guardando las miniaturas también; ahora estoy guardando las miniaturas, así que no tendrás que esperar a que se regeneren).
Tras la restauración, las subidas también se restauran.
¿Quieres decir que la restauración de las subidas no es correcta y que tienes que hacerlo manualmente?
¿Cómo restauras las subidas a mano?
¿Has descargado la copia de seguridad y descomprimido shared/standalone/uploads?
Si ese es el caso (lo probaré), me parece claro que hay algún tipo de error en el trabajo de restauración.
Gracias.
Estoy buscando alternativas para hacer copias de seguridad y almacenarlas, pero el equipo de Discourse insiste en que la única forma correcta de hacerlo es usando la copia de seguridad estándar.
Hola @ariznaf,
Nosotros no restauramos desde la interfaz de administración (solo hacemos copias de seguridad desde la interfaz web, no restauramos). Usamos sftp para transferir el archivo al contenedor (incluidas las subidas) y luego restauramos de la siguiente manera:
cat /shared/neo/bin/restoreneo
#!/bin/bash
echo "cd /var/www/discourse"
cd /var/www/discourse
echo "discourse enable_restore"
discourse enable_restore
echo "begin neo restore"
discourse restore unix-com-community7-2020-04-15-095302-v20200403100259.tar.gz
echo "discourse disable_restore"
discourse disable_restore
Sin embargo, cuando creé la otra configuración de proxy inverso nginx para socket Unix el otro día, no restauré desde la base de datos porque esta ya estaba presente en el contenedor data (como mencionan los temas de cómo hacerlo).
Por eso tuve que copiar manualmente las subidas al nuevo contenedor.
Tu situación parece diferente a la nuestra.
Espero que esto te ayude.
Gracias.
Parece que mediante la línea de comandos estás ejecutando el mismo procedimiento que realizamos a través de la interfaz: habilitar las restauraciones y restaurar desde los archivos tgz que contienen la base de datos y las cargas.
Pero luego dices que, para que los avatares funcionen (usando sockets y un proxy inverso de nginx), necesitas una segunda restauración solo de las cargas, ¿es correcto?
Hola @ariznaf… no exactamente…
Al principio, teníamos una aplicación independiente. Separé esa aplicación en dos contenedores diferentes (datos y solo web) y luego hice una restauración desde el archivo de copia de seguridad grande que contenía las subidas.
Todo fue bien…
Luego, creé un nuevo contenedor, socket-only, y lo configuré para usar un proxy inverso.
NO hice una restauración en el nuevo contenedor socket-only (porque el contenedor de datos ya tenía los datos de la base de datos intactos), pero olvidé copiar manualmente las subidas (ese fue mi error). Si hubiera seguido el proceso normal de restauración, no habría sido necesario.
Pero no hay razón para hacer una restauración manual de la base de datos nuevamente en el nuevo contenedor, ya que esa es la razón de tener los datos en su propio contenedor. Así que, en esta situación, las subidas deben copiarse al nuevo contenedor. En realidad, está muy bien hecho.
¿Te ayuda esto?
No es lo que dije. Dije que el backend no puede acceder a sí mismo a través del nginx frontal. Lo que tú dices es al revés.
Para optimizar una subida, el trabajo de Sidekiq la recupera mediante http(s).
No, puedes deshabilitar la plantilla SSL, pero tendrás que habilitar manualmente force_https.