10 ms·

Simplifying Docker on OS X

259 points by joeyespo 11y ago

corybrown 11y ago
Pretty cool trick to make the OS X docker hacks feel transparent. I've been tempted into getting a Linux laptop just because using Docker on OS X feels so hacky.
- derefr 11y ago
  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.)
  - sneak 11y ago
    ...or just get one in a colo for $40/month.
    - derefr 11y ago
      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.
      - ewindisch 11y ago
        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.
        comex 11y ago
        Not bad. Personally, I can't stand the hit to latency that doing work over SSH or screen sharing introduces, unless the ping time is very low... and your average cloud server has way less CPU power and RAM than a good laptop too, though I suppose you can avoid that by selecting a more expensive server to do work on. There are certainly huge advantages to the remote method for those that can pull it off.
- mr337 11y ago
  I did and never looked back. Lenovo X1 Carbon Gen 3
  - Diederich 11y ago
    Been using Linux on my work macbooks since 2009. There are some bumps involved, but it works really well on the awesome Apple hardware.
    - corybrown 11y ago
      How's the battery life?
      - rocky1138 11y ago
        I use a Macbook Pro (2014) with Kubuntu Linux installed full-time. The battery life is about half of what it is when running OSX. If you forget your charger, there is serious range anxiety. Luckily, I've been running PC laptops for years and have gotten completely used to bringing my charger any time I take my laptop.
      - Diederich 11y ago
        I estimate that I get better than half of the battery life. Years ago, when I started doing it, the battery life of Linux on Macbook was really terrible. I only need a couple of hours of battery life for my mac at most, so that's fine for me at least.
      - fernandotakai 11y ago
        I get ~3/4s of the battery life that i have on osx if i do not run anything on flash. if flash starts, i get less than half. (using archlinux on a mid-2012 mbp)
    - jalada 11y ago
      I dual-booted Mint on my 2011 MBA the other week and it was a nasty experience. I feel like Linux users have low standards, or maybe I've been away too long. Here's four things I found immediately: 1. The fans don't automatically react to temperature without a background daemon (?!). 2. Multi-touch trackpad support is terrible. The default synaptic driver can't handle you resting your thumb on the bottom of the trackpad. The alternative driver doesn't support momentum scrolling (and is still a bit shit). At least palm detection has been solved; well done Linux, it only took you 10 years. 3. It cannot seem to handle using left Alt as a third-level activator (e.g. for # key on EU keyboards) at the same time as actually letting you /use/ your Alt key (e.g. for activating menus). I think I eventually solved this, but how hard should it be?! 4. As others have mentioned; battery life. I was impressed that sleep, audio, wifi and display brightness all worked out of the box though. Progress, eh?
- sbd01 11y ago
  Would it not just be easier to dual boot Linux? If you've got a big enough hard drive it works very nicely.
- beat 11y ago
  Just use Vagrant! Start a Vagrant VM on your Mac and do the Docker stuff inside it.
  - knicholes 11y ago
    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.
    - beat 11y ago
      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.
      - tlrobinson 11y ago
        docker-machine automates setting up a VM running Docker. There's nothing manual about it (besides running "docker-machine create dev" or whatever)
        beat 11y ago
        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.
        knicholes 11y ago
        It's unfortunate you had such a bad experience with Docker. No doubt there's a steep learning curve to use more advanced features. If you're still willing to look in to it, I'd recommend taking at look at https://docs.docker.com/engine/userguide/dockervolumes/ https://docs.docker.com/engine/userguide/dockervolumes/ under "Mount a host directory as a data volume."
- legulere 11y ago
  Linux works quite well on Macbooks. No need to buy more hardware.
  - fishnchips 11y ago
    It works great indeed. My main pain point though is that if you want to dual-boot then every update of OS X will destroy your Linux workspace.
