Nos exemplos desta página, você verá alguns cenários hipotéticos com frotas que ilustram alguns dos conceitos e práticas recomendadas dos nossos guias. Antes de ler este guia, você precisa conhecer os conceitos em Introdução às frotas e Requisitos e práticas recomendadas para frotas.
Exemplo 1: frotas com recursos de produção, preparo e desenvolvimento
Neste primeiro exemplo, há quatro clusters. Dois clusters são para produção
(em duas regiões para redundância), um para preparo e teste e o último
para desenvolvimento. Todos os clusters pertencem e são administrados
centralmente pela equipe da plataforma. Neste exemplo simples, há dois serviços:
frontend e backend. No entanto, cenários mais complexos podem ter um
número maior de serviços e clusters.
Abordagem 1: frotas separadas para produção, preparo e desenvolvimento
Uma abordagem possível para aproveitar frotas é criar frotas separadas para recursos de produção, preparo e desenvolvimento.
Para fazer isso, criamos três projetos de host de frota separada e colocamos
recursos neles ou, no caso do nosso cluster
de desenvolvimento local, registramos o cluster no projeto example-dev. Não foi preciso
resolver muitos dos problemas de semelhança de namespace e de serviço devido à
granularidade no exemplo, mas garantimos que os namespaces dos clusters prod-east e
prod-west foram normalizados.
A vantagem dessa abordagem é que temos um isolamento muito forte entre cada uma das frotas. A principal desvantagem dessa abordagem é que precisamos administrar três frotas diferentes, o que dificulta a consistência entre produção, preparo e desenvolvimento. Para equipes de desenvolvimento, também é mais difícil desenvolver com serviços preparados.
Abordagem 2: uma frota para todos os recursos
Nessa abordagem, criamos uma única rota para todos os recursos.
Para fazer isso, podemos deixar os recursos no projeto example e criar a
frota nesse projeto. Poderíamos ter separado nossos recursos
de produção e preparo colocando-os em outros projetos de host de frota e aproveitando a
VPC compartilhada, mas optamos por não fazer isso para simplificar
este exemplo.
Nessa abordagem, precisamos garantir que nossos namespaces e serviços estejam
normalizados em todo a frota. Por exemplo, renomeamos nosso frontend
genérico como frontend-prod e frontend-staging nos clusters de produção e preparo,
respectivamente. Por fim, embora possamos manter os nomes originais dos nossos
namespaces de desenvolvimento, fornecemos nomes mais claros (como frontend-dev-alice) para
indicar que eles são namespaces de desenvolvimento.
Com essa abordagem, estamos trocando o isolamento por uma maior facilidade de gerenciamento. Contamos com a autorização da malha de serviço para evitar comunicações indesejadas entre serviços, mas podemos administrar facilmente o sistema geral com uma única frota. Isso nos permite aplicar políticas em todos os recursos, o que nos dá a certeza de que o desenvolvimento parece muito próximo à produção.
Abordagem 3: frotas separadas para produção e não produção
Nessa abordagem, usamos uma configuração intermediária que combina os recursos de preparo e desenvolvimento em uma frota de não produção e coloca a produção em uma frota separada.
Para isso, criamos dois projetos de host de frota, um para produção e outro para
não produção. Também colocaremos nossos recursos diretamente nesses projetos, com o
cluster dev no local registrado na nossa frota de não produção. Precisamos
normalizar os namespaces e serviços entre nossos recursos de
preparo e desenvolvimento para oferecer mais clareza. Por exemplo, renomeamos frontend como
frontend-staging no cluster de preparo.
A vantagem é que a produção é bem isolada da não produção. Por
exemplo, podemos permitir que os serviços de desenvolvimento conversem com os serviços de preparo para
que o frontend da desenvolvedora Alice possa se comunicar com um backend de preparo enquanto
ela estiver desenvolvendo o serviço.
Resumo
Cada uma das abordagens descritas no exemplo 1 é válida. A escolha da sua organização depende do isolamento em relação à consistência (e facilidade de gerenciamento). Em outras palavras, é preciso definir o isolamento necessário entre diferentes tipos de recursos em relação à consistência necessária entre eles. É mais fácil conseguir uma consistência maior com menos frotas. A terceira abordagem é oferecida como um possível meio-termo, mantendo a produção completamente isolada e, ao mesmo tempo, oferecendo aos desenvolvedores a capacidade de trabalhar com serviços preparados.
Exemplo 2: frotas com diferentes proprietários de recursos
Para este exemplo, temos duas equipes: team-a e team-b. Essas equipes têm e
administram os próprios clusters, e ambas usaram namespaces frontend e
backend para os serviços que produzem. No entanto,
frontend e backend da equipe team-a não são iguais aos da equipe team-b. As duas equipes querem
criar uma malha de serviço para que os serviços possam interagir.
Sem intervenção, não há como tornar esses clusters parte da
mesma malha. Um bom ponto de partida é transferir a propriedade dos clusters para uma
equipe centralizada de plataforma para estabelecer a confiança entre eles. Como alternativa, se
as equipes team-a e team-b confiarem uma na outra, elas também podem se coordenar para estabelecer essa confiança.
A próxima etapa é normalizar o uso do namespace para que o frontend e
backend não fiquem mais sobrecarregados nos clusters dessas duas equipes. Depois disso,
elas podem estabelecer uma única frota para todos os recursos e criar
a malha de serviço deles.
Se esse nível de confiança não puder ser estabelecido, team-a e team-b precisam formar duas frotas separadas que usam dois projetos de host de frotas diferentes. A desvantagem dessa abordagem é que agora elas precisam usar a federação de malha, que é mais difícil de administrar do que uma única malha. A vantagem é que nenhuma equipe precisa normalizar os namespaces e serviços implantados, e somente a comunicação explícita e especificamente autorizada é possível.
