{"id":3487,"date":"2025-01-24T06:56:24","date_gmt":"2025-01-24T12:56:24","guid":{"rendered":"https:\/\/promincproductions.com\/blog\/?p=3487"},"modified":"2025-01-24T06:56:26","modified_gmt":"2025-01-24T12:56:26","slug":"update-container-version-in-qnap-container-station-3","status":"publish","type":"post","link":"https:\/\/promincproductions.com\/blog\/update-container-version-in-qnap-container-station-3\/","title":{"rendered":"Update Container Version in QNAP Container Station 3"},"content":{"rendered":"

This post is a tutorial on how to use Container Station 3 to update Containers and Applications on a QNAP server.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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<\/a>] When QNAP released Container Station 3<\/a> – 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.<\/p>\n\n\n

\n
\"How<\/figure>\n<\/div>\n\n\n

Identifying if an Update is Available<\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

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><\/code> So for example, if the Image name in Container Station is mattermost\/mattermost-enterprise-edition<\/code>, then the docker URL is: https:\/\/hub.docker.com\/r\/mattermost\/mattermost-enterprise-edition<\/code>. Once on that page, click on the Tags<\/strong> 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><\/code>. Each developer can choose to mange this how they’d like. There are some standards, but not always followed the same by all developers.<\/p>\n\n\n\n

A helpful tip is when creating a container in Container Station use the <version_number><\/code> 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<\/code> it’s still not identifiable)<\/p>\n\n\n\n

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<\/strong> link in the right hand column).<\/p>\n\n\n\n

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! <\/p>\n\n\n\n

ASIDE:<\/strong> 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<\/a> or docker notify<\/a>.<\/p>\n\n\n\n

How Container Naming and Versioning Works<\/h2>\n\n\n\n

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:<\/p>\n\n\n\n

namespace\/package<\/code><\/pre>\n\n\n\n
The namespace<\/code> is the vendor or software manufacturer who created the image.<\/p>\n\n\n\n
The package<\/code> is what the software is.  There can be many package<\/code>s for one namespace<\/code>.<\/p>\n\n\n\n
A \/<\/code> separates the namespace<\/code> and the package<\/code>.<\/p>\n\n\n\n
To specify what version of a package<\/code> the container is, a version number is added at the end of the container name.  Example:<\/p>\n\n\n\n
namespace\/package:2.4<\/code><\/pre>\n\n\n\n
A :<\/code> separates the image naming and the version.<\/p>\n\n\n\n
Alternatively the version can be left off as in the initial example in this section.  Or latest<\/code> can be used.  Both have the same result – the latest version of the containers package will be used.  Example:<\/p>\n\n\n\n
namespace\/package:latest<\/code><\/pre>\n\n\n\n
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<\/code> 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<\/code> or :<version_number><\/code> 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.<\/p>\n\n\n\n
Methods to Update Containers<\/h2>\n\n\n\n
Container Station 3 provides two methods for updating containers.<\/p>\n\n\n\n
    \n
  1. Update in place<\/li>\n\n\n\n
  2. Duplicate Container<\/li>\n<\/ol>\n\n\n\n
    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.<\/p>\n\n\n\n
    Feature<\/th>Update in Place<\/th>Duplicate Container<\/th><\/tr><\/thead>
    Container Usage<\/td>The existing container is reused.

    This minimizes disk space usage and doesn’t require cleanup<\/em> 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.<\/td>    		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.<\/td><\/tr>
    Disk Space Usage<\/td>Less<\/td>More (until manual cleanup run)<\/td><\/tr>
    Container Settings<\/td><\/td>Not all of the settings transfer to the new container – they must be configured manually in the creation process.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    Application vs Container<\/h2>\n\n\n\n
    Container Station has two methods for creating containers:<\/p>\n\n\n\n
      \n
    1. Applications<\/li>\n\n\n\n
    2. Containers<\/li>\n<\/ol>\n\n\n\n
      Containers<\/strong> 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.<\/p>\n\n\n\n
      Applications<\/strong> 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.<\/p>\n\n\n
      \n
      \"Multiple
      Multiple Docker images running within one Container Station Application<\/strong><\/figcaption><\/figure>\n<\/div>\n\n\n
      Depending on if the container to be updated is a Container<\/strong> or an Application<\/strong> requires a slightly different process as outlined below.<\/p>\n\n\n\n
      Container Station 2 Compatibility<\/h2>\n\n\n\n
      In my personal experience, I found some Container Station 2 containers that the Duplicate<\/strong> 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<\/strong> button.  This will display the parameters used to create the container.  This can help in guiding how to recreate the a new container.<\/p>\n\n\n
      \n
      \"The<\/figure>\n<\/div>\n\n\n
      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.<\/p>\n\n\n\n
      Tutorial to Update a “Container” Image in Container Station 3<\/h2>\n\n\n\n
      Follow this process step by step to update Container Station 3 images for a Container<\/strong> on a QNAP server.  As mentioned above, there are two methods to do this – Update in Place<\/strong> and Duplicate Container<\/strong>.  Tutorials for both methods are below to guide through the process.<\/p>\n\n\n\n
      Steps for Update in Place<\/strong> to Upgrade a \u201cContainer\u201d Image in Container Station 3<\/a><\/h3>\n\n\n\n
      When using Update in Place<\/strong> 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.<\/p>\n\n\n\n
        \n
      1. Login to the QNAP Admin Panel<\/li>\n\n\n\n
      2. Open Container Station<\/strong><\/li>\n\n\n\n
      3. Click on Containers<\/strong><\/li>\n\n\n\n
      4. Click on the Name of the container to update<\/li>\n\n\n\n
      5. Click the down arrow next to the Edit<\/strong> button and select either the Recreate Directly<\/strong> or Recreate<\/strong> option\n