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.