<p>Let's take your questions one-by-one:</p>

<blockquote>
  <p>I want to be able to specify different versions of microservices for different prodction servers. How should I approach this?</p>
</blockquote>

<p>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.</p>

<blockquote>
  <p>Should I have one general docker-compose file or one file with specified versions for each production environment?</p>
</blockquote>

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

<blockquote>
  <p>Where should I keep docker-compose? In a repository? </p>
</blockquote>

<p>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.</p>

<blockquote>
  <p>How it is copied then to a remote host? How to deploy docker-compose.yml file to a remote host?</p>
</blockquote>

<p>For deploying a docker-compose.yml it depends on the target architecture.  Since you mentioned Linux you could use <a href="https://haydenjames.io/linux-securely-copy-files-using-scp/" rel="nofollow noreferrer">scp</a> to copy the file.</p>

<blockquote>
  <p>How can I deploy new version of a microservice to a remote host?</p>
</blockquote>

<p>The industry leading tool for this right now is <a href="https://kubernetes.io/" rel="nofollow noreferrer">Kubernetes</a>.  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.  <a href="https://github.com/containrrr/watchtower" rel="nofollow noreferrer">Watchtower</a> or a similar tool may be helpful.</p>

<p>Based on what you've described I would recommend taking a look at the interactive <a href="https://kubernetes.io/docs/tutorials/kubernetes-basics/" rel="nofollow noreferrer">Kubernetes tutorials</a>, and seeing if that is ultimately an easier approach than everything I outlined above.</p>

CC BY-SA 4.0
2020-01-08T08:43:10.900Z
Thanks for a detailed answer and guiding me into right direction. However, I have additional questions to your answer :) 

Ad.2 Right, but I won’t be able to specify the image tag version in an env file, therefore it seems that one docker compose per production site is the way to go, but this gives an overhead of maintaining all files :/ 

Ad 4. Yea, I thought of scp but it seems a low-level thing to do, it is hard for me to believe that there is no tool yet for executing a simple deploy such as: copy the file, restart the services.
Adam Wolski
CC BY-SA 4.0
2020-01-08T08:43:26.547Z
Ad 5. Yea, I have heard about Kubernetes but I thought it is made for clusters. Is it reasonable to run a Kubernetes on a single linux instance? Woudn’t it be an overkill?
Adam Wolski
CC BY-SA 4.0
2020-01-08T14:26:31.130Z
@AdamWolski for Ad. 2 that's why the answer depends.  Managing multiple files could get cumbersome.  Ad 4 this is why tools like Kubernetes were created.  I've used Kubernetes on single instances.  In the event you need to scale, it should be very easy to do since you would already have a cluster.
Wesley Rolnick
CC BY-SA 4.0
2020-01-08T01:18:02.443Z
2020-01-08T01:18:02.443Z
Wesley Rolnick
<p>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. </p>

<p>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.</p>

<p>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:</p>

<p>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? </p>

<p>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? </p>

<p>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 </p>

<pre><code>tool deploy app@2.33 [server1]
</code></pre>

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

<p>For instance I was using a tool for meteor deployment <a href="http://meteor-up.com" rel="noreferrer">meteor-up</a> 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. </p>

<p>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 <code>docker-compose up -d</code> ? </p>

<p>Any thoughts appreciated, thank you! </p>

CC BY-SA 4.0
2020-12-10T11:48:37.020Z
as a follow-up I went for a kubernetes (k3s) and it works super nicely.
Adam Wolski
<docker><docker-compose><deployment>
How to deploy docker-compose to a remote host
Adam Wolski
# How to deploy docker-compose to a remote host

(Asked by: username_0 on 2020-01-07)

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!

**Tags:** docker, docker-compose, deployment

> **Comments:**
> **username_0**: as a follow-up I went for a kubernetes (k3s) and it works super nicely.  

---

## 1 answers

### Answer by username_1 on 2020-01-08. Score: 4 | Accepted answer

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](https://haydenjames.io/linux-securely-copy-files-using-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](https://kubernetes.io/). 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](https://github.com/containrrr/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](https://kubernetes.io/docs/tutorials/kubernetes-basics/), and seeing if that is ultimately an easier approach than everything I outlined above.

> **Comments:**
> **username_0**: Thanks for a detailed answer and guiding me into right direction. However, I have additional questions to your answer :)   Ad.2 Right, but I won’t be able to specify the image tag version in an env file, therefore it seems that one docker compose per production site is the way to go, but this gives an overhead of maintaining all files :/   Ad 4. Yea, I thought of scp but it seems a low-level thing to do, it is hard for me to believe that there is no tool yet for executing a simple deploy such as: copy the file, restart the services.  
> **username_0**: Ad 5. Yea, I have heard about Kubernetes but I thought it is made for clusters. Is it reasonable to run a Kubernetes on a single linux instance? Woudn’t it be an overkill?  
> **username_1**: @AdamWolski for Ad. 2 that's why the answer depends.  Managing multiple files could get cumbersome.  Ad 4 this is why tools like Kubernetes were created.  I've used Kubernetes on single instances.  In the event you need to scale, it should be very easy to do since you would already have a cluster.  

---

