There's Docker Swarm (now built into Docker) and Docker-Compose. People seem to use Docker-Compose when running containers on a single node only. However, Docker-Compose doesn't support any of the deploy
config values, see https://docs.docker.com/compose/compose-file/#deploy, which include mem_limit
and cpus
, which seems like nice/important to be able to set.
So therefore maybe I should use Docker Swarm? although I'm deploying on a single node only. Also, then the installation instructions will be simpler for other people to follow (they won't need to install Docker-Compose).
But maybe there are reasons why I should not use Swarm on a single node?
I'm posting an answer below, but I'm not sure if it's correct.
Edit: Please note that this is not an opinion based question. If you have a look at the answer below, you'll see that there are "have-to" and "cannot-do" facts about this.
As mentioned in the previous paragraph, Swarm remains to be utilized by both Docker and Kubernetes as a core engine for container storage. Granted that Kubernetes is in a dominant position on the market right now, its adoption and usage of Swarm continue to be in the spotlight.
For beginners, Docker Swarm is an easy-to-use and simple solution to manage your containers at scale. If your company is moving to the container world and does not have complex workloads to manage, then Docker Swarm is the right choice.
Docker Compose is used for configuring and starting multiple Docker containers on the same host–so you don't have to start each container separately. Docker swarm is a container orchestration tool that allows you to run and connect containers on multiple hosts.
Advantages of Docker Swarm Swarm is built for use with the Docker Engine and is already part of a platform that's familiar to most teams. It's easy to install and set up for a Docker environment. Tools, services and software that run with Docker containers will also work well with Swarm. It has its own Swarm API.
For development, use Docker-Compose. Because only Docker-Compose is able to read your Dockerfiles and build images for you. Docker Stack instead needs pre-built images. Also, with Docker-Compose, you can easily start and stop single containers, with docker-compose kill ...
and ... start ...
. This is useful, during development (in my experience). For example, to see how the app server reacts if you kill the database. Then you don't want Swarm to auto-restart the database directly.
In production, use Docker Swarm (unless: see below), so you can configure mem limits. Docker-Compose has less functionality that Docker Swarm (no mem or cpu limits for example) and doesn't have anything that Swarm does not have (right?). So no reason to use Compose in production. (Except maybe if you know how Compose works already and don't want to spend time reading about the new Swarm commands.)
Docker Swarm doesn't, however, support .env
files like Docker-Compose does. So you cannot have e.g. IMAGE_VERSION=1.2.3
in an .env
file and then in the docker-compose.yml
file have: image: name:${IMAGE_VERSION}
. See https://github.com/moby/moby/issues/29133 — instead you'll need to set env vars "manually": IMAGE_VERSION=SOMETHING docker stack up ...
(this actually made me stick with Docker-Compose. + that I didn't reasonably quickly find out how to view a container's log, via Swarm; Swarm seemed more complicated.)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With