Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

Typically on a server, automatic updates of security-related patches are configured. Therefore, if I'm running MySQL 5.5 and a new security patch comes out, Ubuntu Server will apply the upgrade and restart MySQL to keep me protected in an automated way. Obviously, this can be disabled, but it's helpful for those of us who are a bit lazy ;)

Does such a concept exist inside of a Docker container? If I'm running MySQL in a Docker container, do I need to constantly stop the container, open a shell in it, then update and upgrade MySQL?

share|improve this question
    
This is Docker, and not LXC question. As LXC containers themselves are just another linux distribution running under same kernel, you would just use same commands to update the LXC container system. –  edvinas.me May 5 at 17:34

2 Answers 2

up vote 3 down vote accepted

TL;DR: If you don't build it in yourself, it's not going to happen.

The effective way to do this is to simply write a custom start script for your container specified by CMD in your Dockerfile. In this file, run an apt-get update && apt-get upgrade -qqy before starting whatever you're running.

You then have a couple way of ensuring updates get to the container:

  1. Define a cron job in your host OS to restart the container on a schedule, thus having it update and upgrade on a schedule.
  2. Subscribe to security updates to the pieces of software, then on update of an affected package, restart the container.

It's not the easiest thing to optimize and automate, but it's possible.

share|improve this answer

I disagree with accepted answer. First, you should design your containers with separation of state in mind (in the MySQL case this means that at least /var/lib/mysql goes in its own volume). Secondly, you should determine a strategy for upgrades; state-of-the-art would be to create versioned images for each set of apt packages upgrade and have them tested before swapping the data volume from running container to new one. This can either include a downtime or no downtime at all if you use something like hipache.

This setup, although more expensive to initially setup, is the same used by companies with a mass scale of containers and will be cheaper to maintain over time.

Furthermore, package upgrades can eventually break your running containers, thus applying them to running containers is not a best practice - as it is not to run outdated software.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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