|
|
## Ferramentas Escolhidas
|
|
# Arquitetura Pró-Mata - Infraestrutura e Banco de Dados
|
|
|
|
|
|
|
|
<table>
|
|
## Modelagem do Banco de Dados
|
|
|
<tr>
|
|
|
|
|
<td>
|
|
|
|
|
|
|
## Banco de Dados PostgreSQL
|
|
|
|
|
|
|
|
|
|
**Desenvolvimento**: Um container PostgreSQL simples que roda localmente. O Prisma ORM gerencia as migrações automaticamente.
|
|
|
O PostgreSQL é uma ferramenta que atua como sistema de gerenciamento de bancos de dados relacionados. Seu foco é permitir implementação da linguagem SQL em estruturas, garantindo um trabalho com os padrões desse tipo de ordenação dos dados. Tem o papel de gerenciar os dados desses bancos de maneira organizada e eficaz, rodando e gravando todas as informações que ficam registradas nesses compartimentos. Por meio desse sistema, usuários podem executar consultas de maneira simples, sem precisar acessar diretamente o banco de dados.
|
|
|
|
|
|
|
**Produção**: PostgreSQL com replicação master-slave, backups automáticos criptografados, e monitoramento futuro com Grafana e PostgreSQL exporter.
|
|
|
|
|
|
|
|
|
|
## Como os Repositórios se Conectam
|
|
|
O Adminer é uma ferramenta completa para administração de banco de dados, desenvolvido em PHP. Ao contrário do phpMyAdmin, o Adminer é constituído em um único arquivo, pronto para ser implantado no servidor. O Adminer está disponível para MySQL, MariaDB, PostgreSQL, SQLite, MS SQL, Oracle, Elasticsearch, MongoDB e outros via plugin.
|
|
|
|
|
|
|
**Backend**: Precisa do PostgreSQL e se conecta via variáveis de ambiente do `.env`
|
|
|
|
|
|
|
|
|
|
**Frontend**: Só conversa com o backend através da API, não toca no banco diretamente
|
|
|
O dbdiagram.io é uma ferramenta online intuitiva e gratuita, projetada para simplificar a criação de diagramas de banco de dados. Ideal para desenvolvedores, analistas de sistemas e qualquer profissional envolvido no design de estruturas de dados, essa plataforma permite aos usuários desenhar rapidamente modelos de banco de dados por meio de uma interface visualmente clara e fácil de usar.
|
|
|
|
|
|
|
**Infrastructure**: O "maestro" que orquestra tudo:
|
|
|
|
|
- **Terraform**: Cria a infraestrutura no Azure (VMs, redes, IPs)
|
|
|
|
|
- **Ansible**: Configura as máquinas e instala Docker Swarm
|
|
|
é uma ferramenta que facilita a definição e execução de aplicações multi-contêineres Docker. Com ele, é possível configurar todos os serviços de que sua aplicação depende (como **bancos de dados**, filas de trabalho, caches, etc.) em um único arquivo docker-compose.yml. Além de ser projetado para facilitar o desenvolvimento e teste de aplicações que requerem um banco de dados PostgreSQL, fornecendo uma maneira fácil de gerenciar o banco de dados por meio de uma interface web.
|
|
- **Docker Swarm**: Gerencia os containers em produção
|
|
|
</td>
|
|
|
|
|
</tr>
|
|
## Segredos com Ansible Vault
|
|
|
</table>
|
|
|
|
|
|
|
É como um cofre digital. Cada ambiente tem uma senha em `.vault_pass` que desbloqueia os segredos criptografados. No CI/CD, os segredos ficam no GitHub Secrets e são usados temporariamente durante o deploy.
|
|
|
## Modelagem
|
|
|
|
|
|
|
## Fluxo de Deploy
|
|
|
Optamos por criar um banco de dados relacional, tendo em vista que o banco possui várias relações entre as diferentes tabelas existentes que compõem o projeto Excedentes.
|
|
|
|
|
|
|
1. Terraform cria/atualiza infraestrutura
|
|
|
### Modelo ER
|
|
2. Ansible pega os IPs criados e configura as máquinas
|
|
|
|
|
3. Docker Swarm orquestra os containers
|
|
|
|
|
4. CI/CD detecta mudanças na tag `latest` e redeploya automaticamente
|
|
|
|
|
|
|
|
Para ver com mais detalhes sobre este modelo, clique [aqui](https://dbdiagram.io/d/Copy-of-AGES-Excedentes-667b46569939893dae423fdb)
|
|
## Cloudflare
|
|
|
|
|
|
|
|
## Scripts de criação das tabelas
|
|
Funciona como DNS + CDN + proteção. Só precisa apontar os nameservers do registro.br para o Cloudflare.
|
|
|
|
|
|
|
|
```plaintext
|
|
**Benefícios**: SSL gratuito, proteção DDoS, aceleração, esconde IP real do servidor.
|
|
|
Table clientes {
|
|
|
|
|
id integer [increment, primary key]
|
|
## Estratégias PostgreSQL em Homologação
|
|
|
tipo_cliente enum('Pessoa Fisica', 'Pessoa Juridica') [not null]
|
|
|
|
|
nome varchar2 [not null]
|
|
### Arquitetura Master-Slave
|
|
|
cpf_cnpj varchar2 [not null, unique]
|
|
|
|
|
email varchar2 [not null, unique]
|
|
**Banco Principal (Master)**: Recebe todas as escritas de dados. Roda em uma máquina com label `database.primary = true` no Docker Swarm.
|
|
|
senha varchar2 [not null]
|
|
|
|
|
isOng bool [not null]
|
|
**Réplicas (Slaves)**: Copiam dados do master automaticamente. Servem apenas consultas de leitura. Quantidade configurável por variável `postgres_replica_count`.
|
|
|
createdAt timestamp [not null]
|
|
|
|
|
updatedAt timestamp [not null]
|
|
**Sincronização**: A replicação é automática via streaming replication do PostgreSQL. Se o master falhar, uma réplica pode ser promovida manualmente.
|
|
|
deletedAt timestamp
|
|
|
|
|
}
|
|
### PgBouncer - Pool de Conexões
|
|
|
```
|
|
|
|
|
|
|
**Função**: Atua como um "porteiro" entre aplicações e banco, controlando quantas conexões simultâneas são permitidas.
|
|
|
```plaintext
|
|
|
|
|
Table pedidos {
|
|
**Configuração em Homologação**:
|
|
|
id integer [increment, primary key]
|
|
- **Pool Mode**: `transaction` (mais eficiente, compartilha conexões entre transações)
|
|
|
id_cliente integer [not null]
|
|
- **Max Client Conn**: 200 conexões cliente simultâneas
|
|
|
codigo integer [not null]
|
|
- **Pool Size**: 25 conexões reais ao banco por pool
|
|
|
valor_total double [not null]
|
|
- **Replicas**: 2-3 instâncias PgBouncer para alta disponibilidade
|
|
|
data date [not null]
|
|
|
|
|
aberto bool [not null]
|
|
**Benefícios**: Evita sobrecarga do banco com muitas conexões, reutiliza conexões existentes, distribui carga entre múltiplas instâncias.
|
|
|
createdAt timestamp [not null]
|
|
|
|
|
updatedAt timestamp [not null]
|
|
## PostgreSQL Alta Disponibilidade
|
|
|
}
|
|
|
|
|
```
|
|
### Tolerância a Falhas
|
|
|
|
|
|
|
|
```plaintext
|
|
**Auto-Recovery**: Docker Swarm reinicia automaticamente containers PostgreSQL que falharem. Configuração `restart_policy` com 3 tentativas e delay de 10-15 segundos.
|
|
|
Table alimentos {
|
|
|
|
|
id integer [primary key, not null]
|
|
**Replication Slots**: Garantem que o master preserve WAL (Write-Ahead Logs) necessários para réplicas, mesmo se a réplica ficar offline temporariamente.
|
|
|
id_empresa integer [not null]
|
|
|
|
|
nome varchar2 [not null]
|
|
**Health Checks**: Verificações `pg_isready` a cada 30 segundos com 5 tentativas before declaring failure. Se um nó falhar, é automaticamente removido do load balancing.
|
|
|
descricao varchar2 [not null]
|
|
|
|
|
preco double [not null]
|
|
**WAL Archiving**: Logs de transações são arquivados automaticamente para recuperação point-in-time em caso de corrupção de dados.
|
|
|
quantidade integer [not null]
|
|
|
|
|
marca varchar2 [not null]
|
|
### Disponibilidade Contínua
|
|
|
data_validade date [not null]
|
|
|
|
|
categoria varchar2 [not null]
|
|
**Hot Standby**: Réplicas ficam ativas e podem servir consultas de leitura mesmo durante sincronização com o master.
|
|
|
foto varchar2
|
|
|
|
|
cod_barras varchar2 [not null]
|
|
**Physical Replication Slots**: Impedem que o master descarte WAL logs que réplicas ainda precisam, evitando quebra de sincronização.
|
|
|
createdAt timestamp [not null]
|
|
|
|
|
updatedAt timestamp [not null]
|
|
**Streaming Replication**: Dados são replicados em tempo real via conexão TCP contínua, mantendo réplicas sempre atualizadas.
|
|
|
deletedAt timestamp
|
|
|
|
|
}
|
|
**Placement Constraints**: Docker Swarm garante que master e réplicas rodem em nós físicos diferentes (`node.labels.database.primary` vs `node.labels.database.replica`).
|
|
|
```
|
|
|
|
|
|
|
### Recuperação de Desastres
|
|
|
```plaintext
|
|
|
|
|
Table item_pedido {
|
|
**Base Backup Automático**: Script `pg_basebackup` cria cópias completas do banco que podem ser usadas para restaurar réplicas ou criar novos masters.
|
|
|
id integer [increment, primary key]
|
|
|
|
|
id_pedido integer [not null]
|
|
**Point-in-Time Recovery**: Combinação de backups + WAL archives permite restaurar banco para qualquer momento específico no passado.
|
|
|
id_alimento integer [not null]
|
|
|
|
|
quantidade integer [not null]
|
|
**Replication Slot Cleanup**: Limpa automaticamente slots órfãos para evitar acúmulo de WAL logs que consomem espaço em disco.
|
|
|
preco_unitario double [not null]
|
|
|
|
|
createdAt timestamp [not null]
|
|
**Failover Manual**: Se master falhar, uma réplica pode ser promovida manualmente a master usando comandos `pg_promote()`.
|
|
|
updatedAt timestamp [not null]
|
|
|
|
|
}
|
|
Esta arquitetura garante que o sistema suporte falhas de hardware, rede ou software com perda mínima de dados e downtime reduzido. |
|
|
```
|
|
\ No newline at end of file |
|
|
|
|
|
|
|
```plaintext
|
|
|
|
|
Table empresas {
|
|
|
|
|
id integer [increment, primary key]
|
|
|
|
|
nome varchar2 [not null]
|
|
|
|
|
cnpj varchar2 [not null, unique]
|
|
|
|
|
email varchar2 [not null, unique]
|
|
|
|
|
senha varchar2 [not null]
|
|
|
|
|
horario_comercial varchar2 [not null]
|
|
|
|
|
id_endereco integer [not null, unique]
|
|
|
|
|
createdAt timestamp [not null]
|
|
|
|
|
updatedAt timestamp [not null]
|
|
|
|
|
deletedAt timestamp
|
|
|
|
|
}
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
```plaintext
|
|
|
|
|
Table enderecos {
|
|
|
|
|
id integer [increment, primary key]
|
|
|
|
|
nome_formatado varchar2 [not null]
|
|
|
|
|
latitude double [not null]
|
|
|
|
|
longitude double [not null]
|
|
|
|
|
createdAt timestamp [not null]
|
|
|
|
|
updatedAt timestamp [not null]
|
|
|
|
|
}
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
```plaintext
|
|
|
|
|
Ref: empresas.id_endereco > enderecos.id
|
|
|
|
|
|
|
|
|
|
Ref: pedidos.id_cliente > clientes.id
|
|
|
|
|
|
|
|
|
|
Ref: alimentos.id_empresa > empresas.id
|
|
|
|
|
Ref: item_pedido.id_pedido > pedidos.id
|
|
|
|
|
Ref: item_pedido.id_alimento > alimentos.id
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
## Implementação
|
|
|
|
|
|
|
|
|
|
1. Certifique-se de ter o Docker e o Docker Compose instalados em sua máquina.
|
|
|
|
|
2. Clone o repositório do aplicativo Excedentes.
|
|
|
|
|
3. Navegue até o diretório onde o arquivo `docker-compose.yml` está localizado.
|
|
|
|
|
4. Execute o seguinte comando para iniciar os serviços:
|
|
|
|
|
|
|
|
|
|
```shell
|
|
|
|
|
docker-compose up -d
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
5. O banco de dados PostgreSQL estará disponível em `localhost:5432`.
|
|
|
|
|
6. O Adminer estará disponível em `localhost:8080` para gerenciar o banco de dados.
|
|
|
|
|
|
|
|
|
|
#### Reconstrução de containers
|
|
|
|
|
|
|
|
|
|
Em certos momentos, pode ser necessário reconstruir suas imagens Docker para aplicar alterações feitas no Dockerfile ou nas configurações definidas no `docker-compose.yml`. Para isso, você pode utilizar a opção `--build` com o comando `docker-compose up`.
|
|
|
|
|
|
|
|
|
|
```shell
|
|
|
|
|
docker-compose up --build -d
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Se desejar garantir que as imagens sejam reconstruídas do zero, sem utilizar o cache de construções anteriores, você pode usar o comando docker-compose build com a opção --no-cache:
|
|
|
|
|
|
|
|
|
|
```shell
|
|
|
|
|
docker-compose build --no-cache
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
#### Encerramento
|
|
|
|
|
|
|
|
|
|
Para encerrar o container sem removê-lo, você pode usar o seguinte comando no terminal:
|
|
|
|
|
|
|
|
|
|
```shell
|
|
|
|
|
docker-compose stop
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Para parar e remover todos os serviços definidos no seu arquivo docker-compose.yml. Certifique-se de estar no mesmo diretório onde o arquivo está localizado antes de executar o comando.
|
|
|
|
|
|
|
|
|
|
```shell
|
|
|
|
|
docker-compose down
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Para uma limpeza completa, incluindo volumes, acrescente `-v` ao comando (`docker-compose down -v`). |
|
|
|
\ No newline at end of file |
|
|
