Tenant vinculado ao hostname
src/util/bootstrap.php usa o primeiro rótulo de HTTP_HOST. Migrar o portal para apps altera o contexto de banco previsto. Corrigir com identidade confiável antes do DNS definitivo.
Relatório de infraestrutura / Implementação e Riscos
Implementação e Riscos
Procedimento de publicação manual, controles operacionais, pontos críticos no PHP e ações necessárias antes de autorizar o ambiente de produção.
Módulo 06 de 07 · RollbackCitizen Apps / Pesquisa de infraestrutura
Siebot Infrastructure Lab
Implante com controle e recuperabilidade
Do deploy manual à observabilidade: os cuidados técnicos, riscos do código atual e critérios antes da entrada em produção.
06 / Projeto de execução
Da aprovação ao container publicado
Modelo proposto para o Citizen Apps: um control plane de governança e um hosting plane de execução. O deploy inicial é manual e auditável.
Plano de controle
O portal PHP cadastra aplicação, responsável, tenant, tecnologia, finalidade, ambiente e solicitações de API. O cadastro não dispara Docker automaticamente.
Permissões e escopos precisam ser validados no servidor, nunca apenas na interface.
Plano de hospedagem
Linux, Docker Engine, Compose, proxy reverso e uma imagem por Citizen App. Separar volumes, permissões, redes e logs. Definir quotas de CPU/memória.
Containers compartilham o kernel do host: isolamento não equivale a uma VM completa.
Plano de dados
Aplicações chamam o Siebot API Hub com credenciais limitadas. Evitar acesso direto aos bancos corporativos. Tokens e segredos ficam fora da imagem e do Git.
Banco externo reduz uso do SSD local, mas impõe dependência da rede/API.
Sequência operacional recomendada
1
Provisionar e proteger a VPS
Escolher região, IP público e Ubuntu LTS; configurar acesso SSH por chave, usuário administrativo não-root, firewall e atualizações de segurança. Manter SSH restrito a IPs administrativos quando possível.
2
Instalar Docker Engine e Compose
Instalar pelo repositório oficial, validar daemon, cgroups e limites. Proteger acesso ao grupo docker, que na prática oferece privilégios elevados ao host.
3
Publicar um proxy HTTPS
Apontar o DNS apps.siebot.cloud ao servidor. Liberar 80/443; usar Nginx ou Traefik com certificados TLS e redirecionamento HTTP→HTTPS. Evitar publicar diretamente as portas dos containers.
4
Implantar uma aplicação piloto
Criar Dockerfile, Compose, healthcheck, limites de CPU/RAM/PIDs, volumes necessários e rede privada. Publicar manualmente, testar rollback e reinicialização após reboot.
5
Validar integração e governança
Conectar via API Hub, testar token sem permissão, token revogado, tenant incorreto, timeout e indisponibilidade do gateway. Registrar responsável, versão e procedimento de resposta a incidentes.
6
Escalar somente após benchmark
Repetir ensaios com 1, 5, 10, 20 e 40 containers; fixar P95/erros máximos aceitáveis e uma margem de capacidade. Comparar custos totais com a demanda real antes de aumentar o plano.
Template ilustrativo de Compose
services:
controle_visitas:
image: registry.exemplo/controle_visitas:1.0.0
restart: unless-stopped
cpus: "0.50"
mem_limit: 512m
pids_limit: 100
read_only: true
security_opt:
- no-new-privileges:true
tmpfs:
- /tmp
networks: [app_net]
# secrets e volumes conforme necessidade
networks:
app_net:
internal: trueIlustrativo: o proxy precisará de conectividade controlada com a aplicação. A configuração final depende da stack, portas, volumes e healthcheck.
Path vs. subdomínio
Path: apps.siebot.cloud/controle_visitas. Facilita DNS e TLS, mas exige que o aplicativo suporte base path em redirecionamentos, CSS, JS e cookies.
Subdomínio: controle-visitas.apps.siebot.cloud. Favorece separação de origem no navegador, mas requer estratégia de DNS e certificados wildcard ou individuais.
O estudo detectou que o tenant era derivado do primeiro trecho do hostname. Ao mudar de siebert.siebot.cloud para apps.siebot.cloud, essa lógica deve ser corrigida para não resolver tenant como apps.
Decisão de segurança:
Não dar ao portal PHP acesso irrestrito ao socket Docker. Automatizar somente após haver pipeline isolado e revisado.
07 / Governança de risco
O que pode inviabilizar a produção
Itens específicos do projeto e da infraestrutura que devem constar da decisão, além do preço da VPS.
Segurança de acesso
Rever o login compartilhado que expõe credenciais do usuário à Citizen App; avaliar autenticação central com OIDC / Authorization Code + PKCE. Separar identidade humana de token de aplicação.
Autorização de API
A aprovação administrativa deve ser estritamente limitada às conexões solicitadas. Validar no back-end tenant, aplicação, escopo, ambiente e vínculo do token.
Disponibilidade
Uma VPS única é ponto único de falha. Planejar recuperação, snapshots, backup externo, teste de restauração, monitoramento e eventual segunda instância para maior disponibilidade.
Capacidade
2 vCPUs podem saturar antes de 8 GB RAM. Burst/CPU credits em EC2 t3a e limites efetivos de CPU do provedor exigem atenção. Não confundir container ocioso com usuário simultâneo.
Custos além do plano
Contabilizar impostos, contratação antecipada, renovação, câmbio, tráfego, backup, observabilidade, suporte operacional e horas de manutenção. Para EC2, tráfego e créditos excedentes podem alterar significativamente o total.
Reprodutibilidade
Corrigir migrations inconsistentes do repositório Citizen Apps, documentar deploy, fixar versões de imagens e manter caminho de rollback antes de criar novos ambientes.
Evidências do código
Pontos que impedem declarar a implantação pronta
Achados documentados de maneira resumida para este relatório de infraestrutura. O detalhamento técnico de segurança deve permanecer no repositório privado e ser resolvido antes da publicação.
Migrations ausentes
O README menciona migrations de 03/09 para sie_dash_dev e sessões, porém o ZIP contém apenas a migration de 01/09. Uma instalação nova não é reproduzível com o material fornecido.
Permissões e credenciais
Revisar vinculação entre solicitação, escopo aprovado e token real; não basta confiar em valores enviados pelo navegador. Validar isolamento por tenant e acesso ao catálogo de usuários.
Autenticação e base path
O contrato atual de login compartilhado envolve senha informada à Citizen App. Estudar SSO/OIDC e testar sessão, cookies e links com o prefixo do caminho público.
Infraestrutura ainda inexistente
Não há Compose, rede Docker, TLS, healthcheck, templates de aplicação, observabilidade nem rotinas de backup/rollback no pacote entregue.
Verificações estáticas vs funcionamento
Os arquivos PHP e JS passaram nos checks de sintaxe locais. Isso não garante comportamento HTTP, segurança de acesso, funcionamento de banco, nem desempenho sob carga.
Encaminhamento recomendado
Próxima decisão de infraestrutura
Piloto controlado: Hostinger KVM 2 ou Lightsail 8 GB
Ambas são opções para começar o exercício de implantação com 2 vCPU / 8 GB; custos, região e contratos diferem. Para produção ou maior concorrência, comparar Hostinger KVM 4 ou Lightsail 16 GB / 4 vCPU e EC2 mediante cotação regional.
A decisão definitiva depende de latência até o API Hub, número real de apps, consumo sob carga, requisitos de dados, backups e isolamento. Não contratar exclusivamente pela quantidade teórica de containers.