Hacker News Reader

Comment by maque_onlyverse | Hacker News Reader

well, when I see someone playing `sed` on yml file - I'm out. If you are looking for simpler approach, why just not run docker with passing env, or mount volume with those information which image need?

View on HN

Agreed. That's a great point when it is a simple use case, and how I started. Now that I build for Docker Compose out of the gate, it allows me to deploy a composition across a multi-host Docker Swarm (usually just changing the network driver to overlay + utilize labels) with 1 command, and more importantly I do not have to rebuild my container on production. Back in docker 1.9, I found myself running too many variations to get the same behavior that Compose natively handles with the new labels + overlay functionality (reference http://blog.levvel.io/blog-post/running-distributed-docker-s...). I was using `docker run` to deploy across specific hosts using manually-assigned env vars invoked with a docker run:

# docker run -itd --name=AppDeployedToNode1 --env="constraint:node==swarm1.internallevvel.com" busybox

# docker run -itd --name=AppDeployedToNode2 --env="constraint:node==swarm2.internallevvel.com" busybox

# docker run -itd --name=AppDeployedToNode3 --env="constraint:node==swarm3.internallevvel.com" busybox

RabbitMQ Example - https://gist.github.com/jay-johnson/2673ce4df42317667908#fil...

Looking back I feel like it was a lot of effort to deploy 3 busybox instances or that initial RabbitMQ cluster…and that effort to handle the “production deployment case” as early as possible is what set me on the path to the new Docker Compose-centric approach discussed in the link above.

Reply on news.ycombinator.com