Aseptic vs Docker Compose
Quasi tutti cominciano da qui, e a ragione: un docker-compose.yml e un comando
avviano Kafka, Redis e Postgres senza discussione. La domanda non è se Compose serva —serve—,
ma cosa succede quando ciò che sta dentro il compose smette di essere infrastruttura e comincia
a essere i tuoi servizi, quelli che tocchi ogni giorno.
In una frase
Docker Compose dichiara un insieme di container e la loro rete in un file YAML, e li avvia insieme. Tutto ciò che gira, gira in container; tutto ciò che comunica, lo fa tramite il nome del servizio dentro quella rete.
Aseptic usa Docker per l'infrastruttura comune e avvia i tuoi servizi come processi della tua macchina, risolvendo ogni dipendenza verso un servizio locale, il tuo ambiente condiviso nel cloud o un mock, e riscrivendo gli URL fra loro all'avvio.
La tabella
| Docker Compose | Aseptic | |
|---|---|---|
| Avvia l'infrastruttura comune | Sì, è ciò che fa meglio | Sì — con Docker, sotto |
| I tuoi servizi | In container, con la loro immagine | Nativi di default; in container se vuoi |
| Vedere una modifica al codice | Ricostruire l'immagine e ricreare il container | L'hot reload del framework stesso |
| Debugger agganciato | Si può, cablando porte e opzioni | È un processo locale: come sempre |
| Dove chiama ogni servizio | Al nome del servizio nella rete del compose | Per dipendenza: locale, cloud o mock |
| Avviare solo una parte del sistema | up di alcuni; il resto, a mano | Lo scenario definisce cosa entra, e il resto si risolve da solo |
| Configurazione | Uno YAML, di solito dentro un repo | Scenari fuori dai repo; manifest rilevati in automatico |
| Collisioni di porte | Le risolvi tu | Rimappatura automatica |
| Serve anche in CI | Sì | No — è uno strumento desktop |
| Licenza | Open source | Gratis per uso personale, a pagamento per uso commerciale |
Resta con Docker Compose se…
- Il tuo sistema sono due o tre servizi stabili che non tocchi ogni giorno. Un compose e un comando sono difficili da battere, e non installi nulla di nuovo.
- Ti serve la stessa cosa sulla tua macchina e in CI. Aseptic è desktop; Compose gira in entrambi i posti con lo stesso file.
- I servizi che avvii sono di altri e devono solo stare su: se non li tocchi mai, che girino in container è esattamente quello che vuoi.
- Vuoi uno strumento open source, senza licenza da esaminare.
Resta con Aseptic se…
- Il servizio che stai modificando lo vuoi nativo —con hot reload e il debugger agganciato— e gli altri su e zitti. Quella è una miscela che un compose non distingue: lì dentro, tutto è un container.
- Vuoi avviarne tre dei dodici e che gli altri nove escano verso il tuo ambiente nel cloud o verso un mock, decidendolo per dipendenza e non per ambiente.
- Sei stanco di cambiare un URL nell'
application.ymldi un repository che non è tuo e di ricordarti di non committarlo. - Vuoi che l'ambiente si condivida come un file e non come un documento di quaranta passi che nessuno aggiorna.
Dove Aseptic resta corto
Non gira in CI. È un'applicazione desktop con la sua CLI, pensata per il ciclo di lavoro di una persona. Se quello che cerchi è avviare dipendenze dentro un job di integrazione continua, Compose —o Testcontainers— è la risposta, e Aseptic non compete lì.
Non è nemmeno open source, e Compose è da anni lo standard di fatto: sta sulla macchina di tutti, c'è una risposta per qualsiasi problema e non bisogna convincere nessuno a installarlo.
E se il tuo sistema è piccolo, Aseptic è più macchinario di quello che ti serve. Il vantaggio compare quando ci sono abbastanza servizi perché decidere dove chiama ognuno sia un lavoro in sé.
Quello che di solito finisce per succedere
Che convivono, perché non competono sullo stesso livello. Il compose si tiene ciò che Compose fa bene —l'infrastruttura comune—, e di fatto Aseptic lo usa così com'è: gli punti il file che hai già. Ciò che esce dal compose sono i tuoi servizi, ed è lì che il ciclo di costruire un'immagine per ogni riga che cambi si sente.
Se stai valutando anche Tilt, Skaffold o un Kubernetes locale, la pagina delle alternative a Docker Compose le mette fianco a fianco, e il confronto ampio copre i tre approcci generali. Se quello che ti frulla è se Testcontainers già ti risolva questo, c'è il confronto con Testcontainers.
Domande frequenti
Aseptic sostituisce Docker Compose?
No, lo usa. Aseptic avvia l'infrastruttura comune (Kafka, Redis, PostgreSQL) con Docker, proprio come faresti tu. Quello che cambia è cosa succede ai tuoi servizi: invece di costruire un'immagine di ognuno a ogni modifica, li esegue come processi della tua macchina —o in container, se preferisci— e ne riscrive gli URL all'avvio.
Posso continuare a usare il mio docker-compose.yml?
Sì. Aseptic punta al file compose che hai già per l'infrastruttura; non c'è nulla da riscrivere né da migrare a un altro formato.
Cosa fa meglio Docker Compose rispetto ad Aseptic?
È standard, è open source e lo esegue chiunque senza installare altro: se il tuo sistema è piccolo e stabile, un compose e un comando sono difficili da battere. È anche l'unico dei due che funziona in CI come sul tuo portatile.
E se voglio avviare solo due dei miei dodici servizi?
È proprio il caso in cui compose resta corto: o avvii anche gli altri dieci, o modifichi a mano gli URL dei due che vuoi davvero. In Aseptic decidi per dipendenza se risolverla verso il servizio locale, il tuo ambiente nel cloud o un mock, e si applica all'avvio senza toccare i tuoi repository.
Mi serve Docker per usare Aseptic?
Sì, per l'infrastruttura comune. Aseptic gestisce quei container per te, con rimappatura automatica delle porte quando collidono.