| ... | @@ -10,4 +10,159 @@ |
... | @@ -10,4 +10,159 @@ |
|
|
<th> [BD](banco de dados) </th>
|
|
<th> [BD](banco de dados) </th>
|
|
|
<th> [Gerência](gerência) </th>
|
|
<th> [Gerência](gerência) </th>
|
|
|
</tr>
|
|
</tr>
|
|
|
</table> |
|
</table>
|
|
\ No newline at end of file |
|
|
|
|
|
# Infraestrutura AWS
|
|
|
|
|
|
|
|
No processo de deploy descrito no diagrama, o **backend** (APIs) e o **banco de dados** (PostgreSQL) são configurados em _containers_ Docker executados em uma instância EC2. As imagens Docker desses serviços são buildadas a partir dos repositórios GitLab (`revforce-api` e `revforce-front`) por meio de um **GitLab Runner** também em container. Após cada build de backend, a EC2 puxa a imagem mais recente do **Amazon ECR** e inicia o container das APIs, garantindo que a versão em produção esteja sempre atualizada. Para o **frontend**, o fluxo de deploy faz com que, a cada push no repositório `revforce-front`, o GitLab Runner gere os arquivos estáticos e transfira tudo para um bucket **Amazon S3**, permitindo que o site seja servido diretamente de um storage estático. Esse conjunto de serviços automatiza completamente o ciclo de CI/CD: do commit no GitLab até a aplicação em produção, contemplando banco, APIs e front-end.
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
## Diagrama de Deploy
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
## Componentes e Benefícios
|
|
|
|
|
|
|
|
A seguir, cada bloco do diagrama é explicado de forma resumida, com o propósito e o motivo de uso:
|
|
|
|
|
|
|
|
### EC2 Instance
|
|
|
|
|
|
|
|
- **O que é**: Máquina virtual Linux hospedada na AWS.
|
|
|
|
- **Para que serve**:
|
|
|
|
- Executar o **Docker**, que por sua vez roda todos os _containers_ (Postgres, RevForce APIs e GitLab Runner).
|
|
|
|
- Centralizar o pipeline de CI/CD sem necessidade de múltiplos servidores.
|
|
|
|
- **Benefícios**:
|
|
|
|
- Custos controlados (tudo em uma instância).
|
|
|
|
- Simplicidade de gerenciamento: basta acesso SSH/Console para inspecionar logs e containers.
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
### Docker
|
|
|
|
|
|
|
|
- **O que é**: Plataforma de contenção de aplicações (containers).
|
|
|
|
- **Para que serve**:
|
|
|
|
- Isolar cada serviço (banco, APIs, runner) em ambientes independentes e facilmente recriáveis.
|
|
|
|
- Garantir que todos rodem na mesma versão, sem conflitos de dependências.
|
|
|
|
- **Benefícios**:
|
|
|
|
- Portabilidade (mesmo container dev → prod).
|
|
|
|
- Reprodutibilidade: se precisar recriar, basta puxar a imagem correta.
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
### Postgres (Container Docker)
|
|
|
|
|
|
|
|
- **O que é**: Serviço de banco de dados relacional.
|
|
|
|
- **Para que serve**:
|
|
|
|
- Armazenar tabelas, esquemas, usuários, dados do RevForce.
|
|
|
|
- Receber conexões do container de APIs (`RevForce APIs`).
|
|
|
|
- **Benefícios**:
|
|
|
|
- Dados armazenados no **Database Volume (EBS)**, garantindo persistência mesmo que o container seja parado ou recriado.
|
|
|
|
- Facilidade de upgrade ou rollback simplesmente trocando a imagem Docker.
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
### RevForce APIs (Container Docker)
|
|
|
|
|
|
|
|
- **O que é**: Back-end do sistema empacotado em imagem Docker.
|
|
|
|
- **Para que serve**:
|
|
|
|
- Processar requisições do front-end e de consumidores externos.
|
|
|
|
- Realizar CRUD no banco Postgres e aplicar regras de negócio.
|
|
|
|
- **Benefícios**:
|
|
|
|
- Deploy atômico: o GitLab Runner builda e faz push da imagem ao **ECR**, e a EC2 “puxa” a versão mais nova para produção.
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
### GitLab Runner (Container Docker)
|
|
|
|
|
|
|
|
- **O que é**: Executor de pipelines CI/CD do GitLab, registrado junto aos repositórios.
|
|
|
|
- **Para que serve**:
|
|
|
|
1. Escutar eventos (push/merge) nos repositórios `revforce-front` e `revforce-api`.
|
|
|
|
2. Executar estágios definidos em `.gitlab-ci.yml`:
|
|
|
|
- **revforce-front**: build do front-end e sincronização com S3.
|
|
|
|
- **revforce-api**: testes, build de imagem Docker e push para ECR.
|
|
|
|
- **Benefícios**:
|
|
|
|
- Automação total do ciclo de deploy: commit → build → deploy.
|
|
|
|
- Não há necessidade de runners externos: tudo roda dentro da mesma EC2.
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
### EBS – Database Volume
|
|
|
|
|
|
|
|
- **O que é**: Volume anexado à EC2.
|
|
|
|
- **Para que serve**:
|
|
|
|
- Persistir o diretório de dados do PostgreSQL.
|
|
|
|
- Garantir durabilidade: mesmo que o container Postgres seja recriado, os dados permanecem.
|
|
|
|
- **Benefícios**:
|
|
|
|
- Snapshot fácil para backup.
|
|
|
|
- Redimensionamento de volume sem interrupção.
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
### EBS – Root Volume
|
|
|
|
|
|
|
|
- **O que é**: Volume de bloco principal que contém o sistema operacional da EC2.
|
|
|
|
- **Para que serve**:
|
|
|
|
- Armazenar arquivos de sistema, configurações, dependências e logs do container das APIs.
|
|
|
|
- Espaço onde o Docker armazena camadas e volumes ligados a serviços diversos (exceto o banco, que tem volume específico).
|
|
|
|
- **Benefícios**:
|
|
|
|
- Manutenção simplificada: tudo no Linux (atualizações, backups, logs).
|
|
|
|
- Permite persistir arquivos de configuração sem poluir o volume do container.
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
### Amazon S3
|
|
|
|
|
|
|
|
- **O que é**: Serviço de armazenamento de objetos (arquivos) escalável e altamente disponível.
|
|
|
|
- **Para que serve**:
|
|
|
|
- Hospedar **arquivos estáticos** do front-end (HTML, CSS, JavaScript, imagens).
|
|
|
|
- Servir diretamente ao usuário final sem necessidade de servidor Web tradicional.
|
|
|
|
- **Benefícios**:
|
|
|
|
- Custo muito baixo para hospedagem estática.
|
|
|
|
- Alta performance / baixa latência.
|
|
|
|
- Facilidade de versionamento e políticas de expiração.
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
### Amazon ECR (Elastic Container Registry)
|
|
|
|
|
|
|
|
- **O que é**: Registro privado de imagens Docker gerenciado pela AWS.
|
|
|
|
- **Para que serve**:
|
|
|
|
- Armazenar as imagens do `revforce-api` geradas pelo GitLab Runner.
|
|
|
|
- **Benefícios**:
|
|
|
|
- Integração nativa com EC2 e IAM Roles, sem necessidade de credenciais estáticas.
|
|
|
|
- Segurança e escaneamento de vulnerabilidades.
|
|
|
|
- Alta disponibilidade e baixa latência para pull de imagens em produção.
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
### GitLab – Repositórios
|
|
|
|
|
|
|
|
- **revforce-front**
|
|
|
|
- Contém código-fonte do front-end.
|
|
|
|
- Define pipeline de build → deploy (upload para S3).
|
|
|
|
- **revforce-api**
|
|
|
|
- Contém código-fonte do back-end.
|
|
|
|
- Define pipeline de testes → build Docker → push para ECR.
|
|
|
|
|
|
|
|
**Benefícios dos repositórios no GitLab**:
|
|
|
|
- Versionamento completo do código.
|
|
|
|
- Configuração central de CI/CD (arquivo `.gitlab-ci.yml`).
|
|
|
|
- Controle de acesso e revisão de código (Merge Requests, Revisões, Labels).
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
## Conclusão
|
|
|
|
|
|
|
|
A infraestrutura apresentada otimiza o ciclo de desenvolvimento e deploy do RevForce ao:
|
|
|
|
|
|
|
|
1. **Centralizar todo o CI/CD** em um único **GitLab Runner** dentro da EC2.
|
|
|
|
2. **Garantir persistência** de dados via **EBS** (Database e Root).
|
|
|
|
3. **Escalar o front-end** de forma simples e econômica diretamente no **S3**.
|
|
|
|
4. **Versionar e distribuir** o back-end como imagem Docker pelo **ECR**.
|
|
|
|
5. **Reduzir custos operacionais** ao não manter múltiplos servidores separados, concentrando tudo em uma única instância com containers.
|
|
|
|
|
|
|
|
Com essa arquitetura, bastam alguns comandos no GitLab (push em branches específicas) para que toda a stack (frontend + backend + banco) seja automaticamente atualizada em produção, garantindo agilidade e confiabilidade no fluxo de deploy contínuo. |
|
|
|
\ No newline at end of file |
