El administrador de Discourse autoalojado durante 10 años pregunta: ¿por qué no limpiar el lanzador como parte de la reconstrucción?

Hola a todos. Mi nombre es Lee y he estado autoalojando Discourse de forma intermitente desde 2013. Recuerdo tener que lidiar con rbenv para empezar. Recuerdo tener que compilar nginx con Phusion Passenger para que las cosas funcionaran. Recuerdo haber discutido con @sam probablemente hace diez malditos años que cambiar a Docker era capitular a la debilidad del desarrollador de “me funciona en mi directorio personal y mi pesadilla de archivos ocultos” (¡y estar completamente equivocado!). Recuerdo la primera vez que escuché la frase “bike-shedding”. Para citar al hombre, lo recuerdo todo.

Después de estar ausente durante varios años, he tenido la ocasión de volver a autoalojar Discourse como reemplazo de los comentarios nativos de Wordpress en un sitio de noticias meteorológicas del área de Houston que normalmente tiene ~10k PV/día, pero durante los huracanes, puede tener ~2 millones de PV/día para ~1 millón de visitantes únicos. Hemos tenido problemas con los comentarios nativos de Wordpress durante años, pero a partir del pasado miércoles, estamos en vivo con Discourse autoalojado. (¡Y en Graviton3, nada menos! En serio, simplemente funciona y es genial).

Aquí está el punto al que quiero llegar: es 2025, y como autoalojador, sigo lidiando con la gestión manual de mi espacio de imágenes de docker. Presento una historia sobre /dev/root, contada en fragmentos de código, después de menos de una semana en producción:

[11:49:56] 0 ✓ (1.8ms)
root@discourse:/var/discourse # df -h
Filesystem       Size  Used Avail Use% Mounted on
/dev/root         30G   21G  9.6G  69% /
tmpfs            7.7G     0  7.7G   0% /dev/shm
tmpfs            3.1G  1.1M  3.1G   1% /run
tmpfs            5.0M     0  5.0M   0% /run/lock
efivarfs         128K  3.6K  125K   3% /sys/firmware/efi/efivars
/dev/nvme1n1p16  891M  109M  720M  14% /boot
/dev/nvme1n1p15   98M  6.4M   92M   7% /boot/efi
/dev/nvme0n1      32G  346M   30G   2% /var/discourse
tmpfs            1.6G   12K  1.6G   1% /run/user/1001
overlay           30G   21G  9.6G  69% /var/lib/docker/overlay2/5a649418bbfc064f488e895572eec1ace487a3eaa324fe1d8e3b395e6c5e3645/merged

[11:49:59] 0 ✓ (4.8ms)
root@discourse:/var/discourse # ./launcher cleanup
WARNING! This will remove all stopped containers.
Are you sure you want to continue? [y/N] y 
Total reclaimed space: 0B
WARNING! This will remove all images without at least one container associated to them.
Are you sure you want to continue? [y/N] y
Deleted Images:
untagged: discourse/base@sha256:3696bdf18652b5455bd33795ec3b8e0f201c17a04f0e0126fc0317ed821373cd
....

[una enormidad de líneas redactadas]

....
Total reclaimed space: 12.43GB

[11:50:34] 0 ✓ (27.8s)
root@discourse:/var/discourse # df -h
Filesystem       Size  Used Avail Use% Mounted on
/dev/root         30G  6.9G   24G  23% /
tmpfs            7.7G     0  7.7G   0% /dev/shm
tmpfs            3.1G  1.1M  3.1G   1% /run
tmpfs            5.0M     0  5.0M   0% /run/lock
efivarfs         128K  3.6K  125K   3% /sys/firmware/efi/efivars
/dev/nvme1n1p16  891M  109M  720M  14% /boot
/dev/nvme1n1p15   98M  6.4M   92M   7% /boot/efi
/dev/nvme0n1      32G  346M   30G   2% /var/discourse
tmpfs            1.6G   12K  1.6G   1% /run/user/1001
overlay           30G  6.9G   24G  23% /var/lib/docker/overlay2/5a649418bbfc064f488e895572eec1ace487a3eaa324fe1d8e3b395e6c5e3645/merged

[11:55:28] 0 ✓ (3.3ms)
root@discourse:/var/discourse #

Los amo. Amo Discourse. Estoy casado con el producto y tengo la intención de seguir usándolo más o menos para siempre.

Pero, como… ¿por qué? ¿Por qué es 2025 y yo, por mi cuenta, sigo lidiando con la gestión manual de launcher cleanup? ¿Por qué la gestión de imágenes no es una función inherente de launcher?

De nuevo, los amo. Elegí Discourse para SCW porque creo en lo que han construido y me encanta usarlo. Pero es como si la mitad del volumen de arranque de mi pobre AMI estuviera ocupado con basura inútil que podría —al menos si entiendo el lado técnico de las cosas— ser gestionada automáticamente.

No pretendo quejarme, solo estoy volviendo a revisar después de unos años alejado de la silla de administrador. Me encanta la detección de spam con IA y la clasificación con IA, especialmente en un foro meteorológico donde las publicaciones políticamente cargadas sobre el cambio climático (a favor o en contra) son una característica habitual. Gracias por todo <3

7 Me gusta

¡Genial verte de vuelta, Lee!

Me pasó lo mismo en mi sitio autoalojado esta semana. Las copias de seguridad fallaban y lo dejé pasar una semana más o menos porque estaba fuera y no tenía acceso a mi portátil. Tan pronto como regresé, ejecuté la limpieza y recuperé mucho espacio en disco, y las copias de seguridad pudieron ejecutarse de nuevo.

4 Me gusta

¡Hola, me alegra verte de vuelta por aquí!

