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