Update Container Version in QNAP Container Station 3

This post is a tutorial on how to use Container Station 3 to update Containers and Applications on a QNAP server.

Updating the software version of a container is critical to ensure the latest and greatest version is running the best features, and possibly more importantly ensure all security updates are applied. QNAP’s Container Station will do most of the heaving lifting here – allowing you to manage the version via the QNAP admin.

Now if you’ve use Container Station 2 in the past – it’s been a bit clunky to manage and at times rather difficult to do updates. [see post Update Container Version in QNAP Container Station 2] When QNAP released Container Station 3 – they addressed many of the shortcomings of Container Station 2. Container Station 3 may look similar on the surface, however it has many huge improvements hidden within it. Container Station 3 solves most of the issues/complaints that were common in it’s prior versions.

How to update e QNAP Container Station 3 Containers and Applications

Identifying if an Update is Available

The remainder of this post isn’t very helpful if it’s not known that an update is needed. So how does one identify that an update is required? Often times as a user of the software within the container a notice will be prompted. But not always – many updates go undetected. And that’s partly because there isn’t a great system in place to alert when new updates come along. So at this time, it’s a bit of a manual process. Make a habit to check frequently (first of the month?). Also check with the software developers – many have newsletters or alerts when new versions are released.

If a Docker image was used to create the container, the version releases are published at Docker Hub – so that’s a great place to check what the latest version is. Docker Hub uses fairly standard URL patterns, so that’s helpful. https://hub.docker/com/r/<namespace>/<package> So for example, if the Image name in Container Station is mattermost/mattermost-enterprise-edition, then the docker URL is: https://hub.docker.com/r/mattermost/mattermost-enterprise-edition. Once on that page, click on the Tags tab – this lists all of the versions available. Not all tagged versions are the official releases however. Some developers put frequent tags into Docker Hub with their work in progress. It’s typically best to take the official releases – which will often have a numbered scheme to them or start with the name release-<version_number>. Each developer can choose to mange this how they’d like. There are some standards, but not always followed the same by all developers.

A helpful tip is when creating a container in Container Station use the <version_number> in the container name so that it’s quickly identifiable what version the container is. This small bit of effort will pay off in the long run of not having to click into the container to look at the image to figure out what version it is (and if the version is :latest it’s still not identifiable)

Another tip is that most developers publish notes of what changed in each release. But they don’t publish this at Docker Hub. Release notes are often available at their website, or GitHub (look for the Releases link in the right hand column).

And lastly – once you’ve found the Docker Hub page and release notes for a software package – it’s smart to bookmark these. Make a folder in your browsers Bookmark bar and add these there. They will be visited again in the future I’m sure!

ASIDE: Ideally the system would ping Docker Hub from time to time to see if there is an updated version of a container and alert in some way (ie. email) so that it can be applied when desired. Full disclosure: I don’t have that setup at this time and thus I don’t know much for specifics here. However some possible options are Watchtower or docker notify.

How Container Naming and Versioning Works

As software developers update their software, they increment the version number. This helps to know/understand what features/bug-fixes you are running. Each container has a specific naming pattern, which often includes a version number. Example:

The namespace is the vendor or software manufacturer who created the image.

The package is what the software is. There can be many packages for one namespace.

A / separates the namespace and the package.

To specify what version of a package the container is, a version number is added at the end of the container name. Example:

A : separates the image naming and the version.

Alternatively the version can be left off as in the initial example in this section. Or latest can be used. Both have the same result – the latest version of the containers package will be used. Example:

A wise strategy to use with the version number is to specify the specific version number. Typically the latest version number will be used, but it’s better to specify that version as opposed to using :latest so that it’s clear in the future to know what version is installed. It becomes a quick easy reference and also is helpful in ensuring that the software is what it is. Additionally when it comes to applying version updates this makes it easy to keep things straight. Another thing to consider when deciding to use :latest or :<version_number> is that not versions run as expected. There may be reasons that the latest version isn’t desired and thus forcing a specific version will ensure your system runs smoothly and as expected.

Methods to Update Containers

Container Station 3 provides two methods for updating containers.

  1. Update in place
  2. Duplicate Container

Each of these methods have their pros and cons. Understanding when to use either method and the outcomes is wise to know before beginning the update.

FeatureUpdate in PlaceDuplicate Container
Container UsageThe existing container is reused.

This minimizes disk space usage and doesn’t require cleanup of old containers. However if the update goes wrong for some reason, or the updated version isn’t suitable, it becomes a larger task to rollback to an older version.
A new container is created for each version.

This method insulates against update failures or unforeseen reasons that a rollback to an older version if needed. This does create multiple versions of the software package, which does result in some cleanup over time – deleting older unused containers, ensuring only the latest version is set to auto-start, etc.
Disk Space UsageLessMore (until manual cleanup run)
Container SettingsNot all of the settings transfer to the new container – they must be configured manually in the creation process.

