4

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!

3

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.

| improve this answer | |
  • 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 Jan 8 at 8:43
  • 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 Jan 8 at 8:43
  • @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 Jan 8 at 14:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.