Parte de ello es que ha sido “suficientemente bueno”: no lo usamos internamente en nuestro hosting ya que rotamos frecuentemente contenedores e imágenes, por lo que nuestra cadencia es muy diferente a la que tendría un sitio autoalojado.

La otra explicación aquí es que, entre el lanzador y docker, ningún sistema quiere asumir la plena responsabilidad del calendario de eliminación de datos: el calendario para eliminar los datos del usuario debe estar bajo el control total del usuario.

Me he encontrado con algunos problemas en sitios autoalojados donde la limpieza también limpia la nueva base de discourse que necesitaba construir, lo que lleva a un terrible problema de huevo o gallina. Que esto no se note debido a que se ejecuta automáticamente probablemente sería un obstáculo para intentar resolverlo.

Una sugerencia simple aquí podría ser programar un docker system prune o launcher clean bajo su propio riesgo. ¿Podría funcionar?

6 Me gusta

Porque a veces puede eliminar el único contenedor que funciona que tienes.
Podrías ejecutarlo cada vez antes de ejecutar una reconstrucción, mientras todos tus contenedores que funcionan siguen en ejecución.

1 me gusta

Buena idea, a veces las respuestas simples son las mejores. ¡Gracias, y así lo haré!

¿Cómo puedo/podemos responder sí al ejecutar ./launcer cleanup a través de cron? Me refiero a que para mí los contenedores no son un gran problema, pero las imágenes huérfanas sí lo son.

1 me gusta

No hay razón para hacerlo con cron, solo creas nuevas imágenes cuando construyes una con launcher. Solo necesitas hacerlo antes o después de construir una imagen.

Si quieres evitar las indicaciones de launcher, puedes hacerlo con los comandos docker como se sugirió anteriormente. Aquí tienes uno (pero lee el manual para asegurarte de lo que hace y que es lo que quieres):

/usr/bin/docker image prune -a -f
1 me gusta

Tengo que echarle un vistazo. Gracias.

No sé nada más, pero hoy, de nuevo, la reconstrucción falló porque me quedaban menos de 5 GB de espacio libre. Claro, cleanup hizo el trabajo, y eso no fue más que un poco molesto. Y aun así, me gustaría no ver tales situaciones.

Y aquí se demuestra lo poco que entiendo cómo funciona Docker :joy: Si entendí bien, esas imágenes, que fueron destruidas porque no eran utilizadas por ningún contenedor, no eran imágenes en el sentido de fotos como había pensado todo el tiempo :face_with_peeking_eye: :rofl:

2 Me gusta

La respuesta directa es que podrías echo y | launcher cleanup para enviar “y” anticipadamente.

La respuesta indirecta es que la limpieza real del lanzador (después de que sea equivalente) es con estos dos comandos:

docker container prune --force --filter until=24h
docker image prune --all --force --filter until=24h

y el aviso al que creo que te refieres es para eliminar directorios de datos antiguos de postgres:

rm -rf /var/discourse/shared/standalone/postgres_data_old*

Podrías eliminar la dependencia del lanzador y usar esos comandos directamente.

2 Me gusta

En realidad me refiero a las preguntas que obtuve al ejecutar ./launcher cleanup. Primero elimina todos los contenedores que están detenidos. Luego, ofrece eliminar todas las imágenes que no son utilizadas por al menos un contenedor, y esa parte es la que me libera espacio, cerca de 40 GB la última vez.

Por eso he estado bastante confundido porque no podía entender por qué tenía tantas imágenes huérfanas (jpg, png, etc.). Pero estamos hablando aquí de imágenes totalmente diferentes, ¿verdad?

Sí, reconstruyo al menos dos veces por semana. O más recientemente, cuando estaba cazando un plugin que se comportaba mal, hice al menos una docena de reconstrucciones.

¿Hará una nueva imagen cada vez? No lo sé.

Cada reconstrucción es una nueva imagen, por lo que se acumularían si no se limpian.

El lanzador actualmente solo solicita limpiar al ejecutar otros comandos una vez que el espacio en disco es bajo.

1 me gusta

Lo que puede ser un fastidio si lo ejecutas con un script; el script simplemente se quedará colgado esperando una respuesta (supongo que por eso se le pasa yes a través de una tubería). Yo simplemente hago una limpieza si el disco tiene menos de 10 GB libres.

1 me gusta

Aquí hay quizás una posible solución alternativa que podría funcionar para mí. Lo menciono aquí en caso de que sea útil para otros.

Estoy contemplando agregar una configuración data-root a /etc/docker/daemon.json, para ver si eso obliga a Docker a colocar sus imágenes —las imágenes de Discourse, en este caso, ya que no hay nada más alojado en la máquina— en una ubicación menos crítica que no haga estallar mi volumen de arranque.

Buscando en meta hilos anteriores sobre esto me da un par de resultados que en realidad no me dicen mucho, y antes de que mi instancia de producción de Discourse colapse en un montón humeante y en llamas, quería preguntar para ver si esto es viable :slight_smile:

Tomé un enfoque diferente y monté un sistema de archivos separado en /var/lib/docker

En mi caso, por razones muy específicas del sitio, elegí sistemas de archivos separados para cada uno de /var/discourse/shared, /var/discourse/shared/data, /var/discourse/shared/app/uploads/default/original y /var/lib/docker — pero si solo quieres tener /var/discourse como un sistema de archivos separado, probablemente podrías crear el directorio /var/discourse/share/docker y montarlo en /var/lib/docker (obviamente haciendo esto con el sistema en reposo y moviendo archivos según sea necesario).

4 Me gusta

¡Esa es una idea aún mejor que manipular las entrañas de Docker! ¡Gracias!

1 me gusta

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