Я хотел бы обсудить лучшие практики выполнения основных задач обслуживания экземпляра Discourse с минимизацией или полным исключением простоев.
Такие задачи, как изменение настроек критических ресурсов (например, UNICORN_WORKERS, DISCOURSE_SIDEKIQ_WORKERS, DISCOURSE_DB_POOL) или применение крупных обновлений, обычно требуют выполнения команды launcher rebuild app, что может занять значительное время — иногда 30 минут и более.
Мой вопрос: Какие рекомендуемые стратегии существуют для системных администраторов, чтобы выполнять эти важные обновления и изменения конфигурации с минимальным временем простоя для пользователей?
Существуют ли какие-либо передовые техники, такие как сине-зелёное развёртывание или другие стратегии развёртывания без простоя, которые поддерживаются или рекомендуются для Discourse? Или стандартный процесс rebuild является единственным поддерживаемым методом, и основное внимание следует уделить оптимизации самого времени развёртывания?
Мне интересно услышать от тех, у кого есть опыт управления крупными или высоконагруженными экземплярами, и узнать, как выглядит их рабочий процесс при проведении технического обслуживания.
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.