Voltar para Lista
BLOG / Crom Editor / / 5 min leitura

🐳 OI - Orquestrador de containers open-source: Para você nunca mais depender de PaaS pago(Auto-SSL • Go • Docker • Caddy • 3MB. Precisa de mais o que?)

Cansei de configurar Docker e criei o OI (Orquestrador de Intenção): uma CLI em Go que troca YAML complexo por um JSON simples. Ele faz Blue-Green deployment e gerencia SSL via Caddy automaticamente. Busco feedback sobre arquitetura (persistência de estado vs. Docker e build integrado) e colaboradores.

Noite. Uma ideia simples para um micro-SaaS e um querer de colocar um MVP no ar. Abre o terminal, empolgado.

Duas horas depois, a empolgação vira frustração. Não estava codando o produto; estava brigando com um arquivo docker-compose.yml de 50 linhas, tentando lembrar a sintaxe correta do traefik.labels, depurando porque o container do Nginx não "enxergava" o backend na rede interna e renovando certificados SSL que falharam silenciosamente.

Eu percebi que passo mais tempo configurando infraestrutura para projetos pequenos do que realmente construindo eles.

Foi aí que decidi parar de configurar e começar a declarar minha intenção.

Apresentando o OI (Orquestrador de Intenção)

O OI é uma ferramenta CLI open-source que desenvolvi em Go para eliminar a complexidade do "como fazer" e focar apenas no "o que eu quero".

A filosofia é: Implantação por meio de intenção, não de configuração.

Ao invés de gerenciar Dockerfiles, redes, volumes e proxies manualmente, eu apenas digo ao OI o que eu quero, e ele faz a "mágica" acontecer.

Como instalar (em 10 segundos)

Se você estiver no Linux (x86 ou ARM64), pode instalar com um único comando. Criei um script que detecta sua arquitetura e baixa o binário correto:

curl -sSL https://raw.githubusercontent.com/MrJc01/crom-oi/main/scripts/install.sh | sudo bash

**

Pronto. O comando oi já deve estar disponível no seu terminal.

Como funciona na prática?

Esqueça o YAML gigante. Você cria um arquivo oi.json com sua intenção clara:

{
  "nome": "meu-app",
  "origem": "docker.io/library/nginx:alpine",
  "dominio": "meu-app.localhost",
  "porta": 80,
  "recursos": {
    "cpu": "0.5",
    "memoria": "128mb"
  }
}

E roda:

oi up

O OI lê esse arquivo e garante que a realidade do servidor corresponda exatamente a essa intenção.

O que acontece "debaixo do capô"? (A parte técnica)

O oi não é um shell script glorificado. Ele é uma aplicação robusta em Go que interage diretamente com o Docker SDK e a API do Caddy. Eis o fluxo que implementei (está no internal/core/service/orchestrator.go):

  1. Fail-Fast Validation: Antes de tocar em qualquer container, ele valida DNS e conectividade.
  2. Blue-Green Deployment (Nativo):
    • Ele sobe um novo container (Green).
    • Aguarda o Health Check passar (implementei uma espera ativa).
    • Se passar, ele reconfigura o Caddy (via API) para apontar o tráfego para o novo container.
    • Só então ele remove o container antigo (Blue) com graceful shutdown.
    • Resultado: Zero downtime real.
  1. Gestão de Proxy: Ele fala diretamente com a API administrativa do Caddy (:2019) para criar rotas de proxy reverso dinamicamente.
  2. Isolamento de Rede: Cada projeto ganha sua própria rede bridge isolada automaticamente.
  3. Bilíngue: O parser JSON aceita chaves em Português (memoria) ou Inglês (memory), porque... por que não?

Onde estou "travado" (Pedido de Ajuda)

O projeto está funcional. Consigo fazer deploys, rollbacks automáticos, ver logs (oi logs -f) e monitorar o status. Mas, como todo projeto solo, cheguei num ponto de indecisão sobre o futuro da arquitetura e gostaria da visão de vocês:

  1. Estado: Hoje o "estado" é o que está rodando no Docker. Se eu reiniciar o servidor, o Docker sobe os containers, mas estou pensando se deveria implementar um banco KV local (tipo BoltDB) para persistir a "intenção" de forma mais rígida. É exagero para uma CLI?
  2. Build vs. Deploy: Hoje ele puxa imagens prontas (origem). Vocês acham que uma ferramenta assim deveria também buildar a imagem (oi build) ou isso fere o princípio de responsabilidade única?
  3. Abstração do Proxy: A integração é forte com o Caddy. Deveria gastar energia abstraindo para suportar Nginx/Traefik ou focar em fazer a integração com Caddy ser impecável?
  4. Ele resolveu minha dor até agora, não sei se realmente quero implementar novas funcionalidades, mas gostaria de saber como melhorar.

Código e Link

O projeto é 100% open-source. Se você curte Go, Docker ou apenas quer uma ferramenta simples para seus side-projects, dá uma olhada:

🔗 Repositório: https://github.com/MrJc01/crom-oi

Qualquer feedback — seja sobre o código em Go, a usabilidade ou a ideia em si — é muito bem-vindo nos comentários!

☕ Apoie o Desenvolvimento open-source do seu país(Não falo só de mim aqui)

Manter o desenvolvimento de ferramentas open-source exige tempo, dedicação e, claro, muito ☕ para alguns, e muito 🍀 para outros. Se você gostou da filosofia do OI, achou a ferramenta útil ou simplesmente quer incentivar a continuidade do projeto, qualquer apoio é bem-vindo.

Estou trabalhando em um módulo de doações dedicado na Crom (a organização por trás do projeto), mas enquanto ele não fica pronto, estou aceitando apoios via PIX:

Chave: mrj.crom@gmail.com

⚠️ Importante: Se você fizer uma doação, por favor, envie o comprovante com uma mensagem (pode ser só seu usuário do GitHub ou TabNews) para o e-mail: mrj.crom@gmail.com

Assim que eu finalizar e lançar a implementação oficial de donate/invest da Crom, farei questão de migrar e disponibilizar esses apoios lá como créditos, badges de apoiadores, ou minimamente agradecimentos pelo valor investido.

Muito obrigado pela sua atenção! 🗿🍷

Fim da Transmissão