1

Pitch: Tender: uma alternativa open source ao Docker Desktop para quem usa Docker no WSL 2

Quem desenvolve no Windows e utiliza Docker geralmente acaba seguindo um de dois caminhos: instala o Docker Desktop ou configura o Docker Engine diretamente em uma distribuição do WSL 2 e gerencia tudo pelo terminal.

O segundo caminho funciona muito bem, mas sempre senti falta de uma interface gráfica para visualizar e administrar os recursos do Docker sem precisar abrir mão dessa configuração.

Foi daí que surgiu o Tender.

O Tender é um aplicativo desktop open source, licenciado sob MIT, que se conecta ao Docker Engine que você já possui. A ideia é oferecer uma experiência visual para administrar ambientes Docker e Kubernetes, sem instalar outro daemon, criar uma VM própria ou exigir uma conta.

O que é possível fazer com o Tender?

O projeto começou com o gerenciamento de Docker, mas acabou evoluindo para algo um pouco maior.

Docker

  • Visualizar e administrar containers, imagens, volumes e projetos Docker Compose.
  • Acompanhar logs em tempo real, com busca, filtros e exportação.
  • Monitorar CPU, memória, rede e I/O dos containers.
  • Acessar terminais dentro dos containers.
  • Utilizar um shell de debug baseado em BusyBox para investigar containers sem shell próprio, incluindo imagens distroless e scratch, sem modificá-las.

Kubernetes

Também implementei uma integração com Kubernetes, utilizando os contextos disponíveis no kubeconfig.

  • Gerenciamento de Pods, Deployments, Jobs, CronJobs, Ingresses e Secrets.
  • Visualização de eventos e manifests YAML.
  • Histórico de rollouts e possibilidade de rollback.
  • Port forwarding.
  • Proteção adicional para clusters identificados como produção, exigindo confirmação antes de operações de alteração.

Um detalhe importante: ao visualizar Secrets, o Tender exibe somente os nomes das chaves, nunca seus valores.

Integração com Windows e WSL 2

Essa é provavelmente a parte que mais diferencia o projeto.

O Tender consegue se comunicar com o Docker Engine executado dentro do WSL 2 sem precisar expor uma porta TCP ou modificar a configuração da distribuição Linux.

Além disso, disponibiliza o named pipe padrão:
//./pipe/docker_engine

Isso permite que ferramentas que esperam encontrar o Docker no Windows continuem funcionando, como:

  • Docker CLI (docker.exe);
  • Extensão Docker do VS Code;
  • Testcontainers;
  • IDEs JetBrains.

Também implementei funcionalidades para ajudar a identificar e recuperar recursos consumidos pelo WSL, incluindo memória, discos virtuais e cache de build.

Para quem está migrando do Docker Desktop, existe ainda uma funcionalidade de migração de containers, imagens e volumes.

E, para facilitar o diagnóstico de problemas, o aplicativo conta com uma tela de Checkup que verifica o WSL, Docker Engine, DNS e ferramentas do Windows, apresentando orientações para corrigir os problemas encontrados.

Algumas decisões técnicas

O projeto foi desenvolvido utilizando:

  • Electron 44 + React 18 + TypeScript: estrutura principal da aplicação.
  • Dockerode: comunicação com o Docker Engine.
  • @kubernetes/client-node: integração com Kubernetes.
  • SQLite (node:sqlite): persistência local de preferências, endpoints, notificações e histórico.
  • TanStack Query e TanStack Table: gerenciamento de cache, polling e tabelas.
  • xterm.js: implementação dos terminais.
  • uPlot: gráficos e métricas.

Além da stack, algumas decisões de arquitetura merecem destaque.

1. Comunicação IPC com validação

O renderer executa em sandbox e não possui acesso direto aos recursos do processo principal.

A comunicação acontece por meio de uma API restrita, exposta pelo preload. Cada chamada passa por uma verificação da origem e pela validação dos argumentos utilizando Zod antes de chegar ao Docker ou Kubernetes.

A intenção foi manter uma fronteira bem definida entre a interface e as operações privilegiadas da aplicação.

2. Desenvolvimento sem depender de Docker

Uma das coisas que considero interessantes no projeto é o modo npm run dev:design.

Ele permite executar a interface em um navegador utilizando um Docker Engine simulado. Com isso, consigo desenvolver funcionalidades, validar componentes e executar testes Playwright, incluindo verificações de acessibilidade com axe, sem precisar ter Docker instalado na máquina.

Inclusive, os screenshots utilizados neste post foram gerados nesse ambiente.

3. Testes de integração com Kubernetes

Para não depender apenas de mocks, os testes de integração com Kubernetes executados no CI utilizam um cluster real criado com kind.

Estado atual

O Tender está atualmente em beta, na versão 0.8.

  • Windows: disponível.
  • Linux: disponível.
  • macOS: compilação a partir do código-fonte.

Um ponto importante: os instaladores ainda não possuem assinatura de código. Portanto, o Windows SmartScreen pode exibir um aviso na primeira execução.

Cada release também disponibiliza um arquivo SHA256SUMS.txt para verificação da integridade dos downloads.

No Windows, a conferência pode ser feita com:

Get-FileHash .\Tender-Setup-<versão>.exe -Algorithm SHA256

O que vem pela frente?

Ainda tenho algumas ideias para evoluir o projeto:

  • Gerenciamento de networks.
  • Build de imagens diretamente a partir de Dockerfiles.
  • Inicialização de projetos a partir de arquivos compose.yaml.
  • Integração com Trivy para análise de vulnerabilidades, sem necessidade de login.

Feedback e contribuições

Esse é um projeto que desenvolvi por iniciativa própria, fora do ambiente de trabalho, e que decidi disponibilizar publicamente.

Gostaria muito de receber feedback principalmente de quem utiliza Docker diretamente no WSL 2.

O que está faltando? O que poderia ser melhor? Existe alguma funcionalidade que faria você considerar utilizar o Tender no lugar de outra ferramenta?

Contribuições, sugestões e abertura de issues são muito bem-vindas. Caso encontre alguma vulnerabilidade, existe também a possibilidade de reportá-la de maneira privada pela aba Security do repositório.

Repositório: https://github.com/jluispbraga/Tender

O projeto é open source e está disponível sob licença MIT.

Se puderem dar uma olhada, testar e compartilhar as impressões, já vai ajudar bastante! :)

Carregando publicação patrocinada...
1

Ótimo conteúdo. Em fluxos de desenvolvimento local, automatizar tarefas repetitivas de diagnóstico (como checar portas ocupadas e processos órfãos) economiza um tempo absurdo ao longo da semana.