How to deploy docker-compose to a remote host

I am new to the docker ecosystem and I am trying to figure out a proper deployment infrastructure for a system I am working on.

Imagine a following scenario: a system consists of three microservices - DB, core server, and an app (server + client). For each of these I created a docker image. I also linked them together with docker compose to describe the system as a whole and described links between the microservices. During a release of the microservice I tag the image with a proper tag and push it to a private docker repository. So far so good, it works locally.

Now, imagine I have three different production clients, and each has it’s own one rack linux server. I am not sure how should I approach deployment of the system with docker:

1) I want to be able to specify different versions of microservices for different prodction servers. How should I approach this? Should I have one general docker-compose file or one file with specified versions for each production environment?

Where should I keep docker-compose? In a repository? How it is copied then to a remote host? How to deploy docker-compose.yml file to a remote host?

2) How can I deploy new version of a microservice to a remote host? I am looking for a tool so that if I run

tool deploy app@2.33 [server1]

it would run the app image at version 2.33 on server1. Is there a tool for that?

For instance I was using a tool for meteor deployment meteor-up that sends the meteor app docker image to a remote host and runs it there - I am looking for the same thing but for a random docker image/docker compose.

I can’t find what is the best practice now in the docker ecosystem to deploy an image to a simple server without AWS/Beanstalk or any other cloud environment. Should I just ssh into it, copy docker-compose and run docker-compose up -d ?

Any thoughts appreciated, thank you!

Let's take your questions one-by-one:


I want to be able to specify different versions of microservices for different prodction servers. How should I approach this?

There are many different ways to handle this. One possibility be to "tag" your docker images and have different docker-compose files that use these images.


Should I have one general docker-compose file or one file with specified versions for each production environment?

Depends. How many environments do you have? What I've often seen is a single docker-compose that references a separate environment file.


Where should I keep docker-compose? In a repository?

Again this depends. A standard enterprise best practice would be to store this in a repository so that it is naturally version controlled, and can easily be accessed by others.


How it is copied then to a remote host? How to deploy docker-compose.yml file to a remote host?

For deploying a docker-compose.yml it depends on the target architecture. Since you mentioned Linux you could use scp to copy the file.


How can I deploy new version of a microservice to a remote host?

The industry leading tool for this right now is Kubernetes. If you go this approach your docker-compose could be morphed into a Kubernetes deployment. Using just docker-compose you will need to somehow detect that a new container is available and pull it. Watchtower or a similar tool may be helpful.

Based on what you've described I would recommend taking a look at the interactive Kubernetes tutorials, and seeing if that is ultimately an easier approach than everything I outlined above.

StackExchange DevOps Q#10423, answer score: 4