OPatch one server at a time
{{page.title}}
In this article we want to explore how to automate using OPatch against one server at a time.
In this use case, we will do the following:
Redirect all traffic to node 1
Take node 2 out of the domain
Upgrade node 2 to OSB BP 5
Redirect all traffic to node 2
Verify working of upgraded node 2
Upgrade node 1 to OSB BP 5
Put node 1 and 2 back into the domain
Redirect traffic to both nodes
Example: Upgrading OSB to Bundle Patch 5 using a rolling restart approach
One Time Configuration Steps
After establishing the MyST workspace integrated with MyST Studio using the steps detailed here, execute the MyST properties action on the platform model of your choice by performing the following:
Take note of the unique server logical IDs, you will use these later to specific the rolling in a sequence of your choice. In the example below, which is a 2 node OSB cluster, we have osb.server1 and osb.server2
Also, take note of the unique node logical IDs for each OSB node. These are defined as a comma-separated list under product.osb.node-list. In our example, lets assume the nodes are called node1 and node2.
Create the Jenkins job to orchestrate the MyST patching with rolling restarts
Jenkins is a CI server which allows for orchestrating multiple steps in a single job which can be executed on demand or as part of a schedule. The same principles would apply for setting up an orchestration in another CI server or dashboard such as Rundeck. In the example below it is assumed that MyST is installed under /opt/myst on the master (or slave) where the Jenkins job is being run under.
1 . From the Jenkins console, click on "New Item"
2 . Create a "Freestyle project"
NOTE: Alternatively, you can use the MyST CLI plugin for Jenkins. In order to provide instructions that would be compatible for other CI server and orchestration tools, we are going to use the generic "Execute shell" option in our example.
5 . Under "Execute shell", enter your desired patching sequence. An example matching the use case described at the start of this document is listed below. In this example, osb.server1 and osb.server2 are on node1 and osb.server3 and osb.server4 are on node2
Placeholders have been left in the script above for automated tests and interaction with the load balancer for redirects. If the load balancer interactions are intended to be manual, you may wish to split the above up into multiple CI jobs which are triggered at the appropriate times after each manual load balancer configuration step. This same approach could also be done with MyST Studio alone and no CI server required as detailed in the section "Alternative Approach: Applying the patch and rolling restart exclusively with MyST Studio"
6 . Save the job
Orchestrating a fully-automated patch rolling restart from Jenkins using MyST
This part is simple, just go to the job in Jenkins and click the run button when you want to perform the fully-automated patch rolling restart.
Alternative Approach: Applying the patch and rolling restart directly with MyST Studio as individual steps
If you need to perform manual steps during the process such as redirecting the load balancer or running manually sanity checks, the Jenkins approach would not be ideal. In this case, you can simply perform the operations directly from MyST Studio as required as part of the overall manual sequence.
For example, you could run the "Update" operation to apply the patch using the out-of-the-box feature in MyST Studio. Then when it comes to restarting certain nodes, you could use the "Control" operation to run the actions such as stop-via-as and start-via-as with the given overrides.
Last updated
