Operating - installing and maintaining - Oracle Fusion Middleware, especially Oracle SOA Suite 12.2.1.4 is quite some work. Not only does installation itself consist of a number of steps, but each quarterly critical patch update also requires applying a number of patches and - especially in simple, single server environments quite some downtime.
This blog post series will cover how to run Oracle Fusion Middleware - especially Oracle SOA Suite on docker. The first post covered the high-level steps of manual installation, Docker and Kubernetes options and has pointers to the relevant Oracle certification documentation. The second post then described how - using OCI and Oracle Linux - a host to run docker containers can be setup up within minutes. After that in the third post we covered provisioning an Oracle Database instance to hold the meta data of Oracle SOA Suite. Next up were in the 4th and 5th episode all the details on provisioning and configuring SOA Suite itself - especially the metadata repository in the database created previously as well as the SOA Suite domain.
In this final episode we will cover patching options for the environment.
Patching to latest SOA Suite image
Patching to the latest SOA Suite CPU is straightforward and fast. Let’s walk through this step by step. In this example we start with a SOA Suite instance on the January CPU level:
[root@docker-test ~]# docker image ls container-registry.oracle.com/middleware/soasuite_cpu REPOSITORY TAG IMAGE ID CREATED SIZE container-registry.oracle.com/middleware/soasuite_cpu 12.2.1.4-jdk8-ol7-240117 7d72a1d5c81f 6 months ago 4.6GB
List of available versions; we see a later one that 240117 here
To upgrade this to the latest version (at the point of this screenshot the April CPU), simply pull the latest image:
docker pull container-registry.oracle.com/middleware/soasuite_cpu:12.2.1.4-jdk8-ol7-240430
Newly pulled soasuite image
Then stop the existing instance and just start it again:
docker stop soams1 docker stop soaadmin1 docker run -d --rm --name soaadmin1 --network soanet1 -v soa1_userprojects:/u01/oracle/user_projects -p 7001:7001 --env-file ./adminserver.env container-registry.oracle.com/middleware/soasuite_cpu:12.2.1.4-jdk8-ol7-240430 docker run -d --rm --name soams1 --network soanet1 -v soa1_userprojects:/u01/oracle/user_projects -p 8001:8001 --env-file ./soa_server1.env container-registry.oracle.com/middleware/soasuite_cpu:12.2.1.4-jdk8-ol7-240430 "/u01/oracle/container-scripts/startMS.sh"
And there you go; the latest CPU is applied (on all parts of FMW/SOA):
April 2024 CPU being applied with 10 minutes of work and 3 minutes of downtime
Doing this manually is a multi-hour effort; just pulling the latest container image brings this down to 10 minutes with just 5 minutes of downtime.
Obviously, it makes sense to doublecheck the release notes of the latest CPU patches if any pre- or post-patching steps are required. But in most cases this such steps are not necessary.
Applying custom patches
In many real-world scenarios additional (one-off) patches have to be applied. If you want to for example connect to Office 365 for UMS E-Mails (see here) you may want to apply patch 35773019. Let’s see how this can be achieved using the weblogic image tool.
Get the latest version of the WebLogic Image tool from here: https://github.com/oracle/weblogic-image-tool/releases and thus install as follows:
wget https://github.com/oracle/weblogic-image-tool/releases/download/release-1.13.2/imagetool.zip unzip imagetool.zip yum install jdk-17 # minimum of Java8 export JAVA_HOME=/usr/java/jdk-17.0.5/ imagetool/bin/imagetool.sh update --fromImage container-registry.oracle.com/middleware/soasuite_cpu:12.2.1.4-jdk8-ol7-240430 --tag soasuite_jm --patches 35773019 --user johannes.michler@promatis.de --password
Creating custom image with One-Off patch
As you can see it took just 30 seconds to download all the relevant patches, apply them and build a custom image including the patch. That image can then be started in the regular way:
One-Off patch is applied, Office365 here we go
You might consider to push this image to your own container registry (e.g. on OCI) after creating the image on a testing environment to make sure that you run the exactly same image everywhere.
Summary
This concludes this blog series on running Oracle SOA Suite on docker. As has been shown, using docker greatly simplifies management of the environment and especially makes patching both faster and more reliable.
In another soon to be published blog series I’ll cover an option to run Oracle SOA Suite without a “pre-paid” license by subscribing to a SOA Suite license through the Oracle Cloud Marketplace. So, stay tuned.