sciurus 11y ago
The interesting links are https://github.com/nlf/dhyve https://github.com/nlf/dhyve https://github.com/nlf/dhyve-os https://github.com/nlf/dhyve-os
sneak 11y ago
Docker does run natively on OSX. Just forward a port with ssh/socat/etc and set the environment variable correctly to point to your build host that can run lxc. There is so much over-engineering going on in this arena. :/
- e40 11y ago
  There is no definition of "native" where your statement is true.
  - sneak 11y ago
    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.
    - sagichmal 11y ago
      Docker hasn't used lxc for a long time. And the Docker daemon doesn't compile on OS X.
    - cyphar 11y ago
      Docker doesn't and hasn't used LXC for a long time. It uses libcontainer, which is their own implementation of a container runtime. Even when Docker did use LXC, the Docker daemon was required for management. The Docker daemon only runs on GNU/Linux and Windows, so there is no sane definition of "native" where the statement "Docker runs natively on OS X" is correct.
  - tracker1 11y ago
    I think the meaning is the docker tools/client runs on OSX, so one could just run a remote host or VM with docker installed and use the default tools for running/connecting against the remote host... Personally, I wish more of it worked as transparently as what Joyent provides for their server implementation.
tniswong 11y ago
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
- mentat 11y ago
  Thanks for this, I'd been typing way too much for too long. However, dc overlaps with the dc program so I've moved to dkm and dkc (since I actually use dc from time to time.)
- bm1362 11y ago
  Mine are similar: dssh() { docker exec -ti $1 /bin/bash } dexec() { img="$1" shift docker exec $img /bin/sh -c "$@" }
- jzelinskie 11y ago
  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/b2d33f8c601d1b7d9cce1df3319561e182251a26/zshrc#L12-L30 https://github.com/jzelinskie/dotfiles/blob/b2d33f8c601d1b7d...
ialex 11y ago
Add this to your bash profile and it will feel simpler function docker_activate() { eval $(docker-machine env $1) } alias docker_activate=docker_activate Then: docker-machine start mymachine docker_activate mymachine
josteink 11y ago
> However, there's one big challenge with adopting Docker for our developers: it doesn't natively work on OS X. Then don't use OSX. Problem solved.
BinaryIdiot 11y ago
Thank you! I'll have to check this out. It baffles me that a company such as Docker has yet to make using its primary product on Mac OS X simple plug and play. Needing to remember to run `eval $(docker-machine env docker)` is not a sustainable solution. Hell I know about this and would occasionally forget and become confused at the error messages. In fact I put this horrible hack into my ~/.bash_profile (I wouldn't recommend doing this but, hey, it works.): docker-machine start dev eval "$(docker-machine env dev)"
- bentruyman 11y ago
  One thing I do to avoid this is to write out the Docker environment to a file in my home directory. Then I source that file, if it exists, for each new terminal session. Not perfect, but you can see it here: https://github.com/bentruyman/dotfiles/blob/392914f92e5a8d8d9fc20cc967aadc1a3971e99b/env/docker.sh https://github.com/bentruyman/dotfiles/blob/392914f92e5a8d8d... But DLite appears to resolve a lot of this 'hackiness'.
- rocky1138 11y ago
  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.
  - lotyrin 11y ago
    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.
    - rocky1138 11y ago
      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.
shlant 11y ago
From someone who has wasted many hours trying to get B2D working, I have ended up using https://github.com/codekitchen/dinghy 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.
- spike021 11y ago
  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.
- STRML 11y ago
  After seeing this article, I just migrated from Dinghy to Dlite. I saved about 5GB of disk space, got much faster VM startup time and basically no hassle. It was a cinch to work my docker-compose startup into a LaunchAgent and now I finally have all my services running on boot. I highly recommend giving it a shot; my eyes nearly popped when I saw how quickly it downloaded and started the VM (must have been all of a 10MB download).
  - Pym 11y ago
    As a Dinghy user too, thank you! I will give a shot at Dlite right now :)
- adamsea 11y ago
  Out of curiousity, did you try docker-machine (the docker toolbox)? I have found that to be fairly straightforward, though I had not used B2D previously.
  - yeukhon 11y ago
    To be clear on adamsea's point, docker-machine is now the replacement for B2D and is also officially supported.
