Inner Renewal

Using Volumes for Dynamic Updates

Anyone running a Docker container with MariaDB will normally have a Docker volume for the data. From an operational point of view, this provides a decisive advantage for updates: You can prepare the new container with the new version of MariaDB in the background while the old container continues to run as before. In specific terms, this means you download a new base image of MariaDB or build your own container image, which you test thoroughly.

If it works as desired, simply stop the old container at time t , delete the connection between the old image and the volume, and connect it directly to the new container with the new MariaDB. Assuming you have ensured that the volume is mounted in the container at the correct place in the filesystem (i.e., where MariaDB expects the data in the new container), the downtime will be negligible.

The persistent volume procedure offers another advantage: If you want to test with real data whether problems can be expected during an upgrade, you can create a clone of the existing Docker volume and connect it to the new container. The risk of problems during the update of the live system can thus be successfully reduced further.

Conclusions

Rolling out security and application updates in containers is not a particularly difficult task if you have a clear concept. Tinkering with solutions that involve updating running containers is reserved for emergencies and should never be used longer than absolutely necessary. The ideal way is to build your containers and all the necessary parts yourself, with tools such as GitLab and Docker providing practical help.

If you don't want to do this, you can use the ready-made images from different software providers – they don't differ greatly from their DIY counterparts when it comes to performing updates. However, you might have to wait awhile until an updated version of the required software is available as a container.