Docker e condivisione di file su OS X

Question

Ok. Sto giocando con diversi strumenti per preparare l'ambiente di sviluppo. Docker è una buona opzione. Ho creato l'intero ambiente di sviluppo nella finestra mobile e posso creare un progetto al suo interno.

Il codice sorgente per questo progetto si trova all'esterno del contenitore finestra mobile (sull'host). In questo modo è possibile utilizzare l'IDE per modificarlo e utilizzare la finestra mobile per crearlo.

Tuttavia, c'è un problema

a) Docker su OS X utilizza VM (VirtualBox VM)

b) la condivisione di file è ragionevolmente lento (modo più lento di quello del file IO su host)

c) Il progetto ha qualcosa come un file gazzilion (che esagera i problemi #a an #b).

Se sposto il codice sorgente nella finestra mobile, avrò lo stesso problema in IDE (dovrà accedere ai file condivisi e sarà lento).

Ho sentito parlare di una soluzione alternativa per renderlo veloce. Tuttavia, non riesco a trovare alcuna informazione su questo argomento.

Update 1

ho usato Docker funzione di condivisione di file (che significa corro)

docker run -P -i -v <VMDIR>:<DOCKERDIR> -t <imageName> /bin/bash 

Tuttavia, la condivisione tra VM e Docker non è un problema. È veloce.

Il collo della bottiglia è la condivisione tra host e VM.

Answer 1

La soluzione alternativa che utilizzo non è l'utilizzo di boot2docker, ma invece di un vagabondo VM provisioned with docker. Nessuna penalità così grande per il montaggio delle cartelle host-> vagabondo-> finestra mobile.

Sul lato negativo, devo pre-mappare le cartelle a vagrant (fondamentalmente la mia intera directory di lavoro) e pre-esporre una serie di porte dalla casella vagabonda all'host per avere accesso ai servizi di docker direttamente da lì.

Sul lato positivo, quando voglio pulire inutilizzati finestra mobile spazzatura (immagini, volumi, ecc) ho semplicemente distruggere il vm vagabonda e ricrearlo ancora :)

Elaborazione

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config| 
    config.vm.box = "trusty-docker" 
    config.vm.box_url = "https://oss-binaries.phusionpassenger.com/vagrant/boxes/latest/ubuntu-14.04-amd64-vbox.box" 
    config.vm.provision "docker" 

    #by default we'll claim ports 9080-9090 on the host system 
    for i in 9080..9090 
    config.vm.network :forwarded_port, guest: i, host: i 
    end 

    #NB: this folder mapping will not have the boot2docker issue of slow sync 
    config.vm.synced_folder "~/work", "/home/vagrant/work" 
end 

Avere che:

host$ vagrant up && vagrant ssh 
vagrant$ docker run -it --rm -v $(pwd)/work:/work ubuntu:12.04 find /work 

Answer 2

Questo purtroppo è un problema tipico utenti Windows e OS X sono attualmente alle prese con quella canno essere risolto banalmente, specialmente nel caso di utenti Windows. Il principale colpevole è VirtualBox vboxfs che viene utilizzato per la condivisione di file che, nonostante sia incredibilmente utile, si traduce in un I/O del filesystem scadente.

Ci sono numerose situazioni in cui lo sviluppo delle sorgenti del progetto all'interno della VM guest viene portato a passo d'uomo, i due principali sono i punteggi delle fonti di terze parti introdotte dai gestori di pacchetti e dai repository Git con una storia considerevole.

L'approccio ovvio è quello di spostare la maggior parte dei file relativi al progetto al di fuori di vboxfs da qualche altra parte nell'ospite. Per esempio, un collegamento simbolico alla directory gestore di pacchetti in vboxfs albero del progetto, con qualcosa come:

mkdir /var/cache/node_modules && ln -s /var/cache/node_modules /myproject/node_modules

Questo da solo ha migliorato il tempo di avvio da ~ 28 secondi fino a ~ 4 secondi per un'applicazione Node.js con un poche decine di dipendenze in esecuzione sul mio SSD.

Sfortunatamente, questo non è applicabile alla gestione dei repository Git, a corto di splatting/troncamento della cronologia e di commit alla perdita di dati, a meno che il repository Git stesso sia fornito all'interno dell'ospite, il che obbliga ad avere due repository: uno da clonare l'ambiente per gonfiare l'ospite e un altro contenente le fonti effettive, dove il consolidamento dei due mondi diventa un dolore assoluto.

