9 ms·

Nice one. However, VirtualBox's shared-folder support is so god-awfully slow, that here at work we all swapped out the regular boot2docker setup for boot2docker

by girvo 11y ago

Nice one. However, VirtualBox's shared-folder support is so god-awfully slow, that here at work we all swapped out the regular boot2docker setup for boot2docker-xhyve[0] which is so much faster at nearly everything that it's not even a comparison. Now, with ailispaw's dockeroot-xhyve you can even get a VM root image that can be grown on the fly, so you never run out of space on your VM when building large Docker images. In addition, I'd never recommend Docker Compose to web developers that rely on databases, as quirks with it have caused many a volume-only container to be destroyed and rebuilt, thus defeating the purpose. [0] https://github.com/ailispaw/boot2docker-xhyve https://github.com/ailispaw/boot2docker-xhyve

domrdy 11y ago
Interesting, thanks for sharing! I agree that the shared folder situation is catastrophic. Doing anything significant with the mounted folders, like doing builds or simply watching for changes is unbearably slow. What I generally do is have a 'rsync' container and attach its volume (--volumes-from) to all containers that depend on the folders. Then, I watch on local file changes and rsync to the container. Builds etc. are all done within containers and this seems to work great!
elvis635 11y ago
Docker under OSX is a real pain to solve ASAP. I've set Docker on my Linux machine and it's working like a charm. Then I had to do the same for my coworkers running OSX, the vbox shared folders are definitely unusable. Now it's been few days that I'm trying to find the best way to have a two-way sync in order to sync back changes from docker to the OSX folder (eg. when you upload a file and it's saved in the /public folder, otherwise it'll be lost) So far I've used docker-osx-dev[0] for 1 way sync (with rsync) and it's working nicely.. they also plan to add the support to unison for a 2way sync I've also found docker-unison[1] but I haven't found a way to have it working correctly I'd like to try with boot2docker-xhyve, but it only runs on Yosemite and later [0] https://github.com/brikis98/docker-osx-dev https://github.com/brikis98/docker-osx-dev [1] https://github.com/leighmcculloch/docker-unison https://github.com/leighmcculloch/docker-unison
- bradgessler 11y ago
  There's https://github.com/codekitchen/dinghy https://github.com/codekitchen/dinghy if you want to mount the Mac host volumes inside boot2docker via NFS. We have a Vagrantfile that does this, but dinghy packages it all up nicely. At the end of the day though, Docker as a development environment is really bad on OS X until a VM vendor fixes file share performance. I really wish Docker would make it a priority to have decent Mac support.
  - huslage 11y ago
    VMware Fusion has fine performance on shared folders. I use it all the time with docker-machine.
- aceccanti 11y ago
  I use docker for development on Mavericks using vagrant + coreos as the host VM and things works nicely [0]. NFS shared folders performance is fine and the configuration is trivial. [0] https://github.com/coreos/coreos-vagrant https://github.com/coreos/coreos-vagrant
- Rapzid 11y ago
  Shared folder performance has been a known issue for as long as I can remember, with the recommended solution being to use NFS.. Is this not possible on OSX?
- scprodigy 11y ago
  Try Hyper on Mac: https://hyper.sh/blog/post/2015/07/30/running-containers-from-mac-os-x.html https://hyper.sh/blog/post/2015/07/30/running-containers-fro...
rcarmo 11y ago
Let me chime in and say that getting rid of VirtualBox and moving to xhyve would be amazing. I was really sad when this PR was closed: https://github.com/docker/machine/pull/1358#issuecomment-126818180 https://github.com/docker/machine/pull/1358#issuecomment-126...
- shykes 11y ago
  It will happen :) Xhyve is pretty new (and only works on pretty recent OSX installs), but we are also feeling the pain of the default vbox install and really want to fix it.
  - rcarmo 11y ago
    That's great news, Solomon - thanks :)
alcidesfonseca 11y ago
Has anyone tried VMWare fusion to run a Docker host VM? Virtualbox shared folders are unusable for my purpose (compiling software on Linux).
- bradgessler 11y ago
  Yes, and I think its much worse in terms of reliability. When I save a file (say a Gemfile), sometimes only half of it shows up inside the container. Anybody know what would cause VMWare Fusion (or any VM for that matter) to behave this way?
  - babs474 11y ago
    I run into this. Files are only partially synced. You end up with broken code. If you are lucky it has a syntax error. If you are not lucky you get mysterious bugs. The work around is to go back and try re-editing the file to retrigger a sync. There are lots recommendations to try Fusion over Vbox but I think this issue makes it a wash.
    - frapposelli 11y ago
      This is a known bug, we're addressing it with a new version of open-vm-tools, there's a thread going on over at github[1] to track this. [1] https://github.com/docker/machine/issues/1460 https://github.com/docker/machine/issues/1460
