No se puede reconstruir la aplicación: controlador de almacenamiento de docker no compatible (btrfs)

Instalación
1

Vamos a migrar nuestro servidor y la instalación de Discourse.
Estamos utilizando un nuevo servidor con el sistema de archivos btrfs.

Estoy haciendo algunas pruebas en una máquina de prueba, he copiado todos los archivos y he instalado todas las partes necesarias (nginx, docker, el propio Discourse).

Lo he intentado con un sistema de archivos ext4 y funcionó bien.
Pero ahora, cuando hago lo mismo con un sistema de archivos formateado en btrfs, obtengo este error cuando intento ‘launcher rebuild app’:

Su instalación de Docker no está utilizando un controlador de almacenamiento compatible. Si continuáramos, podría tener una instalación defectuosa.
overlay2 es el controlador de almacenamiento recomendado, aunque zfs y aufs también pueden funcionar.
Se sabe que otros controladores de almacenamiento son problemáticos.
Puede saber qué sistema de archivos está utilizando ejecutando "docker info" y mirando la línea 'Storage Driver'.

Si desea continuar de todos modos utilizando su controlador de almacenamiento no compatible existente,
lea el código fuente de launcher y descubra cómo omitir esta verificación.

Obviamente, docker info indica que está utilizando btrfs.
He leído en este foro que Discourse tiene problemas con algunos controladores de almacenamiento de Docker y por eso se niega a reconstruir.

¿Hay alguna forma de cambiarlo a ‘overlay’ u otro controlador compatible con Discourse y capaz de recuperar los archivos del sistema de archivos btrfs?

¿Cómo debería configurar Docker?
¿Es posible hacerlo solo para el contenedor de Discourse y dejar el resto de la configuración de Docker por defecto?

Gracias.

2

Nota

Tanto overlay como overlay2 no están soportados actualmente en btrfs o en cualquier sistema de archivos Copy on Write y solo deben usarse sobre particiones ext4.

Dado que Docker no soporta el uso del controlador overlay2 sobre btrfs, parece que la recomendación de la herramienta launcher es el alcance de tus opciones aquí. Es decir, continuar ejecutando Discourse en un sistema donde Docker está respaldado por ext4 o modificar launcher para ignorar el controlador de almacenamiento y esperar lo mejor.

