When deploying applications onto servers, there is typically a separation between what the application bundles with itself and what it expects from the platform (operating system and installed packages) to provide. One point of this is that the platform can be updated independently of the application. This is useful for example when security updates need to be applied urgently to packages provided by the platform without rebuilding the entire application.

Traditionally security updates have been applied simply by executing a package manager command to install updated versions of packages on the operating system (for example "yum update" on RHEL). But with the advent of container technology such as Docker where container images essentially bundle both the application and the platform, what is the canonical way of keeping a system with containers up to date? Both the host and containers have their own, independent, sets of packages that need updating and updating on the host will not update any packages inside the containers. With the release of RHEL 7 where Docker containers are especially featured, it would be interesting to hear what Redhat's recommended way to handle security updates of containers is.

Thoughts on a few of the options:

  • Letting the package manager update packages on the host will not update packages inside the containers.
  • Having to regenerate all container images to apply updates seems to break the separation between the application and the platform (updating the platform requires access to the application build process which generates the Docker images).
  • Running manual commands inside each of the running containers seems cumbersome and changes are at risk of being overwritten the next time containers are updated from the application release artifacts.

So none of these approaches seems satisfactory.

  • 1
    The best idea for this I've seen so far is Project Atomic. I don't think it's quite ready for prime time though. Jul 8 '14 at 22:01
  • 1
    Valko, what workflow did you end up with? I'm running long-term containers (hosting php-cgi, for instance) and what I've found so far is: docker pull debian/jessie to update the image, then rebuild my existing image(s), then stop the containers and run them again (with the new image). The images I build have the same name as previous ones, so the starting is done via the script. I then remove "unnamed" images. I would surely appreciate a better workflow.
    – miha
    Nov 1 '14 at 8:40
  • 1
    miha: That sounds similar to what I have ended up doing. Basically continuously updating and rebuilding all images as part of making new releases. And restarting the containers using the new images. Nov 4 '14 at 10:42
  • 1
    The best answer here helps a lot because there is a script which contains main commandlines to do exactly what Johannes Ziemke said: Jan 29 '16 at 6:32
  • Interesting question. I wonder about it myself. If you have 20 applications running on one docker host, you have to upgrade base images, rebuild and restart! 20 applications and you don't even know if the security update affected them all, or just one of them. You have to rebuild image for say Apache when the security update affected only libpng for example. So you end up with unnecessary rebuilds and restarts... Aug 3 '19 at 13:15

A Docker image bundles application and "platform", that's correct. But usually the image is composed of a base image and the actual application.

So the canonical way to handle security updates is to update the base image, then rebuild your application image.

  • 3
    Thanks, this sounds reasonable. Just still wish updating the platform so to speak wouldn't have to trigger repackaging the entire application (consider for example having to rebuild 100 different application images due to a single base image getting update). But maybe this is inevitable with the Docker philosophy of bundling everything together inside a single image. Nov 20 '14 at 11:54
  • 3
    @ValkoSipuli You could always write a script to automate the process.
    – dlyk1988
    Jan 16 '15 at 14:28
  • Why not apt-get upgrade, dnf upgrade, pacman -syu, etc equivalent inside the container? You could even create a shell script that does that and then runs the application, then use that as the container's entrypoint so that when the container is started / restarted it upgrades all its packages.
    – Arthur Kay
    Sep 29 '15 at 16:53
  • 10
    @ArthurKay Two reasons: 1) You blow up the container size, since all packages that get upgraded will be added to the container layer while keeping the outdated package in the image. 2) It defeats the biggest advantage of (container) images: The image you run isn't the same you build/tests because you change packages on runtime. Sep 30 '15 at 9:32
  • 11
    There's one thing I don't understand: If you are a company buying a piece of software that is shipped as a docker container, do you have to wait for the manufacturer of the software to rebuild the application package every time a security issue comes out? Which company would give up the control over their open vulnerabilities in that way?
    – Sentenza
    Oct 17 '17 at 13:04

The containers are supposed to be lightweight and interchangeable. If your container has a security problem, you rebuild a version of the container that's patched and deploy the new container. (many containers use a standard base image that uses standard package management tools like apt-get to install their dependencies, rebuilding will pull the updates from the repositories)

While you could patch inside containers, that's not going to scale well.


This is handled automatically in SUSE Enterprise Linux using zypper-docker(1)


Docker Quick Start


First of all, many of your updates that you traditionally ran in the past will simply not be inside the container itself. The container should be a fairly lightweight and small subset of the full file system your accustomed to seeing in the past. The packages you should have to update would be those that are a part of your DockerFile, and since you have the DockerFile, you should be able to to keep track of those packages and container IDs that need updates. Cloudstein's UI that will be released soon keeps track of these DockerFile ingredients for you so that one can build the update scheme that fits best for their containers. Hope this helps


it is generally even worse than the three choices you provided. Most docker images are not built with package managers therefore you can't just shell into the docker image and issue an update. You will either need to rebuild or reobtain the docker image.

The fact that you need to rebuild or are beholding to others to rebuild for security patches seems unreasonable in most cases.

I was considering deploying sonarr and radarr in docker containers but knowing they are not going to get the regular security updates my container gets is a deal breaker. Managing security updates for my container is enough hassle without having to deal with somehow having to manually apply security updates to each docker image individually.

  • 2
    Your post would not be considered an answer, as you do not provide an answer to the question. Please add it as a comment to the question and remove your "answer". StackExchange is not a forum, but should be considered as a Q&A where experts answer questions they can provide help with. May 1 '19 at 19:13
  • Ha, well surly I should be down voted for attempting to contribute to the understanding of the problem. There is an answer in the response " You will either need to rebuild or reobtain the docker image."
    – Lee Burch
    Jan 15 '20 at 22:12

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.