Ambientes e containers:
como está hoje e para onde vamos
Um retrato do que roda hoje, com as fragilidades, e uma planta para um ecossistema com muitas linguagens, muitos servidores e as sessões de IA do Genezze trabalhando junto com os projetos dos clientes, cada um no seu lugar.
Use ◀ ▶ (ou as setas do teclado) para seguir os destaques com a Geni. Clique em qualquer bloco para acendê-lo: o endereço da página muda e quem abrir o mesmo link vê o mesmo destaque.
Cinco requisitos para a nova arquitetura
Alta escalabilidade
Crescer acrescentando servidores, sem refazer nada: cada nó novo entra e passa a receber trabalho.
Segurança em camadas
Os arquivos do Genezze (núcleo) separados e protegidos dos arquivos dos projetos de clientes. Infra do sistema de um lado, ambiente de terceiro do outro.
Uma imagem por runtime
Node, PHP, Python, Java… cada um com a sua imagem Docker, construída à parte. Nada de várias linguagens na mesma base.
O ambiente parte da imagem certa
Cada projeto sobe um container a partir da imagem da sua linguagem, com o seu código montado.
IA em pools distribuídos
As sessões de IA do Genezze podem rodar nos servidores dos clientes, como outro usuário, sem misturar permissões com o ambiente do cliente.
Como está montado agora
Um servidor principal faz quase tudo. Um único broker sobe os containers dos ambientes, e todos usam a rede do próprio servidor. Os pools de mídia e build já rodam em servidores da Contabo.
Seis pontos que a nova planta resolve
Núcleo e cliente no mesmo lugar
Todo container de app enxerga as pastas de todos os projetos e de todos os usuários, e roda como administrador. Arquivos do próprio núcleo moram nessa mesma área compartilhada.
Sem fronteira de rede
Tudo usa a rede do servidor: um app de cliente alcança as portas internas do sistema. O que separa é só senha e token.
Um broker só, sem código-fonte
A peça que sobe todos os ambientes existe só compilada, fora do repositório, e atende um servidor só.
Runtimes misturados
A imagem do núcleo junta Python, Node, ffmpeg e navegador. Uma das imagens de PHP não tem receita no repositório: num servidor novo, ela não nasce.
IA presa a um servidor
As sessões de IA rodam só no servidor principal, como administrador. Não há como levá-las para perto do código do cliente.
Crescer = encher o mesmo servidor
Cada imagem é construída em cada máquina, e os apps só sabem morar onde o broker único está.
A planta: camadas, imagens por runtime e pools distribuídos
Cinco camadas com fronteira clara. Um broker em cada servidor, comandado por um Regente. Imagens separadas por linguagem. Apps, IA e trabalho pesado em pools, com usuários que nunca se misturam, mesmo na mesma máquina.
Cada camada só fala com a vizinha, pela porta certa
Traefik + Ponte
O único ponto exposto à internet. A Ponte (Genezzin) confere quem chama e o que pode, emite tokens curtos e registra tudo.
O Genezze em si
API, fila, voz, banco e cofre de segredos. Usuário próprio, rede própria, arquivos que nunca são montados em container de terceiro.
Regente + brokers
O Regente decide; o broker de cada servidor executa, só o que veio assinado e só imagens conhecidas.
Registro, filas, artefatos
As imagens versionadas que todo servidor puxa, as filas de trabalho e o barramento de eventos entre apps.
Pools em N servidores
Apps de clientes, sessões de IA e trabalho pesado, cada pool com usuário, rede e limite de CPU e memória próprios.
Uma imagem por linguagem, o ambiente parte dela
gz-base
Sistema mínimo, usuário sem administrador, certificados e a sonda de log. Nenhuma linguagem.
Runtimes, cada um à parte
gz-rt-node · gz-rt-php-cli · gz-rt-php-apache · gz-rt-python · gz-rt-java. Cada um tem o seu Dockerfile no repositório e a sua versão. Linguagem nova = um Dockerfile + uma linha no catálogo. As do sistema também ficam separadas: núcleo, IA, mídia e nativo.
O ambiente
Container = imagem do runtime certo + o volume só daquele projeto + os adaptadores da linguagem, só leitura. Precisa de biblioteca extra? O projeto traz um Dockerfile FROM gz-rt-…; o pool de build gera a imagem dele e qualquer servidor sobe igual.
Como o broker sobe um ambiente
- Pedido. Alguém (tela, Geni ou sessão de IA) pede para subir o ambiente. O pedido chega ao núcleo pela Ponte.
- Catálogo. O Regente lê no catálogo único a stack do ambiente: imagem, rede, portas, com quem pode falar, limites de CPU e memória.
- Escolha do servidor. Ele pergunta aos brokers quem tem vaga e prefere o servidor onde o projeto já mora (ou o servidor do próprio cliente).
- Ordem assinada. O Regente manda ao broker daquele servidor uma ordem assinada. O broker recusa o que não vier assinado ou pedir imagem desconhecida.
- Isolamento. O broker cria a rede só daquele ambiente, monta só a pasta daquele projeto e escolhe o usuário da organização. Nada de pasta do núcleo, nada de administrador.
- Subida. Puxa a imagem do registro, conferida pela assinatura, e sobe o container com os limites do catálogo.
- Ligação. O Regente gera a rota na borda, a permissão na Ponte e o acesso às filas e eventos daquele ambiente.
- Vida. Saúde a cada 10 s. Ocioso dorme; chamado, acorda. Servidor cheio ou fora do ar: o Regente sobe em outro.
A IA do Genezze no servidor do cliente, sem misturar permissões
O mesmo servidor pode rodar o app do cliente e uma sessão de IA do Genezze trabalhando nesse app. Os dois são usuários diferentes, em redes diferentes. A IA recebe, só durante a sessão, acesso à pasta daquele projeto, e o cliente nunca enxerga as credenciais da IA.
| Quem roda | Arquivos do núcleo | Projeto da sessão / do app | Outros projetos | Segredos e banco do núcleo | Controle do Docker |
|---|---|---|---|---|---|
| gz-core núcleo | sim | pela Ponte | pela Ponte | sim | não (só o broker) |
| gz-ia sessões de IA | não | sim, só na sessão | não | não — token curto pela Ponte | não |
| gz-pool mídia, build, nativo | não | cópia temporária | não | não | não |
| amb-<org> app do cliente | não | só o próprio | não | não — fala pela Ponte | não |
Balanceamento de verdade
Sessões de IA, builds e mídia entram em filas. O servidor que tem vaga pega o próximo trabalho. Mais servidores = mais vazão, sem configurar nada no núcleo.
Perto do código
A IA prefere o servidor onde o projeto mora. Para cliente com servidor próprio, o código e o dado não saem de lá: quem viaja é a sessão.
Como a planta cresce
Instalar o broker-agente e registrar. O Regente passa a usá-lo na hora.
API sem estado em várias cópias atrás da Ponte; banco com conexão em pool e réplica de leitura.
Dormem quando ociosos (já existe) e podem ter várias cópias quando quentes.
Construídas uma vez e puxadas do registro por qualquer servidor.
Hoje × proposta
| Tema | Hoje | Proposta |
|---|---|---|
| Núcleo × cliente | mesma área de arquivos, administrador | pastas e usuários separados, sem administrador |
| Rede | rede do servidor para todos | uma rede por zona e por ambiente |
| Entrada dos apps | direto na porta do app | pela Ponte, com identidade e cota |
| Broker | um, compilado, fora do git | um por servidor, no git, só ordem assinada |
| Imagens | núcleo mistura linguagens; uma sem receita | uma por runtime, no registro, versionadas |
| Sessões de IA | só no servidor principal | pool em qualquer servidor, usuário gz-ia |
| Pools | SSH + cópia por job | filas, quem tem vaga pega |
| Linguagens conversando | sem jeito padrão | barramento de eventos + funções iguais em cada linguagem |
Em fases, sem parar o que está no ar
Já: separar núcleo de cliente
Tirar os arquivos do núcleo da área compartilhada, montar em cada app só o próprio projeto e parar de rodar como administrador. É pequeno e fecha o risco maior.
Imagens e broker no lugar
Base sem linguagem, um Dockerfile por runtime (inclusive o que falta), registro privado e o broker de volta ao repositório.
Redes por zona e Ponte na frente dos apps
Cada ambiente na sua rede; o app só sai pela Ponte. O catálogo passa a dizer rede, portas e limites.
Regente, um broker por servidor e pools
Brokers nos servidores da Contabo e nos de clientes; sessões de IA viram pool com usuário gz-ia; mídia e build entram em filas.
Barramento entre linguagens
Eventos com contrato e as mesmas três funções em PHP, Node, Python e Java.