In part 1 and 2 of this series I reported about my progress towards containerizing my own server-side code. Now that things are in place, the next question is how to perform software updates. The answer is surprisingly simple.
The Traditional Way
In a manual installation, a software update would be done by updating the server installation with a sudo apt update && sudo apt upgrade procedure which would update the server itself, the Apache web-server, the PHP installation, and the MySQL database. To update the web-server application on top, one would un-tar the latest version of the software in the web directory. Not very difficult but quite a number of steps to take.
The Docker Way
If I had already taken the final step of open-sourcing my web database, a software update for a user would be done by pulling the current version of the container image from Docker Hub and starting the service again:
docker-compose down docker pull mysql:5.8 docker pull webdb:latest docker-compose up -d
This would take care of all required updates, including the system that runs in the two containers. But I am not quite at that point yet and still deliver my software in a tar file for updates. In this case, the update procedure requires to re-build the image locally instead of pulling it from Docker hub and then restarting the service:
# un-tar the webdb tar image in the docker-compose directory # of the project. docker-compose down docker pull mysql:5.8 docker pull ubuntu:20.04 sudo docker build -t webdb . docker-compose up -d
As my webdb image is built locally and is based on Canonical’s Ubuntu 20.04 image, I have to pull the latest version of the base image before I re-build the image locally. Otherwise, security fixes that have gone into the Ubuntu base image won’t be inside. Still, only a few painless steps that can easily be put into a script. No loops, no variables, a straight forward thing.