beat 11y ago
I used to struggle with this. Then I set up a Vagrantfile and put my docker code in a Vagrant instance. It's just far and away better than any other hack I've tried. File mount point transparency problems? Solved!
nzoschke 11y ago
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 state is uninstall, reboot and reinstall. Annoying but passable b I have also experimented with xhyve and it looks extremely promising but does need some new tools to make it a turnkey docker dev environment. From my survey of this technique and the tools we need more time, energy and cooperation to get there. Thank you and everyone else for your efforts!
- toomuchtodo 11y ago
  > 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.
pchm 11y ago
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 making it work on El Capitan: https://gist.github.com/pch/aa1c9c4ec8522a11193b https://gist.github.com/pch/aa1c9c4ec8522a11193b
- jeromenerf 11y ago
  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?
- joeyespo 11y ago
  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 https://github.com/nlf).
evacchi 11y ago
Unfortunately it seems that Xhyve cannot connect to the Internet when traffic is routed through OpenVPN. Otherwise I would use it at my job. I tried https://github.com/coreos/coreos-xhyve https://github.com/coreos/coreos-xhyve, https://github.com/ailispaw/docker-root-xhyve https://github.com/ailispaw/docker-root-xhyve and Veertu, and they all won't work. Apparently is a known issue https://github.com/mist64/xhyve/issues/84 https://github.com/mist64/xhyve/issues/84 ; it might have to do with Hypervisor.framework
- colordrops 11y ago
  Same goes for Cisco AnyConnect VPN. Updating the routing table seems to temporarily fix it, but it would be nice not to hack around it to get it to work.
  - evacchi 11y ago
    > Updating the routing table seems to temporarily fix it, can you share a link ? thanks
    - colordrops 11y ago
      It's been a while, but I believe the fix is in this thread: https://github.com/boot2docker/boot2docker/issues/628 https://github.com/boot2docker/boot2docker/issues/628
kevan 11y ago
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.
- jjn2009 11y ago
  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.
  - adamsea 11y ago
    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
    - jjn2009 11y ago
      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.
      - manojlds 11y ago
        But that mount is vboxfs and is slow. You need to do some extra work to get NFS going.
  - deleted 11y ago
    [deleted]
vittore 11y ago
Question, is there a homebrew package for DLite?
- leipert 11y ago
  Hopefully soon: https://github.com/Homebrew/homebrew/pull/48460 https://github.com/Homebrew/homebrew/pull/48460
Diamons 11y ago
I created a very similar post not too long ago: http://shahruk.com/code/snippets/2016/01/18/Definitive-Guide-To-Making-Docker-Wordpress-Work-Mac-OSX.html http://shahruk.com/code/snippets/2016/01/18/Definitive-Guide...
heurist 11y ago
`eval $(docker-machine env docker)` is great, I can stick it in scripts and separate my development environment from testing, staging, and production for every project I need to track. It works on Windows, OS X, and Linux so all my developers can use whatever OS they want and I still have one platform-agnostic environment setup script that gets people up and running in less than 15 minutes. The only problem with docker-machine is you can't share environments without copying over the entire machine configuration, which is somewhat baffling in the case of EC2 machines but is by no means a deal-breaker.
ossreality 11y ago
So, now your OS X scripts are basically non-portable, (worse really). All to save exporting a variable? And now I'm ALWAYS running a Linux VM no matter why I logged into my Mac? Solution in search of a problem.
abhv 11y ago
So I imagine the solution is using xhyve to run a simple linux. Why is the xhyve virtualization framework through low-level go-bindings better than using VirtualBox for the same task?
- biehl 11y ago
  It is more light-weight?
  - therealmarv 11y ago
    Yes. VirtualBox is emulating a whole PC including controllers for all internal stuff like CPU, graphics, HDD etc. Where as xhyve is more like an interface which can be used by VMs to access the native hardware indirectly.
- stock_toaster 11y ago
  > Why is the xhyve virtualization framework through low-level > go-bindings better than using VirtualBox for the same task? Presumably, because xhyve uses the native os virtualization framework, and as such does not require custom third party kernel modules. It also apparently works a bit better with the native os scheduler.