- frostmatthew 11y ago
  > Has anyone tried VMWare fusion to run a Docker host VM? If you're considering Fusion I'd suggest taking a look at AppCatalyst[1] instead (N.B. I work at VMware, but not on AppCatalyst). [1] http://blogs.vmware.com/cloudnative/vmware-appcatalyst/ http://blogs.vmware.com/cloudnative/vmware-appcatalyst/
  - sharksandwich 11y ago
    looks great, but doesn't have a docker-machine driver yet https://github.com/docker/machine/pull/1401 https://github.com/docker/machine/pull/1401
kolev 11y ago
It will be available in docker-machine v0.5.0 as a plugin.
selestify 11y ago
What should I use in place of docker compose?
- fearenales 11y ago
  I strongly recommend you to use azk [0]. It's an alternative to docker compose but instead of being a container manager, it provides the whole environment orchestration. When compared to docker compose, azk has several advantages, such as: - Its manifest file is more verbose and has a greater toolset [1]; - You can persist content from inside the container way better than simply mounting volumes using docker compose [2]; - Fow now, it relies on VirtualBox (usign debian2docker) but it has a built-in function [3] to sync folders into the container using rsync (significantly increasing performance for file sharing). You can still use VirtualBox Shared Folders if you want to; - Its built-in DNS server makes you don't worry about port mapping and docker IP issues. You can access your local app running with azk by simply accessing a custom address, like: my-app.dev.azk.io. [0] http://azk.io http://azk.io [1] http://docs.azk.io/en/azkfilejs/README.html http://docs.azk.io/en/azkfilejs/README.html [2] http://docs.azk.io/en/reference/azkfilejs/mounts.html#persistent http://docs.azk.io/en/reference/azkfilejs/mounts.html#persis... [3] http://docs.azk.io/en/reference/azkfilejs/mounts.html#sync http://docs.azk.io/en/reference/azkfilejs/mounts.html#sync
nickstinemates 11y ago
> In addition, I'd never recommend Docker Compose to web developers that rely on databases, as quirks with it have caused many a volume-only container to be destroyed and rebuilt, thus defeating the purpose. Can you point me in the direction of a bug report or a more concrete example? I'd like to make sure we follow up.
- girvo 11y ago
  Some of it is insurmountable without having some way of marking a container in the docker-compose.yml as "never destroy this!". It's a UX thing more than a bug, although there was two cases where "docker-compose up" destroyed and rebuilt a volume-only container that was in the docker-compose.yml -- unfortunately it was difficult to replicate so we didn't send a bug report through. The big thing is that using it on OSX with boot2docker means the cache can get confused, and so to get it to pick up config file changes (say, changes to an nginx config that are brought into the container) or some Dockerfile changes requires a "docker-compose rm && docker-compose build --no-cache", which of course will delete the volume-only container unless you're aware enough of the need to name the container you want to rebuild; as I said, it's more a UX issue than a bug, in my opinion. In terms of fixes, ideally I'd like to see a way of marking a container as "volume-only" -- this would then mean a "docker-compose rm" would not remove it, and "docker-compose up" would never rebuild it.

by girvo 11y ago

domrdy 11y ago

Interesting, thanks for sharing! I agree that the shared folder situation is catastrophic. Doing anything significant with the mounted folders, like doing builds or simply watching for changes is unbearably slow. What I generally do is have a 'rsync' container and attach its volume (--volumes-from) to all containers that depend on the folders. Then, I watch on local file changes and rsync to the container. Builds etc. are all done within containers and this seems to work great!

elvis635 11y ago

Docker under OSX is a real pain to solve ASAP. I've set Docker on my Linux machine and it's working like a charm. Then I had to do the same for my coworkers running OSX, the vbox shared folders are definitely unusable. Now it's been few days that I'm trying to find the best way to have a two-way sync in order to sync back changes from docker to the OSX folder (eg. when you upload a file and it's saved in the /public folder, otherwise it'll be lost) So far I've used docker-osx-dev[0] for 1 way sync (with rsync) and it's working nicely.. they also plan to add the support to unison for a 2way sync I've also found docker-unison[1] but I haven't found a way to have it working correctly I'd like to try with boot2docker-xhyve, but it only runs on Yosemite and later [0] https://github.com/brikis98/docker-osx-dev https://github.com/brikis98/docker-osx-dev [1] https://github.com/leighmcculloch/docker-unison https://github.com/leighmcculloch/docker-unison

bradgessler 11y ago
There's https://github.com/codekitchen/dinghy https://github.com/codekitchen/dinghy if you want to mount the Mac host volumes inside boot2docker via NFS. We have a Vagrantfile that does this, but dinghy packages it all up nicely. At the end of the day though, Docker as a development environment is really bad on OS X until a VM vendor fixes file share performance. I really wish Docker would make it a priority to have decent Mac support.
- huslage 11y ago
  VMware Fusion has fine performance on shared folders. I use it all the time with docker-machine.