Application vs Container

Container Station has two methods for creating containers:

  1. Applications
  2. Containers

Containers are the most straightforward method of using Container Station as it is the least complex, runs one system, and much of it’s configuration is pre-set. These are single stand-alone containers.

Applications offer a more robust solution allowing multiple Docker images to be configured to be running in the same Container. (a bit confusing, I know). Applications will require writing a Docker Make file using a language called YAML. This is outside of the scope of this article. A few pre-built YAML files are offered for common applications as needed.

Multiple Docker images running within one Container Station Application
Multiple Docker images running within one Container Station Application

Depending on if the container to be updated is a Container or an Application requires a slightly different process as outlined below.

Container Station 2 Compatibility

In my personal experience, I found some Container Station 2 containers that the Duplicate method didn’t work – thus forcing a complete recreation of the container under Container Station 3. The recreation can be made easier by clicking into the existing container and clicking the Inspect button. This will display the parameters used to create the container. This can help in guiding how to recreate the a new container.

The inspect button of a container displays the configuration of a container and can be used to recreate the container.

Given how the QNAP UI works, you likely need to close this screen though before being able to create the new container. QNAP didn’t provide a simple way to copy this… While you can highlight the text and copy it, anything under a closed triangle expander will not copy unless it’s expanded first. Thus you need to click on all of them to expand, then you can copy all of the text and paste it into a text editor to keep it as a reference as needed.

Tutorial to Update a “Container” Image in Container Station 3

Follow this process step by step to update Container Station 3 images for a Container on a QNAP server. As mentioned above, there are two methods to do this – Update in Place and Duplicate Container. Tutorials for both methods are below to guide through the process.

Steps for Update in Place to Upgrade a “Container” Image in Container Station 3

When using Update in Place the container is reused. The settings can be altered with this method. If issues with the updated version are encountered the method of going back is to update the container again changing the settings back.

  1. Login to the QNAP Admin Panel
  2. Open Container Station
  3. Click on Containers
  4. Click on the Name of the container to update
  5. Click the down arrow next to the Edit button and select either the Recreate Directly or Recreate option
    • To know which option to use, look at the Image heading in the left hand column of the container information panel.
      • If the Image has :latest at the end of the name or no specific version number (ie. :12.1.4) then the Recreate Directly option should be used as no modification will be necessary.
      • If the Image has a specific version number (ie. :12.1.4) then the Recreate option is needed to allow for changing the container settings.

Recreate Directly Method

  1. Check the Try pulling the image from the registry before creating the container. check box.
  2. Click the Yes button

Recreate Method

  1. Alter the Image: field setting the image number at the end of the name as needed (ie. :12.0.1).
  2. Check the Try pulling the image from the registry before creating the container. check box.
  3. Click the Next button
  4. Set the Restart policy: to Always so the container will restart if it were to crash or upon server restart
  5. Click the Next button
  6. Click the Finish button

At this point Container Station will take over and download the image from Docker hub, create the container, and finally auto-start the container (based on the policy set). After a bit of time the container will be running and this task is complete.

Steps for Duplicate Container to Upgrade a “Container” Image in Container Station 3

Duplicating a container results in more than one containers of different versions. This provides a quick/easy method to roll-back to the prior container if needed. This method is not recommended when the version is :latest however. Without a clearly defined version number anytime the underlying image is updated any container with a version of :latest would inherit that update. The Recreate Directly Method above is desired in that case.

Login to Container Station on QNAP

  1. Login to the QNAP Admin Panel
  2. Open Container Station
  3. Click on Containers
  4. Click on the Name of the container to update

Disable Auto-restart

Typically containers are configured to restart automatically. Since the existing container will no longer be used, it’s wise to ensure that it’s no longer going to auto-restart.

  1. Click the Edit button
  2. Set the Restart Policy to None
  3. Click the Apply button
Change the restart policy for the existing container to none

Backup Settings

Some of the settings don’t carry over as you’d expect. So doing a quick prep-work step makes it easy to get past this hurdle.

  1. Click the Inspect button
  2. Expand out the closed arrows to reveal sub-content – namely the Mount section.
  3. Copy the contents of the Inspect window and paste it into a text editor to reference later.

Duplicate the Container

