In a previous post I wrote out the Ubuntu OS upgrade process on How to upgrade Ubuntu but preserve your docker versioned application stack. I’ve executed this on several docker based application servers. Since a picture says more than a thousand words I created a simple schematic that explains the reason why dockerization (or similar) is good practice. It lowers, or rather removes the OS footprint the application has on the underlying Operating System.
OS footprint
The direct OS dependencies, or footprint, in case of a docker application is non existent as opposed to natively installed software. The docker version can be fixated having no effect on the application running on top of it. Whereas if you natively install your components the touchpoint is pretty broad. You can of course install everything native if that has your preference. You just need a different more extensive approach when performing an OS release upgrade.
As you can see in the above schematic it displays Nginx in a docker container. If you have Nginx natively installed, for instance because of an elaborate proxy setup, this would increase the footprint but does have it’s uses. Think for instance of Google’s GCP cloud platform service definition. In that case another docker container with merely Nginx in it would have no direct added value.
If your application stack is fully dockerized, after the OS upgrade, everything should run as it did before. On the other hand, the more software you natively install on the OS, the more you should test it before hand.
The reason for this is because an OS upgrade also upgrades the underlying executable libraries. This results in mandatory upgrades for services like Nginx and others. This also means, and I’ve seen this in the past, a possible change of modules and configuration files. In an older use-case
Nginx changed to a different security module to run website instances in user space. This demanded different configuration attributes which, if not adjusted, would result in leaving Nginx inoperable after doing the OS upgrade. Thus, no running services for user and/or visitors.
Keep it clean
Over the last several Ubuntu LTS version release upgrades you see more standalone system services (like resolver, ntp, etcetera) move to a systemd integrated version. Not cleaning up old configuration files will result in legacy files on your system which makes it harder to troubleshoot. Changing old unused configuration files will have no effect, obviously, and this can give you headaches if it doesn’t work. So all files not in use (by internal system services) better be removed.
Best thing to do to make sure the aimed upgrade ends as expected is run a full upgrade or new installation on a local vm and check what’s what. I usually do a manual install of all the top level packages needed (think of for instance Postgres and Nginx). This way you know what comes with them in terms of dependent modules and packages. More importantly, you can review the latest configuration files of all those packages.
Stay secure
There will most likely be deprecated attributes in your currently deployed configuration files. But there also will be newer attributes and features in the configuration files that you want in your live setup. A good example is the configuration of SSH, SSL and other security components. Over time certain aspects and protocol versions will become exploitable. This is known by the public but also by hackers. For these security exploits fixes are released and you want those included in your live system.
Concluding, running your (small to medium size) application platform in docker containers makes OS release upgrades a lot easier, resulting in less migrations over time. Should you choose to run native installed components, be sure to check them up front in a test environment to avoid breaking live systems.
Happy system maintenance!
– Gerard
