Estou tentando entender a configuração de “tempo de inatividade zero” (zero downtime). Minha configuração atual possui algumas instâncias do Discourse para diferentes comunidades. Ambas têm a configuração de contêineres de dados/web 2. Tenho um Nginx no nível do host que lida com a terminação SSL e usa uma conexão em socket que é repassada para o Nginx do contêiner.
Encontrei estes dois tópicos de interesse:
Então, estou tentando entender esse processo. Parece haver um pouco de conhecimento prévio assumido para realizar isso. Qualquer ajuda que alguém possa fornecer aqui seria ótima.
A primeira coisa que gostaria de entender é como saber quando um contêiner de dados precisa ser atualizado. Parece haver casos em que você não pode apenas reconstruir o contêiner web. Como saber com certeza quando este é o caso? Seria em todos os casos em que a opção de atualização está desabilitada (cinza) no painel de administração para atualizações, juntamente com trabalhos personalizados potenciais com temas e plugins? Eu seria capaz de saber com certeza analisando as migrações do esquema do banco de dados? Eu precisaria ter um ambiente de staging e apenas tentar para saber com certeza?
A próxima coisa que gostaria de saber é como executar uma atualização com tempo de inatividade zero. Pela forma como os dois links parecem para mim, você estaria fazendo uma reconstrução do contêiner de dados e do contêiner web de qualquer maneira? Não consigo decifrar isso. Eu precisaria de contêineres de dados/web separados para conseguir o tempo de inatividade zero no final?
Qualquer orientação seria incrível! Provavelmente eu poderia gastar muitas horas e descobrir algo que parecia funcionar, mas prefiro me apoiar nos ombros de gigantes e não ter que descobrir casos de borda da maneira difícil (em produção), se possível.
Se você precisar de mais informações sobre minha configuração específica, por favor, peça esclarecimentos. Responderei diretamente e atualizarei esta postagem.
Não sei muito sobre “migração pós-implementação”, mas, de acordo com o que lembro de ter lido (aqui no meta), uma maneira de realizar isso é usando 3 contêineres: 1 de dados e 2 de web. Você atualiza o contêiner web que não está em execução e o troca pelo que está em uso assim que a atualização for concluída.
Acho que isso faz sentido. Então, o container de dados não executa uma reconstrução via launcher? Eu apenas lidaria com o balanceamento de carga no nível do host, usando o Nginx. Deixe-me ver se consigo organizar isso:
container de dados:
./launcher enter data_container
SKIP_POST_DEPLOYMENT_MIGRATIONS=1 rake db:migrate
Tudo depende de quais atualizações precisam ser feitas no contêiner de dados.
A atualização do Postgres 12 é um bom exemplo de tempo de inatividade inevitável. Mesmo que você tivesse um contêiner de dados duplicado, precisaria manter seu site duplicado em modo somente leitura enquanto a atualização do banco de dados ocorresse.
A única maneira de nunca ter tempo de inatividade é nunca atualizar. Atualizações via /admin/upgrade em uma instalação de contêiner único já são sem tempo de inatividade. Atualizações feitas via ssh, como quando a imagem base precisa ser atualizada, terão diferentes graus de tempo de inatividade, dependendo do seu orçamento e disposição para lidar com complexidade.
A melhor maneira de evitar tempo de inatividade é criar uma cópia de staging; caso contrário, você corre um pequeno risco de tempo de inatividade após cada atualização quando plugins ou personalizações enfrentam problemas de compatibilidade.
Certo. Então, para garantir que não terei um problema grave, farei uma execução no ambiente de staging e observarei os resultados… Assim, tentaria o procedimento acima e veria se o contêiner de dados falharia?
Se sim, meu staging poderia consistir em 1 servidor de dados e 1 servidor web, enquanto a produção teria 2 servidores de dados e 2 servidores web. No pior cenário, se tentarmos primeiro no staging e depois na produção, seria:
Se os usuários não conseguem acessar o site, isso é tempo de inatividade, obviamente.
Se eles não conseguem se registrar, postar, responder ou curtir, você consideraria isso tempo de inatividade?
Se for uma comunidade grande, os custos de executar vários contêineres de dados em SSD serão consideráveis. Você já considerou um servidor PostgreSQL externo, como o Amazon RDS?
Os tipos de detalhes que @Stephen está destacando são realmente importantes. Porque precisamos entender o que é tempo de inatividade zero; por exemplo, eu poderia burlar um requisito de Tempo de Inatividade Zero fazendo o seguinte:
Eu defino tempo de inatividade zero como nunca responder ao usuário com um código diferente de HTTP 200 quando a solicitação é válida (mantendo os códigos 300 e 400 abertos conforme necessário). Então, eu implanto o Discourse em um droplet de 10$ em uma solução de um único container e adiciono Add an offline page to display when Discourse is rebuilding or starting up para evitar erros 500. Dessa forma, não mostro um site que esteve fora do ar.
Eu, em uma mente racional, acharia que isso é tempo de inatividade zero? Nunca. Funciona conforme proposto? Claro. E eu poderia até adicionar um servidor de reserva em outra região para ficar ainda mais à prova de tempo de inatividade zero.
É por isso que qualificação e semântica são importantes. Não é a mesma coisa mostrar sempre algo do que sempre ter funcionalidade no site.
Ajude-nos a entender. O que você precisa para cumprir sua definição de tempo de inatividade zero? Os usuários podem ficar 10 a 30 minutos em modo somente leitura? Você tem conhecimento técnico para criar uma solução? Você está buscando oferecer aos nossos usuários uma página agradável com a mensagem Em manutenção, já voltamos. Precisamos de mais detalhes para fornecer uma solução mais precisa que realmente funcione para você. Ou, pelo menos, para orientá-lo na direção certa.
Esta discussão estava ficando um pouco acalorada e fora do tópico. Por favor, lembrem-se de ser respeitosos uns com os outros ao debater o tema. Perguntas de esclarecimento são feitas para fornecer uma resposta mais precisa, já que a configuração e os objetivos de cada um são diferentes.
e não ter que descobrir casos de borda da maneira difícil (em produção), se possível.