Docker-compose vs docker stack for local development

I’m using docker-compose for running local dev environment. I found out about docker stack functionality and now I’m not clear what should I use. I would prefer to have the build option enabled which is usual in docker-compose, but not supported for docker stack. What is the roadmap? Will the integration of docker-compose to docker continue or will the docker-compose preserve to exist?

Using docker stack forces us to use swarm mode. Is there any inconsiderable performance influence when using docker in swarm mode on just one node against plain docker?

2 Likes

For a not distributed environment, I’d use compose with one or multiple compose files. It’s geared towards local environments and you have as mentioned the build option. Should you need a distributed setting for deployment in future, you can still use the compose files with a few different options, since compose as well as stack ignore options that they don’t know. Stack does not accept multiple compose files, but you can merge the compose files via ‘docker-compose configuration’ and use the resulting file for stack.
Hope this answers your question.

What is the road map for this. Would they like to get rid of docker-compose any time soon? Or do they plan to support the build functionality in docker stack?

I’ve found a number of cases where docker-compose behaviour differs to that of stack; I’ve found that docker-compose has race conditions on creating networks and volumes which don’t exist when using stack.

I’ve pretty much moved to exclusively using docker stack now but will use docker-compose config to generate configs from multiple files / with overrides set.

Depends on the use case. It’s really a mess that probably won’t get cleaned up any time soon. More often than compose, I’ll use Ansible for single-host deployments and Ansible with stack for swarm-mode deployments when not using Kubernetes.

Compose and Swarm are totally 2 different things.
You typically use docker-compose for local development because it can build and works only on a single docker engine. Docker stack and docker service commands require a Docker Swarm cluster and geared towards production. No builds just pull images from container registry which are typically built from your CI. It also has different set of features like distribution, resource allocation, update policy, fault tolerance,…
Swarm is an orchestrator and is comparable to kubernetes (although much simpler) but definitely not to Compose.
Hope that helps.

Isn’t Ansible to much of an overhead for just local development deployments? I need to confess I know close to nothing about Ansible. But for me, at first glance, it looks like additional burden for developer. Anyway will check it out.

@hammady True. Stack and Compose are more aligned, but I short cut because compose doesn’t work with swarm and stack doesn’t work without it. So, semantics in my mind.

@wortner I don’t use local development deployments often, instead relying on CI to push to dev/stage environments. And, again, only use stack if I’m forced to use swarm-mode (because it’s just so limited). In this scenario, Ansible makes sense (at least for my use cases) since I assume that I’m deploying to a virgin environment and must make all necessary changes to support the workload that will be deployed. Although, recently, we’ve taken a trip down memory lane and are starting to use make/bash in many cases over Ansible.