Live data from Hacker News

Simplifying Docker on OS X

blog.andyet.com

61–70 of 89 posts

Re: Simplifying Docker on OS X

#61
post #50
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.

[deleted]

Re: Simplifying Docker on OS X

#62
post #37
post #16

Earlier quoted context omitted.

There is no definition of "native" where your statement is true.

Containers don't run on osx, but docker isn't responsible for the containers anyway - lxc is. The "docker" program builds and runs natively under osx just fine, like any other Go binary.

Docker hasn't used lxc for a long time. And the Docker daemon doesn't compile on OS X.

Re: Simplifying Docker on OS X

#63

This looks great and is now high on my todo list to test. I am all in on docker development because I am all in on using images and containers in production via ECS. Getting a laptop and AWS talking the same abstraction is the future. I too suffer from problems with Docker Machine and virtual box on OS X. Frequently I find myself debugging these subsystems. It's been ok because the worst case to get back to a good st…

> Getting a laptop and AWS talking the same abstraction is the future.

You can already do this with Vagrant and VirtualBox. Docker is just additional abstraction.

Re: Simplifying Docker on OS X

#65
post #5

I just use bash aliases in my .profile ---- alias dm="docker-machine" alias dc="docker-compose" alias denv='function __denv() { eval "$(dm env $@)"; unset -f __denv; }; __denv' ---- dm create --driver virtualbox local denv local Also works with swarm params: denv local --swarm swarm-master

The whole Quay team at CoreOS uses OSX to develop a container registry. As a result I have a bunch of useful aliases as well[0]. A lot of them have to do with just plain cleaning up after yourself, but I also wrap my calls to `docker` with a zsh function that will eval my dev docker-machine environment if it hasn't been already.

[0]: https://github.com/jzelinskie/dotfiles/blob/b2d33f8c601d1b7d...

Re: Simplifying Docker on OS X

#66
post #49
post #39

Earlier quoted context omitted.

...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.

It's easy, you just do everything on the remote machine(s). I've taken this to such an extreme that I've given up on the Macbook and moved to a far less expensive and more secure Chromebook.

Re: Simplifying Docker on OS X

#67
post #60
post #50

Earlier quoted context omitted.

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.

I also am not sure what major advantages this brings. And the article was slightly unclear in that you can add Docker environment variables to your `.bash_profile` -- you still are dealing with environment vars, but don't have to run the `eval` command all the time. And, I believe the docker-machine default VM settings mount your User (Users/myname) directory in it's virtual machine

yes you are correct, docker-machine mounts your current user's folder into the VM as well so thats not an advantage over docker-machine either.

Re: Simplifying Docker on OS X

#68
docker-machine is almost completely seamless to me. The only thing I have to do is start the VM, the eval is in my .profile.

This whole problem took me <5 mins to solve, and about 30s to solve each boot. I could quite easily start the VM on boot as well, but it's such a non problem for me that I don't even bother spending the 3 mins it'd take to set up.

Re: Simplifying Docker on OS X

#69
post #33

Earlier quoted context omitted.

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)

Docker-machine drove me up a wall. Getting file sharing to work so I could use my nice Mac editors on my in-docker code was a huge waste of time and effort. Docker-machine was just another one of those crappy half-measures that keep Mac owners struggling to find a way to make Docker graceful.

I was also motivated by bringing on new team members who were on Windows rather than Macs. Vagrant works fine and transparently on both Mac and Windows, with the same commands. It's not necessary for everyone, but I was pleased that my best Mac solution also works just as well on Windows.

Re: Simplifying Docker on OS X

#70
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…

Sorry for any confusion; this wasn't my work. I only shared it on HN. Nathan LaFreniere is the author of this post and project (https://github.com/nlf).
Post reply on HN