aceccanti 11y ago
I use docker for development on Mavericks using vagrant + coreos as the host VM and things works nicely [0]. NFS shared folders performance is fine and the configuration is trivial. [0] https://github.com/coreos/coreos-vagrant https://github.com/coreos/coreos-vagrant
Rapzid 11y ago
Shared folder performance has been a known issue for as long as I can remember, with the recommended solution being to use NFS.. Is this not possible on OSX?
scprodigy 11y ago
Try Hyper on Mac: https://hyper.sh/blog/post/2015/07/30/running-containers-from-mac-os-x.html https://hyper.sh/blog/post/2015/07/30/running-containers-fro...

rcarmo 11y ago

Let me chime in and say that getting rid of VirtualBox and moving to xhyve would be amazing. I was really sad when this PR was closed: https://github.com/docker/machine/pull/1358#issuecomment-126818180 https://github.com/docker/machine/pull/1358#issuecomment-126...

shykes 11y ago
It will happen :) Xhyve is pretty new (and only works on pretty recent OSX installs), but we are also feeling the pain of the default vbox install and really want to fix it.
- rcarmo 11y ago
  That's great news, Solomon - thanks :)

alcidesfonseca 11y ago

Has anyone tried VMWare fusion to run a Docker host VM? Virtualbox shared folders are unusable for my purpose (compiling software on Linux).

bradgessler 11y ago
Yes, and I think its much worse in terms of reliability. When I save a file (say a Gemfile), sometimes only half of it shows up inside the container. Anybody know what would cause VMWare Fusion (or any VM for that matter) to behave this way?
- babs474 11y ago
  I run into this. Files are only partially synced. You end up with broken code. If you are lucky it has a syntax error. If you are not lucky you get mysterious bugs. The work around is to go back and try re-editing the file to retrigger a sync. There are lots recommendations to try Fusion over Vbox but I think this issue makes it a wash.
  - frapposelli 11y ago
    This is a known bug, we're addressing it with a new version of open-vm-tools, there's a thread going on over at github[1] to track this. [1] https://github.com/docker/machine/issues/1460 https://github.com/docker/machine/issues/1460
frostmatthew 11y ago
> Has anyone tried VMWare fusion to run a Docker host VM? If you're considering Fusion I'd suggest taking a look at AppCatalyst[1] instead (N.B. I work at VMware, but not on AppCatalyst). [1] http://blogs.vmware.com/cloudnative/vmware-appcatalyst/ http://blogs.vmware.com/cloudnative/vmware-appcatalyst/
- sharksandwich 11y ago
  looks great, but doesn't have a docker-machine driver yet https://github.com/docker/machine/pull/1401 https://github.com/docker/machine/pull/1401

kolev 11y ago

It will be available in docker-machine v0.5.0 as a plugin.

selestify 11y ago

What should I use in place of docker compose?

fearenales 11y ago
I strongly recommend you to use azk [0]. It's an alternative to docker compose but instead of being a container manager, it provides the whole environment orchestration. When compared to docker compose, azk has several advantages, such as: - Its manifest file is more verbose and has a greater toolset [1]; - You can persist content from inside the container way better than simply mounting volumes using docker compose [2]; - Fow now, it relies on VirtualBox (usign debian2docker) but it has a built-in function [3] to sync folders into the container using rsync (significantly increasing performance for file sharing). You can still use VirtualBox Shared Folders if you want to; - Its built-in DNS server makes you don't worry about port mapping and docker IP issues. You can access your local app running with azk by simply accessing a custom address, like: my-app.dev.azk.io. [0] http://azk.io http://azk.io [1] http://docs.azk.io/en/azkfilejs/README.html http://docs.azk.io/en/azkfilejs/README.html [2] http://docs.azk.io/en/reference/azkfilejs/mounts.html#persistent http://docs.azk.io/en/reference/azkfilejs/mounts.html#persis... [3] http://docs.azk.io/en/reference/azkfilejs/mounts.html#sync http://docs.azk.io/en/reference/azkfilejs/mounts.html#sync

nickstinemates 11y ago

> In addition, I'd never recommend Docker Compose to web developers that rely on databases, as quirks with it have caused many a volume-only container to be destroyed and rebuilt, thus defeating the purpose. Can you point me in the direction of a bug report or a more concrete example? I'd like to make sure we follow up.

girvo 11y ago
Some of it is insurmountable without having some way of marking a container in the docker-compose.yml as "never destroy this!". It's a UX thing more than a bug, although there was two cases where "docker-compose up" destroyed and rebuilt a volume-only container that was in the docker-compose.yml -- unfortunately it was difficult to replicate so we didn't send a bug report through. The big thing is that using it on OSX with boot2docker means the cache can get confused, and so to get it to pick up config file changes (say, changes to an nginx config that are brought into the container) or some Dockerfile changes requires a "docker-compose rm && docker-compose build --no-cache", which of course will delete the volume-only container unless you're aware enough of the need to name the container you want to rebuild; as I said, it's more a UX issue than a bug, in my opinion. In terms of fixes, ideally I'd like to see a way of marking a container as "volume-only" -- this would then mean a "docker-compose rm" would not remove it, and "docker-compose up" would never rebuild it.