Rebuilds are far from a common or regular practice. Most upgrades can be performed from /admin/upgrade
And for sites where any server error is a problem there are guides on how to present a holding page during the upgrade process.
I have to perform rebuilds when I add or remove plugins, and when they are mandated by the occasional upgrade (several times a year). But yes, it’s not a showstopper for a local community forum like mine, and /admin/upgrade works very well for regular updates.
I present a holding page during my rebuild upgrades for the benefit of users, but how would the Googlebot perceive this? To the bot, my homepage suddenly has no intra-site links, and all the pages the bot has previously indexed have their content replaced with the holding page.
If you’re catching all requests with a 302 to show the holding page there should be zero impact. Google confirmed a couple of years back that redirects don’t impact SEO/pagerank:
Gary is the “House Elf and Chief of Sunshine and Happiness at Google” (Webmaster Trends Analyst)
If you’ve just rebranded the 502 error page then yes, it will have an impact.
What you don’t understand is that most of the people deploying discourse don’t know what docker is, much less care about best practices.
If you want a docker image, just use pups to generate it yourself. Is that what you guys do, @sam? Do create a separate container image for each enterprise client with their plugins?
If you want to avoid downtime when you need to rebuild, make a 2 container configuration. You can search here or look in discourse-setup for a command line option that will build one for you. Then downtime is limited to the time it takes for the new container to boot up.
If you want zero downtime, configure haproxy with multiple web containers.
There’s a very large number of people running their own servers who are looking for this exactly. I know personally dozens of hobbyists who are looking for a forum which is truly self-hosted, not on a droplet or other VPS. Many self-hosting enthusiasts run multiple apps (think Nextcloud, Plex, Wikis, CMS/Blogs, etc.), whether they actually host them or run them on a VPS. Here’s my situation: I’m running docker swarm for dozens of apps. It seems to me at least that the way the tool works now it can’t be incorporated into a docker swarm with Traefik or HAProxy reverse-proxying requests.
Maybe (hopefully!) I’m mistaken and you can explain or point me to instructions on how to take your final, single completed container, reference it in a new docker-compose and run it in a swarm?
I understand that. But the developers of Discourse do, and they depend on it for their deployments. I apologize, I don’t know what pups is. Looks like it’s related to Ansible, which I don’t know.
Debt in the deployment management code & process. It is very complicated right now with lots of moving parts and things that are difficult to understand and support. One of docker’s primary draws is the encapsulation of prerequisite code and builds which complete prerequisite work with less risk of a user messing something up, especially if the whole thing is ultimately wrapped in a script to create/upgrade the installation. That gives those who don’t (and don’t need to) understand docker well a good solution, and gives engineers or “hobbyists” a solution as they could skip the wrapper and compose things the way they want.
One of the things I think overlooked here is that a major reason for self-hosting is control over data and backups, etc. Docker makes this especially convenient since you can bind volumes and back those up, and even run a container in the stack whose role is backing up the DB to a flat file in the backup location. When you can’t self-host it along with other docker apps, it effectively means you cannot self-host on your server, you need to purchase a VPS just for Discourse, rather than reusing the same hardware and ecosystem that works for the vast majority of apps which use docker in their deployment.
By way of disclaimer, I am not employed or compensated by any hardware vendor, Saas provider, or forum software developers.
Think about how many potentially unnecessary Digital Ocean, Linode, and VULTR subscriptions Discourse has been responsible for launching. Then consider that there are companies making a revenue stream hosting Discourse for others in part because it is too complex for them:
The Discourse forum software is fantastic, but quite hard to install and host it yourself. We think it’s too great a product to be limited to a technical audience only.
Then again, the way you’ve modeled your revenue-stream, it makes zero sense making things easier to install and run in simple to use containers which expose only necessary ports and bind mounts, using environment variables for everything else so that deployment is as simple as docker stack deploy or docker-compose up. Like I said - maybe and hopefully I’m the one mistaken, and there’s a way to take the final docker container and deploy it in a swarm or other compose environment with other apps and a reverse proxy.
This is exactly the point many folks have been making in this lengthy thread: Is there a solution for those who do know what nano is and can exit VI / VIM just fine? I trust you know your customer base better than I, but I have to imagine that such basic knowledge of Linux is the case for the overwhelming majority of those wanting to self-host open-source software on Linux.
Yes. Create a web_only.yml (there is a sample in discourse_docker) and use that to build your docker image with your plugins. Then add it to your swarm. Everything can be configured via environment variables; you can see them in the last line when you to a ./launcher start web_only. It’s not that hard, but you’re not going to get free support here to help you figure it out (and it’s not just you but a whole bunch of people with a zillion different definitions of Best Practices who would need much, much more help than you would).
I can probably help you figure out what you need to know in an hour or two of my time.
Recently I found the commands to fast forward a git clone depth 1:
git checkout --detach #avoid tangle with git tree state
git fetch --depth 1 -f -origin [branch|commit]
git checkout -f [branch|commit]
Thanks to archive.org team.
So would running ./launcher bootstrap mybase that had the bundle exec rake db:migrate; bundle exec rake assets:precompile added to the init script do something like that? Just run it against a test database, or maybe strip those rake tasks out of web.template.yml?
EDIT: Found this comment:
# this allows us to bootstrap on one machine and then run on another
which might answer my question.
¿Eso significa que aún inicializan una nueva imagen para cada despliegue que se crea a partir de la imagen base más los cambios realizados por precompile assets, o simplemente usan la imagen única y la hacen precompilar cuando se inicia?
Técnicamente, precompilamos dos veces. Una vez para la imagen base más nuestros cambios, y una segunda vez al desplegar sitios específicos con plugins específicos.
Sin embargo, nuestra configuración no es algo que harías a menos que estuvieras alojando Discourse como negocio.
Me encantaría usar Discourse. Pero la forma en que estos desarrolladores utilizan la tecnología de contenedores me impide hacerlo. Nunca he visto un proyecto que logre hacer que una instalación en contenedor sea no portátil de esta manera. Hay muchas mejores formas de solucionar esto. Para mí, parece que este proyecto evolucionó orgánicamente hacia los contenedores, pero no sabe realmente cómo deberían usarse. Y ahora el proyecto está atrapado con esta solución excesivamente compleja y no portátil. Probablemente, las restricciones de tiempo no permitirán crear un contenedor portátil adecuado.
Por favor, proporcionen un Dockerfile que construya un estado consistente. Documenten las variables de entorno que los usuarios deben utilizar para manipular el comportamiento del contenedor. Y simplemente usen un script de punto de entrada para asegurar que todo se inicie en tiempo de ejecución. La combinación de contenedores puede hacerse con Docker Compose o Kubernetes. Pero no así; esto es realmente decepcionante.
Intento ejecutar esto en, por ejemplo, Fedora CoreOS, CentOS 8 o Fedora 32. Pero no es posible. Los estándares de contenedores definitivamente lo permitirían. Sin embargo, esto es una forma muy específica de básicamente solo admitir Ubuntu LTS. Aunque algunas personas ya se han alejado de Docker (especialmente al ejecutar un servicio como root), los contenedores están estandarizados, por lo que las personas pueden decidir usar Docker o Podman. Pero esta mezcla extraña haría eso muy difícil, lo cual va en contra del concepto de contenedores y la seguridad moderna de contenedores.
Intenta buscar en 2014. Cuando el proyecto comenzó, docker-compose realmente no existía.
¡Qué cierto! Tal vez tú puedas solucionarlo. Todo lo que necesitas hacer es cambiarlo todo sobre cómo construir e iniciar un contenedor y ver que no rompa miles de sitios que funcionan correctamente.
O bien, crea tus contenedores de modo que permitan iniciarse con cualquier herramienta que a las personas que saben cómo deben usarse los contenedores les guste. Bitnami parece haberlo logrado. Puedes buscar aquí y encontrar a muchas personas que han tenido problemas y no tienen a dónde acudir para obtener ayuda.
Sé que no es algo fácil de hacer. Pero el propósito de los contenedores es tener un estado consistente y portable. Así que si los contenedores se utilizan como deberían, y funciona para ti, entonces hay una probabilidad bastante alta de que funcione para todos los que usen ese contenedor.
Si el bootstrap se moviera dentro del contenedor, en lugar de en el host, ya habrías avanzado bastante en hacerlo portable. Puedo echar un vistazo después de terminar otros proyectos. Tampoco soy un experto en contenedores, pero he construido algunos. Sin embargo, la desventaja es que no hay documentación de instalación disponible, ¿verdad? Es simplemente: aquí tienes, solo ejecuta este script. Puedo intentar replicar lo que hace el script. Pero eso no deja mucho margen para sugerencias de mejora.
Así que si la comunidad, especialmente las personas estrechamente involucradas y con información interna sobre cómo debería funcionar la instalación, están dispuestas a aconsejar/ayudar, entonces estoy dispuesto a iniciar esta iniciativa. De lo contrario, la calidad no será la que quieres ver.
Los objetivos serían más o menos:
- Un Dockerfile que tenga una construcción atómica de la configuración (sin bootstrap local fuera del contenedor)
- Sin necesidad de ejecutar el contenedor como root; lo mejor es usar fakeroot y agregar capacidades (estos son argumentos de línea de comandos; la gente aún puede elegir iniciar un contenedor como root…)
- Crear un script de punto de entrada que pueda ser influenciado por variables de entorno, las cuales deben estar claramente documentadas
podman-generate-systemdo algo similar puede usarse para crear una unidad de systemd para (re)iniciar un contenedor, o iniciar un contenedor al arrancar (característica de Podman; quizás Docker tenga algo similar, pero se trata más de integrarlo)
Eso sería para la instalación básica. Para la solución escalable, se necesita una solución docker-compose y Kubernetes. Lo cual, francamente, no considero responsabilidad de la comunidad de Discourse encontrar una solución que sirva para todos. Porque estas cosas pueden adaptarse muy finamente, especialmente en Kubernetes. Así que supongo que una solución compose básica sería suficiente para que la gente se ponga al día.
Esto proporcionará una solución portable y más segura, aumentando la adopción y la calidad en general. Mientras tanto, veré si Discourse es realmente algo que necesito para mi comunidad. Si lo es, entonces usaré un sistema Ubuntu LTS por ahora. Una vez que tenga más tiempo, invertiré tiempo en una configuración así.
Hola @AquaL1te,
He realizado parte de lo que sugieres. Puede utilizar Podman, k8s o Docker. Se admite modo sin privilegios de root (no fakeroot). Utiliza una configuración de 4 contenedores con nginx, sidekiq, redis y el daemon de Ruby.
En general, se pueden seguir las instrucciones de instalación para desarrolladores.
Hay que tener en cuenta que hay algunos aspectos complejos relacionados con la forma en que Discourse gestiona los activos.
Ah, sí. Me confundí con la terminología; he estado usando mucho Singularity últimamente, que utiliza el parámetro --fakeroot.
Lo revisaré, ¡suena muy bien! Porque prefiero usar Fedora CoreOS para esto, para aprovechar al máximo el potencial de seguridad de una configuración contenerizada. Esto no es fácilmente posible en la configuración actual.
Aún me molesta que la solución principal no sea portátil y que no haya indicios de una solución moderna. Examinaré tu configuración con más detalle y, quizás en el futuro, te contacte para colaborar en su mantenimiento. Si es necesario, por supuesto. ¡Gracias por tu trabajo y tus sugerencias!
Acabo de terminar de leer todo este hilo monumental y especialmente me identifico con las necesidades de Gkoerk, quien comentó arriba el 19 de octubre de 2018 buscando ayuda para autoalojar Discourse en un swarm, aparentemente para su inclusión en su docker-swarm-cookbook definitivo. Vaya. ¡Qué recopilación! Según se informa, Gkoerk falleció a la temprana edad de 40 años. Maldita sea. Parecía un tipo genuinamente excelente y un gran contribuidor.