Del enlace anterior, puedo ver que las imágenes y los archivos adjuntos se almacenan en una carpeta compartida más profunda en la instalación de Discourse, no dentro de docker. Dado que me gustaría usar una carpeta de imágenes enlazada simbólicamente desde mi segundo almacenamiento, que monto NFS a otros servidores. Y, en un servidor secundario, me gustaría ejecutar el contenedor docker de Discourse, como un medio de balanceo de carga / conmutación por error… y me gustaría usar la misma carpeta de imágenes del montaje NFS. Ya tengo la base de datos de otro servidor de red, por si acaso.
Acabo de probar la configuración, pero el resultado no es bueno. Copié todos los archivos de imagen de /var/discourse/shared/standalone/uploads a /var/www/image/uploads
Luego,
Creé enlaces simbólicos a la carpeta de imágenes montada en NFS
chmod & chown con www-data:www-data y 755 para las carpetas /uploads
Puedo ver las imágenes en el servidor principal donde la carpeta de imágenes está montada de forma nativa, pero no es el caso en el servidor secundario montado en NFS. Las imágenes faltan con el tamaño del contenedor.
Además, incluso en el servidor principal, puedo verlas, pero ya no puedo descargarlas.
Supongo que se debe a los permisos de archivo. Me pregunto cuál es la configuración ideal.
No estoy seguro si es vanilla o debido a docenas de reconstrucciones, pero las imágenes en la carpeta predeterminada son 755/644 (carpeta/archivo) y main_id:www-data en mi servidor. También copié la misma estrategia, pero no funcionó. Podría ser un problema específico de enlace simbólico o NFS, pero ya no puedo rastrearlo.
Ese fue mi intento inicial. Dentro del docker, encontré que el sistema de archivos estaba un poco desordenado, como lo había encontrado antes. Estaba anidado /uploads/uploads/uploads antes de que se viera /default/. No estoy seguro de lo que realmente sucedió, pero copié todos los archivos del interior a mi montaje de imagen y agregué la carpeta de montaje como un volumen.
Aquí, la situación no fue muy diferente a la de un enlace simbólico. Los permisos de archivo efectivamente crean el mismo problema. Después de entender que los archivos en realidad se almacenan fuera del contenedor de Docker, pensé que un enlace simbólico podría ser una solución mucho más fácil.
Para ambos, estoy casi seguro de que se trata de permisos de archivo, pero una CDN personalizada solo con un bloque de servidor Nginx suena como una solución mucho más simple que un volumen de docker, siempre y cuando el enlace simbólico no funcione.
Estoy bastante seguro de que no saldrá nada bueno de usar symlinks. Un problema es que es difícil que el symlink sea el mismo dentro y fuera del contenedor, y supongo que tu problema de subidas anidadas está relacionado con eso. He visto que se recomienda no usar symlinks y creo que esta es la razón.
¿Discourse admite CDN personalizados basados en CNAME? Recuerdo haber visto la configuración de S3 en la administración y publicaciones en meta para Fastly, pero no recuerdo bien la configuración de CDN personalizada.
Encontré la publicación. Supongo que necesito configurar una versión autoalojada de CDN compatible con S3. Un simple servidor de imágenes Nginx no es suficiente.