Diagrama da Infra montada na infra:
Esse projeto possui o deploy via GitHub Actions para o AWS ECS. A task definition fica em .aws/task-definition.json.
O projeto segue a seguinte estrutura:
- external: database, controller, apis e adapters
- core: entities, use cases e interface de repositories
- application: inicialização da aplicação
Existe um módulo principal chamado tc que agrupa os 3 módulos.
Documentação de apoio: https://spring.io/guides/gs/multi-module/
Para executar:
./mvnw install -DskipTests && ./mvnw spring-boot:run -pl application2.1 Estrtura do módulo core
core
├── pom.xml
└── src
| ├── main
| | └── java
| | ├── META-INF
| | | └── MANIFEST.MF
| | └── br
| | └── com
| | └── fiap
| | └── soat1
| | └── t32
| | ├── exceptions
| | | ├── DuplicateKeyException.java
| | | ├── IntegrationException.java
| | | ├── NotFoundException.java
| | | └── ValidationException.java
| | ├── pagamentos
| | | ├── entities
| | | | ├── Checkout.java
| | | | ├── PagamentoPedido.java
| | | | └── ProdutoCheckout.java
| | | └── use_cases
| | | ├── CheckoutService.java
| | | └── PagamentoService.java
| | ├── pedidos
| | | ├── entities
| | | | ├── CategoriaProduto.java
| | | | ├── Pedido.java
| | | | ├── PedidoProduto.java
| | | | ├── Produto.java
| | | | ├── StatusPagamentoPedido.java
| | | | └── StatusPreparacaoPedido.java
| | | ├── repositories
| | | | ├── PedidoRepository.java
| | | | └── ProdutoRepository.java
| | | └── use_cases
| | | ├── PedidoService.java
| | | └── ProdutoService.java
| | └── vendas
| | ├── entities
| | | ├── Cliente.java
| | | ├── Cpf.java
| | | └── Email.java
| | ├── repositories
| | | └── ClienteRepository.java
| | └── use_cases
| | └── ClienteService.java
2.2 Estrutura do módulo external
external
├── pom.xml
└── src
| └── main
| └── java
| ├── META-INF
| | └── MANIFEST.MF
| └── br
| └── com
| └── fiap
| └── soat1
| └── t32
| ├── configs
| | ├── CheckoutConfiguration.java
| | ├── ClienteConfiguration.java
| | ├── PagamentoConfiguration.java
| | ├── PedidoConfiguration.java
| | └── ProdutoConfiguration.java
| ├── handler
| | ├── HandlerResource.java
| | └── vo
| | ├── DetalheErro.java
| | └── RespostaErro.java
| ├── pagamentos
| | ├── adapters
| | | ├── CheckoutAdapter.java
| | | └── PagamentoAdapter.java
| | ├── apis
| | | ├── CheckoutResource.java
| | | ├── PagamentoWebhookResource.java
| | | └── vo
| | | ├── request
| | | | ├── CheckoutVo.java
| | | | ├── ClienteCheckoutVo.java
| | | | ├── PagamentoPedidoVo.java
| | | | └── ProdutoCheckoutVo.java
| | | └── response
| | | └── CheckoutResponse.java
| | └── controllers
| | ├── CheckoutController.java
| | └── PagamentoWebhookController.java
| ├── pedidos
| | ├── adapters
| | | ├── PedidoAdapter.java
| | | ├── PedidoProdutoAdapter.java
| | | └── ProdutoAdapter.java
| | ├── apis
| | | ├── PedidoResource.java
| | | ├── ProdutoResource.java
| | | └── vo
| | | ├── request
| | | | ├── ClientePedidoVo.java
| | | | ├── PedidoVo.java
| | | | ├── ProdutoPedidoVo.java
| | | | └── ProdutoVo.java
| | | └── response
| | | ├── ConsultaProdutoData.java
| | | ├── ConsultaProdutoResponse.java
| | | ├── CriacaoPedidoResponse.java
| | | ├── CriacaoProdutoResponse.java
| | | ├── ListaPedidosClienteData.java
| | | ├── ListaPedidosData.java
| | | ├── ListaPedidosProdutoData.java
| | | └── ListaPedidosResponse.java
| | ├── controllers
| | | ├── PedidoController.java
| | | └── ProdutoController.java
| | └── repositories
| | ├── PedidoCrudRepository.java
| | ├── PedidoProdutoCrudRepository.java
| | ├── PedidoRepositoryImpl.java
| | ├── ProdutoCrudRepository.java
| | ├── ProdutoRepositoryImpl.java
| | └── entities
| | ├── PedidoDb.java
| | ├── PedidoProdutoDb.java
| | ├── PedidoProdutoKey.java
| | └── ProdutoDb.java
| └── vendas
| ├── adapters
| | └── ClienteAdapter.java
| ├── apis
| | ├── ClienteResource.java
| | └── vo
| | ├── request
| | | └── ClienteVO.java
| | └── response
| | └── ConsultaClienteResponse.java
| ├── controllers
| | └── ClienteController.java
| └── repositories
| ├── ClienteCrudRepository.java
| ├── ClienteRepositoryImpl.java
| └── entities
| └── ClienteDb.java
Para subida do projeto em um cluster kubernetes, mais espeficamente no minikube, se faz necessário executar os seguintes passos:
- Instalar o minikube. Caso já tenha o minikube instalado, recomendo verificar se já existe uma instância criada e caso exista fazer a remoção usando o comando
minikube delete. - Iniciar uma instância do minikube
minikube start --driver=docker- Verificar que o kubectl está configurado para o cluster do minikube em um terminal
- Aplicar as mudanças as seguir
kubectl apply -f k8s/namespace.yaml
kubectl apply -f k8s/secret.yaml
kubectl apply -f k8s/github-registry.yaml
kubectl apply -f k8s/db/pv.yaml
kubectl apply -f k8s/db/pvc.yaml
kubectl apply -f k8s/db/svc.yaml
kubectl apply -f k8s/db/statefulset.yaml
kubectl apply -f k8s/backend/svc.yaml
kubectl apply -f k8s/backend/deployment.yaml
kubectl apply -f k8s/nlb.yaml- Para validar o NLB, executar o comando a seguir. A senha de administrador pode ser necessária para dar seguimento ao tunelamento.
minikube tunnel- Em outro terminal, executar o comando que abrirá o um dashboard do cluster kubernetes.
minikube dashboard- Alterar no menu superior do dashboard para a namespace tc-s1-32. Em seguida, na seção services do dashboard irá aparecer o link para o nlb que direciona para o backend. Ao abrir, é esperado encontrar o swagger do backend.
Se por algum acaso precisar refazer esses passos, recomendo que rode o comando:
minikube deleteCom isso você pode retornar ao passo 2.
Todos os pods, services e volumes estão contidos no namespace tc-s1-32.
O build e push da imagem da aplicação pode ser feito pelo comando ./push2registry.sh identificador-da-versão.
Nele são executados os passos de build e push para o container registry do Github.
É importante se atentar aos pré-requisitos:
- gere seu personal token no github com permissão de
write:package. Dúvidas verifique a documentação - com o token em mãos, autentique no github container registry utilizando o comando
echo seu_novo_token | docker login ghcr.io -u flavioneubauer --password-stdin
Para configurar o acesso ao container registry do Github pelo cluster kubernetes existe o arquivo de configuração github-registry.yaml. Dentro dele existe um conteúdo em formato base64 do seguinte json:
{"auths":{"ghcr.io":{"auth":"<AUTH-TOKEN>"}}}A chave AUTH-TOKEN é um base64 de usuario:token_de_acesso. Esse token de acesso precisa ser gerado no Github e ter apenas a permissão read:package.
Exemplo de geração:
- token usuario =
echo 'flavioneubauer:meu_token_somente_leitura' | base64 -w0 - .dockerconfigjson =
echo -n '{"auths":{"ghcr.io":{"auth":"ZmxhdmlvbmV1YmF1ZXI6Z2hwX2dRWHVnTHdxakxFTm9tUERmSVpwM0Noc0RwSTI3ajJHS0V4Yw=="}}}' | base64 -w0
Já foi gerada uma chave de acesso somente leitura, portanto esse passo é apenas caso haja o desejo de configurar uma nova chave no futuro.
A responsabilidade deste software é controlar o fluxo de pedidos feitos pelos clientes, e com manutenção de produtos e checkout de pagamento.
O projeto está estruturado em 3 módulos sendo:
- adapters: driven e drivers
- core: domain. ports e use cases
- application: inicialização da aplicação
Existe um módulo principal chamado tc que agrupa os 3 módulos.
Documentação de apoio: https://spring.io/guides/gs/multi-module/
Para executar:
./mvnw install -DskipTests && ./mvnw spring-boot:run -pl applicationPara executar usando docker compose:
- Primeiro realize o build do container
docker compose build- Suba a aplicação e o banco de dados
docker compose upPara escalar a aplicação, utilzar docker compose up --scale app=3 e serão instanciadas 3 aplicações de backend nas portas 8080, 8081 e 8082.
Caso não suba mais de uma instância, utilize o comando docker compose up e verifique a porta em que a aplicação subiu utilizando o comando docker ps. A porta estará no range de 8080 a 8083.
Durante os testes foi utilizada a versão 24.0.0 do docker engine e v2.17.3 do docker compose.