Requirements for upgrading from v2018.4.1.8 or later
Review the requirements for upgrading from Version 2018.4.1.8 or later.
- Verify the API Connect deployment is fully operational. See Checking cluster health on Kubernetes.
When upgrading to v2018.4.1.10 or later, this step is optional because a health check will be run automatically as part of the
apicup subsys installcommand. Note that you might still want to run the health check when preparing for the upgrade, to ensure the health of the backup image you must create prior to runningapicup subsys install. -
When upgrading API Connect, complete a manual backup of the management database, Portal subsystem, and Analytics subsystem just prior to starting the upgrade. Note that this backup is in addition to any scheduled backups that you have configured. The manual backup ensures that any data changes that occurred after the most recent scheduled backup are captured.
For details on creating a backup, see Backing up the management database in a Kubernetes environment, Backing up and restoring the Developer Portal and Backing up and restoring the analytics database.
- If not already set up, send your deployment logs to a remote server. The upgrade process terminates pods, and the logs will be lost if not stored remotely. To send your deployment logs to a remote server, see Configuring remote logging for a Kubernetes deployment.
- Helm version 2.8.2 or higher is required when upgrading API Connect in a Kubernetes environment.
- The same distribution file for each API Connect subsystem is used for either upgrades or fresh installations. For an example list of the files for Kubernetes upgrades, see First steps for installing API Connect: Upload files to registry.
- Download the Install Assist (APICUP) installer from the same URL where you download your Fix Pack version. You must use the latest Install Assist package with the latest product version.
- The original project directory created with the APICUP installer during the initial product installation (for example, myProject) is required to both restore the database and to upgrade your deployment. You cannot restore the database or perform an upgrade without the initial project directory because it contains pertinent information about the cluster. A good practice is to back up the original project directory to a location from which it can always be retrieved.
- If the upgrade is initiated from the original project directory, the certificates are automatically copied into the upgraded version. The original project directory contains the apiconnect-up.yml file. An upgrade using the same project directory as the one used for installation will transfer the encryption-secret and all other certificates for the project to the upgraded version.
- All external traffic to the management server must be blocked during the upgrade of the management subsystem. This restriction applies to traffic from all sources via the user interfaces (Cloud Manager, API Manager), CLI, and REST API. The Cloud Manager and API Manager UIs cannot be used during the upgrade of the management subsystem. The Developer Portal also cannot be used to create, update, or delete any applications, subscriptions, memberships, or consumer organizations during the time.
- The upgrade order for subsystems is important. Upgrade the subsystems in the
following order: (1) Management, (2) Analytics, (3) Portal, (4) Gateway. Analytics and Portal may be
switched between second or third, but Management must be upgraded first. Gateway must be upgraded
after Management for the following reasons:
- Upgrading the Management service before the Gateway ensures that any new policies and capabilities will be available to a previously registered Gateway service.
- After a completed upgrade, the Management server and Gateway firmware versions must match, for example, APIC 2018.4.1.2 with DP 2018.4.1.2.
- Downgrading any of the IBM® API Connect subsystems to an earlier fix pack level is not supported.