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.
Cela signifie-t-il que vous amorcez toujours une nouvelle image pour chaque déploiement créé à partir de l’image de base, en y ajoutant les modifications effectuées par precompile assets, ou utilisez-vous simplement une image unique et effectuez-vous le précompilage au moment de son démarrage ?
Techniquement, nous précompilons deux fois. Une première fois pour l’image de base avec nos modifications, et une seconde fois lors du déploiement de sites spécifiques avec des plugins spécifiques.
Cependant, notre configuration n’est pas quelque chose que vous adopteriez sauf si vous hébergez Discourse en tant qu’entreprise.
J’aimerais vraiment utiliser Discourse. Mais la façon dont ces développeurs utilisent la technologie des conteneurs m’empêche vraiment de l’utiliser. Je n’ai jamais vu de projet rendre une installation en conteneur aussi non portable que cela. Il existe bien de meilleures façons de résoudre ce problème. Il me semble que ce projet a évolué naturellement vers les conteneurs, mais ne sait pas vraiment comment les utiliser correctement. Et maintenant, le projet est coincé avec cette solution trop complexe et non portable. Et probablement, les contraintes de temps ne permettront pas de créer un conteneur portable approprié.
Veuillez fournir un Dockerfile qui construit un état cohérent. Documentez les variables d’environnement que les utilisateurs doivent utiliser pour modifier le comportement du conteneur. Et utilisez simplement un script d’entrée pour s’assurer que tout est démarré au moment de l’exécution. La combinaison de conteneurs peut être réalisée avec Docker Compose ou Kubernetes. Mais pas comme cela, c’est vraiment moyen.
J’essaie d’exécuter cela sur, par exemple, Fedora CoreOS, CentOS 8 ou Fedora 32. Mais ce n’est pas possible. Les standards des conteneurs le permettraient certainement. Mais c’est une manière très spécifique de soutenir essentiellement uniquement Ubuntu LTS. Alors que certaines personnes ont déjà abandonné Docker (surtout lorsqu’elles exécutent un service en tant que root). Mais les conteneurs sont standardisés, donc les gens peuvent décider d’utiliser Docker ou Podman. Mais cette création de Frankenstein rend cela très difficile, ce qui va à l’encontre du concept des conteneurs et de la sécurité moderne des conteneurs.
Essayez de regarder autour de 2014. Au début du projet, docker-compose n’existait pas vraiment.
C’est tout à fait vrai ! Peut-être pouvez-vous le corriger. Tout ce que vous avez à faire, c’est tout changer dans la façon de construire et de lancer un conteneur, puis constater que cela ne casse pas des milliers de sites fonctionnels.
OU, créez vos conteneurs de manière à pouvoir les lancer avec n’importe quel outil que les personnes qui savent comment les conteneurs doivent être utilisés apprécieront. Bitnami semble y être parvenu. Vous pouvez chercher ici et trouver beaucoup de gens qui ont eu des problèmes et n’ont nulle part où aller pour obtenir de l’aide.
Je sais que ce n’est pas une tâche facile. Mais l’objectif des conteneurs est d’assurer un état cohérent et portable. Ainsi, si les conteneurs sont utilisés comme ils devraient l’être, et que cela fonctionne pour vous, alors il y a de fortes chances que cela fonctionne pour tous ceux qui utilisent ce conteneur.
Si le processus de démarrage (bootstrap) était déplacé à l’intérieur du conteneur plutôt que sur l’hôte, vous feriez déjà un grand pas en avant vers la portabilité. Je peux jeter un œil après avoir terminé d’autres projets. Je ne suis pas non plus un expert des conteneurs, mais j’en ai créé quelques-uns. L’inconvénient, cependant, est qu’il n’existe aucune documentation d’installation, n’est-ce pas ? C’est simplement : « Voici, exécutez ce script. » Je peux essayer de reproduire ce que fait le script, mais cela ne laisse pas beaucoup de place pour des suggestions d’amélioration.
Donc, si la communauté, en particulier les personnes directement impliquées et disposant d’informations internes sur le fonctionnement de l’installation, est prête à conseiller ou à aider, alors je suis prêt à lancer cette initiative. Sinon, la qualité ne sera pas à la hauteur de vos attentes.
Les objectifs seraient plus ou moins les suivants :
- Un Dockerfile qui réalise une construction atomique de l’installation (sans bootstrap local en dehors du conteneur)
- Pas besoin d’exécuter le conteneur en tant que root ; l’idéal est d’utiliser fakeroot et d’ajouter des capacités (ce sont des arguments en ligne de commande ; les utilisateurs peuvent toujours choisir de démarrer un conteneur en tant que root…)
- Créer un script d’entrée (entrypoint) qui peut être influencé par des variables d’environnement, lesquelles doivent être clairement documentées
- Utiliser
podman-generate-systemdou un outil similaire pour créer une unité systemd afin de (redémarrer) un conteneur ou de le démarrer au démarrage (fonctionnalité de Podman ; Docker propose peut-être quelque chose de similaire, mais l’intégration est plus poussée)
Cela concernerait l’installation de base. Pour une solution évolutive, une solution docker-compose et Kubernetes est nécessaire. Je ne pense pas franchement que ce soit à la communauté Discourse de trouver une solution universelle, car ces éléments peuvent être très finement adaptés, surtout sur Kubernetes. Je suppose donc qu’une solution compose de base suffirait pour mettre les gens à niveau.
Cela fournirait une solution portable et plus sécurisée, augmentant ainsi l’adoption et la qualité globales. En attendant, je verrai si Discourse est vraiment ce dont j’ai besoin pour ma communauté. Si c’est le cas, j’utiliserai pour l’instant un système Ubuntu LTS. Une fois que j’aurai plus de temps, j’investirai dans une telle configuration.
Bonjour @AquaL1te,
J’ai déjà mis en œuvre certaines de vos suggestions. Cela peut utiliser Podman, Kubernetes ou Docker. Le mode rootless est pris en charge (pas de fakeroot). L’architecture repose sur 4 conteneurs : nginx, sidekiq, redis et le démon Ruby.
En général, il est possible de suivre la documentation d’installation pour les développeurs.
Il faut toutefois garder à l’esprit qu’il y a quelques aspects délicats liés à la manière dont Discourse gère les ressources statiques.
Ah, oui. J’ai été confus par la terminologie ; j’utilise beaucoup Singularity récemment, qui utilise l’option --fakeroot.
Je vais jeter un coup d’œil, cela semble très intéressant ! Je préfère en effet utiliser Fedora CoreOS pour cela, afin de maximiser le potentiel de sécurité d’une configuration conteneurisée. Ce n’est pas facilement possible pour le moment avec la configuration actuelle.
Cela me chiffonne toujours que la solution principale soit non portable et qu’il n’y ait aucun signe en faveur d’une solution moderne. Je vais examiner votre configuration plus en détail et, peut-être à l’avenir, je vous contacterai pour co-maintenir le projet. Si nécessaire, bien sûr. Merci pour votre travail et vos suggestions !
Je viens de terminer la lecture de ce fil de discussion colossal, et j’ai particulièrement résonné avec les besoins de Gkoerk, qui avait commenté plus haut le 19 octobre 2018 en cherchant de l’aide pour auto-héberger Discourse dans un swarm — apparemment pour l’inclure dans son docker-swarm-cookbook ultime. Waouh. Quelle collection ! Gkoerk serait décédé à la jeune âge de 40 ans. Putain. Il semblait être un vrai type génial et un contributeur formidable.