Te lo agradezco, ¡pero reconstruir la aplicación lleva unas 3 horas!
Y esto es en un VPS masivo.
¿No sería genial poder eliminar plugins de la misma manera que podemos añadir y eliminar temas?
¿Quizás algo a considerar como característica en el futuro?
¡¡Gracias!!
¿¡Perdón!? ¿Debería tardar unos 20 minutos?
no está aquí
La instalación original tardó 2 horas.
Ahora, el ./launcher rebuild app se ha ido hasta el punto:
Ensuring launcher is up to date
Fetching origin
Updating Launcher...
Updating eeefdde..30be122
Fast-forward
image/base/install-imagemagick | 5 ++++-
launcher | 2 +-
templates/web.letsencrypt.ssl.template.yml | 2 +-
templates/web.template.yml | 6 +++---
4 files changed, 9 insertions(+), 6 deletions(-)
Launcher updated, restarting...
Ensuring launcher is up to date
Fetching origin
Launcher is up-to-date
Stopping old container
+ /usr/bin/docker stop -t 60 app
app
Unable to find image 'discourse/base:2.0.20220818-0047' locally
2.0.20220818-0047: Pulling from discourse/base
1efc276f4ff9: Pulling fs layer
1b880e64942b: Pulling fs layer
794f6dc9a2ff: Pulling fs layer
1efc276f4ff9: Verifying Checksum
1efc276f4ff9: Download complete
1efc276f4ff9: Pull complete
794f6dc9a2ff: Verifying Checksum
794f6dc9a2ff: Download complete
1b880e64942b: Verifying Checksum
1b880e64942b: Download complete
1b880e64942b: Pull complete
794f6dc9a2ff: Pull complete
Digest: sha256:7734701087766821ffb2ddcef423754798bd345c2ac0d550131c6e6905c268e8
Status: Downloaded newer image for discourse/base:2.0.20220818-0047
Y después de la última línea, simplemente sigue parpadeando (el proceso está en curso)
Eso es desde hace unos 30 minutos.
La última vez que hice esto, tardó 160 minutos completos.
Memoria total del servidor: 4.657GiB, Versión del kernel: 5.15.0-43-generic, Sistema operativo: Ubuntu 22.04 LTS, disco SSD de 50GB, 2.5 núcleos, 5 hilos Intel® Xeon® CPUs
…
No estoy seguro de qué podría estar mal, aparte de que tarda mucho tiempo 
3 horas suena muy mal. Debes investigar este problema y resolverlo como primera prioridad.
Hay ‘pausas visuales’ en el registro de compilación, esto es normal, pero ese retraso no lo es.
Mi presentimiento es que de alguna manera estás empezando a usar swap durante la compilación, pero no soy un SA. ¿Estás ejecutando algo más en esa máquina?
Las descargas requieren descomprimir, y eso es computacionalmente costoso, pero son las mismas imágenes para todos.
Como referencia, acabo de reconstruir un sitio justo ahora y tomó 13 minutos, 46 segundos en una máquina de 2GB 2vCPU en https://scaleway.com
No, este es un VPS que es exclusivamente para esta instancia de Discourse. Y ejecuto muchos otros VPS con la misma compañía, los cuales funcionan sin problemas (pero no son instancias de Discourse, son otras aplicaciones como instancias personalizadas de PHP o CMS WP/CP, etc.).
No tengo conocimiento de ningún uso de swap, y no puedo ver ningún pico en el uso de recursos que lo justifique.
Ahora está en building.... - parece un poco más rápido que la última vez, sin embargo, todavía está claramente por encima de los 20 minutos.
Preguntaré a los proveedores del servidor si pueden detectar algo inusual en sus sistemas, sin embargo, recuerdo que me dijeron personalmente que su propia instancia de Discourse tardó aproximadamente 2 horas en compilarse. (PD: Estos VPS están en máquinas Hetzner alquiladas a través de un tercero, dudo que pueda conseguir algo mejor).
En cualquier caso, mi sugerencia se mantiene en que sería increíble poder agregar y eliminar plugins como podemos hacer con los temas. ¿Quizás es algo a considerar?
Realmente no sé nada, pero AFAIK no es posible, porque Discourse son muchos javascript compilados. Cuando hay necesidad de agregar o quitar algo que cambia cómo actúa y funciona el núcleo, debe haber una reconstrucción.
Situación muy similar a la de Varnish, por ejemplo.
Ok…
Por cierto, me registré con la gente del servidor y, efectivamente, alcanzamos el 100% de memoria.
¿¿¿5 GB??? 5 GB de RAM es demasiado para consumir en cualquier cosa.
Los requisitos de Discourse dicen que necesita 1 GB de RAM.
Y ahora está atascado en lo siguiente:
104:M 04 Oct 2022 07:19:27.251 # Redis está listo para salir, adiós...
sha256:662695076506add39a630c2169b8b618f0121386951e93c6ffd2a6473107ae55
f4a95a1e69d5375e6ea30dfb22576209d249e5bc67b04a6fa09df289b1441888
Eliminando contenedor antiguo
+ /usr/bin/docker rm app
app
Por lo tanto, ni siquiera puedo actualizar el servidor, ya que el proceso se interrumpiría.
Realmente, no creo que este sea un problema del servidor en absoluto. Si necesitamos 1 GB, entonces 5 GB deberían ser más que suficientes.
Algo está mal con esto, enormemente mal.
Entiendo que otros deben tener una mejor experiencia (mirando a @merefield, quien dijo que actualizara en un 2 GB…), sin embargo, no está funcionando para nosotros como debería.
De todos modos, supongo que esto está fuera de tema en este hilo.
Acabo de reconstruir otro sitio, 4 GB, 3 vCPU, de nuevo \u003c 15 minutos (es decir, la memoria/CPU adicional en realidad no ayudó mucho en mi caso, ¡pero todavía lejos de horas!).
Lo único que acabo de notar es que mi VPS usa vfs en lugar de los aufs u overlay sugeridos.
Sin embargo, según esto Can't run ./launcher rebuild app - Docker storage driver is unsupported - #45 by david, no debería ser nada importante, y por lo tanto ejecutamos el lanzador con --skip-prereqs, porque de lo contrario ni siquiera podemos ejecutar Discourse.
Me pregunto si hay algo más en ese requisito del controlador de almacenamiento.
Eso es un poco… demasiado optimista. Para fines de prueba puede ser suficiente, y puede ser un poco justo incluso entonces. 2 GB está mucho más cerca de la realidad.
4 GB son suficientes para instancias más grandes, sin embargo. Pero la cantidad y la potencia de los núcleos también juegan un papel importante.
Y aun así… si tienes 5 GB y la reconstrucción tarda tanto tiempo, debe haber algo mal.
Estoy en DigitalOcean/4 GB/2 vCPU Intel y la reconstrucción tarda alrededor de 25 minutos.
¿Cuál es tu sistema exactamente, además de app.yml? ¿Hay algo personalizado?
Hola, la única personalización es la que mencioné antes (vfs en lugar de aufs/overlay).
El resto es estándar.
Servidor:
Memoria total del servidor: 4.657GiB, Versión del kernel: 5.15.0-43-generic, Sistema operativo: Ubuntu 22.04 LTS, Unidad SSD de 50 GB, 2.5 núcleos, 5 hilos Intel® Xeon® CPUs
yaml es original aparte de estos plugins adicionales:
discourse-assign
discourse-chat
discourse-checklist
discourse-docs
discourse-reactions
discourse-solved
discourse-surveys
discourse-voting
docker_manager
styleguide
No veo en esos datos por qué la reconstrucción llevaría tanto tiempo.
Yo haría girar en un VPS de Ubuntu del mismo tamaño en otro lugar. Solo para averiguar si el problema proviene de la empresa de alojamiento. Le cuesta unos cuantos dólares y un trabajo de una o dos horas.
Se necesita mucha memoria para precompilar el javascript. Intenta añadir swap.
La superposición
Creo que esa prueba puede estar ahí por una razón. Este podría ser tu problema.
¿Por qué 5 GB de RAM con Discourse vanilla necesitarían más swap si los más pequeños están totalmente contentos con lo que obtuvieron automáticamente?
Porque es más fácil que hacer lo que realmente necesitas hacer.
Agregar swap podría ayudar, pero no es tu mayor problema.
Supongo que debería haber intentado esto antes de desplegar el contenedor de discourse: How to change the Docker storage driver – Webdock
Aparentemente es posible cambiar el controlador de almacenamiento, contrariamente a lo que me indicó el host cuando desplegamos el contenedor (que era editar el archivo del cargador o ignorar la verificación).
Duh, ahora es demasiado tarde, supongo.
Gracias de todos modos, si esta es la causa de los problemas, supongo que es culpa del usuario. Mea culpa 
No lo creo.
Además, la configuración de dos contenedores ha reducido el tiempo de inactividad, ya que reconstruyes el nuevo contenedor web mientras el antiguo sigue funcionando.
¿Qué tan grande es tu sitio? Yo añadiría swap independientemente para abordar el problema de la memoria.
Una instancia en blanco de 1 GB con 1 GB de swap funciona bien para una pequeña comunidad de prueba, pero tan pronto como crezca, eso no será suficiente. El swap marca absolutamente la diferencia.
Si reconstruir en un VPS “masivo”, ubicado en un centro de datos con una conexión a Internet potente, lleva 3 horas, y reconstruir mi instalación en https://discourse-on-a-pi.falco.dev, que se ejecuta en una placa del tamaño de una tarjeta de crédito en mi escritorio, conectada a Internet a través de un plan doméstico estándar en un país del tercer mundo, lleva solo 14 minutos (+4 minutos cuando hay una nueva imagen de contenedor), hay algo mal en el producto que te están vendiendo…
¿Cómo está el uso de memoria en el servidor? Si está al límite o cerca de la capacidad antes de empezar a reconstruir, tendrá mucha paginación y eso sin duda hará que todo tarde excesivamente.
Si ese es el caso, le sugiero que deshabilite temporalmente cualquier otra cosa que pueda estar ejecutándose en el servidor, si es posible.