Ho sostituito Docker Desktop con i container nativi di Linux e non mi sono mai voltato indietro
Docker Desktop è indubbiamente elegante. L'interfaccia pulita, la gestione con un clic e l'astrazione della complessità lo rendono ottimo per i principianti, ma quell'astrazione ha un prezzo.
Eseguire Docker Desktop su Linux ha poco senso perché Docker Desktop stesso avvia una macchina virtuale Linux nascosta per funzionare. Quindi i tuoi container non girano veramente sulla tua macchina, ma all'interno di una VM. Questo strato aggiuntivo consuma costantemente risorse e trasforma la risoluzione dei problemi in un incubo, ed è per questo che ho deciso di passare ai container Linux nativi e non ho mai guardato indietro.
Incus non è solo “un altro sostituto di Docker”
Proviene da una tradizione di contenitori diversa
La maggior parte delle alternative a Docker cerca di comportarsi come Docker. Podman mantiene familiare il modello di immagini e comandi, nerdctl offre a containerd un'interfaccia simile a Docker, e Rancher Desktop e strumenti simili avvolgono Kubernetes locale o il runtime dei container in qualcosa di più accessibile. Questi sono strumenti utili, ma vivono ancora per lo più nel mondo dei container applicativi.
Incus proviene da una linea di discendenza diversa. È la continuazione comunitaria del modello di container di sistema in stile LXD, il che significa che è costruito attorno all'idea di gestire ambienti Linux completi, non solo immagini di applicazioni a processo singolo. Un container Incus può sembrare una VM leggera. Ha un sistema init, networking, storage, profili, snapshot e identità persistente. Puoi fare SSH in esso, installare pacchetti, eseguire servizi e trattarlo come una piccola macchina.
Ma per molto tempo, ho dovuto usare Docker per le immagini delle applicazioni OCI e Incus per i contenitori di sistema e le macchine virtuali, ma poi Incus ha iniziato a supportare i contenitori OCI, e ora posso eseguire la maggior parte dei miei contenitori usando quello.
Il supporto OCI ha cambiato l'equazione
Ora puoi eseguire immagini docker su Incus
Il supporto OCI è la parte che rende Incus molto più interessante come alternativa a Docker Desktop. Docker ha reso popolare il flusso di lavoro, ma il formato delle immagini e l'ecosistema dei registri non sono più legati all'esperienza di Docker Desktop. Gran parte di ciò che le persone chiamano "immagini Docker" sono in realtà immagini in stile OCI distribuite attraverso i registri.
Con il supporto Incus OCI, posso scaricare ed eseguire container di applicazioni utilizzando immagini da registry come Docker Hub. Ciò significa che il divario pratico diventa più piccolo. Posso eseguire un normale container di sistema Linux quando ho bisogno di un ambiente persistente, e posso eseguire un container di applicazione OCI quando ho solo bisogno del servizio confezionato.
Questo è il cambiamento che ha fatto scattare Incus per me, poiché la mia infrastruttura locale poteva contenere entrambi i tipi di container. Preferisco i container OCI quando l'immagine dell'applicazione è già l'unità giusta. Questo significa che Nginx, Caddy, Redis, piccole applicazioni web, exporter, servizi di test e strumenti preconfezionati possono funzionare come container OCI. Una macchina di sviluppo, un ambiente di build o un host di servizio possono funzionare come container di sistema. Le VM rimangono disponibili nei casi in cui ho bisogno di un kernel separato o di un confine di isolamento più forte.
Non dirò che Incus sia un sostituto perfetto uno a uno di Docker Compose perché Compose rimane molto valido nel descrivere stack di applicazioni multi-contenitore. La cosa buona è che Incus non cerca di essere Compose con un logo diverso. Si sente più come un cloud privato locale con supporto per più tipi di istanze e questo è un modello diverso, e serve un piccolo adattamento, ma il vantaggio è che l'adattamento si ripaga rapidamente.
L'interfaccia web fa sentire Incus come un cloud locale
Dà visibilità senza trasformare tutto in un prodotto dashboard
La linea di comando di Incus è abbastanza buona da permetterti di gestire tutto dal terminale. È così che inizio gran parte del flusso di lavoro quotidiano. Per un po', non pensavo di aver bisogno di nient'altro.
Poi ho iniziato a usare l'interfaccia web. L'interfaccia web cambia la percezione di Incus. Rende visibili contenitori, VM, reti, volumi di archiviazione, profili e immagini in un unico posto. Puoi vedere cosa è in esecuzione, ispezionare la configurazione, aprire console, controllare snapshot e comprendere la struttura dell'ambiente senza eseguire cinque comandi e unire mentalmente i risultati. Inoltre, puoi effettuare il passaggio della GPU con pochi clic.
Un'interfaccia web non è un sostituto per comprendere il sistema, ma è molto buona per rendere il sistema ispezionabile. Incus mi dà questo senza rendere la GUI il centro dell'architettura.
Il mio flusso di lavoro quotidiano è diventato più semplice
L'ospite si sente più pulito
La prima cosa che ho notato dopo aver spostato più lavoro su Incus è stata quanto più pulito apparisse il mio host. Potevo smettere di installare versioni casuali di database, runtime di linguaggi, code di messaggi e dipendenze di build direttamente sul laptop. Questo era già vero con Docker, naturalmente, ma Incus ha reso gli ambienti di sviluppo a lungo termine più naturali.
Ad esempio, se voglio una macchina di sviluppo basata su Debian, non ho bisogno di scrivere un Dockerfile solo per simulare un sistema normale. Posso avviare un contenitore Debian, installare ciò di cui ho bisogno, crearne uno snapshot e tenerlo a disposizione. Se rompo qualcosa, ripristino lo snapshot. Se voglio una seconda copia, la clono. Se ho bisogno di testare contro un'altra distribuzione, avvio un'altra immagine.
Questo è particolarmente utile per la scrittura e la sperimentazione sull'infrastruttura. Quando sto testando il comportamento di systemd, strumenti di rete, differenze tra gestori di pacchetti o configurazioni dei servizi, un contenitore di sistema ha più senso di un contenitore Docker a processo singolo. Voglio che l'ambiente si comporti come una piccola macchina Linux perché è di solito di questo che parla l'articolo o l'esperimento. Docker può essere spinto in questo ruolo, ma sembra sempre leggermente fuori posto.
Il networking è meno misterioso
È ancora networking, quindi può ancora punirti
Il networking dei container è dove molti strumenti "semplici" diventano meno semplici. Docker Desktop nasconde gran parte di questo, specialmente su piattaforme non Linux. Su Linux, la magia è meno necessaria, ma le abitudini rimangono. Pubblicate porte, ispezionate bridge, vi chiedete quale percorso DNS viene utilizzato e alla fine finite per leggere regole di iptables o nftables mentre vi pentite dell'ottimismo precedente.
Il networking di Incus risulta più esplicito poiché è possibile creare bridge gestiti, collegare istanze alle reti, assegnare dispositivi tramite profili, utilizzare dispositivi proxy e ispezionare la configurazione in un modo che sembra più vicino all'amministrazione normale di Linux. Non elimina la necessità di comprendere il networking e nulla di buono lo fa (direi addirittura “dovrebbe”), ma rende il modello più facile da comprendere perché il container è trattato come un'istanza gestita con dispositivi, non solo come un processo con mappature di porte.
Perché non sto tornando indietro?
La ragione per cui sono rimasto con Incus non è l'ideologia. Non mi interessa sostituire un logo con un altro logo. Mi importa avere un ambiente locale che sia veloce, ispezionabile, scriptabile e vicino a Linux. Incus mi fornisce container di sistema quando ho bisogno di piccole macchine Linux e VM quando i container non sono sufficienti. Quella combinazione è difficile da battere.
Docker Desktop è ancora utile per molte persone, specialmente su macOS e Windows, dove il contenitore Linux deve comunque passare attraverso una VM. Su Linux, però, non vedo più il senso di portare quello strato extra per il mio flusso di lavoro quotidiano. I contenitori Linux nativi sembrano più diretti e Incus li rende gestibili senza renderli semplicistici.