Only one host for production environment. What to use: docker-compose or single node swarm?

[marcos-muino-garcia]

We have recently moved all our corporative services to run ONE DigitalOcean server having all services in a docker environment: redmine, dokuwiki, opends, mattermost, a docker registry, portainer,...

The way we did it, was creating all the needed docker-compose files (one by service, and having all the needed containers in each one: RoR+postgresql, Node+Mongo+redis,...), add all the needed mountpoints for the volumes (and almost all containers must be persistent), and include the option in all of them with "restart: always". All this apps were started with 'docker-compose -d up", and in this way this only ONE server is able to run all services (and all of them get started with server startup). We don't need a cluster right now.

We don't know if this approach is a good one or it shouldn't be used for production (and why in this case). We want to have one server to pay the less as possible, and taking into account that it can manage all our apps. Should we create a swarm, move all containers to be swarm services, but only have one manager and no workers? I would be that approach a better option?

If this is true, what should we use to replace the use of jwilder/nginx-proxy (and docker-letsencrypt-nginx-proxy-companion) to manage http redirections and automatic generation of letsencrypt certificates.

Thanks in advance!

[BretFisher]

I always recommend single-node Swarm with the assumptions you know the risks of a single node of anything, and you're backing up persistent data, keys/secrets, etc.

My top reasons for a single-node Swarm over docker-compose:

• It only takes a single command to create a Swarm from that docker host docker swarm init.
• It saves you from needing to manually install/update docker-compose on that server. Docker engine is installable and updatable via common Linux package managers (apt, yum) via https://store.docker.com but docker-compose is not.
• When you're ready to become highly-available, you won't need to start from scratch. Just add two more nodes to a well-connected network with the 1st node. Ensure firewall ports are open between them. Then use docker swarm join-token manager on 1st node and run that output on 2nd/3rd. Now you have a fully redundant raft log and managers. Then you can change your compose file for multiple replicas of each of your services and re-apply with docker stack deploy again and you're playin' with the big dogs!
• You get a lot of extra features out-of-the-box with Swarm, including secrets, configs, auto-recovery of serivces, rollbacks, and healtchecks.
• Healthchecks, healthchecks, healthchecks. docker run and docker-compose won't re-create containers that failed a built-in healthcheck. You only get that with Swarm, and you always want healthchecks in production on all containers.
• Rolling updates. Swarm's docker service update command (which is also used by docker stack deploy when updating yaml changes) has TONS of options for controlling how you replace containers during an update. If you're running your own code on a Swarm, updates will be often, so you want to make sure the process is smooth, depends on healthchecks for being "ready", maybe starts a new one first before turning off old container, and rolls back if there's a problem. None of that happens without Swarm's orchestration and scheduling.
• Local docker-compose for development works great in the workflow of getting those yaml files into production Swarm servers.
• Docker and Swarm are the same daemon, so no need to worry about version compatibility of production tools. Swarm isn't going to suddenly make your single production server more complex to manage and maintain.

There's more, but that's my big-ticket heavy hitters!

Don't get me wrong, I 😍love😍 docker-compose, and use it for most things I do locally with Docker. It's great. But, the right tool for the job:

I like focusing on the above positives of Swarm, but take that list and turn it into negatives of "why not docker-compose on servers":

• Requires pip install or manual updates. No yum/apt packages.
• Docker demoed at DockerCon 2020 that they are adding "docker compose" (no dash) features to the Docker CLI, so I'm not sure if it's got a long multi-year future as a separate tool. The docker-compose tool is Python, rather than Go that all the other Docker tools are developed in, so it may take some time for Docker Inc. to convert the main docker-compose functionality over to the Docker CLI, but that's where they want to go with it.
• It doesn't do well on reboots. docker-compose is really just a wrapper around the Docker API, so once it has started something in the detached background, it is no longer running as a separate process. One issue with this is if Docker restarts those containers that were created via YAML, docker doesn't know about any YAML changes or any env var changes that would be pulled into that YAML.
• It can't monitor your containers with healthchecks or do anything if there is a problem.
• It can't use encrypted secrets.
• It has no way to replace a container without downtime. No rolling updates.

[WTFKr0]

Go for a one swarm master node, for all @BretFisher says
Here we only go for docker-compose (v2) containers for privileged one (such as Docker in Docker)

For your second point, go give a try to https://github.com/containous/traefik
It do all what you want, for swarm mode or classic containers, and it's a single go binary

[marcos-muino-garcia]

Many thanks for your answers. We are giving a try to a swarm approach (but I think a good point will be enroll the Docker Swarm Mastery course before) :-)

Best regards!

[augnustin]

How about those downsides:

• swarm is harder to learn than compose (at least for me)
• docker-compose relies on file configurations while swarm relies on commands, which are much harder to maintain

