EUROTECHMulti-service IoT GatewaysDownloads
Support

Upgrade from 5.6

Suggest Edits

General recommendations

Be sure to read the Everyware Cloud release notes and the planning the upgrade section.

It's recommended to upgrade to the latest version of the 5.6.x release before moving to 5.7.

Preparing to upgrade

Before upgrading to a patch release be sure to follow these steps:

  • backup the databases
  • backup your existing configuration exporting all project configurations

Upgrade steps

🚧

This version of Everyware Cloud deprecates the OpenShift templates and introduces Helm Charts to manage the various configurations of the components also on OpenShift.

The process to upgrade Everyware Cloud is the following:

  • create a new secrets ec-credentials-transport and ec-credentials-cache as described in Using Helm Charts page
  • add a new label to the namespace. This is used for new features present in version 5.7. The label is namespace is the name of the namespace itself.
# For Kubernetes
kubectl label namespaces everyware-cloud name=everyware-cloud

# For OpenShift
oc label namespaces everyware-cloud name=everyware-cloud
  • edit the certificate secret adding a new key full, containing the full certificate chain (certificate + certificate authority chain) encoded in base64
  • migrate from OpenShift templates to Helm Charts for OpenShift installations. This is described more in detail in the following section Migration from OpenShift Templates to Helm Charts.
  • edit the charts' property files changing the image version for Everyware Cloud
  • edit the charts' property files enabling schema updates in the common EC configurations
  • upgrade the common EC configurations using Helm
helm upgrade -n everyware-cloud -f ec-configs.yaml ec-configs charts/01-prerequisites/ec-configs
  • upgrade the standard EC components using Helm
# Deploy the Events Broker
helm upgrade -n everyware-cloud -f ec-events-broker.yaml ec-events-broker charts/02-components/ec-events-broker

# Deploy the Message Broker
helm upgrade -n everyware-cloud -f ec-broker.yaml ec-broker charts/02-components/ec-broker

# Deploy the RESTful API
helm upgrade -n everyware-cloud -f ec-api.yaml ec-apicharts/02-components/ec-api

# Deploy the Web Console
helm upgrade -n everyware-cloud -f ec-console.yaml ec-console charts/02-components/ec-console
  • upgrade the optional EC components using Helm
# Upgrade the VPN Service if installed
helm upgrade -n everyware-cloud -f ec-vpn.yaml ec-vpn charts/02-components/ec-vpn

# Upgrade the Monitoring Service if installed
helm upgrade -n everyware-cloud -f ec-vpn.yaml ec-vpn charts/02-components/ec-vpn
  • edit the charts' property files disabling schema updates in the common EC configurations
  • upgrade the common EC configurations using Helm
helm upgrade -n everyware-cloud -f ec-configs.yaml ec-configs charts/01-prerequisites/ec-configs

Migration from OpenShift Templates to Helm Charts

The migration from OpenShift Template to Helm charts requires a few steps that need to be followed in the correct order. Doing so will ensure minimum downtime of Everyware Cloud.

Firstly migrate the common configurations. Create a new property file for ec-configs containing the correct overrides for your environment. More details can be found in the Using Helm Charts section. Once this has been done, import the existent ConfigMap and run the Chart. For the second label use the name of the namespace where the resources are configured.

oc annotate cm ec-configs meta.helm.sh/release-name=ec-configs
oc annotate cm ec-configs meta.helm.sh/release-namespace=everyware-cloud

oc label cm ec-configs app.kubernetes.io/managed-by=Helm

helm install -n everyware-cloud -f ec-configs.yaml ec-configs charts/01-prerequisites/ec-configs

Repeat the same operation for the rest of the standard EC components. The following snippet contains the commands for the RESTful APIs. The command is the same for the other components, just replace ec-events-broker with ec-api, ec-broker and ec-console. These commands will import the OpenShift Services and replace the DeploymentConfigs. This will cause the disconnection of the devices from the brokers and a small downtime for the various components. Every IP/LoadBalancer associated to the Services will be kept.

oc annotate svc ec-events-broker meta.helm.sh/release-name=ec-events-broker
oc annotate svc ec-events-broker meta.helm.sh/release-namespace=everyware-cloud

oc label svc ec-events-broker app.kubernetes.io/managed-by=Helm

oc delete dc ec-events-broker

helm install -n everyware-cloud -f ec-events-broker.yaml ec-events-broker charts/02-components/ec-events-broker

Finally repeat the same operation for the optional components ec-vpn and ec-monitoring if installed.

Rollback

In case of problems with the upgraded version it's possible to revert to a previous version.

The steps for the rollback are the following:

  • stop all the services scaling down the deployments to 0
  • restore the databases to the backed-up version
  • change the version of the docker images to the previous one
  • start the services scaling up the deployments to 1 and then, once the service is available again, to the original number of pods. Follow the order described in the planning section.

Updated over 3 years ago