tunesmith 11y ago
My main problem with using Docker on OS X is that I have multiple OS X user accounts - one for myself, one for my main client. And I ran into a bunch of trouble trying to run boot2docker and dockermachine on both of them, it just wouldn't work. Unfortunately I forget the details since I haven't had need to use docker since then.
omni 11y ago
There's a lot of neat work going on in this space because Docker support on OS X is pretty lackluster out of the box. My team and I built Dusty[1] to try to solve many of the same problems, though we seem to be operating at a bit of a higher level than this tool. I'm excited to try out xhyve for virtualization, but even if you solve the virtualization problem there are still some real usability concerns around using Docker for development in even medium-sized teams. I gave a talk at PyGotham[2] about some of the benefits and issues of using Docker for dev at this point. All told, this looks like it might be an attractive lightweight solution though if virtualization is your main problem now. [1] http://dusty.gc.com/ http://dusty.gc.com/ [2] https://www.youtube.com/watch?v=pYLOuuR7HI0 https://www.youtube.com/watch?v=pYLOuuR7HI0
lbrindze 11y ago
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)...
- tlrobinson 11y ago
  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 https://github.com/zchee/docker-machine-driver-xhyve).
therealmarv 11y ago
I also really hatte the official Docker way in OS X. It's even hard to uninstall! If anybody is interested how to uninstall official Docker for OSX: https://therealmarv.com/how-to-fully-uninstall-the-offical-docker-os-x-installation/ https://therealmarv.com/how-to-fully-uninstall-the-offical-d... Running Docker in a Vagrant VM is or was the best way. Speaking of Vagrant... does anybody know if there is a xyhve Vagrant project?
brown9-2 11y ago
Is there a technical reason why docker-machine on OS X doesn't set up /var/run/docker.sock in a similar way? It sounds so simple when put this way in the article.
Laaw 11y ago
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.
arsalanb 11y ago
Docker is one of the tools that was concocted (by brilliant people!) after I began programming professionally. From my understanding, Docker allows you to containerize your applications so they function properly anywhere you (so to say) "place those containers". Now, does if I'm working with say Django or Flask, and things behave differently on an AWS server than they do on your local machine, for example — relative paths for file uploads work on localhost, but mess up on AWS. Also file permissions are irritating to work with on AWS, but never an issue on localhost (on a Mac). In such a scenario, is Docker for these issues? I imagine I use Docker, make a "container" and setup everything properly in that, and then just move it to AWS when I'm deploying?
- mateuszf 11y ago
  You can also use Docker on AWS. Just use it as a target "runtime" for all your environments.
  - arsalanb 11y ago
    So that would mean telling Docker to setup a container to model the configuration on AWS on all my environments, correct?
pikzel 11y ago
I actually just use aliases, it feels like this DLite/dhyve is more of a hack.
outcoldman 11y ago
Honestly, for me it looks like a wasting time. If you want to have simplicity - install Docker Toolbox, which will help you with getting access to docker with all environment variables. If do not need simplicity - you probably want to handle multiple docker hosts, including VM, Linux machines, Cloud instances - this is why you want to have an option to switch between docker environments using `eval $(...)`. Also you can use something like https://github.com/Tarrasch/zsh-autoenv https://github.com/Tarrasch/zsh-autoenv to automatically call this command in specific folders. And if you really need docker-lite- you do not need to write it in go, just do Run that once (do sudo or any other crazy stuff): ``` echo $(docker-machine ip dev) local.docker >> /etc/hosts ``` Add that to `.bashrc` ``` eval $(docker-machine eval dev) ```
CommanderNyx 11y ago
Hey, this is pretty sweet. This is a simple alternative than the solution I wrote about here: https://allysonjulian.com/setting-up-docker-with-xhyve/ https://allysonjulian.com/setting-up-docker-with-xhyve/ which uses docker-machine-driver-xhyve (https://github.com/zchee/docker-machine-driver-xhyve https://github.com/zchee/docker-machine-driver-xhyve). I've been trying to figure out how to deal with the env variables used by docker, and used a workaround ~/.profile (https://gist.github.com/astrohckr/efceb07887225cbc2ba2 https://gist.github.com/astrohckr/efceb07887225cbc2ba2). Like the OP, running eval in every terminal session makes me a bit concerned as well. I'll give dlite a Go.

