We talked a little about this previously, but it seems that in most online documentation and blogs, package updates have been sorely neglected in coverage within the context of Docker containers. While there are supporters of both camps, it is important to remember that there is no guarantee that the tagged images available from places such as Docker Hub have been built with the latest updates, and even in cases where they are, the tagged image might have been built a while ago and, as such, won't contain the latest security patches.

While it is true that within Docker containers, the host's kernel is used to run the context of the container, a security hole in any of the supporting libraries within the container can (and usually does) result in a breach that can often cascade onto the host and into your whole network. Due to this fact, my personal recommendation for containers that will be deployed to production is that you should always make sure that the container is built with the latest libraries if possible. There are definite risks, albeit small, in manually upgrading packages on some base images that are caused by library incompatibilities that occur when you do the upgrade, but as a general rule, it is a risk worth taking.

In most cases, in order to do this kind of upgrade, just like we covered earlier in most of our Docker examples, you pretty much need to invoke the system upgrade lines specific to the base OS distribution of the image in Dockerfile. For our default deployment OS (Ubuntu LTS), this operation is done with apt-get update and apt-get dist-upgrade:

...
RUN apt-get update && apt-get -y dist-upgrade
...