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.
Bedeutet das, dass Sie bei jedem Deploy, das aus dem Basis-Image plus den Änderungen durch precompile assets erstellt wird, immer noch ein neues Image bootstrappen, oder verwenden Sie einfach das einzelne Image und lassen es beim Hochfahren die Assets vorkompilieren?
Technisch gesehen kompilieren wir zweimal vor: Einmal für das Basis-Image plus unsere Änderungen und ein zweites Mal, wenn wir bestimmte Sites mit spezifischen Plugins bereitstellen.
Unser Setup ist jedoch nichts, was Sie übernehmen würden, es sei denn, Sie hosten Discourse als Unternehmen.
Ich würde Discourse wirklich gerne nutzen. Aber die Art und Weise, wie diese Entwickler die Containertechnologie einsetzen, hindert mich daran. Ich habe noch nie ein Projekt gesehen, das eine Container-Installation so nicht-portabel macht wie dieses. Es gibt viel bessere Wege, dies zu lösen. Mir scheint, dieses Projekt hat sich organisch in Richtung Container entwickelt, weiß aber nicht wirklich, wie sie eingesetzt werden sollten. Und jetzt steckt das Projekt in dieser übermäßig komplexen und nicht-portablen Lösung fest. Und wahrscheinlich werden Zeitbeschränkungen nicht erlauben, einen ordentlichen, portablen Container zu erstellen.
Bitte stellt eine Dockerfile bereit, die einen konsistenten Zustand herstellt. Dokumentiert die Umgebungsvariablen, die Nutzer verwenden sollten, um das Verhalten des Containers zu steuern. Und verwendet einfach ein Entrypoint-Skript, um sicherzustellen, dass alles zur Laufzeit gestartet wird. Das Kombinieren von Containern kann mit Docker Compose oder Kubernetes erfolgen. Aber nicht so – das ist wirklich mittelmäßig.
Ich versuche, dies z. B. auf Fedora CoreOS, CentOS 8 oder Fedora 32 auszuführen. Aber das ist nicht möglich. Die Container-Standards würden es certainly zulassen. Doch dies ist eine fein abgestimmte Methode, die im Grunde nur Ubuntu LTS unterstützt. Während einige Leute bereits von Docker abgerückt sind (insbesondere beim Ausführen eines Dienstes als root). Aber Container sind standardisiert, sodass Nutzer sich für Docker oder Podman entscheiden können. Doch dieses Frankenstein-Ding macht das sehr schwierig, was dem Konzept von Containern und moderner Containersicherheit widerspricht.
Schauen Sie sich mal das Jahr 2014 an. Als das Projekt begann, war docker-compose noch kaum etabliert.
Das ist leider wahr! Vielleicht können Sie es beheben. Alles, was Sie tun müssen, ist, alles an der Art und Weise, wie Container gebaut und gestartet werden, zu ändern, und dann zu sehen, dass dadurch nicht Tausende funktionierende Seiten kaputtgehen.
ODER: Stellen Sie Ihre Container so her, dass sie mit jedem Tool gestartet werden können, das von Leuten, die wissen, wie Container richtig verwendet werden sollten, begrüßt wird. Bitnami scheint das geschafft zu haben. Sie können hier suchen und werden viele Leute finden, die Probleme hatten und keine Hilfe finden konnten.
Ich weiß, dass das keine leichte Aufgabe ist. Aber der Zweck von Containern ist es, einen konsistenten und portablen Zustand zu gewährleisten. Wenn Container also wie vorgesehen verwendet werden und bei dir funktionieren, besteht eine recht hohe Wahrscheinlichkeit, dass sie auch für alle anderen funktionieren, die diesen Container nutzen.
Wenn das Bootstrap-Script allein in den Container verlegt würde, statt auf dem Host, hättest du bereits einen großen Schritt in Richtung Portabilität gemacht. Ich kann mir das ansehen, sobald ich andere Projekte abgeschlossen habe. Ich bin auch kein Container-Experte, aber ich habe einige erstellt. Der Nachteil ist jedoch, dass es keine Installationsdokumentation gibt, oder? Es heißt einfach: „Hier, führe dieses Skript aus.
Hallo @AquaL1te,
Ich habe einige deiner Vorschläge umgesetzt. Es kann mit Podman, Kubernetes oder Docker betrieben werden. Rootless wird unterstützt (nicht fakeroot). Es wird ein 4-Container-Setup mit Nginx, Sidekiq, Redis und dem Ruby-Daemon verwendet.
Im Allgemeinen können die Entwickler-Installationsanleitungen befolgt werden.
Etwas, das man beachten sollte, sind einige knifflige Aspekte im Umgang mit den Assets von Discourse.
Ah, ja. Ich war mit der Terminologie verwirrt; ich habe kürzlich viel Singularity verwendet, das eine --fakeroot-Option nutzt.
Ich werde mir das ansehen, es klingt sehr gut! Da ich dafür lieber Fedora CoreOS verwende, um das Sicherheitspotenzial einer containerisierten Umgebung voll auszuschöpfen. Das ist im aktuellen Setup derzeit nicht einfach möglich.
Es stört mich immer noch, dass die Hauptlösung nicht portierbar ist und es keine Anzeichen für eine moderne Lösung gibt. Ich werde mir dein Setup genauer ansehen und vielleicht werde ich dich in der Zukunft kontaktieren, um es gemeinsam zu pflegen. Wenn nötig, natürlich. Vielen Dank für deine Arbeit und Vorschläge!
Ich habe gerade diesen ganzen Thread, der eine wahre Herausforderung war, zu Ende gelesen. Besonders angesprochen haben mich die Bedürfnisse von Gkoerk, der am 19. Oktober 2018 einen Kommentar verfasst hat, in dem er Hilfe beim Selbsthosten von Discourse in einem Swarm suchte – anscheinend zur Integration in sein Mutter-aller-docker-swarm-cookbook. Wow. Was für eine Sammlung! Gkoerk ist reportedly im jungen Alter von 40 Jahren verstorben. Verdammt. Er schien ein wirklich großartiger Typ und Mitwirkender zu sein.