259 points by joeyespo 11y ago

Pretty cool trick to make the OS X docker hacks feel transparent. I've been tempted into getting a Linux laptop just because using Docker on OS X feels so hacky.

derefr 11y ago
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.)
- sneak 11y ago
  ...or just get one in a colo for $40/month.
  - derefr 11y ago
    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.
    - ewindisch 11y ago
      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.
      - comex 11y ago
        Not bad. Personally, I can't stand the hit to latency that doing work over SSH or screen sharing introduces, unless the ping time is very low... and your average cloud server has way less CPU power and RAM than a good laptop too, though I suppose you can avoid that by selecting a more expensive server to do work on. There are certainly huge advantages to the remote method for those that can pull it off.
mr337 11y ago
I did and never looked back. Lenovo X1 Carbon Gen 3
- Diederich 11y ago
  Been using Linux on my work macbooks since 2009. There are some bumps involved, but it works really well on the awesome Apple hardware.
  - corybrown 11y ago
    How's the battery life?
    - rocky1138 11y ago
      I use a Macbook Pro (2014) with Kubuntu Linux installed full-time. The battery life is about half of what it is when running OSX. If you forget your charger, there is serious range anxiety. Luckily, I've been running PC laptops for years and have gotten completely used to bringing my charger any time I take my laptop.
    - Diederich 11y ago
      I estimate that I get better than half of the battery life. Years ago, when I started doing it, the battery life of Linux on Macbook was really terrible. I only need a couple of hours of battery life for my mac at most, so that's fine for me at least.
    - fernandotakai 11y ago
      I get ~3/4s of the battery life that i have on osx if i do not run anything on flash. if flash starts, i get less than half. (using archlinux on a mid-2012 mbp)
  - jalada 11y ago
    I dual-booted Mint on my 2011 MBA the other week and it was a nasty experience. I feel like Linux users have low standards, or maybe I've been away too long. Here's four things I found immediately: 1. The fans don't automatically react to temperature without a background daemon (?!). 2. Multi-touch trackpad support is terrible. The default synaptic driver can't handle you resting your thumb on the bottom of the trackpad. The alternative driver doesn't support momentum scrolling (and is still a bit shit). At least palm detection has been solved; well done Linux, it only took you 10 years. 3. It cannot seem to handle using left Alt as a third-level activator (e.g. for # key on EU keyboards) at the same time as actually letting you /use/ your Alt key (e.g. for activating menus). I think I eventually solved this, but how hard should it be?! 4. As others have mentioned; battery life. I was impressed that sleep, audio, wifi and display brightness all worked out of the box though. Progress, eh?
sbd01 11y ago
Would it not just be easier to dual boot Linux? If you've got a big enough hard drive it works very nicely.
beat 11y ago
Just use Vagrant! Start a Vagrant VM on your Mac and do the Docker stuff inside it.
- knicholes 11y ago
  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.
  - beat 11y ago
    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.
    - tlrobinson 11y ago
      docker-machine automates setting up a VM running Docker. There's nothing manual about it (besides running "docker-machine create dev" or whatever)
      - beat 11y ago
        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.
        knicholes 11y ago
        It's unfortunate you had such a bad experience with Docker. No doubt there's a steep learning curve to use more advanced features. If you're still willing to look in to it, I'd recommend taking at look at https://docs.docker.com/engine/userguide/dockervolumes/ https://docs.docker.com/engine/userguide/dockervolumes/ under "Mount a host directory as a data volume."
legulere 11y ago
Linux works quite well on Macbooks. No need to buy more hardware.
- fishnchips 11y ago
  It works great indeed. My main pain point though is that if you want to dual-boot then every update of OS X will destroy your Linux workspace.

sciurus 11y ago

The interesting links are https://github.com/nlf/dhyve https://github.com/nlf/dhyve https://github.com/nlf/dhyve-os https://github.com/nlf/dhyve-os

sneak 11y ago

