Tsuru Cluster Águia Pescadora #4
Comments
|
TL;DR: a ideia inicial de configurar o águia pescadora com tsuru seria a seguinte
Outro ponto: Pelo menos uma das VPSs idealmente deveria permitir executar Apps menos confiáveis. Talvez até mesmo os apps dela teriam até bloqueio específico para tentar conectar nas demais (mesmo que isso seja feito via docker e não via Tsuru) Mais detalhes dos motivos por trás disso: Rascunho de ideia geral de arquitetura
Sobre os nósSituação atualSobre nós menores ou maiores que a situação atualNo caso desse fornecedor específico que tem preços super interessantes e os benchmarks de performance definitivamente não deixam a desejar as VPSs de 8 GB de RAM são as menores que são custo benefício. Até tem umas de 4 GB de RAM, mas seriam apenas 1 euro a menos e o HD não seria SSD. Tendo isso em mente talvez possam entender porque nesse provedor talvez tentar um setup com 6 VMs menores seria talvez até mais caro porque propositalmente dão um preço bom: ele nem as tem. Outro ponto também é que no caso de VMs existe um custo de setup (que é equivalente a 1 mes de uma VM SSD pequena). Ou seja, ainda que os preços sejam interessantes, ficar criando novas VMs para depois desistir acaba encarecendo. Sobre porque tem uma VM maiorA Delta é maior do que as outras duas porque um dos servidores que foi aposentado, a Bravo fititnt/cplp-aiops#16, também tinha o propósito de servir para eventuais tarefas que fossem mais pesadas. E as duas menores existem além dessa maior porque também estava querendo desativar um Galera Cluster que estava em 3 VMs idênticas fititnt/cplp-aiops#45. Considerando o preço do Setup, e também que talvez em algum momento (por exemplo, se os servidores estivessem super dimensionados e não sendo tão usados ainda já nesses próximos meses) então eu iria optar por deixar apenas uma máquina ligada e desativar as demais. E nesse planejamento provavelmente a que ficaria ligada por tempo indeterminado seria a Bravo de 16GB de RAM. Em teoria nem todos os apps seriam confiáveisExiste uma situação onde alguns apps poderiam executar código menos confiável. Um exemplo é que executar um trabalho sob demanda de compilar código de linguagens de programação (i.e. um Evalbot / compilebot). Então mesmo sem ir muito a fundo como é isolamento dentro do Tsuru, mas assumindo o que conheço de docker, em um caso extremo onde um conteiner é comprometido a VM em que ele está correria mais riscos do que outras VMs. Claro que sugestões de como fazer esses tipos de conteiners em especial ter uma proteção extra (mesmo que não seja usando comandos do tsuru, mas sim diretamente no Docker) são bem vindas também. mas estou dizendo isso para dar ideia de porque prefiro que pelo menos os conteiners que rodam o core do tsuru estejam simetricamente em todas as máquinas. O ideal seria que pelo menos uma das três máquinas fosse aquela em que é possível correr mais riscos. |
|
pertinente:
Estou refazendo o cluster inteiro (não demora muito considerando que ainda não temos dados de usuário, mesmo sabendo que não estou usando Puppet ou Ansible) porém dessa vez vou começar a fazer ajustes também nas portas dos apps do Tsuru. Como isso também poderia afetar o MVP #5 vou manter em pasta original, e deixar uma separada que não precisa necessariamente ser tão amigável. Uma pessoa que quer conhecer o Tsuru já poderia ficar sobrecarregada apenas com MVP dele, então creio que vou deixar uma diario-de-bordo/tsuru-inicializacao++ para conter essas informações extras. |
…s do zero, veja openresty (#16) e #4 (comment)
|
Atualização rápida aqui: possivelmente o Águia Pescadora tenderá a ser uma pilha de soluções inteira, sendo que o Tsuru seria uma delas para usuário do Etica.Dev poder usar. O principal impacto disso é que deve demorar mais tempo, e que mesmo as soluções como o https://github.com/kubernetes-sigs/kubespray não são completas o suficiente. Porém acredito que vale a pena. Criar um Tsuru para usar 1 nó (vide fititnt/cplp-aiops#59), ou mesmo um pequeno cluster Tsuru (vide #5 e as pastas deste repositório diario-de-bordo/tsuru-inicializacao e diario-de-bordo/tsuru-inicializacao++) já foi feito. Eu só não fiz de primeira já em Ansible porque tinha certo preconceito de muitos anos atrás da época que eu usava Puppet e achava que outras ferramentas de IaC não teriam tanto aumento de produtividade para quantidade menor de máquinas, mas tem sim. Então posso estar errado, mas talvez com uma boa ferramenta de IaC como Ansible de para incluir ainda mais softwares na pilha de soluções e procurar otimizar para gente que tenha menos conhecimento de infra. Ou seja, mesmo que implique em demorar mais, vou procurar otimizar os playbooks para tentar proteger quem ainda não saiba tanto assim. Ainda assim, a documentação atual sem Ansible pode permitir quem queira fazer passo a passo. A principal dificuldade que alguem poderia ter ao usar o tsuru-inicializacao e o tsuru-inicializacao++ não foi inclusa na versão atual é que não documentei como usar volumes (pense pasta de upload de arquivos dos apps) com Tsuru sem Kubernetes e não documentei como criar pelo menos um Service de MySQL ou Postgres. E estou indo para Kubernetes (que eu meses atrás queria evitar, porém para por Docker em produção vale a pena pela quantidade de integrações que tem) por causa de manutenibilidade do dia a dia. |
Principais issues relacionados
The text was updated successfully, but these errors were encountered: