7

I'm planning to set up a jenkins-based CD workflow with Docker at the end. My idea is to automatically build (by Jenkins) a docker image for every green build, then deploy that image either by jenkins or by 'hand' (I'm not yet sure whether I want to automatically run each green build).

Getting to the point of having a new image built is easy. My question is about the deployment itself. What's the best practice to 'reload' or 'restart' a running docker container? Suppose the image changed for the container, how do I gracefully reload it while having a service running inside? Do I need to do the traditional dance with multiple running containers and load balancing or is there a 'dockery' way?

Csaba Okrona
  • 693
  • 1
  • 6
  • 8

2 Answers2

6

Suppose the image changed for the container, how do I gracefully reload it while having a service running inside?

You don't want this.

Docker is a simple system for managing apps and their dependencies. It's simple and robust because ALL dependencies of an application are bundled with it. If your app runs today on your laptop, it will run tomorrow on your server. This is because we have captured 100% of the "inputs" for your application.

As soon as you introduce concepts like "upgrade" and "restart", your application can (accidentally) store state internally. That means it might behave differently tomorrow than it does today (after being restarted and upgraded 100 times).

It's better use a load balancer (or similar) to transition between your versions than to try and muck with the philosophy of Docker.

BraveNewCurrency
  • 12,654
  • 2
  • 42
  • 50
  • good answer, although one could add the fact it is still important to kill running processes gracefully – Hedde van der Heide Mar 18 '16 at 21:12
  • Docker already sends a signal and waits for your app to quit (only for 10s by default, you may need to increase it). My comment was trying to say "restarting services (or any mucking about) within a container is an anti-pattern". Always prefer to start the containers fresh. Anything else is just building up technical debt that will cause massive problems down the road. – BraveNewCurrency Mar 19 '16 at 01:04
1

The Docker machine itself should always be immutable as you have to replace it for a new deployment. Storing state inside the Docker container will not work when you want to ship new releases often that you've built on your CI.

Docker supports Volumes which will let you write files that are permanent into some folder on the host. When you then upgrade the Docker container you use the same volume so you've got access to the same files written by the old container:

https://docs.docker.com/userguide/dockervolumes/

Florian Motlik
  • 386
  • 3
  • 7