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.
Discourse può distribuire frequentemente immagini Docker che non necessitano di essere bootstrapate?
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.
Questo significa che create ancora una nuova immagine per ogni deployment partendo dall’immagine di base più le modifiche apportate da precompile assets, oppure utilizzate un’unica immagine e la fate compilare al momento dell’avvio?
Tecnicamente eseguiamo la precompilazione due volte. La prima volta per l’immagine di base più le nostre modifiche. La seconda volta quando distribuiamo siti specifici con plugin specifici.
Tuttavia, la nostra configurazione non è qualcosa che fareste a meno che non ospitaste Discourse come attività commerciale.
Vorrei davvero usare Discourse. Ma il modo in cui questi sviluppatori utilizzano la tecnologia dei container mi impedisce di farlo. Non ho mai visto un progetto che renda un’installazione in container non portatile come questa. Esistono modi molto migliori per risolvere il problema. A mio avviso, questo progetto si è evoluto organicamente verso i container, ma non sembra sapere come utilizzarli correttamente. Ora il progetto è bloccato con una soluzione eccessivamente complessa e non portatile. E probabilmente le restrizioni temporali non permetteranno di creare un container portatile adeguato.
Per favore, fornite un Dockerfile che porti a uno stato coerente. Documentate le variabili d’ambiente che gli utenti dovrebbero utilizzare per modificare il comportamento del container. Utilizzate semplicemente uno script di entrypoint per garantire che tutto venga avviato a runtime. L’orchestrazione dei container può essere gestita con Docker Compose o Kubernetes, ma non in questo modo: è davvero mediocrità.
Cerco di eseguirlo su, ad esempio, Fedora CoreOS, CentOS 8 o Fedora 32, ma non è possibile. Gli standard dei container lo consentirebbero certamente. Invece, questa è una soluzione troppo specifica che di fatto supporta solo Ubuntu LTS. Mentre alcune persone si sono già allontanate da Docker (specialmente quando si esegue un servizio come root), i container sono standardizzati, quindi gli utenti possono scegliere tra Docker o Podman. Ma questa sorta di Frankenstein rende tutto molto difficile, andando contro il concetto stesso di container e la sicurezza moderna dei container.
Prova a dare un’occhiata intorno al 2014. Quando il progetto è iniziato, docker-compose non esisteva davvero.
Vero! Forse puoi risolverlo. Tutto quello che devi fare è cambiare tutto su come costruire e avviare un container e vedere che non rompe migliaia di siti funzionanti.
OPPURE, crea i tuoi container in modo da poterli avviare con qualsiasi strumento che piaccia a chi sa come dovrebbero essere utilizzati i container. Sembra che Bitnami l’abbia fatto. Puoi cercare qui e trovare molte persone che hanno avuto problemi e non hanno dove andare per chiedere aiuto.
So che non è un compito facile. Tuttavia, lo scopo dei container è garantire uno stato coerente e portatile. Quindi, se i container vengono utilizzati come dovrebbero e funzionano per te, c’è un’alta probabilità che funzionino per chiunque utilizzi quel container.
Se il processo di bootstrap venisse spostato all’interno del container, invece di essere eseguito sull’host, si farebbe già un grande passo avanti verso la portabilità. Posso darci un’occhiata dopo aver terminato altri progetti. Nemmeno io sono un esperto di container, ma ne ho costruiti alcuni. Lo svantaggio, però, è che non esiste documentazione di installazione, giusto? È semplicemente: “Eccolo, esegui questo script”. Potrei provare a replicare ciò che fa lo script, ma questo non lascia molto spazio a suggerimenti di miglioramento.
Quindi, se la comunità, in particolare le persone coinvolte da vicino e che hanno informazioni interne su come dovrebbe funzionare l’installazione, sono disposte a dare consigli o aiuto, allora sono disposto a lanciare questa iniziativa. Altrimenti, la qualità non sarà quella che ci si aspetta.
Gli obiettivi sarebbero più o meno i seguenti:
- Un Dockerfile che preveda una build atomica dell’ambiente (nessun bootstrap locale esterno al container)
- Nessuna necessità di eseguire il container come root; l’ideale è utilizzare fakeroot e aggiungere capabilities (questi sono argomenti da riga di comando; gli utenti possono comunque scegliere di avviare un container come root…)
- Creare uno script di entrypoint influenzabile da variabili d’ambiente, che devono essere chiaramente documentate
- Utilizzare
podman-generate-systemdo qualcosa di simile per creare un’unità systemd per (ri)avviare un container o avviarne uno all’avvio del sistema (funzionalità di Podman; forse Docker ha qualcosa di simile, ma è più orientato all’integrazione)
Questo sarebbe per l’installazione di base. Per una soluzione scalabile, è necessaria una soluzione docker-compose e Kubernetes. Onestamente, non ritengo che sia responsabilità della comunità Discourse trovare una soluzione universale, poiché questi aspetti possono essere adattati con grande precisione, specialmente su Kubernetes. Quindi, immagino che una soluzione compose di base sia sufficiente per permettere alle persone di prendere confidenza.
Questo fornirebbe una soluzione portatile e più sicura, aumentando l’adozione e la qualità complessiva. Nel frattempo, verificherò se Discourse è davvero ciò di cui ho bisogno per la mia comunità. Se lo è, per ora utilizzerò un sistema Ubuntu LTS. Quando avrò più tempo, investirò nello sviluppo di un tale ambiente.
Ciao @AquaL1te,
Ho già implementato alcune delle tue suggerimenti. È possibile utilizzare Podman, Kubernetes o Docker. Il supporto rootless è attivo (non fakeroot). La configurazione prevede 4 container: nginx, sidekiq, redis e il demone Ruby.
In generale, è possibile seguire la documentazione per lo sviluppo del progetto.
Tieni presente che ci sono alcuni aspetti complessi relativi alla gestione delle risorse statiche (asset) in Discourse.
Ah, sì. Ero confuso dalla terminologia; ultimamente ho usato molto Singularity, che utilizza il flag --fakeroot.
Ci darò un’occhiata, sembra davvero ottimo! Preferisco usare Fedora CoreOS per questo, per massimizzare il potenziale di sicurezza di un ambiente containerizzato. Al momento, con la configurazione attuale, questo non è facilmente realizzabile.
Mi dà ancora fastidio che la soluzione principale non sia portabile e che non ci siano segnali verso una soluzione moderna. Esaminerò più approfonditamente la tua configurazione e, forse in futuro, ti contatterò per co-mantenere il progetto. Se necessario, ovviamente. Grazie per il tuo lavoro e i tuoi suggerimenti!
Ho appena finito di leggere tutto questo thread mostruoso e mi sono sentito particolarmente in sintonia con le esigenze di Gkoerk, che ha commentato sopra il 19 ottobre 2018 cercando aiuto per l’auto-ospitazione di Discourse in uno swarm – apparentemente per includerlo nel suo docker-swarm-cookbook definitivo. Wow. Che raccolta incredibile! Si dice che Gkoerk sia morto prematuramente all’età di 40 anni. Maledizione. Sembrava davvero una persona fantastica e un grande contributor.