fititnt
commented
5 years ago Troquei de 2.0-alpha para 3.0-alpha.
Talvez este ponto de questão acabe sendo resolvido mais fácil com uso de kubernetes e k3s e para as implementações usando docker puro que ainda estiverem sendo usadas (como nosso foco é algo amigável e idealmente resiliente para não especialistas) a gente nem mesmo dê opção para quem for usar e alertar que valeria a pena pagar um pouco mais e ter VPSs que suportem pelo menos um nó tudo-em-um em kubernetes.
Veja também
Afeta (neste momento):
Independente de como dentro da rede de docker/tsuru seja gerenciado dados em cluster, se for para deixar a Águia Pescadora com idealmente manutenção relativamente mínima, tem casos muito específicos em que arquivos precisam ser compartilhados entre as VPSs.
Um exemplo mais imediato é (pelo menos sem ajustes finos) como é feito em tempo real desafio para descobrir se quem pediu um certificado para o Let's Encrypt realmente deveria receber ele.
Vamos dizer que por padrão é aconselhado para os usuários apontarem domínios customizados para um CNAME que este usa Delta, Echo e a Foxtrot. A máquina que receber a primeira visita via o https://github.com/EticaAI/aguia-pescadora/issues/16 vai solicitar ao Let's encrypt que lhe dê a chave. Porém o Let's encrypt vai tentar descobrir se ela merece isso, só que poderá escolher qualquer um dos 3 servidores ativos para perguntar. E isso implica em ter 33% de acertar. E rodar logo em seguinda não quer dizer que vai conseguir, porque o Let's Encrypt pode ter cacheado a errada.
Uma das formas de fazer isso (sem desligar 2 balanceadores de carga apenas pra obter uma TLS nova) seria garantir que o desafio escrito no disco em um servidor possa ser acessado ao mesmo tempo (uns 200ms, talvez?) nos demais. Isso seria suficiente para pelo menos um dos servidores receber a chave privada dele.
Esse arquivo de desafio acaba sendo um dos mais criticos. A chave privada da SSL (que é lida o tempo todo pelo provedor de HTTPS) até pode ser sincronizada com os demais depois de segundos (ou mesmo deixar uma rotina de 5 minutos) fazendo isso.
Uma das soluções: o GlusterFS
Eu já tenho experiência com GlusterFS, mas esse é um dos casos em que se houver alternativa melhor, eu usaria. Eu não tenho como culpar o software por algo que é um problema do desafio em si, mas eu abri esse issue aqui porque talvez isso seja um dos pontos mais problemáticos.
Ok que nesse caso aqui, os servidores da Águia Pescadora são muito mais poderosos do que os que tenho em cliente em produção em alta disponibilidade na amazon são paulo, mas de toda uma pilha de software em cliente o glusterfs é uma das que menos já consegui otimizar.
Pensem que o fato de ter sincronia em tempo real (aka se escrever em um servidor, o outro ao ler tem como saber que leu um arquivo que todo mundo está lendo) implica em deligar várias super otimizações de cache de kernel de linux. E isso pode afetar performance de forma absurda. É triste.