As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Simplificação da implantação de aplicações multilocatário no Amazon EKS usando o Flux
*Nadeem Rahaman, Aditya Ambati, Aniket Dekate e Shrikant Patil, Amazon Web Services*
## Resumo
Diversas empresas que fornecem produtos e serviços atuam em setores regulados por dados e devem preservar a separação de dados entre suas áreas internas. Este padrão descreve como você pode usar o recurso multilocatário no Amazon Elastic Kubernetes Service (Amazon EKS) para desenvolver uma plataforma de dados que garanta isolamento lógico e físico entre locatários ou usuários que compartilham um único cluster do Amazon EKS. O padrão oferece isolamento por meio das seguintes abordagens:
+ Isolamento entre namespaces no Kubernetes
+ Regras de controle de acesso com base em função (RBAC)
+ Políticas de rede
+ Cotas de recurso
+ AWS Identity and Access Management Funções (IAM) para contas de serviço (IRSA)
Além disso, a solução usa o Flux para garantir que a configuração do locatário permaneça imutável durante a implantação das aplicações. É possível implantar as aplicações do locatário especificando o repositório do locatário que contém o arquivo `kustomization.yaml` do Flux na sua configuração.
Este padrão realiza a implementação de:
+ Um AWS CodeCommit repositório, AWS CodeBuild projetos e um AWS CodePipeline pipeline, que são criados com a implantação manual de scripts do Terraform.
+ Componentes de rede e de computação necessários para hospedar os locatários. Eles são criados por meio CodePipeline e CodeBuild usando o Terraform.
+ Namespaces dos locatários, políticas de rede e cotas de recursos, os quais são configurados via chart do Helm.
+ Aplicações pertencentes a diferentes locatários, implantadas usando o Flux.
Recomendamos que você planeje e desenvolva cuidadosamente a própria arquitetura multilocatário com base em seus requisitos e considerações de segurança. Este padrão fornece um ponto de partida para a sua implementação.
## Pré-requisitos e limitações
**Pré-requisitos **
+ Um ativo Conta da AWS
+ AWS Command Line Interface [(AWS CLI) versão 2.11.4 ou posterior, [instalada](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) e configurada](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)
+ [Terraform](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli) versão 0.12 ou versões posteriores, instalado em sua máquina local
+ [Terraform AWS Provider](https://registry.terraform.io/providers/hashicorp/aws/latest) versão 3.0.0 ou versões posteriores
+ [Kubernetes Provider](https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs) versão 2.10 ou versões posteriores
+ [Helm Provider](https://registry.terraform.io/providers/hashicorp/helm/latest/docs) versão 2.8.0 ou versões posteriores
+ [Kubectl Provider](https://registry.terraform.io/providers/gavinbunney/kubectl/latest/docs) versão 1.14 ou versões posteriores
**Limitações**
+ **Dependência de implantações manuais do Terraform:** a configuração inicial do fluxo de trabalho, incluindo a criação de CodeCommit repositórios, CodeBuild projetos e CodePipeline pipelines, depende de implantações manuais do Terraform. Isso introduz uma limitação potencial em termos de automação e escalabilidade, pois exige intervenção manual para alterações na infraestrutura.
+ **CodeCommit dependência do repositório:** o fluxo de trabalho depende dos CodeCommit repositórios como solução de gerenciamento de código-fonte e é fortemente acoplado a. Serviços da AWS
## Arquitetura
**Arquiteturas de destino**
Este padrão implanta três módulos para criar o pipeline e a infraestrutura de rede e de computação de uma plataforma de dados, conforme ilustrado nos diagramas a seguir.
*Arquitetura do pipeline:*
*Arquitetura da rede:*
*Arquitetura da computação:*
## Ferramentas
**Serviços da AWS**
+ O [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) é um serviço de compilação totalmente gerenciado que permite compilar o código-fonte, realizar testes de unidade e produzir artefatos preparados para a implantação.
+ O [AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html) é um serviço de controle de versão que ajuda no armazenamento e no gerenciamento de repositórios Git de forma privada, sem a necessidade de administrar o próprio sistema de controle de origem.
+ O [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) ajuda você a modelar e configurar rapidamente os diferentes estágios de uma versão de software, além de automatizar as etapas necessárias para a implantação contínua de alterações.
+ [O Amazon Elastic Kubernetes Service (Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html)) ajuda você a executar o AWS Kubernetes sem precisar instalar ou manter seu próprio plano de controle ou nós do Kubernetes.
+ [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)é um hub central que conecta nuvens privadas virtuais (VPCs) e redes locais.
+ [A Amazon Virtual Private Cloud (Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) ajuda você a lançar AWS recursos em uma rede virtual que você definiu. Essa rede virtual é semelhante a uma rede tradicional que você operaria no próprio datacenter, com os benefícios de usar a infraestrutura escalável da AWS.
**Outras ferramentas**
+ As[ políticas de rede da Cilium](https://cilium.io/use-cases/network-policy/#:~:text=Cilium%20implements%20Kubernetes%20Network%20Policies,%2C%20Kafka%2C%20gRPC%2C%20etc.) fornecem suporte para as políticas do Kubernetes voltadas para as camadas 3 e 4. Essas políticas podem ser complementadas com políticas para a camada 7 para prover segurança de API em protocolos como HTTP, Kafka, gRPC e outros equivalentes.
+ O [Flux](https://fluxcd.io/) é uma ferramenta de entrega contínua (CD) baseada em Git que automatiza a implantação de aplicações no Kubernetes.
+ O [Helm](https://helm.sh/docs/) é um gerenciador de pacotes de código aberto para o Kubernetes que auxilia na instalação e no gerenciamento de aplicações no cluster do Kubernetes.
+ [O Terraform](https://www.terraform.io/) é uma ferramenta de infraestrutura como código (IaC) HashiCorp que ajuda você a criar e gerenciar recursos na nuvem e no local.
**Repositório de código**
O código desse padrão está disponível no repositório GitHub [EKS Multi-Tenancy Terraform Solution](https://github.com/aws-samples/aws-eks-multitenancy-deployment).
## Práticas recomendadas
Para obter diretrizes e práticas recomendadas para o uso dessa implementação, consulte:
+ [Práticas recomendadas para a arquitetura multilocatário no Amazon EKS](https://aws.github.io/aws-eks-best-practices/security/docs/multitenancy/)
+ [Documentação do Flux](https://fluxcd.io/flux/get-started/)
## Épicos
### Criação de pipelines para as fases de desenvolvimento, teste e implantação do Terraform
| Tarefa | Description | Habilidades necessárias |
| --- | --- | --- |
| Clone o repositório do projeto. | Clone o repositório GitHub [EKS Multi-Tenancy Terraform Solution](https://github.com/aws-samples/aws-eks-multitenancy-deployment) executando o seguinte comando em uma janela de terminal:git clone https://github.com/aws-samples/aws-eks-multitenancy-deployment.git
| AWS DevOps |
| Inicialize o bucket do S3 do Terraform e o Amazon DynamoDB. | 1. Na pasta `bootstrap`, abra o arquivo `bootstrap.sh` e atualize os valores das variáveis para o nome do bucket do S3, o nome da tabela do DynamoDB e a Região da AWS:S3_BUCKET_NAME=""
DYNAMODB_TABLE_NAME=""
REGION=""
2. Execute o script `bootstrap.sh`. O script requer o AWS CLI, que você instalou como parte dos [pré-requisitos](#simplify-amazon-eks-multi-tenant-application-deployment-by-using-flux-prereqs).cd bootstrap
./bootstrap.sh
| AWS DevOps |
| Atualize os arquivos `run.sh` e `locals.tf`. | 1. Após a conclusão bem-sucedida do processo de inicialização, copie o nome do bucket do S3 e da tabela do DynamoDB da seção `variables` do script `bootstrap.sh`:# Variables
S3_BUCKET_NAME=""
DYNAMODB_TABLE_NAME="
2. Cole esses valores no script `run.sh`, que está no diretório raiz do projeto:BACKEND_BUCKET_ID=""
DYNAMODB_ID=""
3. Faça o upload do código do projeto em um CodeCommit repositório. É possível criar esse repositório automaticamente por meio do Terraform ao definir a seguinte variável como `true` no arquivo `demo/pipeline/locals.tf`:create_new_repo = true
4. Atualize o arquivo `locals.tf` de acordo com seus requisitos para criar os recursos do pipeline. | AWS DevOps |
| Implante o módulo do pipeline. | Para criar os recursos do pipeline, execute manualmente os comandos do Terraform apresentados a seguir. Não há orquestração para executar esses comandos automaticamente../run.sh -m pipeline -e demo -r -t init
./run.sh -m pipeline -e demo -r -t plan
./run.sh -m pipeline -e demo -r -t apply
| AWS DevOps |
### Criação da infraestrutura de rede
| Tarefa | Description | Habilidades necessárias |
| --- | --- | --- |
| Iniciar o pipeline. | 1. Na pasta `templates`, verifique se os arquivos `buildspec` têm a seguinte variável configurada para `network`:TF_MODULE_TO_BUILD: "network"
2. No [CodePipeline console](https://console.aws.amazon.com/codesuite/codepipeline/home), na página de detalhes do pipeline, inicie o pipeline escolhendo **Release change**.Após essa primeira execução, o pipeline é iniciado automaticamente sempre que você confirma uma alteração na ramificação principal do CodeCommit repositório.
O pipeline inclui as seguintes [fases](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html#concepts-stages):+ `validate` inicializa o Terraform, executa verificações de segurança do Terraform usando as ferramentas [checkov](https://www.checkov.io/) e [tfsec](https://github.com/aquasecurity/tfsec), e envia os relatórios de verificação para o bucket do S3.
+ `plan ` exibe o plano do Terraform e envia o plano para o bucket do S3.
+ `apply`aplica a saída do plano Terraform do bucket S3 e cria AWS recursos.
+ `destroy`remove os AWS recursos criados durante o `apply` estágio. Para habilitar essa fase opcional, defina a seguinte variável como `true` no arquivo `demo/pipeline/locals.tf`:enable_destroy_stage = true
| AWS DevOps |
| Valide os recursos criados por meio do módulo de rede. | Confirme se os seguintes AWS recursos foram criados após a implantação bem-sucedida do pipeline:+ Uma VPC de saída com três sub-redes públicas e três privadas, gateway da internet e gateway NAT.
+ Uma VPC do Amazon EKS com três sub-redes privadas.
+ Locatário 1 e Locatário 2 VPCs com três sub-redes privadas cada.
+ Um gateway de trânsito com todos os anexos da VPC e rotas para cada sub-rede privada.
+ Uma rota estática no gateway de trânsito para a VPC de saída do Amazon EKS, com o bloco CIDR de destino `0.0.0.0/0`. Isso é necessário para permitir que todos tenham acesso de saída VPCs à Internet por meio da VPC de saída do Amazon EKS. | AWS DevOps |
### Criação da infraestrutura de computação
| Tarefa | Description | Habilidades necessárias |
| --- | --- | --- |
| Atualize `locals.tf` para permitir o acesso do CodeBuild projeto à VPC. | Para implantar os complementos para o cluster privado do Amazon EKS, o CodeBuild projeto deve ser anexado à VPC do Amazon EKS.1. Na pasta `demo/pipeline`, abra o arquivo `locals.tf` e defina a variável `vpc_enabled` como `true`.
2. Execute o `run.sh` para aplicar as alterações no módulo do pipeline:demo/pipeline/locals.tf
./run.sh -m pipeline -env demo -region -tfcmd init
./run.sh -m pipeline -env demo -region -tfcmd plan
./run.sh -m pipeline -env demo -region -tfcmd apply
| AWS DevOps |
| Atualize os arquivos `buildspec` para desenvolver o módulo de computação. | Na pasta `templates`, em todos os arquivos YAML de `buildspec`, defina o valor da variável `TF_MODULE_TO_BUILD` de `network` para `compute`:TF_MODULE_TO_BUILD: "compute"
| AWS DevOps |
| Atualize o arquivo `values` para o chart do Helm de gerenciamento de locatários. | 1. Abra o arquivo `values.yaml` no seguinte local:cd cfg-terraform/demo/compute/cfg-tenant-mgmt
Exemplo de arquivo:---
global:
clusterRoles:
operator: platform-tenant
flux: flux-tenant-applier
flux:
tenantCloneBaseUrl: ${TEANT_BASE_URL}
repoSecret: ${TENANT_REPO_SECRET}
tenants:
tenant-1:
quotas:
limits:
cpu: 1
memory: 1Gi
flux:
path: overlays/tenant-1
tenant-2:
quotas:
limits:
cpu: 1
memory: 2Gi
flux:
path: overlays/tenant-2
2. Nas seções `global` e `tenants`, atualize a configuração de acordo com os seus requisitos:`tenantCloneBaseUrl`: caminho para o repositório que hospeda o código de todos os locatários (usamos o mesmo repositório Git para todos os locatários)`repoSecret`: segredo do Kubernetes que contém as chaves SSH e os hosts conhecidos para autenticação no repositório Git referente ao locatário global`quotas`: cotas de recursos do Kubernetes que você deseja aplicar para cada locatário`flux path`: caminho para os arquivos YAML da aplicação do locatário no repositório do locatário global | AWS DevOps |
| Valide os recursos de computação. | Depois de atualizar os arquivos nas etapas anteriores, CodePipeline inicia automaticamente. Confirme se ele criou os seguintes AWS recursos para a infraestrutura computacional:+ Cluster do Amazon EKS com endpoint privado
+ Nós de processamento do Amazon EKS
+ Complementos do Amazon EKS: segredos de entidades externas, `aws-loadbalancer-controller` e `metrics-server`
+ GitOps módulo, gráfico Flux Helm, gráfico Cilium Helm e gráfico Helm de gerenciamento de inquilinos | AWS DevOps |
### Verificação do gerenciamento de locatários e de outros recursos
| Tarefa | Description | Habilidades necessárias |
| --- | --- | --- |
| Valide os recursos de gerenciamento de locatários no Kubernetes. | Execute os comandos apresentados a seguir para verificar se os recursos de gerenciamento de locatários foram criados com êxito com a ajuda do Helm.1. Os namespaces dos locatários foram criados, conforme especificado em `values.yaml`:kubectl get ns -A
2. As cotas foram atribuídas a cada namespace de locatário, conforme especificado em `values.yaml`:kubectl get quota --namespace=
3. Os detalhes das cotas estão corretos para cada namespace de locatário:kubectl describe quota cpu-memory-resource-quota-limit -n
4. As políticas de rede da Cilium foram aplicadas a cada namespace de locatário:kubectl get CiliumNetworkPolicy -A
| AWS DevOps |
| Verifique as implantações das aplicações dos locatários. | Execute os comandos apresentados a seguir para verificar se as aplicações dos locatários foram implantadas.1. O Flux é capaz de se conectar ao CodeCommit repositório especificado no GitOps módulo:kubectl get gitrepositories -A
2. O controlador de personalização do Flux implantou os arquivos YAML no repositório: CodeCommit kubectl get kustomizations -A
3. Todos os recursos das aplicações foram implantados nos seus respectivos namespaces de locatários:kubectl get all -n
4. Uma entrada foi criada para cada locatário:kubectl get ingress -n
| |
## Solução de problemas
| Problema | Solução |
| --- | --- |
| Você recebe uma mensagem de erro semelhante a esta:
`Failed to checkout and determine revision: unable to clone unknown error: You have successfully authenticated over SSH. You can use Git to interact with AWS CodeCommit.` | Siga estas etapas para solucionar o problema:1. Verifique o repositório da aplicação do locatário, pois um repositório vazio ou configurado incorretamente pode estar causando o erro. Certifique-se de que o repositório da aplicação do locatário contém o código necessário.
2. Reimplante o módulo `tenant_mgmt`. No arquivo de configuração do módulo `tenant_mgmt`, localize o bloco `app` e, em seguida, defina o parâmetro `deploy` como `0`:deploy = 0
Após executar o comando `apply` do Terraform, altere o valor do parâmetro `deploy` de volta para `1`:deploy = 1
3. Verifique o status novamente. Após executar as etapas anteriores, use o seguinte comando para verificar se o problema persiste: kubectl get gitrepositories -A
Se o problema persistir, considere analisar os logs do Flux mais aprofundadamente para obter mais detalhes ou consulte o [guia geral de solução de problemas do Flux](https://fluxcd.io/flux/cheatsheets/troubleshooting/). |
## Recursos relacionados
+ [Amazon EKS Blueprints for Terraform](https://github.com/aws-ia/terraform-aws-eks-blueprints)
+ [Guia de práticas recomendadas do Amazon EKS, seção de arquitetura multilocatário](https://aws.github.io/aws-eks-best-practices/security/docs/multitenancy/)
+ [Site do Flux](https://fluxcd.io/)
+ [Site do Helm](https://helm.sh/)
## Mais informações
A seguir, apresentamos um exemplo de estrutura de repositório para a implantação das aplicações dos locatários:
```
applications
sample_tenant_app
├── README.md
├── base
│ ├── configmap.yaml
│ ├── deployment.yaml
│ ├── ingress.yaml
│ ├── kustomization.yaml
│ └── service.yaml
└── overlays
├── tenant-1
│ ├── configmap.yaml
│ ├── deployment.yaml
│ └── kustomization.yaml
└── tenant-2
├── configmap.yaml
└── kustomization.yaml
```