Aseptic vs Docker Compose
Quase toda a gente começa aqui, e com razão: um docker-compose.yml e um comando
levantam Kafka, Redis e Postgres sem discussão. A pergunta não é se o Compose serve —serve—,
mas o que acontece quando o que está dentro do compose deixa de ser infraestrutura e começam
a ser os teus serviços, aqueles em que mexes todos os dias.
Numa frase
O Docker Compose declara um conjunto de contentores e a sua rede num ficheiro YAML, e levanta-os juntos. Tudo o que corre, corre em contentor; tudo o que comunica, fá-lo pelo nome do serviço dentro dessa rede.
O Aseptic usa Docker para a infraestrutura comum e arranca os teus serviços como processos da tua máquina, resolvendo cada dependência para um serviço local, o teu ambiente partilhado na nuvem ou um mock, e reescrevendo os URLs entre eles ao levantar.
A tabela
| Docker Compose | Aseptic | |
|---|---|---|
| Levanta a infraestrutura comum | Sim, é o que faz melhor | Sim — com Docker, por baixo |
| Os teus serviços | Em contentor, com a sua imagem | Nativos por omissão; em contentor se quiseres |
| Ver uma mudança de código | Reconstruir a imagem e recriar o contentor | O hot reload do próprio framework |
| Depurador ligado | Pode-se, ligando portas e opções | É um processo local: como sempre |
| Para onde chama cada serviço | Ao nome do serviço na rede do compose | Por dependência: local, nuvem ou mock |
| Levantar só uma parte do sistema | up de alguns; o resto, à mão | O cenário define o que entra, e o resto resolve-se sozinho |
| Configuração | Um YAML, normalmente dentro de um repo | Cenários fora dos repos; manifestos autodetetados |
| Colisões de portas | Resolve-las tu | Remapeamento automático |
| Serve também na CI | Sim | Não — é uma ferramenta de ambiente de trabalho |
| Licença | Código aberto | Grátis para uso pessoal, pago para uso comercial |
Fica-te pelo Docker Compose se…
- O teu sistema são dois ou três serviços estáveis e não lhes tocas diariamente. Um compose e um comando é difícil de superar, e não instalas nada de novo.
- Precisas do mesmo na tua máquina e na CI. O Aseptic é de ambiente de trabalho; o Compose corre nos dois sítios com o mesmo ficheiro.
- Os serviços que levantas são de outros e só têm de estar de pé: se nunca lhes tocas, que corram em contentor é exatamente o que queres.
- Queres uma ferramenta de código aberto, sem licença para rever.
Fica-te pelo Aseptic se…
- O serviço em que estás a mexer queres nativo —com hot reload e o depurador ligado— e os outros levantados e quietos. Isso é uma mistura que um compose não distingue: lá dentro, tudo é um contentor.
- Queres levantar três dos doze e que os outros nove saiam para o teu ambiente da nuvem ou para um mock, decidindo-o por dependência e não por ambiente.
- Estás cansado de mudar um URL no
application.ymlde um repositório que não é teu e de te lembrares de não o comitar. - Queres que o ambiente se partilhe como um ficheiro e não como um documento de quarenta passos que ninguém atualiza.
Onde o Aseptic fica curto
Não corre na CI. É uma aplicação de ambiente de trabalho com o seu CLI, pensada para o ciclo de trabalho de uma pessoa. Se o que procuras é levantar dependências dentro de um job de integração contínua, o Compose —ou o Testcontainers— é a resposta, e o Aseptic não compete aí.
Também não é código aberto, e o Compose leva anos a ser o padrão de facto: está na máquina de toda a gente, há respostas para qualquer problema e não é preciso convencer ninguém a instalá-lo.
E se o teu sistema é pequeno, o Aseptic é maquinaria a mais. A vantagem aparece quando há serviços suficientes para que decidir para onde chama cada um seja um trabalho em si mesmo.
O que costuma acabar por acontecer
Que convivem, porque não competem na mesma camada. O compose fica com o que o Compose faz bem —a infraestrutura comum—, e de facto o Aseptic usa-o tal e qual: apontas-lhe o ficheiro que já tens. O que sai do compose são os teus serviços, que é onde o ciclo de construir uma imagem por cada linha que mudas se nota.
Se estás a comparar também o Tilt, o Skaffold ou um Kubernetes local, a página de alternativas ao Docker Compose põe-nas lado a lado, e o comparativo amplo cobre as três abordagens gerais. Se o que te ronda é se o Testcontainers já te resolve isto, está a comparação com o Testcontainers.
Perguntas frequentes
O Aseptic substitui o Docker Compose?
Não, usa-o. O Aseptic levanta a infraestrutura comum (Kafka, Redis, PostgreSQL) com Docker, tal como tu farias. O que muda é o que acontece aos teus serviços: em vez de construir uma imagem de cada um a cada mudança, corre-os como processos da tua máquina —ou em contentor, se preferires— e reescreve-lhes os URLs ao levantar.
Posso continuar a usar o meu docker-compose.yml?
Sim. O Aseptic aponta para o ficheiro compose que já tens para a infraestrutura; não há nada para reescrever nem para migrar para outro formato.
O que ganha o Docker Compose sobre o Aseptic?
É padrão, é código aberto e qualquer um o executa sem instalar mais nada: se o teu sistema é pequeno e estável, um compose e um comando é difícil de superar. É também o único dos dois que funciona igual na CI e no teu portátil.
E se só quiser levantar dois dos meus doze serviços?
É esse justamente o caso em que o compose fica curto: ou levantas também os outros dez, ou editas à mão os URLs dos dois que realmente queres. No Aseptic decides por dependência se a resolves para o serviço local, para o teu ambiente na nuvem ou para um mock, e aplica-se ao arrancar sem tocar nos teus repositórios.
Preciso de Docker para usar o Aseptic?
Sim, para a infraestrutura comum. O Aseptic gere esses contentores por ti, com remapeamento automático de portas quando colidem.