Skip to content

Patching a Platform

Introduction

Key ideas:

  • Responsibility: The owner of the platform is responsible for patching the platform.
  • Downtime: During patching, there is no specific downtime. Only restart channels or tasks.
  • Impact on the service: The monitoring component has to be restarted, so you have to discard supervision monitoring during the migration.
  • Rollback: Very easy, remove patches. Must be taken less than 5 min.

Procedure

STEP 0 - Check platform

1 . Check the version of the platform:

1
2
3
4
5
# Go to an operator device and type
$ punchplatform-version.sh
# You must have this kind of output:
 PunchPlatform package:
 punchplatform-operator-environment-[dataanalytics-]X.Y.Z

2 . Check if patch exists on the platform:

It's a key point to check! Go to an operator servers and check the existence of the directory.

Usually, it is located at /data/opt/punchplatform-operator-environment-[dataanalytics-]X.Y.Z

If patch exists (ie patch directory), check the release notes of the version and verify the bug has been fixed in the new release. If a doubt subsists, please contact support@punchplatform.com

3 . Check the platform status

  • All must be green in Punchplatform Monitoring dashboard
  • Nagios (or other monitoring components) must be all OK (especially with the System, storage, memory, CPU).

At this point, you must have a strong picture of the platform (version, patch, system status). If you have question or doubt, please contact the N3 support).

STEP 1 - Preparation

0) Download patch jar

The punchplatform support team provides patch by the punchplatform website. Just download the jar.

1) Update the deployer package

Create a dedicated path for the component to patch

For operator:

1
2
$ cd <deployer_path>
$ mkdir archives/patch/operator-environment

For shiva:

1
2
$ cd <deployer_path>
$ mkdir archives/patch/shiva

Then copy the jar to this path.

2) Create a git tag before patching

Always on the deployment device, go to $PUNCHPLATFORM_CONF_DIR and tag the version

1
2
3
4
$ cd $PUNCHPLATFORM_CONF_DIR
$ git pull
$ git tag -a v<CURRENT_VERSION> -m "before migrate to <NEW_VERSION>"
$ git push --tags

3) Generate the deployment configuration

The deployer has the capacity to generate inventories and variables use by ansible to deploy punchplatform components. Testing the generation of these files has no impact of the running platform : it's only on local.

1
$ punchplatform-deployer.sh -g

If errors, please check the punchplatform.properties and punchplatform-deployment.settings configuration, THEN contact the N3 support.

5) Commit you first changes

Push the new configuration - no impact on the running platform !

1
$ git push

6) Notice of intervention communication

The nexts step has an impact on the running platform. It's crucial to contact / communicate to all stakeholders before continue !

STEP 2 - Deployment

1) Punchplatform deployment

At this step, no running component will be impacted ! Only monitoring component will restart. You still have the capacity to stop/start/reload component with the current version of the platform. In other words: the impact of this deployment is low.

For operator:

1
$ punchplatform-deployer.sh deploy -Kk -t patch [-l punchplatform_operator_servers]

For shiva:

1
$ punchplatform-deployer.sh deploy -Kk -t patch [-l shiva_servers]

2) Test the new operator environment version

At this step, we are going to test the new version of the operator environment.

1
2
3
# ssh (again)
$ punchplatform-channel.sh --stop <tenant>/<channel>
$ punchplatform-channel.sh --start <tenant>/<channel>

After these commands, check:

  • first: the command must prints
  • second: the behaviour of the channel: Rate, Fails, Content of the logs in Elasticsearch, in the SIEM etc...
  • third: check the monitoring status.

Tip

If errors appears, no panic! Rollback your environment with the old deployer (rollback deployment environment variable and redeploy operators )

STEP 3 - After migration

1) Tag the end of migration

From the operator device:

1
2
3
4
$ cd $PUNCHPLATFORM_CONF_DIR
$ git pull
$ git tag -a v<NEW_VERSION> -m "end of migration to <NEW_VERSION>"
$ git push --tags

2) Notice of intervention communication

Announce the end of the migration to all stakeholders

3) Check again the behaviour of the platform ;)

Rollback procedure

CASE 1: there was no patch before this procedure:

Remove the patch directory:

1
$ punchplatform-deployer.sh ssh punchplatform_operator_servers "rm -rf {{install_root}}/{{punchplatform_operator_environment_version}}/patch"

CASE 2: there was patches previously:

First Remove the patch directory:

1
$ punchplatform-deployer.sh ssh punchplatform_operator_servers "rm -rf {{install_root}}/{{punchplatform_operator_environment_version}}/patch"

Second update patch directory on the deployment device and redeploy patches:

1
$ punchplatform-deployer.sh deploy -Kk -t patch [-l punchplatform_operator_servers]