Repository navigation
evaluate "Docker for Mac" as a Dinghy replacement #166
Description
Activity
Looks like that's already been clarified, Docker for Mac will be free and open source.
Agreed. This looks to be very exciting. I'm waiting for my invite :-)
Me too!
I've been testing the beta today. The way it maps permissions for mounted volumes is different, and a little weird. It seems to map all bind mounted volumes to whatever UID:GID you are currently running as inside the container. So when you
gosu foo, the owner and group of all your bind mounted volumes will change fromroottofoo.In theory, this sounds like it should resolve the existing issue where you have to create/modify a user inside the container to match the UID:GID of the bind mounted volumes (which can't be changed). But I was previously working around that by doing
gosu "$(stat -c '%u' "${DIR}"):$(stat -c '%g' "${DIR}")"which no longer works as expected.So at the very least, this different behaviour has broken parity with images that work under regular Docker Engine.
Here's what their docs say. Sounds like this feature might be short-lived:
Presently, all requesting processes are treated as owners and group members on all bind mounted file system resources. This behavior simultaneously solves uid/gid mapping headaches and creates new compatibility (and possibly security) issues. A finer-grained ownership model is in development.
I tested out the beta for a bit yesterday, but ran into I/O errors when trying to
bundle installonto a host-mounted volume. I haven't had a chance to dig further yet. Interestingly they're almost exactly the samegit cloneI/O errors I got when trying to run the unfsd NFS daemon as a non-root user. git seems to be especially sensitive to filesystem bugs.Unfortunately the Docker for Mac beta is significantly slower than dinghy for my workflow. I use the vmware driver -- between the osxfs driver burning significant CPU and the overhead of xhyve, a build which normally takes a little over 4 minutes ends up taking over 20 minutes.
I currently use vagrant for most of my development environment management, but jumped on the docker for mac beta in hopes it would simplify my workflow. And it does! However, the performance is bad enough that it's unusable for me. I have no doubt that xhyve performance will improve over time... eventually, it may be a good alternative. Dinghy to the rescue! :)
Yeah, I believe them when they say the FS performance will improve over time, they should be able to beat NFS performance using their architecture, with some work.
I've been playing with Docker for Mac the past few days. What I'm missing is the DNS functionality that Dinghy provides. I'm hoping that they include a custom DNS but looking at this thread it doesn't look like it...anytime soon anyways. Is there anyway to break out the DNS part of Dinghy into its own component that can be reused by Dinghy and standalone by Docker for Mac users?
Yep, the HTTP proxy and DNS server have been split into a separate project, install instructions are at https://github.com/codekitchen/dinghy-http-proxy#os-x
@codekitchen That's great. Thank you. I will give it a spin....I still find Docker for Mac unstable so I'll stick to Dinghy for the time being. 🍰
osxfs still can't compete with nfs or even the vbox guest additions. It's so slow. IMO, Docker for Mac is not a complete replacement yet.
Hey @codekitchen,
Sorry for a silly question. Is it possible to run dinghy with docker-beta?Thx!
@igorvpcleao From what I understand, the only thing you'd want from Dinghy would be its proxy & DNS which are available here https://github.com/codekitchen/dinghy-http-proxy. One major aspect of Docker for mac is to make osxfs performant and stable. So the NFS and fsevents from Dinghy should not really be needed in Docker for mac.
So if/once https://forums.docker.com/t/custom-dns-for-resolving-containers/8361 gets fixed/merged then I think that Dinghy might be up for deprecation all together.
But until Docker for mac is stable (which it wasn't when I tried it last month) I'm sticking to Dinghy. Now I just received e-mail from Docker that Docker for mac/windows is RC. Might be worth testing it out again.
Reacted by Brian Palmer and Igor LeãoThanks @michaellopez!
Good to hear that. I don't know why, but I'm still experiencing problems with shared folders. Solving this DNS issue will make the transference among host and container faster? It's currently taking a long time to render my rails pages when I use shared folders.
Yeah that's a great summary, thanks @michaellopez
One twist is that we've got devs using Linux laptops and running Docker directly on the host, and it's nice that the Dinghy HTTP proxy works the same way for them. So we may continue on using it anyway, even if Docker for Mac introduces its own solution there.
27 remaining items
@codekitchen unless I'm missing something, there's still only one docker host (VM) with Dinghy, so you can still only ever bind one container to a given port at a time. With Docker for Mac you just also have to avoid conflict with non-container services that are also running on localhost? With Dinghy, I think it's still not possible to say run two containers that both expose port 80 to the host? Or is the Dinghy proxy doing something clever like forwarding port 80 to whatever internally exposed port the containers are running (like dockercloud-haproxy does)? If the container is exposing multiple ports, how does the proxy know which one to proxy?
Yes, it proxies HTTP requests to the other running containers based on hostname, without them having to map a port to the host. See the docs https://github.com/codekitchen/dinghy-http-proxy
Just as a quick update, we still aren't seeing acceptable volume share performance in Docker for Mac. Some people at my company who only work on small projects have been using it daily without issue, but it's still too slow to use on our larger ruby and nodejs codebases.
Reacted by Yannick GouezSo the long and the short of it is, if you're comfortable with Dinghy, stick with dinghy because it is faster for large codebases? It'd probably be good to add some notes about this on the main Readme - I just got very confused when I visited the docker website and everything had changed...
Reacted by George LifchitsThat's a good call, I'll add something to the README
I am evaluating http://docker-sync.io/ for increasing performance when using large codebases.
It definitely needs some work so if anyone wants to give it a try and contribute anything they can, that would be great!
I've been recommending developers move away from Docker for Mac to Dinghy as the former seems to be awfully buggy at the moment and is exponentially slower with non-trivial projects using volume sharing. Some encouragement from me to keep working on this project -- it is valuable.
Reacted by Alexander Kachkaev, Robert Wünsch, Alex Chesters, jarrett jordaan, Cees van Egmond and David ChangReacted by Michael Zetterberg, Daniel Staudigel, André Eriksson, Mathew Davies, Matt Gardner, Robert Wünsch, Alex Chesters, Cees van Egmond and David Chang@debovis You can help keep it up to date. Try out Docker for Mac and report back with your findings. The more data we have the better! 👍
I swapped back to Docker For Mac about a month ago, and swapped back to dinghy about a week ago. dinghy is still exponentially faster than Docker For Mac.
I changed to docker for mac with http://docker-sync.io/
and this tweak applied
docker/for-mac#668
is really fastcan confirm what @rodrigoaguilera said, using the fix docker/for-mac#668 with d4m gives a huge boost in our setup, its enormous for bigger installations / apps, maybe it does scale over linear. Still have to stick with docker-sync though for the host-mounts / shares, those are still very slow
Reacted by davyrolink and Gaston MorixeHi everyone,
I've just used this article after a clean upgrade (OSX 10.13) to install docker for mac.
Personally, I use delegated on volume (more infos) and it seems pretty fast at the moment. For example, before this update, my Laravel application was really slow (it took more than 5 seconds to load a page) but now, it's done in less than 1 second.
Also, I just wanted to say a huge thank you to @codekitchen for this awesome project that helped me a lot to get started on docker!
PS: compared to the article, you don't need the edge version anymore.
Using the
delegatedflag does sound promising, I'll have to try that out. Thanks for the tip @robinparisiHello :) here a speed Test between dinghy and docker4mac.
Native:
docker run --rm -it -w /pwd alpine time dd if=/dev/zero of=speedtest bs=1024 count=100000 100000+0 records in 100000+0 records out real 0m 0.23s user 0m 0.03s sys 0m 0.20sDinghy (Dinghy 4.6.5 with xhyve):
docker run --rm -it -v "$(PWD):/pwd" -w /pwd alpine time dd if=/dev/zero of=speedtest bs=1024 count=100000 100000+0 records in 100000+0 records out real 0m 0.66s user 0m 0.02s sys 0m 0.21sDinghy (Dinghy 4.6.5 with virtualbox):
100000+0 records in 100000+0 records out real 0m 1.34s user 0m 0.06s sys 0m 0.36sdocker4mac cached (Version 18.06.0-ce-mac69 (26398)):
docker run --rm -it -v "$(PWD):/pwd:cached" -w /pwd alpine time dd if=/dev/zero of=speedtest bs=1024 count=100000 100000+0 records in 100000+0 records out real 0m 17.51s user 0m 0.31s sys 0m 1.73sdocker4mac delegated (Version 18.06.0-ce-mac69 (26398)):
docker run --rm -it -v "$(PWD):/pwd:delegated" -w /pwd alpine time dd if=/dev/zero of=speedtest bs=1024 count=100000 100000+0 records in 100000+0 records out real 0m 19.36s user 0m 0.19s sys 0m 2.12sReacted by Mathieu Darse, Pierre Tondereau, Artem Grechka, Daniel Staudigel, Kieran Pilkington, redundantautomata, Derek Myers, Kirill Kolchin and Marc SiegelReacted by Daniel Staudigel, Artem Grechka, Kirill Kolchin and Marc Siegel
You have to agree to an NDA to get into the private beta, but I've gleaned plenty of information from public sources:
https://blog.docker.com/2016/03/docker-for-mac-windows-beta/
https://news.ycombinator.com/item?id=11352594
I've been saying for 18 months that Docker should solve the OS X dev problem themselves, so I'm a big fan of this. From what I've read so far it seems pretty close to Dinghy in terms of features.
remaps MacOS X UIDs into Linux ones (no more permissions problems), which could mean a couple different things. Hopefully it is aimed at editing code on a mounted volume.<containername>.docker.localthat'd be ok.Overall it sounds really nice. The proof will be once we can actually try it out, but if it works as well as they claim I'll probably just deprecate Dinghy once Docker for Mac is publicly released. That's assuming Docker for Mac is a free product, I'd hope it would be but they haven't said, and it sounds like at least parts of it will not be open source.