Perform a Minor Migration¶
- Responsibility: The owner of the platform is responsible for migrate the platform.
- Downtime: During minor migration, 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, patch two environment variable and redeploy. Must be taken 10 min.
STEP 0 - PLATFORM CHECK¶
1) Check the version of the platform:
# 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
If patch exists, check the release notes of the version and verify the bug has been fixed in the new release. If a doubt subsists, please contact email@example.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¶
1) Update environment
On the deployment device (usually Ansible), update your environment variable.
comment the old one, to rollback easily if necessary
$ vim ~/.bashrc export PUNCHPLATFORM_LOG_DIR=/data2/deployer/logs export PUNCHPLATFORM_CONF_DIR=/data2/deployer/live-demo-pp-conf #export PATH=/data2/deployer/punchplatform-deployer-<CURRENT_VERSION>/bin:/home/loic/bin:/home/loic/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin export PATH=/data2/deployer/punchplatform-deployer-<NEW_VERSION>/bin:/home/loic/bin:/home/loic/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
Then, refresh your variable:
exit ssh (again)
2) Create a git tag before migration
Always on the deployment device, go to $PUNCHPLATFORM_CONF_DIR and tag the version
$ cd $PUNCHPLATFORM_CONF_DIR $ git pull $ git tag -a v<CURRENT_VERSION> -m "before migrate to <NEW_VERSION>" $ git push --tags
3) Update configuration
Get the version of the operator-environment :
# go to archives directory in deployer $ ls |grep operator-environment # get the operator-environment version
Then, update the punchplatform-deployment.settings with the previous versions found:
"punchplatform_operator_environment_version" : "punchplatform-operator-environment-[dataanalytics-]<version>",
Then, check the breaking changes in documentation (if exists) to update configuration.
4) 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.
$ punchplatform-deployer.sh --generate-inventory
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 !
$ git push
6) Notice of intervention communication
The next step has an impact on the running platform. It's crucial to contact / communicate to all stakeholders before continue !
STEP 2 - DEPLOYMENT¶
1) Punchplatform Operator 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.
$ punchplatform-deployer.sh --deploy -Kk -t operator -l punchplatform_operator_servers
2) Test the new operator environment version
At this step, we are going to test the new version of the operator environment.
# ssh (again) channelctl stop --channel <channel> channelctl start --channel <channel>
After these commands, check:
- first: the behaviour of the channel: Rate, Fails, Content of the logs in Elasticsearch, in the SIEM etc...
- second: check the monitoring status.
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:
$ 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 ;)