Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Simplifying Docker on OS X

blog.andyet.com

Post reply on HN
Print view View original

41–50 of 89 posts

Re: Simplifying Docker on OS X

#41

Post by rocky1138 »

lotyrin wrote: post #34
rocky1138 wrote: post #29

Earlier quoted context omitted.

From my understanding, the limitation is from OSX and not from Docker, as OSX does not have native support for kernel namespacing. This is why Docker on OSX runs inside of a Linux virtual machine.

Making OSX Linux is hard, but making Docker smarter about running on OSX is easy (have docker-machine provide a socket like this project does, have docker client detect the environment and connect to the correct virtual machine's docker socket) and would be an obvious huge step forward.

Yeah, sure, I agree, there's a lot of room for improvement. But, I still talk to a lot of developers who are new to Docker and use OSX, who are confused as to why they need to run a VM or enter docker commands into a different terminal than they are used to.

Re: Simplifying Docker on OS X

#42

Post by spike021 »

shlant wrote: post #11

From someone who has wasted many hours trying to get B2D working, I have ended up using https://github.com/codekitchen/dinghy Easier to use, more reliable and some nice features like the OPs .docker DNS and NFS shares. The maintainer is very responsive and I recommend it to anyone who is struggling with docker on OSX.

I don't have much use for Docker on my personal OSX computer, but whenever I've tried to get things running smoothly on there for pet projects, B2D was such a pain and either wouldn't work at all, or would be pretty awful to get set up properly.

Re: Simplifying Docker on OS X

#44

Post by jeromenerf »

pchm wrote: post #32

Nice work joeyespo, it's definitely a much-needed step forward. NFS, though, is a huge pain point for me on OSX performance-wise. The only reliable solution I've found so far is Unison sync between Mac & Vagrant (Ubuntu). That also comes with some caveats, as Unison has to be compiled with exactly the same version & dependencies on both OSX and Ubuntu. If anyone's interested, I've created a list of steps involved in…

FS sync, may it be for the code, the assets, the data, the logs, is painfully slow on osx, because of vboxsf poor performance.

If you intend to use docker containers on osx as an isolated runtime, with all your "data" sync'd in realtime between your host and your container, then use linux.

Fswatch / Rsync / unison over NFS, ssh or cifs are hacks of a greater order than having to source an env script.

Out of curiosity, why would you need directional sync/unison?

Re: Simplifying Docker on OS X

#46

Post by lbrindze »

for me, using docker on my own workstation (OSX) makes it easy for me to test deploy's to multiple machines quickly (even if these are only locally hosted VMs). docker-machine facilitates that by allowing you to quickly spin up and spin down virtual machines locally or in the cloud.

I can see advantages for running docker as a way of streamlining dev environments, and keeping them consistent across team members, but by automagicaly awaying the docker-machine env commands you have effectively lost the most powerful facet of container technology.

Perhaps we would all do better if Docker's toolset docs were written in a way to communicate these design decisions (their purpose, and how they conceptually work behind the scenes)...

Re: Simplifying Docker on OS X

#47

Post by tlrobinson »

lbrindze wrote: post #46

for me, using docker on my own workstation (OSX) makes it easy for me to test deploy's to multiple machines quickly (even if these are only locally hosted VMs). docker-machine facilitates that by allowing you to quickly spin up and spin down virtual machines locally or in the cloud. I can see advantages for running docker as a way of streamlining dev environments, and keeping them consistent across team members, but…

If I understand, using this doesn't preclude you from using docker-machine, it just gives you a default Docker installation, similar to what you'd get if you installed the Docker daemon on your Linux workstation.

It might be neat if this were integrated into docker-machine though. Looks like there's already a docker-machine plugin for xhyve (https://github.com/zchee/docker-machine-driver-xhyve).

Re: Simplifying Docker on OS X

#48

Post by tlrobinson »

beat wrote: post #33
knicholes wrote: post #28

Earlier quoted context omitted.

If I "just used Vagrant," I think I'd end up with a virtualbox VM, just like if I were to have used docker-machine.

Vagrant is more repeatable, though. It's straightforward to provision an environment. In my (limited) experience with direct Virtualbox, you wind up manually building a lot of stuff.

docker-machine automates setting up a VM running Docker. There's nothing manual about it (besides running "docker-machine create dev" or whatever)

Re: Simplifying Docker on OS X

#49

Post by derefr »

sneak wrote: post #39
derefr wrote: post #24

Earlier quoted context omitted.

If you're going to go through the trouble of having two computers anyway, why not make the second one a home Linux server? Point the docker client's socket at that machine, instead of at a VM. One of the benefits of doing this, I find, is that all the power-hungry stuff happens on the server, so I can have a really lightweight development machine (e.g. one of the 2015 Macbooks.)

...or just get one in a colo for $40/month.

Depends on your internet speed. Pushing docker images over a LAN is about the same speed as writing them to disk. Pushing them to a remote server somewhere can introduce noticable latency in your workflow.

Re: Simplifying Docker on OS X

#50

Post by jjn2009 »

kevan wrote: post #40

I feel like this isn't much simpler than the official docker-machine workflow, but I may be too far in the weeds at this point to objectively tell how complicated it is. In my case I need to test tools across 4 versions of Docker so I'm locked into using docker-machine and dvm.

The lack of /var/run/docker.sock is annoying but its really not that big of a deal in my opinion either. docker-machine covers a lot of other use cases such as multi-host docker swarms and docker in the cloud. Adding this tool to the toolbox is extra mental overhead for a small benefit if you have any need for these more advanced use cases.
Post reply on HN