Docker does run natively on OSX. Just forward a port with ssh/socat/etc and set the environment variable correctly to point to your build host that can run lxc. There is so much over-engineering going on in this arena. :/

e40 11y ago
There is no definition of "native" where your statement is true.
- sneak 11y ago
  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.
  - sagichmal 11y ago
    Docker hasn't used lxc for a long time. And the Docker daemon doesn't compile on OS X.
  - cyphar 11y ago
    Docker doesn't and hasn't used LXC for a long time. It uses libcontainer, which is their own implementation of a container runtime. Even when Docker did use LXC, the Docker daemon was required for management. The Docker daemon only runs on GNU/Linux and Windows, so there is no sane definition of "native" where the statement "Docker runs natively on OS X" is correct.
- tracker1 11y ago
  I think the meaning is the docker tools/client runs on OSX, so one could just run a remote host or VM with docker installed and use the default tools for running/connecting against the remote host... Personally, I wish more of it worked as transparently as what Joyent provides for their server implementation.

tniswong 11y ago

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

mentat 11y ago
Thanks for this, I'd been typing way too much for too long. However, dc overlaps with the dc program so I've moved to dkm and dkc (since I actually use dc from time to time.)
bm1362 11y ago
Mine are similar: dssh() { docker exec -ti $1 /bin/bash } dexec() { img="$1" shift docker exec $img /bin/sh -c "$@" }
jzelinskie 11y ago
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/b2d33f8c601d1b7d9cce1df3319561e182251a26/zshrc#L12-L30 https://github.com/jzelinskie/dotfiles/blob/b2d33f8c601d1b7d...

ialex 11y ago

Add this to your bash profile and it will feel simpler function docker_activate() { eval $(docker-machine env $1) } alias docker_activate=docker_activate Then: docker-machine start mymachine docker_activate mymachine

josteink 11y ago

> However, there's one big challenge with adopting Docker for our developers: it doesn't natively work on OS X. Then don't use OSX. Problem solved.

BinaryIdiot 11y ago

Thank you! I'll have to check this out. It baffles me that a company such as Docker has yet to make using its primary product on Mac OS X simple plug and play. Needing to remember to run `eval $(docker-machine env docker)` is not a sustainable solution. Hell I know about this and would occasionally forget and become confused at the error messages. In fact I put this horrible hack into my ~/.bash_profile (I wouldn't recommend doing this but, hey, it works.): docker-machine start dev eval "$(docker-machine env dev)"

bentruyman 11y ago
One thing I do to avoid this is to write out the Docker environment to a file in my home directory. Then I source that file, if it exists, for each new terminal session. Not perfect, but you can see it here: https://github.com/bentruyman/dotfiles/blob/392914f92e5a8d8d9fc20cc967aadc1a3971e99b/env/docker.sh https://github.com/bentruyman/dotfiles/blob/392914f92e5a8d8d... But DLite appears to resolve a lot of this 'hackiness'.
rocky1138 11y ago
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.
- lotyrin 11y ago
  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.
  - rocky1138 11y ago
    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.

shlant 11y ago

From someone who has wasted many hours trying to get B2D working, I have ended up using https://github.com/codekitchen/dinghy 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.

spike021 11y ago
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.
STRML 11y ago
After seeing this article, I just migrated from Dinghy to Dlite. I saved about 5GB of disk space, got much faster VM startup time and basically no hassle. It was a cinch to work my docker-compose startup into a LaunchAgent and now I finally have all my services running on boot. I highly recommend giving it a shot; my eyes nearly popped when I saw how quickly it downloaded and started the VM (must have been all of a 10MB download).
- Pym 11y ago
  As a Dinghy user too, thank you! I will give a shot at Dlite right now :)
adamsea 11y ago
Out of curiousity, did you try docker-machine (the docker toolbox)? I have found that to be fairly straightforward, though I had not used B2D previously.
- yeukhon 11y ago
  To be clear on adamsea's point, docker-machine is now the replacement for B2D and is also officially supported.

beat 11y ago

I used to struggle with this. Then I set up a Vagrantfile and put my docker code in a Vagrant instance. It's just far and away better than any other hack I've tried. File mount point transparency problems? Solved!

