L’obiettivo principale non è l’isolamento, ma la facilità di distribuzione…
Non è necessario isolare il container; puoi eseguirlo su un bridge instradato o su un bridge a cui appartiene una porta della tua rete interna. Il primo è il modo in cui lo eseguiamo in produzione - vedi qui un video di @mpalmer che spiega come funziona.
Se qualcuno vuole davvero farlo, può seguire gli stessi passaggi eseguiti dal Dockerfile per ottenere le versioni corrette di tutti gli strumenti utilizzati dall’immagine supportata.
Non abbiamo una guida poiché ciò richiederebbe a qualcuno di mantenerla, e la VASTA maggioranza delle persone che lo desiderano ha:
- poca esperienza con i server
- conoscenze sufficienti per prendere ciò che forniamo e adattarlo alle proprie esigenze
Ad esempio, so che ci sono persone là fuori che usano launcher per creare un’immagine che viene distribuita tramite i propri strumenti (che si tratti di lxc, kubernetes, qualunque cosa) e che funziona per loro.
Tentare di supportare (gratuitamente) tutti coloro che utilizzano la propria installazione personalizzata di un software complicato sarebbe un incubo.
Docker è una via di mezzo. Il nostro sistema non è perfetto; è cresciuto un po’ nel tempo e certamente sentiamo il peso di alcune refactoring in ritardo. Abbiamo creato launcher prima ancora che esistesse docker-compose.
Abbiamo intenzione di refattorizzarlo e/o passare a docker-compose, ma al momento non è una priorità.