Next to start the creation of a new updated container.

  1. Click the Stop button to stop the container
  2. Click the down arrow next to the Edit button and select the Duplicate option
  3. In the Image field set the image name and version.
    • <namespace>/<package>:<version>
    • <version> can be set to latest to pull the most recent version or set to a specific version number.
  4. Check the Try pulling the image from the registry before creating the server box
  5. Click the Next button
  6. Set the Name accordingly
  7. Set the Restart policy as desired. In most cases it is ideal to use Always
  8. Some of the settings don’t transfer in from the prior container. Click the Advanced Settings and go through all the settings to ensure they are set as expected. This is where the previous settings from the Inspect window in the previous step can be used to reference how the settings should be configured.
  9. Click the Apply button
  10. Click the Next button to move onto the Summary step
  11. Click the Finish button
Set the image name and version of the duplicate container

Container Station will take some time to download the image from Docker hub, create the container, and start it up. At this point the version update of the package should be up and running on the duplicated container and all is set to go.

Tutorial to Update an “Application” Image in Container Station 3

These steps will walk through updating the images within an Application on a QNAP server. These tutorials will cover both the Update in Place and Duplicate Container methods.

Login to Container Station on QNAP

  1. Login to the QNAP Admin Panel
  2. Open Container Station
  3. Click on Applications
  4. Click on the Name of the Application to update the images for

Within this screen the multiple containers/images that are running within the application are listed. Depending on the application, maybe one image would need to be updated but not the others.

It is possible to duplicate the entire Application using the down arrow next to the Edit button. But that’s not the focus of what is to be one here as the focus of this tutorial is for the underlying images.

Steps for Update in Place to Upgrade an “Application” Image in Container Station 3

This method can only be used for applications where the version number is not specified in the applications YAML configuration for the image, or the version is set to :latest. The same application will be used. The process will fetch the latest copy of the image from Docker Hub to use for this application.

  1. Click the down arrow next to the Edit button
  2. Select the Recreate option
  3. Click the Update button

Wait as QNAP goes through it’s processes to download the image from Docker Hub, install it, and restart the container. In time, the container will start itself back up and be running again.

Steps for Duplicate Container to Upgrade an “Application” Image in Container Station 3

Duplicating an application means that the original application stays intact. The benefit here is that if anything were to go awry, the original application is there to fallback on. This creates a layer of safety that is wise. The downside is that the old image will still stay around and after the duplicated application is proved to be running sufficiently, the original should be manually deleted. If not, it eats up file space and creates more clutter. Not a huge downside, but could be an issue in time.

NOTE: Some containers/applications do upgrade resources such as databases and configuration files when and updated version is applied. There is a chance that this could break the safety fallback of re-enabling the older version of the application. Identifying which applications this will affect and which won’t is out of the scope of this post however. But some research and critical thinking about how the application is built and runs can be applied to help here.

Disable Auto-restart

It is common that the containers are configured to restart automatically should they fail. Once this process is complete Since the existing container will no longer be used, it’s wise to ensure that it’s no longer going to auto-restart.

  1. Click on the Applications tab in Container Station
  2. Click on the Application name that will be duplicated
  3. Set the Restart Policy to None
  4. Click the Apply button

If multiple images are part of the application, repeat this process for each image.

Stop the Current Container

Stop the running application and it’s images as they will no longer be needed – they are being replaced by the newer version.

  1. Click the Stop button in the top right

Depending on the image running, this may take some time to complete as it may have a shutdown sequence to execute.

Duplicate the Container YAML

  1. Click on the Applications tab in Container Station
  2. Click on the Application name that will be duplicated
  3. Click the down arrow next to the Edit button and select the Duplicate option
  4. Select Duplicate
  5. Set a name in the Application name: field. It is wise to include the package name and version number that the new container will be updated to.
  6. In the YAML code: section, change the image properties value setting the proper namespace/package:version to the desired version.
  7. Click the Create button

At this time the new version of the image needs to be pulled from Docker Hub into the QNAP server and thus it will take a few minutes to complete. The progress of this can be monitored in the queue at the top of the QNAP web admin. Notice a counter shows up on this queue loader to indicate that it is making the container. When it is complete, it will show in the list of applications.

Container creation showing in the queue

Click on the main Applications tab in the left hand column to see what applications are running. In time, the new application will show in this list.

Enable Auto-restart

It’s typically desired to have the application restart automatically if it were to crash or the system is restarted. Since auto-restart was disabled before duplicating the application, this application will not auto-restart. Enable auto-restart for the new application.

  1. Click on the Applications tab in Container Station
  2. Click on the Application name that will be duplicated
  3. Set the Restart Policy to Always
  4. Click the Apply button

If multiple images are part of the application, repeat this process for each image.

Troubleshooting

Update Options are Greyed Out

For whatever reason some containers created in prior versions of Container Station can not be updated using the processes explained here. The Recreate and Duplicate options are greyed out and do not work. This implies that there is an incompatibility with the container and how Container Station 3 work. The workaround here is to manually build a new version of the container in Container Station 3. From this point forward the update methods outlined here should succeed since the new base container was built in Container Station 3.

Resources