feat: adicionadas configuracoes de rede Wireguard e ssh keys da vps1, vps3 e vps4
This commit is contained in:
Rui
+102
-4
@@ -82,7 +82,7 @@ ALTER DATABASE temporal OWNER TO temporal_user;
|
||||
|
||||
## 📊 2. Hardening da Configuração do PostgreSQL (`pg_hba.conf`)
|
||||
|
||||
Edite o arquivo `/etc/postgresql/15/main/pg_hba.conf` para garantir que o acesso ao banco de dados seja liberado apenas para os papéis designados originados da rede interna da VPN Wireguard:
|
||||
Edite o arquivo `/etc/postgresql/18/main/pg_hba.conf` para garantir que o acesso ao banco de dados seja liberado apenas para os papéis designados originados da rede interna da VPN Wireguard:
|
||||
|
||||
```text
|
||||
# TYPE DATABASE USER ADDRESS METHOD
|
||||
@@ -96,7 +96,10 @@ host newwhats newwhats_user 10.99.0.5/32 scram-sha-25
|
||||
# 3. Permitir que o orquestrador Temporal (VPS 5) conecte apenas no database temporal
|
||||
host temporal temporal_user 10.99.0.5/32 scram-sha-256
|
||||
|
||||
# 4. Bloqueio preventivo total para qualquer outro IP ou usuário
|
||||
# 4. Permitir conexões de replicação da VPS 4 (Staging/Replica)
|
||||
host replication replicator 10.99.0.4/32 scram-sha-256
|
||||
|
||||
# 5. Bloqueio preventivo total para qualquer outro IP ou usuário
|
||||
host all all 0.0.0.0/0 reject
|
||||
```
|
||||
|
||||
@@ -180,7 +183,7 @@ PostgreSQL (VPS 3)
|
||||
```
|
||||
|
||||
#### 2. Configuração do `pg_hba.conf` para Múltiplos Projetos:
|
||||
Edite o arquivo `/etc/postgresql/15/main/pg_hba.conf` para mapear de forma cirúrgica as origens permitidas para cada projeto:
|
||||
Edite o arquivo `/etc/postgresql/18/main/pg_hba.conf` para mapear de forma cirúrgica as origens permitidas para cada projeto:
|
||||
|
||||
```text
|
||||
# TYPE DATABASE USER ADDRESS METHOD
|
||||
@@ -197,7 +200,10 @@ host facebook_db facebook_user 10.99.0.1/32 scram-sha-25
|
||||
# 4. Projeto NEWWHATS (Backend na VPS 5 -> Banco na VPS 3)
|
||||
host newwhats newwhats_user 10.99.0.5/32 scram-sha-256
|
||||
|
||||
# 5. BLOQUEIO PADRÃO TOTAL (Zero-Trust)
|
||||
# 5. Permitir conexões de replicação da VPS 4 (Staging/Replica)
|
||||
host replication replicator 10.99.0.4/32 scram-sha-256
|
||||
|
||||
# 6. BLOQUEIO PADRÃO TOTAL (Zero-Trust)
|
||||
host all all 0.0.0.0/0 reject
|
||||
```
|
||||
|
||||
@@ -210,3 +216,95 @@ Cada aplicação Node.js aberta na VPS 1 tentará criar um pool de conexões per
|
||||
```
|
||||
* **PgBouncer (Avançado)**: Se o número de projetos escalonar para dezenas de aplicações na VPS 1, configure o **PgBouncer** na VPS 3 para multiplexar centenas de conexões virtuais em poucas conexões físicas reais do Postgres, reduzindo drasticamente o consumo de RAM.
|
||||
|
||||
---
|
||||
|
||||
## 🚀 5. Otimização de Performance e Tuning do PostgreSQL 18
|
||||
|
||||
Para aproveitar ao máximo os **8 GB de RAM e 4 núcleos de CPU** da VPS 3 (Data Appliance) e garantir o processamento rápido e estável de dados para o `newwhats` e o `giteadb`, aplicamos um tuning avançado nativo.
|
||||
|
||||
As configurações foram modularizadas no arquivo `/etc/postgresql/18/main/conf.d/tuning.conf` para manter o `postgresql.conf` limpo e facilitar a portabilidade:
|
||||
|
||||
```ini
|
||||
# ==========================================
|
||||
# PostgreSQL Performance Tuning Configuration
|
||||
# Optimized for 8 GB RAM / 4 CPU Cores
|
||||
# ==========================================
|
||||
|
||||
# Memory Configuration
|
||||
shared_buffers = 2GB
|
||||
effective_cache_size = 6GB
|
||||
maintenance_work_mem = 512MB
|
||||
work_mem = 10MB
|
||||
|
||||
# Write-Ahead Log (WAL) Configuration
|
||||
checkpoint_completion_target = 0.9
|
||||
wal_buffers = 16MB
|
||||
min_wal_size = 1GB
|
||||
max_wal_size = 4GB
|
||||
|
||||
# Disk and Query Planner Settings (assuming SSD/NVMe)
|
||||
random_page_cost = 1.1
|
||||
effective_io_concurrency = 200
|
||||
default_statistics_target = 100
|
||||
|
||||
# Worker Process and Parallelism Settings
|
||||
max_worker_processes = 4
|
||||
max_parallel_workers_per_gather = 2
|
||||
max_parallel_workers = 4
|
||||
max_parallel_maintenance_workers = 2
|
||||
|
||||
# Connections Configuration
|
||||
max_connections = 100
|
||||
```
|
||||
|
||||
### 🏁 Passos de ativação e validação:
|
||||
```bash
|
||||
# Reiniciar o serviço do cluster 18-main
|
||||
sudo systemctl restart postgresql@18-main.service
|
||||
|
||||
# Confirmar os parâmetros carregados
|
||||
sudo -u postgres psql -c "SHOW shared_buffers; SHOW effective_cache_size; SHOW work_mem;"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🧁 6. Resiliência de Inicialização do Gitea e DragonflyDB (Non-local Bind)
|
||||
|
||||
### 🔴 O Problema do Boot Sequencial
|
||||
Como o Gitea (`HTTP_ADDR = 10.99.0.3`) e o DragonflyDB (`--bind 10.99.0.3`) escutam exclusivamente no IP interno da VPN Wireguard, ocorria uma **falha de bind no reboot**:
|
||||
* O systemd inicializava estes serviços alguns milissegundos **antes** que a interface VPN (`wg0`) estivesse totalmente ativa e com o IP associado.
|
||||
* Isso resultava no erro `bind: cannot assign requested address`.
|
||||
* No caso do Gitea, ele falhava silenciosamente mantendo o processo de gerenciamento ativo, o que impedia o systemd de perceber a queda e reiniciar o serviço automaticamente.
|
||||
|
||||
### 🛡️ Solução Permanente Implementada
|
||||
|
||||
#### 1. Configuração de Kernel: Non-local Bind
|
||||
Ativamos uma diretiva de kernel para permitir que os daemons executem o bind em IPs de interfaces que ainda não estejam totalmente ativas no momento do boot:
|
||||
```bash
|
||||
# Ativar imediatamente
|
||||
sudo sysctl -w net.ipv4.ip_nonlocal_bind=1
|
||||
|
||||
# Persistir para reboots futuros
|
||||
echo "net.ipv4.ip_nonlocal_bind=1" | sudo tee -a /etc/sysctl.conf
|
||||
```
|
||||
|
||||
#### 2. Dependência no Systemd do Gitea
|
||||
Atualizamos a unidade `/etc/systemd/system/gitea.service` para exigir que a rede esteja completamente online antes do início do Gitea:
|
||||
```ini
|
||||
[Unit]
|
||||
Description=Gitea (Git with a cup of tea)
|
||||
After=syslog.target network.target network-online.target postgresql.service
|
||||
Wants=network-online.target
|
||||
```
|
||||
*Após atualizar, execute:* `sudo systemctl daemon-reload`
|
||||
|
||||
#### 3. Dependência no Systemd do DragonflyDB (Override Nativo)
|
||||
Criamos um arquivo de override limpo para o DragonflyDB em `/etc/systemd/system/dragonfly.service.d/override.conf`:
|
||||
```ini
|
||||
[Unit]
|
||||
After=network-online.target
|
||||
Wants=network-online.target
|
||||
```
|
||||
*Após criar, execute:* `sudo systemctl daemon-reload`
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user