Ik wil graag een discussie openen over de best practices voor het uitvoeren van kernonderhoudstaken op een Discourse-instantie met minimale of geen downtime.
Taken zoals het wijzigen van kritieke resource-instellingen (bijv. UNICORN_WORKERS, DISCOURSE_SIDEKIQ_WORKERS, DISCOURSE_DB_POOL) of het toepassen van grote updates vereisen doorgaans een launcher rebuild app, wat aanzienlijke tijd kan duren, soms 30 minuten of langer.
Mijn vraag is: Wat zijn de aanbevolen strategieën voor systeembeheerders om deze essentiële updates en configuratiewijzigingen met de minste gebruikersgerichte downtime uit te voeren?
Zijn er geavanceerde technieken, zoals blue/green deployments of andere zero-downtime deploymentstrategieën, die worden ondersteund of aanbevolen voor Discourse? Of is het standaard rebuild-proces de enige ondersteunde methode, en moet de focus liggen op het optimaliseren van de rebuild-tijd zelf?
Ik ben geïnteresseerd in de ervaringen van iedereen die grote of drukbezochte instanties beheert en hoe hun workflow voor onderhoud eruitziet.
If you have a two container install, the new container builds while the old one runs. Downtime is just the amount of time it takes to launch the new container. The only issue is that you need enough ram to build a container while the other runs.
If you want zero down time then you need a load balancer that keeps the old container running until the new one has fully started. Then you shut down the old container and do the post update migrations.
Discourse is so stable this is pretty unnecessary for most installs (but I guess you might consider it for very high availability requirements or if you are hosting others?!)
I don’t think I’ve had a single outage in 7 years due to a production “glitch” …
The riskiest moments in a Discourse’s life is always at rebuild.
the two container setup gives you the ability to bootstrap a new build before committing to it though that won’t catch some runtime errors of course.
The issue is that if your migrations have run, you might need to commit to the new build and so you would usually try to track down and fix the source of those errors rather than roll back.