| ... | @@ -19,37 +19,30 @@ |
... | @@ -19,37 +19,30 @@ |
|
|
|
|
|
|
|
# Arquitetura do Sistema
|
|
# Arquitetura do Sistema
|
|
|
|
|
|
|
|
Na nossa arquitetura da nuvem usaremos principalmente o serviço [ECS(Elastic Container Service) da AWS](https://aws.amazon.com/ecs/). Este é um serviço de orquestração de contêineres totalmente gerenciado que facilita a implantação, o gerenciamento e a escala de aplicações em contêineres. Este seviço vai servir para garantir à nossa aplicação uma camada extra de segurança e escalabilidade.
|
|
A arquitetura utilizada no projeto é baseada no padrão Modular, com inspiração na arquitetura em camadas (Layered Architecture). No NestJS, os componentes são organizados em DTOs (Data Transfer Objects), Controllers, Services e Modules. Cada módulo encapsula a lógica relacionada a um domínio específico da aplicação, facilitando a manutenção e a escalabilidade. Os DTOs são responsáveis pela definição dos dados de entrada e saída, garantindo validações consistentes. Os Controllers lidam com as requisições HTTP, enquanto os Services contêm a lógica de negócios e manipulam a comunicação com outras partes da aplicação.
|
|
|
|
|
|
|
|
No ECS usaremos uma instância do [AWS Fargate](https://aws.amazon.com/pt/fargate/) que é um mecanismo de computação sem servidor e com pagamento conforme o uso que permite a você se concentrar em construir aplicações sem gerenciar servidores.
|
|
Essa abordagem modular e bem estruturada permite separar responsabilidades e promover um código limpo e reutilizável. A injeção de dependências é um ponto forte dessa arquitetura, possibilitando testes mais simples e maior flexibilidade na substituição de implementações conforme necessário.
|
|
|
|
|
|
|
|
Para realizarmos nosso deploy no ECS usaremos o [ECR(Elastic Container Registry)](https://aws.amazon.com/pt/ecr/) que é um registro de contêiner totalmente gerenciado que oferece hospedagem de alta performance para que você possa implantar imagens e artefatos de aplicações de forma confiável em qualquer lugar.
|
|
|
|
|
|
|
|
|
|
O fluxo da nosso deploy será enviar uma imagem conteinerizada da nossa aplicação, no total 3 imagens (frontend, backend e banco de dados), para o ECR. Com a imagem no ECR iremos para a configuração do ECS, onde criaremos uma task(um serviço) usando uma instancia do AWS Fargate.
|
|
|
|
|
|
|
|
|
|
Esse é um padrão de deploy oferecido pela propria AWS.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Para mais informações do ECS e seu fluxo de deploy, a AWS oferece um [workshop](https://ecsworkshop.com/introduction/) sobre os serviços.
|
|
|
|
|
|
|
|
|
|
# Deploy
|
|
# Deploy
|
|
|
|
|
|
|
|
- O deploy é o processo de disponibilizar uma aplicação concluída para uso. Esse processo pode ser realizado em diversas fases do projeto, assim como após sua finalização. Utilizamos a plataforma de computação em nuvem TDB.
|
|
No processo de deploy descrito no diagrama, o backend e o banco de dados são configurados em containers Docker. Inicialmente, as imagens Docker desses serviços são buildadas a partir do repositório no GitLab. Após a build, essas imagens são enviadas para o Elastic Container Registry (ECR) da AWS. A instância EC2, responsável por executar os serviços, recupera essas imagens diretamente do ECR e as executa em containers Docker, garantindo que a versão mais recente da aplicação esteja rodando.
|
|
|
|
|
|
|
|
Para o frontend, o deploy é gerenciado pelo AWS Amplify, que está integrado ao repositório GitLab. Toda vez que um push é feito na branch main, o AWS Amplify automaticamente detecta as mudanças e inicia o processo de build e deploy da aplicação frontend. Isso automatiza o ciclo de deploy contínuo, garantindo que as atualizações sejam rapidamente disponibilizadas tanto para o backend quanto para o frontend.
|
|
|
|
|
|
|
|
## Diagrama de Deploy
|
|
## Diagrama de Deploy
|
|
|
|
|
|
|
|
- O diagrama apresenta o processo de deploy da aplicação Cosmos utilizando a nuvem AWS.
|
|
- O diagrama apresenta o processo de deploy da aplicação Cosmos utilizando a nuvem AWS.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Diagrama de Componentes
|
|
## Diagrama de Componentes
|
|
|
|
|
|
|
|
Um diagrama de componentes eficiente para a aplicação "Cosmos" pode ser organizado conforme as funções específicas de cada parte do sistema:
|
|
Um diagrama de componentes eficiente para a aplicação "Cosmos" pode ser organizado conforme as funções específicas de cada parte do sistema:
|
|
|
|
|
|
|
|
### Componentes de Infraestrutura
|
|
### Componentes de Infraestrutura
|
|
|
1. **Amazon Elastic Container Service (ECS)**: Responsável pela orquestração dos containers que rodam tanto o backend quanto o banco de dados.
|
|
1. **Amazon Elastic Compute Cloud (EC2)**: Responsável pela execução dos containers Docker que rodam tanto o backend quanto o banco de dados. A EC2 é configurada para puxar as imagens mais recentes do ECR e executar os containers, oferecendo uma infraestrutura flexível e escalável para o deploy.
|
|
|
2. **Amazon Elastic Container Registry (ECR)**: Repositório onde as imagens Docker são armazenadas.
|
|
2. **Amazon Elastic Container Registry (ECR)**: Repositório onde as imagens Docker do backend e banco de dados são armazenadas. As imagens são buildadas e enviadas para o ECR a partir do repositório GitLab.
|
|
|
3. **AWS Fargate**: Provedor de serviço serverless que gerencia a execução dos containers, dispensando o uso de servidores.
|
|
3. **GitLab CI/CD**: Pipeline de CI/CD que automatiza o build das imagens Docker e o envio para o ECR. O GitLab CI/CD é responsável por garantir que o código mais recente seja transformado em uma imagem Docker pronta para ser executada na EC2.
|
|
|
|
|
|
|
|
### Componentes de Backend
|
|
### Componentes de Backend
|
|
|
1. **NestJS**: Framework utilizado para o desenvolvimento do backend, que está dentro de um container Docker.
|
|
1. **NestJS**: Framework utilizado para o desenvolvimento do backend, que está dentro de um container Docker.
|
| ... | | ... | |