nzoschke 11y ago

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 state is uninstall, reboot and reinstall. Annoying but passable b I have also experimented with xhyve and it looks extremely promising but does need some new tools to make it a turnkey docker dev environment. From my survey of this technique and the tools we need more time, energy and cooperation to get there. Thank you and everyone else for your efforts!

toomuchtodo 11y ago
> 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.

pchm 11y ago

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 making it work on El Capitan: https://gist.github.com/pch/aa1c9c4ec8522a11193b https://gist.github.com/pch/aa1c9c4ec8522a11193b

jeromenerf 11y ago
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?
joeyespo 11y ago
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 https://github.com/nlf).

evacchi 11y ago

Unfortunately it seems that Xhyve cannot connect to the Internet when traffic is routed through OpenVPN. Otherwise I would use it at my job. I tried https://github.com/coreos/coreos-xhyve https://github.com/coreos/coreos-xhyve, https://github.com/ailispaw/docker-root-xhyve https://github.com/ailispaw/docker-root-xhyve and Veertu, and they all won't work. Apparently is a known issue https://github.com/mist64/xhyve/issues/84 https://github.com/mist64/xhyve/issues/84 ; it might have to do with Hypervisor.framework

colordrops 11y ago
Same goes for Cisco AnyConnect VPN. Updating the routing table seems to temporarily fix it, but it would be nice not to hack around it to get it to work.
- evacchi 11y ago
  > Updating the routing table seems to temporarily fix it, can you share a link ? thanks
  - colordrops 11y ago
    It's been a while, but I believe the fix is in this thread: https://github.com/boot2docker/boot2docker/issues/628 https://github.com/boot2docker/boot2docker/issues/628

kevan 11y ago

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.

jjn2009 11y ago
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.
- adamsea 11y ago
  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
  - jjn2009 11y ago
    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.
    - manojlds 11y ago
      But that mount is vboxfs and is slow. You need to do some extra work to get NFS going.
- deleted 11y ago
  [deleted]

vittore 11y ago

Question, is there a homebrew package for DLite?

leipert 11y ago
Hopefully soon: https://github.com/Homebrew/homebrew/pull/48460 https://github.com/Homebrew/homebrew/pull/48460

Diamons 11y ago

I created a very similar post not too long ago: http://shahruk.com/code/snippets/2016/01/18/Definitive-Guide-To-Making-Docker-Wordpress-Work-Mac-OSX.html http://shahruk.com/code/snippets/2016/01/18/Definitive-Guide...

heurist 11y ago

`eval $(docker-machine env docker)` is great, I can stick it in scripts and separate my development environment from testing, staging, and production for every project I need to track. It works on Windows, OS X, and Linux so all my developers can use whatever OS they want and I still have one platform-agnostic environment setup script that gets people up and running in less than 15 minutes. The only problem with docker-machine is you can't share environments without copying over the entire machine configuration, which is somewhat baffling in the case of EC2 machines but is by no means a deal-breaker.

ossreality 11y ago

So, now your OS X scripts are basically non-portable, (worse really). All to save exporting a variable? And now I'm ALWAYS running a Linux VM no matter why I logged into my Mac? Solution in search of a problem.

abhv 11y ago

So I imagine the solution is using xhyve to run a simple linux. Why is the xhyve virtualization framework through low-level go-bindings better than using VirtualBox for the same task?

biehl 11y ago
It is more light-weight?
- therealmarv 11y ago
  Yes. VirtualBox is emulating a whole PC including controllers for all internal stuff like CPU, graphics, HDD etc. Where as xhyve is more like an interface which can be used by VMs to access the native hardware indirectly.
stock_toaster 11y ago
> Why is the xhyve virtualization framework through low-level > go-bindings better than using VirtualBox for the same task? Presumably, because xhyve uses the native os virtualization framework, and as such does not require custom third party kernel modules. It also apparently works a bit better with the native os scheduler.

tunesmith 11y ago

My main problem with using Docker on OS X is that I have multiple OS X user accounts - one for myself, one for my main client. And I ran into a bunch of trouble trying to run boot2docker and dockermachine on both of them, it just wouldn't work. Unfortunately I forget the details since I haven't had need to use docker since then.

