Uncloud - uma ferramenta para implantar aplicativos em contêiner entre servidores sem a complexidade do Kubernetes

• Uncloud é uma ferramenta open source que permite implantar e escalar aplicações web conteinerizadas em vários servidores sem Kubernetes
• Mantém um fluxo de trabalho baseado em Docker Compose, com suporte a implantação sem downtime, HTTPS automático e escalabilidade entre servidores
• Sem plano de controle central, cada máquina é conectada por uma rede P2P baseada em WireGuard, permitindo que o cluster continue operando mesmo se alguns servidores ficarem offline
• Inclui HTTPS automático por meio do proxy reverso Caddy, descoberta de serviços com DNS embutido e balanceamento de carga
• Também pode ser implantado da mesma forma em ambientes híbridos de nuvem e on-premises, garantindo controle sobre a infraestrutura e previsibilidade de custos

---

Fluxo de trabalho semelhante a um PaaS

• Oferece uma experiência de implantação simples como Heroku ou Fly.io, mantendo ao mesmo tempo controle total sobre os servidores e os dados
  • Estrutura de custos previsível, sem cobrança por requisição
  • Sem lock-in de fornecedor, com possibilidade de depuração usando ferramentas SSH padrão
• Com uma estrutura amigável ao Docker Compose, é possível executar build, push e deploy com um único comando
  • Sem necessidade de registro de imagens, com suporte a deploy rolling sem downtime
  • Possibilita escalonamento por replicação em várias máquinas

Projeto de baixa manutenção

• Sem necessidade de plano de controle ou gerenciamento de quórum, minimizando a complexidade administrativa
• Suporta comunicação segura entre máquinas sem abrir portas
• Traz embutidos descoberta automática de serviços e emissão automática de HTTPS com base no Let's Encrypt

Como funciona

• Em vez de um cluster complexo, é composto por uma rede simples de máquinas, oferecendo uma infraestrutura estável sem sobrecarga de manutenção
• Cada máquina participa de uma rede mesh WireGuard, realizando descoberta automática de peers e NAT traversal
  • Os contêineres recebem IPs exclusivos e podem se comunicar diretamente entre servidores
• Com uma arquitetura totalmente distribuída, cada máquina sincroniza o estado do cluster sem um nó central de controle
  • Mesmo que algumas máquinas fiquem offline, o cluster continua operando
• Controle de toda a infraestrutura com uma CLI semelhante ao Docker
  • Com acesso SSH a uma única máquina, é possível fazer deploy, monitoramento e escalonamento

Principais recursos

• Implantação em qualquer lugar: compatível com qualquer máquina Linux, incluindo VMs em nuvem, servidores dedicados e ambientes on-premises
• HTTPS automático: o proxy reverso Caddy embutido emite certificados TLS e ativa HTTPS sem configuração
• Balanceamento de carga: distribui o tráfego entre réplicas de contêineres espalhadas por várias máquinas
• Descoberta de serviços: o DNS embutido rastreia automaticamente a localização dos serviços na rede
• Infrastructure as Code: permite definir toda a stack da aplicação com arquivos Docker Compose existentes
• Sem lock-in de fornecedor: permite misturar livremente nuvem e hardware próprio

[GN⁺]

Comentários no Hacker News

• Olá, sou o criador. Obrigado por compartilhar.
  Uncloud é um orquestrador de contêineres sem plano de controle. Em termos simples, é como um Docker Compose distribuído por várias máquinas, com malha WireGuard automática, descoberta de serviços e HTTPS via Caddy. Cada máquina sincroniza o estado do cluster em p2p usando o Corrosion da Fly.io, então não é necessário manter quórum.
  Depois de operar Kubernetes tanto em startups quanto em empresas unicórnio, percebi que a maioria das equipes na verdade só precisa rodar bem contêineres em algumas máquinas, com rede, rollout e HTTPS. O overhead operacional do K8s é grande demais para isso.
  Os principais recursos são:

  • usa a especificação familiar do Docker Compose, sem necessidade de aprender uma nova DSL
  • faz build e push de imagens Docker diretamente para as máquinas, sem registro externo (usando meu outro projeto, unregistry)
  • oferece uma CLI imperativa em vez de declarativa, o que facilita a depuração
  • conecta VMs em nuvem, bare metal e até Raspberry Pi atrás de NAT
  • uso de memória abaixo de 150 MB
    Link do projeto: https://github.com/psviderski/uncloud
    • O K8s já roda contêineres muito bem mesmo em ambientes pequenos, então não vejo muito motivo para usar outra coisa. Distribuições leves como k3s também ficaram fáceis de implantar, então não sinto falta de uma alternativa.
    • A ideia é legal, mas o fato de uc machine init executar internamente curl | bash com privilégios de root parece arriscado do ponto de vista de segurança. Eu até testaria, mas não rodaria isso em máquinas reais.
    • Muito interessante. Acho que vou ter chance de testar em breve. Só que, mesmo lendo a documentação, não ficou claro como fazer o onboarding de outros engenheiros depois de configurar o cluster, nem como implantar a partir de um runner de CI/CD. Queria entender o processo para conectar uma nova máquina a um cluster existente.
    • Queria entender a diferença em relação ao Kamal.
    • Fiquei curioso sobre como fazer uma conexão segura com serviços externos como AWS RDS dentro de uma rede privada montada com WireGuard. Queria saber se isso é suportado de forma parecida com a abordagem da Tailscale para AWS RDS.