Thanks

[BretFisher]

Thanks @augnustin. I might agree with the first point if you haven't taken my Swarm course, but the for the second:

docker-compose up is functionally the same on servers as docker stack deploy -c docker-compose.yml <name>. They both pull images, create containers and networks, and setup volumes, and put all your apps in the yaml file on a single network (by default). They even support the same file format.

I think maybe you're referring to docker service create, but most move to the declarative stacks model because, like docker-compose up, it's easier to maintain. In Kubernetes this is similar to the kubectl apply -f your-resources.yml declarative approach.

[surajrahel]

Thanks @BretFisher for giving more insight of Swarm. I am working on a migration project where we have 3 different nodejs applications running with pm2, one MySQL dB and a few legacy software on the one on-prem box with one backup box in production (Please do not ask why we have only two boxes in production as it is driven by the Business).
In this migration phase, I am looking to run node js and MySQL application with docker containers. By keeping hardware limitation in the mind what would you suggest from pm2, docker-compose and swarm like will it be an overhead if we replace pm2 with docker-compose/docker swarm?
Do you still recommend docker swarm over docker-compose if you have limited hardware resource or both use the equal resources to run the application?

Thanks in Advance.

[BretFisher]

Follow all my recommendations from my Docker Node.js course , so throw out pm2 and only use swarm. You resources won't change much from pre-docker.

[nate-benton90]

With the relatively recent Mirantis acquisition of Docker Enterprise, what is expected for the long-term future of Swarm? It seems that it might be ignored and eventually deprecated in favor of Kubernetes.

[BretFisher]

@nate-benton90 Mirantis has repeated at least 3 times this year they are investing in Swarm, and Enterprises want its simplicity. We're simply waiting on new versions with their expected features (jobs, CSI, Swarm on Kubernetes).

See my live show about Swarm and Mirantis from Spring 2020: https://youtu.be/L5N43aQQArw

Or come today to my live show in 10 minutes and ask questions: https://bret.live

[BretFisher]

By the way, that BoxBoat piece is marketing hype and not everyone at that company was a fan of posting it. Oh, and there's also https://www.nomadproject.io

[u2ros]

Cool, we love Swarm ;) It even has a cool name

[nate-benton90]

@BretFisher what a relief! I'm certainly still a rookie in this environment but still wanted a sanity check. Thanks for the insight. Indeed, the article kinda had a click-bait feel to it. Cheers.

[al-yakubovich]

@BretFisher

If we have one server are there any advantages in creating several swarm nodes on this server with docker-machine command instead of using only one swarm node?

[BretFisher]

no

[ivanduka]

@BretFisher, I am taking your course Docker Mastery on Udemy currently (which is FANTASTIC by the way), and could not even formulate the question that you so brilliantly answered.
Using docker-compose to run several apps is incredibly messy, beginning with the fact that you have to keep all the *.yml files in different folders just to name different deploys (otherwise the prefix is the same).
Thank you so much, you are truly making a dent in the universe with your work :)

[BretFisher]

@ivanduka thanks! Some Pro Tips:

1. You can use template variables in your YAML files to keep from needing a bunch of similar ones. You can pass those variables in through your shell env. See docs template variables.
2. You can layer YAML files over top of each other. Both docker-compose and Swarm let you specify multiple files at the command line and each one will add/override the previous. See docs overrides.
3. In docker-compose, if you want to override container names (which allows you to run the same compose file multiple times) look up the --help and see the -p option (it defaults to directory name) or the environment variables you can set for docker-compose, one of which will use to name the containers.

[bipin332]

@BretFisher , I have taken your course Docker Mastery on Udemy it was nice but I am not getting yaml file for voteapp to deploy with stack
Request you to share that example file

[BretFisher]

Hey @bipin332, for a simple example-voting-app example, see the official repo https://github.com/dockersamples/example-voting-app
For a more complex setup, see my Swarm setup (a bit dated but the stack files can be used as more complex examples) https://github.com/BretFisher/dogvscat

[muhammedh-shadir]

@BretFisher what do you think of same server running both production and staging app? currently it is running on docker compose. Since you recommend swarm for production would it be good idea to run both staging and production as swarm in the same server or would you recommend separate servers for staging and production?

To give more context about the app it's a laravel 12 backend, React frontend, MYSQL db, redis, PHYMyadmin rdbms.

[BretFisher]

That answer is more to do with your requirements. Does the server have enough resources to handle both environments? Since the server port 443 will probably be used for the production website, Are you OK with staging running on a different Port than the default? That's assuming you're not using a layer seven proxy.
If you're not sure about any of this, just try running both on the same server and if it doesn't meet your needs split them out.