Primero intenté ejecutar Discourse con configuraciones semi-predeterminadas y funcionó bastante bien, pude subir archivos y hacer otras cosas.
Luego me di cuenta de que la ruta en app.yml era /var/discourse y la actualicé a /var/www/discourse, detuve y destruí el contenedor, eliminé completamente la carpeta anterior. Y lo volví a poner en marcha… pero noté que ahora ya no puedo subir archivos.
¿Qué tipo de permisos necesita la carpeta uploads? Puedo hacer algunos cambios manualmente, pero me gustaría saber exactamente qué y si está bien en general (¿no debería el lanzador encargarse de establecer los permisos correctos, especialmente cuando se inicia desde cero?)
Eso es lo que se recomienda.
La ruta /var/www/discourse es la ruta de discourse dentro del contenedor. /var/discourse es la ruta normal para Discourse_docker fuera del contenedor.
Dado que acabas de empezar, te recomendaría que empieces de nuevo y no renombres nada esta vez.
Supongo que no actualizaste la ruta en tu app.yml y por eso está intentando acceder a algo que no existe.
Tengo muchos otros proyectos en este servidor y todos están muy bien ubicados en mi carpeta /var/www, ¡así que prefiero mantenerlo así! Y no me importa cómo esté dentro del contenedor.
¿Pero no lo actualicé? En mounts, ¿o dónde más debería ir?
De acuerdo, nada funcionó, así que terminé cambiando los permisos de la carpeta uploads a 755 y ahora está bien. Después de la reconstrucción, parece que las cargas en sí estaban bien (desde el lado del motor), sin embargo, nginx no pudo leerlas.
No entiendo del todo por qué estás haciendo todo esto. Es tu elección poner un contenedor en una ruta que será visible a nivel mundial si cometes un pequeño error, pero esa es tu elección. Pero, ¿todo lo demás… por qué?
Tener un proxy inverso delante de Discourse es realmente trivial y, de lo contrario, tu configuración sería una instalación estándar sin todo ese alboroto. Claro, si quieres jugar y ese es tu pasatiempo, pero muy pronto alguien aparecerá y dirá que solo puedes obtener soporte para una instalación estándar y el mayor problema es que nadie sabe realmente lo que has hecho. O por qué.
Estás solucionando un problema que surgió al intentar hacer otra cosa, lo que necesita una configuración estándar. Incluso con un proxy inverso.
Por eso estás bastante lejos de lo estándar Porque hay dos opciones:
Tienes un error en tus manos que nadie más tiene
Hiciste algo gracioso
Quizás sea un error. Y lo has confirmado haciendo una instalación estándar usando una ruta segura (en muchos sentidos) y al mismo tiempo conectando tu proxy inverso de la manera correcta. Porque si todavía está roto, puedo apostar que el problema está en el host virtual y/o en los puertos. Pero si funciona… entonces volvemos a la opción “gracioso”, donde nadie sabe lo que hiciste.
¿Ves el problema aquí?
De cualquier manera, usar un proxy inverso lleva a ninguna asistencia… esa es la política aquí. Pero otros usuarios pueden y con bastante frecuencia ayudarán.
Y no me importa cómo esté dentro del contenedor.
La situación es la misma con el contenedor de Docker.
