Differenza tra chroot e Docker


15

Non capisco la differenza tra docker e chroot. Sì, è bello in termini di packaging del registro. Ma in qualche modo ho la sensazione che sia solo chroot con campane e fischietti extra.

So che mi manca qualcosa. Sarebbe bello sapere come sono diversi e la necessità di docker se Chroot potesse fare qualcosa di simile.

Non sono riuscito a trovare questo Chroot Vs Docker abbastanza chiaro.


Bene, sì, Docker non fa nulla che il kernel non faccia già per te. Lo impacchetta semplicemente in uno strumento più o meno coerente e abbastanza facile da usare. Potresti creare il tuo Docker se potresti essere disturbato a fare chroot, spazi dei nomi, quote, NAT e tutto il resto da solo.
Gaius,

Risposte:


8

Bene, le campane e i fischietti extra sono chiamati isolamento del processo, un contenitore ottiene il proprio spazio dei nomi dal kernel host, il che significa che il programma nel contenitore non può provare a leggere la memoria del kernel o consumare più RAM di quanto consentito.

Inoltre, isola gli stack di rete, quindi due processi possono ascoltare ad esempio sulla porta 8080, dovrai gestire il routing a livello di host, non c'è magia qui, ma questo consente di gestire il routing in un punto ed evitare di modificare la configurazione del processo in ascolta una porta libera.

In secondo luogo un chroot è ancora in lettura / scrittura, qualsiasi modifica è permanente, l'utilizzo di un contenitore docker aufsverrà avviato da un filesystem pulito ogni volta che si avvia il contenitore (le modifiche vengono mantenute se si interrompe / si avvia IIRC).

Quindi, mentre un contenitore può essere pensato come process namespace+ chroot, la realtà è un po 'più complessa.


Si noti che aufsnon viene più utilizzato per impostazione predefinita. Ora èoverlay2
Vitalii Vitrenko l'

Vero, ma penso che ci siano più materiali didattici che fanno riferimento aufs di overlay2 per ora :)
Tensibai,

Un normale processo non è in grado di leggere alcuna memoria che non dovrebbe neanche. Se fai affidamento su Docker per motivi di sicurezza, stai sbagliando ...
Gaius,

@Gaius mi stai leggendo male, sto solo cercando di fornire indizi di ricerca all'OP ... Aggiungere docker in una pipeline di consegna con tutta la libertà che offre allo sviluppatore a ciò che usano all'interno non è assolutamente un punto di sicurezza. Tuttavia gli spazi dei nomi proteggono da un mucchio di overflow dello stack e buffer overflow per natura.
Tensibai,

5

Sì, c'è assolutamente di più oltre chrootal punto che hanno poco o niente in comune.

  • Un formato di file di script standardizzato che include la semantica relativa al compito una mano
  • Immagini (comprese le immagini intermedie anonime), memorizzazione nella cache, denominazione, download, ecc. Inclusa una potente gestione ( docker image prune...)
  • Contenitori (compresi i propri file system temporanei, la denominazione, la possibilità di docker execinserirli ecc.)
  • Gestione dei processi ( docker container ...)
  • Networking con una semplice opzione, incluso intra-docker-container-networking ecc.
  • Volumi (inclusi volumi gestiti speciali)
  • docker-compose o brulicare come aggiornamenti di basso profilo a molto di più.
  • Il grande zoo di altre soluzioni basate su container dockerizzati (OpenShift ecc.).
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.