Comentar (anteponer # a) la línea exit 1 en las siguientes líneas del script launcher con tu editor de texto preferido logrará lo último si deseas tomar esa ruta:

Sin embargo, considerando que “Otros controladores de almacenamiento se sabe que son problemáticos”, no recomendaría hacer eso.

1 me gusta
3

Gracias por tu rápida respuesta.

Entonces, si lo he entendido bien, Docker no puede utilizar ningún otro controlador de almacenamiento alternativo para acceder a los archivos del sistema subyacentes si estás utilizando un sistema de archivos COW como btrfs.

Por lo tanto, no hay una buena solución, ya que Discourse podría tener problemas al utilizar el controlador de almacenamiento btrfs de Docker.

Revertir a ext4 no es una opción, ya que toda la migración se realizó para asegurar que los archivos de datos se mantuvieran bajo el sistema de archivos COW btrfs y su capacidad para tomar instantáneas y mantener los datos limpios.

No tiene sentido utilizar btrfs en otras partes del sistema, ya que su objetivo principal es proporcionar acceso al foro de Discourse.

Es una lástima porque sería genial tenerlo funcionando con la protección de un sistema de archivos COW.

Es más fácil usar la bandera --skip-prereqs. Pero usarla en el sistema de producción puede ser arriesgado.
Lo he probado en la máquina de pruebas y funciona bien por ahora, pero el problema parece ser a largo plazo.

4

Usar --skip-prereqs omite muchas otras pruebas que, como mencionas, introducen varios riesgos al realizar una reconstrucción. Comentar esa única línea no es más ni menos arriesgado que ejecutar en btrfs y debería fusionarse automáticamente cuando el lanzador se actualiza, lo que significa que probablemente puedas hacer el cambio una vez y olvidarte de él en su mayor parte.

1 me gusta
5

OK; gracias, no me había dado cuenta de eso.

6

Para ser sincero, ese mensaje estaba dirigido al antiguo devicemapper, que era un problema conocido de fiabilidad.

A lo largo de los años utilizamos aufs y, más recientemente, utilizamos el controlador overlay2, sin ningún problema. Si quieres probar con brtfs, por favor, informa aquí dentro de unos meses.

2 Me gusta
7

Gracias.
En el servidor de producción, me temo hacerlo.
Si hay problemas con el controlador de Docker y escribe datos corruptos, tener instantáneas, copias de seguridad o lo que sea no te ayudará si hay una caída.
Si hay alguna forma segura de mantener los datos en una copia de seguridad, podría intentarlo…
¿Qué tipo de problemas ocurrieron en el pasado?

Pero hoy en día, estos sistemas de archivos COW son muy útiles. Puede tomar instantáneas, los datos están protegidos contra corrupciones durante la escritura u otros fallos, es fácil agregar espacio o mover dispositivos…

Sería genial si pudiéramos verlo en Discourse en el futuro.
Quizás pueda ayudar a probarlo. Lo tengo funcionando en una máquina de prueba.

8

El problema es que si edito el archivo del lanzador para agregar btrfs a la lista de controladores de almacenamiento de Docker compatibles, cuando ejecuto el script, se queja de que el script ha sido modificado localmente y será sobrescrito por la versión remota (de GitHub). ¿Cómo soluciono esto?

9

¿Cuál es el mensaje exacto que estás viendo y en qué punto de la reconstrucción ocurre?

Acabo de iniciar una VM que uso para probar y modifiqué la línea, luego la reconstruí. En el punto en que el lanzador se actualiza a sí mismo, hizo el git pull y realizó una fusión fast-forward como esperaba, dejando la modificación intacta.

La versión de la que estaba actualizando no incluía un cambio en el lanzador en sí, pero esperaría que funcionara de la misma manera siempre que no haya un conflicto, es decir, siempre que esa línea exit 1 o líneas muy cercanas no se cambien en el repositorio.

1 me gusta
10

Gracias por tu respuesta e interés.
Permíteme intentar aclarar.

He modificado el script del lanzador para incluir btrfs como uno de los formatos aceptados.
En la función check_prereqs he cambiado:

if ! $docker_path info 2> /dev/null | egrep -q 'Storage Driver: (btrfs|aufs|zfs|overlay2)$'; then

Cuando intenté por primera vez reconstruir la aplicación con el lanzador, recibí un mensaje que decía que el lanzador había sido modificado localmente y si quería continuar descargando archivos del origen.

Así que tuve que dejarlo como estaba, hacer la reconstrucción y cambiarlo después para iniciar la aplicación.

Pero hoy he intentado hacer una reconstrucción de nuevo, y parece que detecta el cambio pero no se queja y el cambio se conserva.

No sé si algo ha sido cambiado recientemente en el lanzador y originalmente podría haber tenido un lanzador antiguo que no hacía la reconstrucción y ahora sí (después de actualizarlo ayer).

Lo estoy probando con btrfs y todo parece funcionar bien, puedes iniciar y detener la aplicación, hacer copias de seguridad, todo funciona bien por ahora.

Docker parece crear subvolúmenes btrfs para los datos de almacenamiento de los contenedores cuando detecta que se está ejecutando en un sistema de archivos btrfs y utiliza el controlador de almacenamiento btrfs.
Así que parece que hace algunas optimizaciones al clonar contenedores o tomar instantáneas a través de comandos de docker.

Pero no sé si el controlador puede ser defectuoso de alguna manera (no parece un controlador experimental en docker, no hay avisos sobre su uso en btrfs o no pude encontrarlos) y si sería mejor (si es posible) cambiar la información de docker para ejecutarlo usando el controlador overlay2 como si se estuviera ejecutando en un sistema de archivos estándar.
En teoría, sería posible que docker escribiera su archivo y realizara operaciones en un sistema de archivos btrfs sin tener en cuenta sus capacidades (ya que btrfs no es diferente de otros sistemas de archivos a nivel de usuario, para E/S de archivos).

Se agradecen opiniones o experiencias sobre el uso del controlador de almacenamiento docker btrfs o la configuración del controlador overlay2 para ser utilizado al usar docker en un sistema de archivos btrfs.

11

No tengo experiencia directa que ofrecer, pero desaconsejaría firmemente forzar a Docker a permitir que el controlador overlay2 se use sobre btrfs. No está explícitamente soportado y el controlador overlay2 podría estar haciendo suposiciones sobre el sistema de archivos que pueden ser o no ciertas para btrfs, lo que podría llevar a varios resultados inesperados. Realmente no quieres resultados inesperados a nivel de sistema de archivos.

Las operaciones de bajo nivel del sistema de archivos serán manejadas por Docker y el controlador de almacenamiento btrfs. Si esa es una combinación madura y bien mantenida, que no tiene errores conocidos como devicemapper, hay una buena posibilidad de que funcione bien.

La razón por la que btrfs no está soportado en Discourse, según entiendo, no es porque se espere que falle, sino simplemente porque no tienen suficiente información para decir a la gente que funcionará.

No tienen ningún incentivo (o suficiente) para ejecutar sus propios servidores en btrfs, por lo que la única forma de obtener esa información es a través de personas de la comunidad que lo prueben en producción y reporten después de períodos prolongados de tiempo. Eso aún no ha sucedido, por lo que sigue sin estar soportado.

Si te encuentras en esta situación en el futuro, siempre puedes restablecer el cambio, actualizar y luego aplicar el cambio nuevamente antes de ejecutar el lanzador:

cd /var/discourse
git reset --hard
git pull
sed -i 's/Storage Driver: (/Storage Driver: (btrfs|/' launcher
./launcher rebuild app
1 me gusta
12

Muchas gracias.

Así que no intentaré usar el controlador de almacenamiento overlay2 de Docker sobre el sistema de archivos btrfs, dejaré que Docker use el controlador btrfs esperando que funcione correctamente y sin ningún problema.
Aquí Docker Storage Drivers | Learn the Different Storage drivers of Docker dicen que es el enfoque recomendado y compatible oficialmente para SLE Linux, pero recomendado en Ubuntu.
Debian 10 y 11 soportan btrfs en el kernel sin modificaciones y soportan el arranque desde una partición btrfs (solo la partición UEFI debería ser de otro tipo).

Así que asumo que está bien probado.

La respuesta de Rafael parece indicar que no hay ninguna razón especial para no usarlo. Los problemas eran con devicemapper y pusieron la solicitud de usar sistemas de archivos conocidos, probablemente en un momento en que no había tanta atención a btrfs u otros sistemas COW.

Lo intentaré.
Informaré de mi experiencia (buena o mala) en su uso.
Por ahora funciona sin problemas y me permite cambiar fácilmente el tamaño del sistema de archivos, añadir dispositivos, eliminarlos, etc., y me da la confianza de que los datos subyacentes son correctos y se mantendrán sin errores.
La única precaución es con el controlador de almacenamiento de Docker si no está lo suficientemente probado, pero parece que se ha utilizado ampliamente en SLE (que implementa btrfs como sistema de archivos de almacenamiento predeterminado desde hace mucho tiempo).

1 me gusta
13

Tengo que decir que hemos estado ejecutando el servidor de producción durante 9 días en un sistema de archivos BTRFS sin ningún problema.

Había probado previamente en un servidor de pruebas.
Y he movido el foro de un lugar a un subvolumen, he añadido y quitado discos y espacio del sistema de archivos, sin problemas.

Informaré después de más tiempo usándolo.

Soy bastante nuevo en BTRFS y no lo conozco en profundidad, pero no es tan difícil y funciona como se esperaba.

2 Me gusta
14

Tengo que decir que hemos estado ejecutando Discourse en el sistema de archivos btrfs durante casi un mes sin ningún problema.

Funciona sin problemas.
Los controladores btrfs de Docker parecen funcionar perfectamente.
Sería genial si otras personas probaran Discourse ejecutándose sobre btrfs y el soporte btrfs pudiera integrarse en la distribución de Discourse.

Detenemos el foro por un momento, tomamos la instantánea usando btrfs (un par de segundos) y lo ejecutamos de nuevo.
Luego hacemos una copia de seguridad externa de la instantánea tomada.

Parece que funciona perfectamente.
He restaurado la copia de seguridad en otra máquina para probar y funciona.

El

2 Me gusta
15

¡Me alegra oír eso! ¿Puedes enviar una PR que lo añada a

16

Lo intentaré. No soy muy hábil con GitHub, espero hacerlo bien.

Hecho, he hecho el PR, espero haberlo hecho bien.

1 me gusta
17

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