omni 11y ago

There's a lot of neat work going on in this space because Docker support on OS X is pretty lackluster out of the box. My team and I built Dusty[1] to try to solve many of the same problems, though we seem to be operating at a bit of a higher level than this tool. I'm excited to try out xhyve for virtualization, but even if you solve the virtualization problem there are still some real usability concerns around using Docker for development in even medium-sized teams. I gave a talk at PyGotham[2] about some of the benefits and issues of using Docker for dev at this point. All told, this looks like it might be an attractive lightweight solution though if virtualization is your main problem now. [1] http://dusty.gc.com/ http://dusty.gc.com/ [2] https://www.youtube.com/watch?v=pYLOuuR7HI0 https://www.youtube.com/watch?v=pYLOuuR7HI0

lbrindze 11y ago

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

tlrobinson 11y ago
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 https://github.com/zchee/docker-machine-driver-xhyve).

therealmarv 11y ago

I also really hatte the official Docker way in OS X. It's even hard to uninstall! If anybody is interested how to uninstall official Docker for OSX: https://therealmarv.com/how-to-fully-uninstall-the-offical-docker-os-x-installation/ https://therealmarv.com/how-to-fully-uninstall-the-offical-d... Running Docker in a Vagrant VM is or was the best way. Speaking of Vagrant... does anybody know if there is a xyhve Vagrant project?

brown9-2 11y ago

Is there a technical reason why docker-machine on OS X doesn't set up /var/run/docker.sock in a similar way? It sounds so simple when put this way in the article.

Laaw 11y ago

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.

arsalanb 11y ago

Docker is one of the tools that was concocted (by brilliant people!) after I began programming professionally. From my understanding, Docker allows you to containerize your applications so they function properly anywhere you (so to say) "place those containers". Now, does if I'm working with say Django or Flask, and things behave differently on an AWS server than they do on your local machine, for example — relative paths for file uploads work on localhost, but mess up on AWS. Also file permissions are irritating to work with on AWS, but never an issue on localhost (on a Mac). In such a scenario, is Docker for these issues? I imagine I use Docker, make a "container" and setup everything properly in that, and then just move it to AWS when I'm deploying?

mateuszf 11y ago
You can also use Docker on AWS. Just use it as a target "runtime" for all your environments.
- arsalanb 11y ago
  So that would mean telling Docker to setup a container to model the configuration on AWS on all my environments, correct?

pikzel 11y ago

I actually just use aliases, it feels like this DLite/dhyve is more of a hack.

outcoldman 11y ago

Honestly, for me it looks like a wasting time. If you want to have simplicity - install Docker Toolbox, which will help you with getting access to docker with all environment variables. If do not need simplicity - you probably want to handle multiple docker hosts, including VM, Linux machines, Cloud instances - this is why you want to have an option to switch between docker environments using `eval $(...)`. Also you can use something like https://github.com/Tarrasch/zsh-autoenv https://github.com/Tarrasch/zsh-autoenv to automatically call this command in specific folders. And if you really need docker-lite- you do not need to write it in go, just do Run that once (do sudo or any other crazy stuff): ``` echo $(docker-machine ip dev) local.docker >> /etc/hosts ``` Add that to `.bashrc` ``` eval $(docker-machine eval dev) ```

CommanderNyx 11y ago

Hey, this is pretty sweet. This is a simple alternative than the solution I wrote about here: https://allysonjulian.com/setting-up-docker-with-xhyve/ https://allysonjulian.com/setting-up-docker-with-xhyve/ which uses docker-machine-driver-xhyve (https://github.com/zchee/docker-machine-driver-xhyve https://github.com/zchee/docker-machine-driver-xhyve). I've been trying to figure out how to deal with the env variables used by docker, and used a workaround ~/.profile (https://gist.github.com/astrohckr/efceb07887225cbc2ba2 https://gist.github.com/astrohckr/efceb07887225cbc2ba2). Like the OP, running eval in every terminal session makes me a bit concerned as well. I'll give dlite a Go.