Helmut4 Server
Last updated
Last updated
The purpose of this guide is to assist with upgrading a stable Helmut4 instance to a more recent snapshot version. It provides instructions for all necessary preparations and security precautions required for a successful upgrade
We strongly advise to always install an update on a development (staging) system first and check it with various stream and workflow tests
The latest snapshot-version can be found on our github page. We strongly recommend that you only install the snapshot versions, as we do not support development versions that are used in production environments.
The versions of the corresponding containers can be found here: Container-Snapshot-Versions
An update can be created within Helmut with no need of any other tools. This task is quite easy & straight forwarded. Navigate to the preferences page and click the backup button.
A window appears in which various parameters can be selected, which are then saved. If you are not sure, you can select everything (we do not recommend selecting jobs and license)
If you want to be on the safe side, you can create a snapshot of your host computer (virtual machine), which can be used to restore the system in no time at all.
Before we can update the server, the client application must first be updated. Since new versions are often associated with Adobe extensions, it is necessary that these are up to date. We strongly recommend doing a clean uninstall of the client for Windows and Mac.
We have two (basic) scripts, which will help you with this procedure.
In general we recommend to remove the extensions from Adobe's CEP & local user temp folder as on windows side to delete the local stream-engine.
The latest version of the client installer is part of the server update - if you want to get this in advance, don't hesitate to write us a ticket.
Since all clients are running the latest version, we can proceed with updating the server. This task is quite simple and straightforward.
The process for a cluster environment is almost identical to that for a standalone environment. The difference is that the update process must be triggered on the server where the portainer instance is running.
This can be identified quite easily - open port 9000 on all servers - if the machine is a slave, this message will be displayed in the stack.
The stack on the master has an additional "editor" tab, the configuration of which is as follows:
The server on which the current stack configuration is displayed is the one on which the update must be performed.
After the successful update, give the system one to two minutes to allow all containers to start. We also recommend that you clear the cache & cookies of the active web-browser, as this can lead to display/connection problems.
First, please open the debugger and run some standard streams such as connected, custom user or creating/opening projects. If these work without problems, this is proof that the update has been successfully completed.
As a next step, we recommend that you check all the streams and replace any deprecated nodes with the corresponding newer version.
This task will take some time, but it does not necessarily have to be done immediately - however, we suggest that it be done in the foreseeable future.
After these steps, we recommend creating a backup again and saving it. If the test system runs without problems for some time, the update can be safely installed on the production system.
The procedure here is the same - however, a time period outside the daily production cycle should be chosen for this.
