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.
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
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!
> 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.
This looks cool, although for the Windows install I'd have hoped that there would be an option to integrate Hyper-V with it instead of Virtualbox, seeing as Hyper-V is available on all Windows 8.1/10 pro/enterprise systems, and having multiple virtualization platforms active on a system is generally a bad idea...
Hi all. We know the experience of using Docker on OSX is not perfect today. The default virtualbox configuration for file sharing is slow and buggy. You need to use 3 different CLIs (`docker`, `docker-machine`, `docker-compose`) which are not well integrated. 3d-party clients need to reimplement everything themselves. The standard clients are not configurable or customizable enough.
We plan on solving all of this. There is a new team at Docker focused entirely on solving "Developer Experience" problems. This initial release of Toolbox is a starting point: a convenience packaging of existing tools. But we are going to update it with more and more improvements.
In short: we are going to work hard to make the experience of using Docker to develop on Mac OS X (and Windows) much, much better.
I really, really, don't understand the docker fixation, but maybe I'm missing something.
The most important function of docker, IMHO, is that it standardizes the creation of a VM using Virtualbox across platforms.
Unless Amazon AWS, DigitalOcean, GoogleCompute, etc. allow a docker image (aka a VirtualBox image) to run directly on their base virtualization platform (without me putting together an AMI or whatever on their platform), this just adds another layer of virtualization that I can do without. Do they do this already?
If and when they do that, docker would be tremendously useful because I wouldn't need to rebuild my image for that particular platform (AWS/DO/GC).
And if they do that already, then why aren't they just accepting existing popular VM images (VMWare/VirtualBox)?
The most important function of Docker is dependency management (allowing you to pack your own runtime with your apps with consummate ease), followed by standardising image distribution and deployment across environments.
A Docker image is not a VM image - it doesn't have a kernel, for starters, and is not designed to be booted in the usual sense (i.e., kernel+init+scripts) - it just has a Linux userland (often quite restricted) and will run _a single process_ by design[1].
Also, AWS and Google Cloud already allow you to run Docker images (on EC2 Container Service and Kubernetes).
Cloud providers won't accept existing VM images in the sense that large-scale hypervisor platforms usually use different formats and they don't need the hassle involved in building and supporting VM conversion services.
It's pointless to have those as a service when anyone can grab Packer or a similar tool and convert a .vbox/.vmdk to an AWS AMI or an Azure Hyper-V image - and support the resulting images themselves (which is another reason why providers make a clear distinction between certified/tested images and third-party ones).
[1]: of course you can launch supervisord and a bunch of stuff underneath it, but if you're doing that, you're doing it wrong.
Related to what you say about "don't VM's solve this problem?" is a project called https://hyper.sh. They're coming at it from the angle that if VM's can boot really fast, containers are a moot point.
AWS supports deploying Docker images on both Elastic Beanstalk and their new Elastic Container Service. While it doesn't completely remove the need to worry about VMs, it does abstract them away somewhat (ECS much more so).
It's true. Docker Just Works™ on GNU/Linux. I'm a Linux guy myself for anything in development. However, unless I'm mistaken, part of the goal of Docker is to provide identical environments to an engineering team and production.
I always advocate for Linux use (in addition to principles, most things are easier as well), but everyone has their preferred environment.
You can stand up Joyent's Triton[1] service locally for development with Docker. The hardware is very affordable, and I think that they have a very underrated product on their hands.
I appreciate the Toolbox suite as I use most of them. But I am concerned though not surprised how this make the "batteries included but removable" motto more insignificant as it becomes more unlikely that people will use alternatives.
I use Vagrant+Docker for development, no problems to install. First, I tried to use boot2docker but I didn't like it. Vagrant has a Docker provisioner or there's a plugin for Vagrant for Docker Compose.
If you look at the contents of the .app, you can edit main.scpt in AppleScript Editor, but it's really just doing two things, creating the VM if necessary:
The docker team completely ignored the great work the parallels team put into creating a parallels driver instead telling them to wait for the plugin architecture to be finished.
[+] [-] girvo|10 years ago|reply
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
[+] [-] elvis635|10 years ago|reply
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
[1] https://github.com/leighmcculloch/docker-unison
[+] [-] rcarmo|10 years ago|reply
https://github.com/docker/machine/pull/1358#issuecomment-126...
[+] [-] domrdy|10 years ago|reply
[+] [-] alcidesfonseca|10 years ago|reply
Virtualbox shared folders are unusable for my purpose (compiling software on Linux).
[+] [-] nickstinemates|10 years ago|reply
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.
[+] [-] kolev|10 years ago|reply
[+] [-] selestify|10 years ago|reply
[+] [-] nzoschke|10 years ago|reply
I bought a new MacBook 2 days ago, and setting it up has never been easier.
Almost all of my development takes place in a Docker environment now, and the Docker ToolBox makes installing that a breeze.
Less XCode, Homebrew, rubygems, npm. More Docker.
[+] [-] raesene4|10 years ago|reply
[+] [-] mattchamb|10 years ago|reply
[+] [-] shykes|10 years ago|reply
We plan on solving all of this. There is a new team at Docker focused entirely on solving "Developer Experience" problems. This initial release of Toolbox is a starting point: a convenience packaging of existing tools. But we are going to update it with more and more improvements.
In short: we are going to work hard to make the experience of using Docker to develop on Mac OS X (and Windows) much, much better.
[+] [-] nogox|10 years ago|reply
It is great to hear you guys are working on that. I find Hyper is pretty interesting to run Docker on Mac https://hyper.sh/blog/post/2015/07/30/running-containers-fro....
[+] [-] msravi|10 years ago|reply
The most important function of docker, IMHO, is that it standardizes the creation of a VM using Virtualbox across platforms.
Unless Amazon AWS, DigitalOcean, GoogleCompute, etc. allow a docker image (aka a VirtualBox image) to run directly on their base virtualization platform (without me putting together an AMI or whatever on their platform), this just adds another layer of virtualization that I can do without. Do they do this already?
If and when they do that, docker would be tremendously useful because I wouldn't need to rebuild my image for that particular platform (AWS/DO/GC).
And if they do that already, then why aren't they just accepting existing popular VM images (VMWare/VirtualBox)?
[+] [-] rcarmo|10 years ago|reply
The most important function of Docker is dependency management (allowing you to pack your own runtime with your apps with consummate ease), followed by standardising image distribution and deployment across environments.
A Docker image is not a VM image - it doesn't have a kernel, for starters, and is not designed to be booted in the usual sense (i.e., kernel+init+scripts) - it just has a Linux userland (often quite restricted) and will run _a single process_ by design[1].
Also, AWS and Google Cloud already allow you to run Docker images (on EC2 Container Service and Kubernetes).
Cloud providers won't accept existing VM images in the sense that large-scale hypervisor platforms usually use different formats and they don't need the hassle involved in building and supporting VM conversion services.
It's pointless to have those as a service when anyone can grab Packer or a similar tool and convert a .vbox/.vmdk to an AWS AMI or an Azure Hyper-V image - and support the resulting images themselves (which is another reason why providers make a clear distinction between certified/tested images and third-party ones).
[1]: of course you can launch supervisord and a bunch of stuff underneath it, but if you're doing that, you're doing it wrong.
[+] [-] bradgessler|10 years ago|reply
For more sophisticated scheduling needs there is http://www.replicated.com/, https://cloud.google.com/container-engine/, and https://aws.amazon.com/ecs/
Related to what you say about "don't VM's solve this problem?" is a project called https://hyper.sh. They're coming at it from the angle that if VM's can boot really fast, containers are a moot point.
[+] [-] jon-wood|10 years ago|reply
[+] [-] saynay|10 years ago|reply
[+] [-] tkubacki|10 years ago|reply
[+] [-] davexunit|10 years ago|reply
[+] [-] codelitt|10 years ago|reply
I always advocate for Linux use (in addition to principles, most things are easier as well), but everyone has their preferred environment.
[+] [-] npx|10 years ago|reply
[1] https://www.joyent.com/blog/spin-up-a-docker-dev-test-enviro...
[+] [-] 9point6|10 years ago|reply
[+] [-] shaan7|10 years ago|reply
[+] [-] flurdy|10 years ago|reply
[+] [-] starikovs|10 years ago|reply
[+] [-] honest_joe|10 years ago|reply
[deleted]
[+] [-] macmac|10 years ago|reply
[+] [-] SloopJon|10 years ago|reply
docker-machine create -d virtualbox --virtualbox-memory 2048 default
and populating environment variables for docker:
eval $(docker-machine env default)
Passing --shell zsh to docker-machine env doesn't seem to change its output. Does zsh understand commands like the following?
export DOCKER_MACHINE_NAME="default"
[+] [-] scrubby|10 years ago|reply
[+] [-] FlyingSnake|10 years ago|reply
[+] [-] vincentriemer|10 years ago|reply
Reference: https://github.com/docker/machine/pull/939
[+] [-] reustle|10 years ago|reply
https://www.google.com/trends/explore#q=parallels%20mac
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] anentropic|10 years ago|reply