Gostaria de abrir uma discussão sobre as melhores práticas para realizar tarefas essenciais de manutenção em uma instância do Discourse, minimizando ou eliminando o tempo de inatividade.
Tarefas como alterar configurações críticas de recursos (por exemplo, UNICORN_WORKERS, DISCOURSE_SIDEKIQ_WORKERS, DISCOURSE_DB_POOL) ou aplicar atualizações importantes geralmente exigem um launcher rebuild app, que pode levar um tempo considerável, às vezes 30 minutos ou mais.
Minha pergunta é: Quais são as estratégias recomendadas para administradores de sistema realizarem essas atualizações essenciais e alterações de configuração com o mínimo de tempo de inatividade para o usuário?
Existem técnicas avançadas, como implantações blue/green ou outras estratégias de implantação sem tempo de inatividade, que são suportadas ou recomendadas para o Discourse? Ou o processo padrão de rebuild é o único método suportado, e o foco deve ser na otimização do tempo de reconstrução em si?
Estou interessado em ouvir qualquer pessoa que tenha experiência em gerenciar instâncias grandes ou com alto tráfego e como é o fluxo de trabalho deles para manutenção.
Se você tiver uma instalação de dois contêineres, o novo contêiner é criado enquanto o antigo está em execução. O tempo de inatividade é apenas o tempo que leva para iniciar o novo contêiner. O único problema é que você precisa de RAM suficiente para criar um contêiner enquanto o outro está em execução.
Se você quiser tempo de inatividade zero, precisará de um balanceador de carga que mantenha o contêiner antigo em execução até que o novo tenha iniciado completamente. Em seguida, você desliga o contêiner antigo e faz as migrações pós-atualização.
O Discourse é tão estável que isso é desnecessário para a maioria das instalações (mas acho que você pode considerar isso para requisitos de alta disponibilidade ou se estiver hospedando outras pessoas?!)
Acho que não tive uma única interrupção em 7 anos devido a uma “falha” de produção…
Os momentos de maior risco na vida de um Discourse são sempre na reconstrução.
A configuração de dois contêineres lhe dá a capacidade de inicializar uma nova compilação antes de se comprometer com ela, embora isso não detecte alguns erros de tempo de execução, é claro.
O problema é que, se suas migrações foram executadas, você pode precisar se comprometer com a nova compilação e, portanto, geralmente tentaria rastrear e corrigir a origem desses erros em vez de reverter.