Upgrade a Container Gateway

This topic describes the process of upgrading your Container Gateway with a Helm Chart and how to update the Gateway image in the Helm Chart values.yaml file
gateway10cr2
2

Upgrading the Gateway Helm Chart

By default, the Helm Chart is configured for rolling updates as the strategy for replacing old pods with new ones, allowing for zero-downtime upgrades. In Kubernetes, updates are versioned and any deployment update can be reverted or rolled back to a previous (stable) version. Helm also supports version management.
You can learn more about rolling updates from Kubernetes documentation.
If you are planning to upgrade a major installation or significant reconfiguration of your Container Gateway, it's strongly recommended that you test the upgrade on a staging cluster before applying it to a production cluster. You may also want to consider backing up the Gateway database if it is hosted on an external MySQL server.
To upgrade an existing Gateway chart to a new version of the same chart, run the following Helm command:
$ helm upgrade <release name> --set-file "license.value=path/to/license.xml" --set "license.accept=true"
Ensure that the same parameters for the
helm upgrade
are the same as the initial
helm install
command that was used to deploy the Gateway. In this case, the
--set
parameter is passing values for two Gateway licensing-related parameters. See the Gateway Helm Chart repository for more details.
Protect Your Custom Chart Values When Upgrading the Gateway Chart
To ensure that any custom values you've tailored for your Gateway solution are NOT overwritten by an upgrade or deployment, specify the -f flag for Helm to reference your custom values .yaml file. For example:
$ helm upgrade <release name> -f mycustomvalues.yaml --set-file "license.value=LICENSE.xml" --set "license.accept=true"
Next, check to see whether the version of the running Gateway cluster has been upgraded by running the following command:
$ helm history gateway
The output should display the new revision of the Gateway cluster with a 'deployed' status:
REVISION UPDATED STATUS CHART DESCRIPTION 1 Fri Sep 18 13:05:00 2020 SUPERCEDED apigateway-10.0 Install complete 2 Mon Sep 21 10:30:15 2020 SUPERCEDED apigateway-10.0 Install complete 3 Mon Sep 21 11:56:10 2020 DEPLOYED apigateway-10.0 Upgrade complete
The Gateway Helm Chart (i.e., Gateway cluster) has been upgraded to the third revision.

Updating the Container Gateway Image from Docker Hub

3
3
This section describes the general instructions for updating the API Gateway image for the deployment of the Container Gateway in a PaaS environment. Before updating the Container Gateway image, ensure that you have the latest version of the supported container platform and Kubernetes in the API Gateway Docker Hub repository (caapim/gateway).
In order for Docker/Helm to automatically pull the desired version of the Gateway each time the container is started, the correct repository tag must be used. To ensure that you are using the correct tags, always refer to the Tags page from the Layer7 API Gateway Docker Hub page.
Where the Gateway Version is identified in the docker-compose.yml deployment file or the values.yaml file for Helm Chart deployments, there are two ways to ensure that you are pulling the latest or a specific version of the container image from Docker Hub.
Always Pulling the Latest Image
If your deployment process requires that the latest version of Gateway is always being pulled each time a Gateway container is run or built, you'll want to use the
latest
tag in the deployment file. See the Gateway Image Tags in Docker section on this page for further details and specific use cases.
version: '2.2' image: registry: docker.io repository: caapim/gateway tag: latest
Pulling a Specific Version of an Image
If you are looking to pull a specific version of the Container Gateway, insert the repository tag that reflects the desired version number. This is also known as pulling an image by its 'digest'. In the following example, the Gateway Helm Chart is instructed to pull version 10.0 with the
10.0.00
tag. See the Gateway Image Tags in Docker section on this page for further details and specific use cases.
version: '2.2' image: registry: docker.io repository: caapim/gateway tag: 10.0.00
Gateway Image Tags in Docker
At the release of a new container image, there are three Docker tags that are assigned to the container to identify it in relation to other Gateway containers.
Tag Type
Example
Latest
latest
Latest Version
10.0.00
Date-Stamped Version Tag
10.0.00_20190331
Early Access
earlyaccess
The Latest Tag
The latest tag, representing the most recent version of the container image that was released, will dynamically move to each newly released container image. When pulling the image using the latest tag, only the most recent version of the Gateway made available to the public will be pulled - any versions under development will not be made available via the latest tag. 
The Latest Version Tag
Similar to the latest tag, the latest version tag is also dynamic and reflects the latest build of a major version. For example, the
9.3.00
tag will move from one container to the latest container that houses the latest CR release (e.g., Version 9.3 CR1).
Date-Stamped Version Tag
Unlike the latest or latest version tags, the date-stamped version tag is static and is permanently assigned to each container release. This tag gives the container image its unique identity and is especially useful when the latest or latest version tag no longer applies. The format of the date stamp is YYYYMMDD (e.g.,
20190331
) and is appended to the version number in the tag (e.g., 10
.0.00_20190331
).
Early Access Tag
Represents a proof-of-concept version of the container image that is strictly used to evaluate new features and bug fixes in the Gateway. This version of the container image should NOT be used in a production environment. 
Database Upgrades Resulting from a Container Image Update
If you are connecting an external database such as MySQL to your Container Gateway, refer to this page to learn how upgrades to the database are handled by the Gateway container.