Il modo migliore per affrontare la situazione è a uno:

1. calo vboxfs a favore di un meccanismo di trasporto condiviso che si traduce in una migliore I/O nel guest, come ad esempio il Network File System. Sfortunatamente, per gli utenti Windows, l'unico modo per ottenere il supporto del servizio NFS è eseguire l'edizione aziendale di Windows (che credo sia ancora valida per Windows 10).
2. revert per il montaggio le partizioni del disco nella guest, notando i relativi rischi di dare il vostro hypervisor accesso grezzo disco

Se il pubblico lo sviluppatore è interamente compromessa degli utenti Linux e OS X, l'opzione 1 potrebbe essere fattibile. Crea una macchina Vagrant e configura NFS shares tra host e guest e profitto. Se si hanno utenti Windows, quindi, a meno di acquistarli una licenza aziendale, sarebbe meglio chiedere semplicemente loro di ripartizionare i propri dischi e lavorare all'interno di una VM guest.

Io personalmente uso un host Windows e hanno una partizione di 64 GB sul mio SSD che monto direttamente nel mio ospite Arch Linux e gestire da lì. Sono passato anche a GPT e UEFI e ho la possibilità di avviare direttamente Arch Linux nel caso in cui volessi aggirare il sovraccarico dell'hardware virtualizzato, offrendomi il meglio di entrambi i mondi con pochi compromessi.

Answer 3

Eseguo un semplice script di controllo che avvia un rsync nei miei contenitori dal volume del codice sorgente condiviso a un volume solo contenitore ogni volta che qualcosa cambia. Il mio entry-point legge solo dal volume del contenitore in modo da evitare i problemi di prestazioni e rsync funziona molto bene, specialmente se lo si imposta correttamente per evitare cose come le cartelle .git e le librerie che non cambiano frequentemente.

Answer 4

paio di pezzi di informazioni che ho trovato

• ho iniziato ad usare Vagrant per lavorare con VirtualBox e installarlo Docker in esso. Dà una maggiore flessibilità

• condivisione predefinito in Vagrant VirtualBox provisioning è molto lento

• NFS condivisione è molto più veloce. Tuttavia, potrebbe essere ragionevolmente lento (specialmente se il processo di generazione creerà file che devono essere riscritti su questa condivisione).

• Vagrant 1.5+ hanno un'opzione rsync (per utilizzare rsync per copiare i file dall'host alla VM). È più veloce perché non è necessario riscrivere le modifiche.

• Questa opzione rsync è autosync (per sincronizzarlo continuamente).

• Questa opzione rsync consuma un sacco di CPU e la gente si avvicinò con una gemma di superarla (https://github.com/smerrill/vagrant-gatling-rsync)

Quindi, Vagrant + VirtualBox + Rsync cartella condivisa + rsync auto + gatling vagabondo sembra una buona opzione per il mio caso (ancora ricercando).

Ho provato gatling vagabondo. Tuttavia, risulta in un comportamento non deterministico. Non so mai se i nuovi file sono stati copiati in VM o meno. Non sarebbe un problema se ci vorrebbe 1 secondo. Tuttavia, ci vogliono 20 secondi, il che è troppo (un utente può cambiare finestra e avviare la compilazione quando i nuovi file non sono ancora sincronizzati).

Ora, sto pensando a un modo per copiare SOLO i file che sono cambiati. Sono ancora in fase di ricerca. L'idea sarebbe di usare FSEvent per ascoltare le modifiche ai file e inviare solo i file modificati. Sembra che ci siano alcuni strumenti attorno a cui farlo.

BTW. Gatling internamente usando FSEvent. L'unico problema che si innesca pieno rsync (che va e iniziare il confronto di data/orari e le dimensioni per i file 40k)

Answer 5

due passaggi possono migliorare le prestazioni abbastanza bene:

1. Passa a NFS. È possibile use this script to do this.

2. Imposta il tuo driver VBox NIC su FAST III. È possibile farlo sul tuo default macchina eseguendo:

VBoxManage modifyvm default --nictype1 Am79C973 VBoxManage modifyvm default --nictype2 Am79C973