7 Things to Hate about Docker Compose on OSX

7) Failures go unannounced

If your docker-compose.yml lists more than one VM and one of them exits in error, `docker-compose up` will just keep on going.

Apparently something went wrong with ‘authapi’ like ten minutes ago. Before I ran failing integration tests.

6) Hacky Environment Variables

Every time you start a new shell and want to access one of your running containers, you have to `eval $(docker-machine env)` to even begin.

“Run this command…” — You’re kidding, right?

5) Erroneous Errors

The machine was already running — but I hadn’t yet run `eval $(docker-machine env default)`

Error messages are often wrong and less than helpful. (See the above image).

4) Lack of Metadata or Environmental Reflection

You cannot find the address of a running container from within that container. As in, say you have a website running inside a container, and you want to send a fully-qualified URL as part of its response to a client. Too bad.

It’s like looking in the mirror. Except the mirror is black. And doesn’t show me anything.

Sorry, it’s just not going to happen.

3) Lack of Abstraction

Running docker-compose involves running your container instances on a Docker server which runs inside another VM, which itself runs inside VirtualBox. Communication with that Docker server happens over a unix socket on your Mac, through the VirtualBox VM, then into the individual containers themselves.

To get anything done requires you to traverse `docker`, `docker-machine`, `docker-compose` and combine their various outputs — even something as simple as addressing a specific container on a particular port.

2) Ports and IP Addresses

Given this docker-compose.yml:

Thirty-two lines of fail.

Say you want to access the RabbitMQ admin dashboard (on the ‘infra’ container) from your OSX host. You have to run two separate commands, then munge their output together:

Encapsulation? What’s that?

Now, I may not have released software that multi-billion-dollar enterprises run on, but I know a pain in the ass when I see one. How about `docker-compose` just returns `192.168.99.100:32814` and we call it good. Yeah?

1) Shared Volumes

Every. Single. Piece. of Documentation. about running docker-compose on OSX says this should work:

volumes:
  - ./:/var/www/my-project

Yes, technically, it does work, unless:

• You have “too many” files. Like, say, a simple rails app with less than 100 lines of code.
• You actually want to read — and write — those files. Ever.
• ???

Soon you’ll hear the familiar sound of your CPU’s fan blowing hot air while you wonder why a ‘ps -ef’ or ‘ls -la’ is taking sixty seconds to return.

There have been several discussions about how to tackle this. “Use NFS mounts” say some. “Mount /Users” say others. “Use `rsync`” say others still.

No, sorry, but unidirectional non-deleting rsync is not the answer. One of two things needs to happen, and needs to happen ALREADY.

1. Oracle can fix VirtualBox Shared Folders, which Hashicorp et al constantly assign blame for the awful performance.
2. Hashicorp can find a workaround and make it the default configuration.

Until then we may be stuck with wonky “solutions” like “Roll Your Own boot2docker” or not developing in Docker at all, as some have suggested.

Having used Vagrant as my development environment for dozens of projects of the last few years, it’s a shame to see it get sidelined by Hashicorp while it’s new offering, docker-machine/docker-compose/or-whatever-they-call-it-this-week is still not fully-baked.

Dear Hashicorp: fix your stuff, or someone else will.