Reconstruir pantalla al usar minio como almacén de objetos
I, [2022-09-01T00:37:48.192311 #1] INFO -- : cd /var/www/discourse & sudo -E -u discourse bundle exec rake s3:upload_assets
rake aborted!
Aws::S3::Errors::BadRequest: Ocurrió un error al analizar la solicitud HTTP PUT en '/'
Todos los dominios tienen las credenciales adecuadas e intento conectarme a la cuenta usando Cyberduck con s3.example.com o bucket.s3.example.com está disponible para cargar y descargar archivos.
He buscado problemas relacionados y no lo he resuelto, funciona bien si se usa el almacenamiento de objetos de vultr. Entonces, ¿es que minio y discourse no funcionan bien juntos, pero he visto a personas usando minio con éxito. Pregunto a todos, creo que este problema se resolverá pronto.
El problema no se ha resuelto, lo que me molesta es que la conexión a la cuenta de minio usando el protocolo de transporte amazon s3 de Cyberduck está disponible y creo que mi configuración de minio parece estar funcionando bien.
¿Ha confirmado que su configuración de MinIO funciona en general con otros mecanismos como el cliente MinIO o el? ¿Y que está utilizando las URL y la configuración adecuadas para MinIO?
Mi sugerencia es asegurarse primero de que todo cumple con los clientes de línea de comandos MinIO y s3cmd. Nunca he oído hablar de este cliente “Cyberduck” (por una buena razón: es para Windows y Mac, yo soy un tipo de Linux), y no puedo confirmar que cumpla con MinIO y otras cosas, ya que dice “AWS S3” en su cosa y probablemente esté diseñado para la API completa de S3 en Amazon, no para elementos compatibles/conformes con S3. Configure el cliente minio (mcli) en la línea de comandos en o cerca de la máquina con la que está intentando trabajar y luego intente enviar un archivo manualmente a sus buckets.
Además, tenga en cuenta que DISCOURSE_S3_BACKUP_BUCKET con MinIO está diseñado para ser su propio bucket, no una subruta dentro de un bucket existente (que yo sepa). Es posible que eso también rompa cosas en la configuración actual, por eso el ejemplo que escribí y el enlace a mi “Cómo” que proporcionó lo tienen como un bucket separado.
Lo que no tengo aquí es información sobre la solicitud específica que se realizó, la ruta de la URL, etc. que utilizó el sistema cuando realizó esa consulta con BadRequest. Parece que es porque solo es un registro de nivel INFO. ¿Hay alguna forma de obtener un nivel de depuración de registro durante el proceso rake@pfaffman (o otros que estén más familiarizados con el lado de Discourse)?
ADEMÁS, asegúrese de pasar también DISCOURSE_S3_INSTALL_CORS_RULE: false para su configuración de Discourse: si el reconstruidor/panadero de la aplicación intenta enviar reglas CORS, se producirá un mensaje de error.
Veo el archivo enviado en el bucket, ¿significa esto que instalé minio con los pasos correctos? Instalé minio usando docker compose y mi archivo docker-compose.yml
DISCOURSE_S3_BACKUP_BUCKET: He intentado usar un bucket separado y he configurado el reenvío del nombre de dominio al puerto 9000 para el bucket, pero no funciona.
¿Reenviar qué puertos? ¿80/443 para que http/https funcione? Eso es todo lo que necesita, NUNCA debería tener que configurar el puerto 9000 en un puerto separado. El bucket separado tendrá el mismo endpoint que s3.example.com; no es algo separado, por lo que está configurando ESO incorrectamente. No olvide tampoco que en la jerga de MinIO, si está utilizando autenticación de ruta, terminaría con s3.example.com/NOMBREDEBUCKET o con autenticación DNS como debería usar BUCKET.s3.example.com para los endpoints de URL que necesita aceptar en el lado de nginx y reenviar al puerto interno 9000. No necesita configurar eso de su lado, eso debe configurarse del lado de MinIO.
El cliente MinIO admite la configuración de estilo path y dns. Hasta donde yo sé, Discourse utiliza un mecanismo basado en URL para la identificación de buckets, no configuraciones de estilo de ruta (siéntase libre de corregirme, desarrolladores de Discourse). Por lo tanto, el comportamiento ‘predeterminado’ que está configurando es incorrecto.
Ahora, mi MinIO no está dockerizado, pero para cumplir aquí con Discourse, necesita usar el enrutamiento de estilo DNS, es decir, necesita agregar en la variable de entorno MINIO_DOMAIN=BASEDOMAINHERE para que el enrutamiento de estilo DNS que Discourse quiere usar funcione. En su ejemplo sería MINIO_DOMAIN=s3.example.com y luego su NGINX necesitaría configurarse para pasar la cabecera Host al backend en el puerto 9000 o donde sea que se ejecuten los componentes base del servidor que no son de consola. Luego, debe asegurarse de que NGINX acepte para *.s3.example.com y lo reenvíe correctamente al contenedor MinIO. Esto es parte de la configuración de MinIO Federation, pero para instancias de un solo nodo con múltiples nombres de bucket en una URL base, debe asegurarse de que esté configurado correctamente de todos modos si desea que funcione con Discourse.
Desafortunadamente, aquí es donde tiene que empezar a profundizar en las configuraciones de MinIO. Y uno de los requisitos que especifico en el documento es que tiene una instancia de MinIO completamente funcional y configurada correctamente, lo cual está más allá del alcance del sitio de Discourse. Creo que su MinIO no está configurado correctamente para la resolución de buckets de estilo DNS como lo hace AWS S3 (bucket.s3.example.com, por ejemplo) y, por lo tanto, no funciona.
Tenga en cuenta que ejecuto la instancia de Discourse para el Proyecto Lubuntu (lubuntu.me) (una variante de Ubuntu que usa LXQt) utilizando un MinIO con resolución de URL de bucket de estilo DNS para que funcione correctamente con Discourse, de lo contrario, una solicitud para BUCKET.basedomain.example.com fallaría.
Dato curioso, incluso indico que necesita que su MinIO esté configurado correctamente para rutas de estilo DNS; si no incluyó MINIO_DOMAIN durante la configuración de MinIO, no hará rutas de estilo DNS. Lo cual necesita aquí para Discourse, según el punto 3 de mi sección de advertencias que escribí:
Hola hermano, configurar MINIO_DOMAIN hace que los errores anteriores desaparezcan, pero aparecen otros nuevos
Aws::S3::Errors::MalformedXML: El XML que proporcionaste no estaba bien formado o no validaba contra nuestro esquema publicado.
Siento que estoy a punto de tener éxito, porque discourse puede acceder correctamente a mi minio, intento eliminar todos los buckets de minio, reconstruyo discourse, me pedirá que el bucket especificado no existe
El problema se resuelve no agregando variables de almacenamiento de objetos a través de app.yml. De lo contrario, se producirá un error MalformedXML; simplemente agregue el parámetro s3 a la configuración. La variable MINIO_DOMAIN debe agregarse al instalar minio (estoy usando una implementación de nodo único).
No, MinIO no admite PutObjectAcl. Admite permisos a nivel de bucket, pero no ACL a nivel de objeto en esa forma de la API.
MinIO NO admite la API completa de AWS. Consulte AIStor Object Store Documentation para ver el conjunto completo de API compatibles.
MINIO_DOMAIN debe agregarse para que ocurran los buckets de estilo DNS, por lo que la PUT inválida sucede. Una vez que avanzamos, vemos las fallas en el XML frente a lo que se permite en los esquemas. Asegúrese de NUNCA implementar ninguna política que tenga variables no admitidas en el conjunto admitido que MinIO realmente admite.
Recuerde: S3-compatible NO significa que sea una coincidencia del 100% para todas las variables/endpoints/valores de la API AWS S3 admitidos.
