You can upgrade Twistlock without losing any of your data or configurations. After upgrading Console, upgrade your Defenders from the Console user interface.
Before upgrading, check the Breaking changes section in the release notes to see if there are any special instructions or requirements. |
If you’ve continually upgraded Twistlock from version 2.4 or older, and you’re now upgrading from version 18.11 to 19.03, you must run a manual step before upgrading. |
You can upgrade from an immediate previous major version only. If your installation is more than one major release behind, you must upgrade in steps. For example, you cannot directly upgrade from version 18.11 to 19.07. You would have to upgrade from version 18.11 to 19.03, and then from 19.03 to 19.07.
Console notifies you when new versions of Twistlock are available. Notifications are displayed in the top right corner of the dashboard.
The currently installed version of Console is displayed in the lower left corner of the user interface.
The versions of your deployed Defenders are listed in Console under Manage > *Defenders:
Upgrade Console first, then upgrade your Defenders.
When you upgrade, your old Twistlock containers are completely replaced with new Twistlock containers. Because Twistlock stores state information outside of the container runtime, all your rules and other configuration settings are immediately available to the upgraded Twistlock containers.
Twistlock state information is stored in a database in the location specified by DATA_FOLDER, which is defined in twistlock.cfg. By default, the database is located in /var/lib/twistlock.
When you have one or more tenant or scale Projects, upgrade all Supervisors before upgrading the Central Console. During the upgrade process, there may be periods where the Supervisors appear as disconnected. This is normal, because the Supervisors are disconnected while the upgrade is occuring and Central Console will recheck connectivity every 10 minutes. Within 10 minutes of upgrading all Supervisors and the Central Console, all Supervisors should appear healthy.
Upgrade each Supervisor and then the Central Console using the appropriate procedure:
If Console is deployed in a High Availability set, remove Console from all secondary nodes, upgrade Console on the primary node, then redeploy Console to all secondary nodes.
Open Console.
Go to Manage > System > High Availability to see a list of all HA nodes.
Delete all secondary nodes using the 'X' button.
SSH to each secondary node and completely remove Twistlock using twistlock.sh Typically, these instances will still have a copy of twistlock.sh from the inital install. If not, download the release to the node to get a copy.
To remove Console, run the following command:
sudo ./twistlock.sh -u
Upgrade the primary Console using the steps in Console - Onebox.
Follow the guide for installing secondary High Availability nodes starting at step 2.
After upgrading Console, upgrade all your Defenders. Log into Console and go to Manage > Defenders > Manage to see all your deployed Defenders.
In order for Defender to be fully operational, its version must exactly match Console’s version. If Defender is an earlier version, it continues to protect your node using the policy most recently cached before upgrading Console. It can still emit to local logs, including syslog. However, it cannot access any API endpoint other than the upgrade endpoint, and it cannot share new data with Console. When Defender is in this state, its status is shown as 'Upgrade needed' in Manage > Defenders > Manage.
Although Defenders appear to be upgradable from the Console UI, it won’t work. Use the appropriate procedure to properly upgrade them. |