• Passei a maior parte da carreira com Kubernetes, então queria entender qual é a vantagem de uma arquitetura sem plano de controle. Para mim, o plano de controle é justamente a funcionalidade central do K8s.
  Algumas centenas de nós e dezenas de milhares de contêineres não são um grande problema com clusters gerenciados e atualizações automáticas. Fico pensando se a dor de quem tenta auto-hospedar K8s é o que está por trás dessas alternativas.

  • “Algumas centenas de nós e dez mil contêineres” não me parece pequeno. Eu trabalho com algo como 2 a 5 nós e 10 a 30 contêineres; nessa escala, K8s é pesado demais. Imagino que existam muitas empresas pequenas assim.
  • Não é uma pergunta rude. A vantagem de não ter plano de controle é simplificar tudo em uma estrutura de pares em que todas as máquinas são equivalentes. Sem um “cérebro do cluster” centralizado, não é preciso se preocupar com HA nem com problemas de quórum do etcd.
    Mesmo se a rede se dividir, cada partição pode continuar operando de forma independente. É uma simplicidade no estilo do antigo Chef ou Ansible, mas com as lições aprendidas com o K8s.
  • Claro que as pessoas tentam auto-hospedar K8s. É como backup: se você não praticar antes, não vai conseguir quando precisar.
  • Para pequenas e médias empresas, dez mil contêineres está longe de ser pouco. Eu tenho menos de 10, mas preciso de alta disponibilidade (HA). O Uncloud parece se encaixar bem no meu caso.
  • “Dez mil contêineres é pouco? Isso não é número de job de CI? ;)”

• Projeto muito legal. Com certeza quero usar depois.
  Se alguém quiser uma alternativa ainda mais simples, o Kamal também é uma boa opção. É uma ferramenta validada em produção, operada por uma empresa que saiu completamente de K8s e da nuvem.

• Queria saber se existe algum recurso para fazer hardening de servidor automaticamente quando você define os servidores.

• Sou usuário de Docker Swarm. O Uncloud é a primeira alternativa que realmente me parece interessante.
  Tenho as seguintes dúvidas:

  • há planos de suporte a secrets?
  • dá para definir regras de rewrite de URL por rótulos de contêiner, como no Swarm+Traefik?
  • se eu implantar duas stacks Compose, contêineres de stacks diferentes conseguem se acessar pela rede?
  • o mapeamento de domínio e porta interna é definido no arquivo Compose com x-ports: app.example.com:8000/https.
    Ou dá para customizar a configuração do Caddy com x-caddy: Caddyfile. Veja os detalhes na documentação oficial.
    No momento não existe isolamento de rede entre stacks. A discussão sobre isso está em andamento na GitHub Discussion #94.
    Fiquei curioso sobre qual comportamento você esperaria.
  • O recurso de secrets está sendo acompanhado na issue #75. Hoje já é possível injetar via config do Compose, mas ainda não há armazenamento criptografado.
    As respostas para as perguntas 2 e 3 são “ainda não” e “atualmente sim”. Veja também a Discussion #94.
    Como alguém que já usou Swarm, fiquei curioso: em que pontos o Swarm te pareceu insuficiente ou incômodo, e onde o Uncloud poderia melhorar isso?

• Projeto muito bacana. Também vale olhar outras ferramentas com tema parecido:

  • Dokploy
  • Coolify
  • Kubero
    Se conhecer mais, seria legal acrescentar.
  • A lista de PaaS self-hosted é útil.
    Testei o Coolify recentemente e achei meio inacabado. No momento uso Dokku, mas gostaria que a UI de gerenciamento de banco de dados fosse melhor.

• Estou satisfeito com k3s, mas gosto de ver novas tentativas nesse meio-termo entre Docker Compose e K8s completo. A integração com WireGuard é especialmente interessante.

• Ferramenta realmente excelente. Obrigado pelo trabalho.
  Fiquei curioso sobre como funciona a replicação de estado no backend. Vi menção a CRDT e protocolo gossip, mas a implementação concreta ainda me parece vaga.

  • Atualmente a replicação de estado é baseada em Corrosion.

• Se não é K8s, por que não Nomad?

  • Nomad também é bom, mas ainda tem um plano de controle.
  • O Nomad tem uma curva de aprendizado considerável. Já o Uncloud é praticamente usável de imediato para quem já conhece Docker e Compose.
  • A licença da HashiCorp proíbe oferecer uma versão modificada como SaaS.
    Ou seja, fora do uso auto-hospedado, o aproveitamento fica limitado e, na prática, não dá para transformá-lo livremente em serviço. Veja o texto completo da licença.

• Como referência, compartilho dois componentes p2p interessantes:

  • edgevpn
  • iroh.computer