Montare il contenuto del contenitore Docker nel file system host

24

Voglio essere in grado di ispezionare il contenuto di un contenitore Docker (sola lettura). Un modo elegante per farlo sarebbe montare il contenuto del contenitore in una directory. Sto parlando di montare il contenuto di un contenitore sull'host, non di montare una cartella sull'host all'interno di un contenitore.

Vedo che ci sono due driver di archiviazione in Docker in questo momento: aufs e btrfs. La mia installazione Docker utilizza btrfs e la navigazione in / var / lib / docker / btrfs / sottovolumi mi mostra una directory per contenitore Docker sul sistema. Questo è comunque un dettaglio di implementazione di Docker e sembra sbagliato montare - legare queste directory da qualche altra parte.

Esiste un modo corretto per farlo o devo patchare Docker per supportare questo tipo di supporti?

— dflemstr
fonte

Perché sarebbe sbagliato legare questi da qualche altra parte?

— Michael Hampton

1

Perché il percorso di archiviazione è un dettaglio di implementazione. La finestra mobile giorno aggiunge un altro driver di archiviazione, la posizione si sposterà. Devo renderlo semiautomatico e sarebbe bello usare le API pubbliche per questo motivo.

— dflemstr,

2

Potrebbe valere la pena considerare di lavorare su nsenter (o docker-enter) per raggiungere i tuoi obiettivi; c'è ovviamente il vincolo di dover inserire il codice / gli strumenti di ispezione all'interno del contenitore.

— VladFr

Non c'è modo di istruire Linux a montare attraverso un confine container?

— dflemstr,

@dflemstr sì, c'è, --volumes-from kinda lo fa, sembra montare un'unione della directory dall'immagine di base dell'altro contenitore e dal volume, ma questo comportamento non è documentato

— afaik

10

Dai un'occhiata docker export.

Per elencare rapidamente i file nel contenitore:

docker export CONTAINER|tar -t

Esportare:

docker export CONTAINER>snapshot.tar
docker export CONTAINER|tar x PATH-IN-CONTAINER

O per guardare un file:

docker export CONTAINER|tar x --to-stdout PATH-IN-CONTAINER
# e.g. 
docker export consul|tar x --to-stdout etc/profile

Docker 1.8 supporta cp :

https://docs.docker.com/reference/commandline/cp/

Usage:  docker cp [options] CONTAINER:PATH LOCALPATH|-
        docker cp [options] LOCALPATH|- CONTAINER:PATH

aggiornamento: dovresti ssh sul tuo computer docker quando esegui questo.

— laktak
fonte

2

Le mie immagini sono abbastanza grandi (molte centinaia di MiB), quindi fare questo per recuperare singoli file è un sovraccarico eccessivo. Creerà il file da più di cento megabyte ogni volta.

— dflemstr,

@dflemstr usa la linea con tar x PATH-IN-CONTAINER, estrarrà solo i file necessari.

— Laktak,

... ma l'intero tararchivio è ancora creato nel demone Docker e ci vogliono più minuti per creare ...

— dflemstr

@dflemstr non è sicuro di quale sia la tua configurazione ma, ad esempio, docker export ubuntu|tar -t|grep etc/networkrichiede 3 secondi per me.

— Laktak,

Probabilmente lo stai eseguendo sulla stessa macchina del demone Docker, quindi non è necessario eseguire un trasferimento di rete e l' ubuntuimmagine è davvero piccola ...

— dflemstr,

3

È possibile utilizzare il commit docker per mantenere lo stato corrente del contenitore in una nuova immagine e avviare un contenitore interattivo da questa immagine per ispezionarne il contenuto.

Dalla documentazione:

Può essere utile eseguire il commit delle modifiche o delle impostazioni del file di un container in una nuova immagine. Ciò consente di eseguire il debug di un contenitore eseguendo una shell interattiva o di esportare un set di dati funzionante su un altro server.

Spero che sia di aiuto.

— Eric Citaire
fonte

2

È possibile utilizzare nsenter per eseguire il programma di ispezione (che probabilmente deve essere già incluso nel contenitore) all'interno di un contenitore / spazio dei nomi. Ma per montare il filesystem contenitore come si vede al suo interno è necessario montare l'immagine originale e tutti i livelli se è aufs, o l'azione equivalente per mappatore dispositivo, btrfs e gli altri (futuri) motori di archiviazione utilizzati, diversi in ciascun caso. Probabilmente sarebbe più efficiente lasciare che il docker faccia il lavoro per te, esattamente come dovrebbe fare, e usare nsenter per fare l'ispezione all'interno del container.

Ci sono altri approcci. docker diff mostrerà quali file sono cambiati in quel contenitore, se vuoi vedere cosa è cambiato invece di quello che era nell'immagine originale.

E per i dati che devono essere persistenti e ispezionabili, probabilmente un modello migliore sarebbe di averli in un volume nel contenitore e di averli montati sul filesystem reale o in un contenitore di dati puro o nello stesso contenitore, ma che è possibile avviare un altro contenitore con il programma di ispezione montando quei volumi da esso.

— gmuslera
fonte

1

EDIT: ho provato la soluzione qui sotto e sfortunatamente non ha funzionato bene per me in pratica. Il filesystem montato non rifletteva accuratamente il filesystem del container (anche con cache=no). Non sono sicuro che questo sia un problema fondamentale o che io stia facendo qualcosa di sbagliato.

È possibile installare sshd nell'immagine della finestra mobile e utilizzare docker execper eseguire un servizio ssh ( /usr/sbin/sshd -D) sul contenitore della finestra mobile (si noti che la porta SSH 22 del contenitore della finestra mobile deve essere esposta).

Quindi, utilizzare docker cpper copiare la chiave ssh pubblica nella /root/.ssh/authorized_keysdirectory del contenitore della finestra mobile.

Infine, usa docker inspectper trovare l'indirizzo IP del container e montare il filesystem del container usando

sudo sshfs -o allow_other,default_permissions,IdentityFile=/path/to/identityfile  root@xxx.xx.x.x:/ /mnt/my_container

Dovresti scrivere una sceneggiatura per farlo funzionare comodamente in pratica.

— mnieber
fonte