[ekidd]

At Faraday, we're also been running Docker in production for over a year, and we're very happy with how well things have been working.

As nzoschke recommends, we rely heavily on ECS, RDS and other managed services. We are very careful about using exotic new Docker features until somebody else has successfully used them in production. We use DNS, load balancers and regular networking for discovering containers and communicating between them.

And it all basically just works. The worst problem we've encountered is that twice a year, we deploy a new version of ecs-agent to our staging cluster and need to revert it because of issues.

For us, the biggest challenge has been setting up a good local workflow for developing Docker apps with multiple services and multiple underlying git repositories. The docker-compose tool is great but it doesn't go far enough and doesn't provide enough structure. We've open sourced some our internal Docker dev tools here http://blog.faraday.io/announcing-cage-develop-and-deploy-co... but we think there's a lot more which could happen to make it easy to develop complicated apps.

[dkastner]

As another Faraday employee, I'll add that we didn't start right away with deployment. Instead, we used docker to provide a consistent way to test our apps. Once all of our apps were properly dockerized to run tests, we were able to move to deploying the app with a simple docker-machine + docker-compose setup. After that, it was a relatively easy move to ECS. docker-compose can probably handle 80% of your development needs, but the tool we wrote allowed us to quickly switch our apps from a canonical "image mode" to "source mode" while developing. It also provided a way to run acceptance tests locally with our entire app cluster running locally. A little more info: https://dkastner.github.io/2015/07/25/accidental-continuous-...

[slobotron]

About a year we opted for azk.io as an alternative to docker-compose.