How to deploy an application running in docker - best practice?

Question

We are discussing how we should deploy our application running in a docker container. At the moment, we build our application image in the pipeline containing the application code. Which means we have to build the docker image every time the application updates.

Another approach we consider is putting the application code in a volume on the server. We then pull the latest release with git on the server. So the image has not to be rebuilt.

So our discussed options are:

1. Build the image containing the application code
2. Use a volume and store the application code on the server

What is best practice to do and why?

Answer 1

While the other answers here have explained the point of building code into your image, I'd like to go one step further and show you how to get the benefits of both worlds while following this best practice.

Docker best practices call for building source code into your image before deployment, rather than deploying an image with dependencies installed and then source code mounted in as a volume.

This gives you a self-contained, portable container that is straightforward to test, deploy, or rollback.

May I take a stab at why you are considering hot-mounting code?

Hot-mounting code is appealing for several reasons — and they're all easy to achieve without sacrificing this best practice of building a self-contained image:

• Building Docker images can be slow, so why rebuild for a minor change when you can just hot-mount the code?

  A complementary best practice is to use a "base image" that installs all dependencies -- usually the slow part of building a docker image. The key insight is that this base image won't change often!

  But the image that derives from it -- your application image, which installs source code -- will change with every commit you want to deploy. That derived image will be very fast to build. The Dockerfile could be as simple as:

  FROM myapp/base .      # all dependencies installed in base image
  ADD code.tar.gz /src   # automatic untaring!
  CMD [...]              # whatever it takes to run your app
  

• Hot-mounting enables faster development cycles, because a developer won't need to flush their docker container, rebuild, and run a new container just to see a change.

  This is a fair point. I recommend making a "dev" image (which will also derive from your base image) that enables code mounting via a volume rather than the source code installation steps you'd have in your testing and deployment images.

Answer 2

I believe you should follow the first approach i.e. rebuilding the docker image every time there are changes in code. Reasons are-

1. Firstly, if you are using volume, every time you have to manage the clean closing and removing of the previous version of the application and check whether the new version of the application is running correctly. Your new application might get affected dependencies of your previous version of the application. That need to be taken care too.
2. Secondly, there might be some version updates of the frameworks installed and some new frameworks are to be installed with the current application. In this case, the first approach seems to be the only option.
3. Thirdly, As when you are using docker volume you will be removing the most important feature of docker i.e. abstraction from outside environment. Also, the image might become machine dependent because of it, which might affect if you want to publish the app in multiple environments.

My suggestion would be creating a pipeline using some continuous integration tool and fully automate the process starting from code building, building of docker image and deploying it to your environment.

Answer 3

When you build image every time with new application you have easy way to deploy it later on to the customer or on your production server. When the docker image is ready you can keep it in the repository. Additionally you have full control on that that your docker is working with current application.

In case of keeping the application in mounted volume you have to keep in mind following problems:

• life cycle of application - what to do with container when you have to update the application - gently stop, overwrite and run again
• how do you deploy your application - you have to do it manually over SSH, or you want just to run simple command docker run, and it runs your latest version from your repository

The mounted volumes are rather for following casses:

• you want to have externally exposed settings for container - what is also not a good idea
• you want to have externally access to the data produced by the application like logs, db, etc

To automate it totally, you can:

• build image for each application and push to the repository
• use for example watchtower to automatic update of the system on your production servers