3 Oracle Banking Microservices Architecture Products Deployment Approaches
This topic describes about the various approaches to deploy the Oracle Banking Microservices Architecture products.
- Containerization of the Services Using Tomcat
This topic describes about the various methods that can be used to containerize a service in the Oracle Banking Microservices Architecture Product stack. - Containerization of the Services Using WebLogic
This topic describes about the various options to build the service containers using Oracle Weblogic images. - Deploying Services without Docker Images
This topic describes about the process to deploy product services without Docker images. - Deploying Services on Private Cloud using Docker Images
This topic describes about the process to deploy the services on private cloud using docker images.
3.1 Containerization of the Services Using Tomcat
This topic describes about the various methods that can be used to containerize a service in the Oracle Banking Microservices Architecture Product stack.
- Using Jib Plugin and Tomcat Image
This topic provides the systematic instructions to create the Docker image using Jib Plugin and Tomcat image. - Pipeline Integration in Jenkins
This topic describes about the pipeline integration in Jenkins. - Using War Artifacts Delivered in OSDC
This topic describes about the usage of War Artifacts delivered in OSDC.
3.1.1 Using Jib Plugin and Tomcat Image
This topic provides the systematic instructions to create the Docker image using Jib Plugin and Tomcat image.
This approach uses the google Jib plugin to integrate the creation of Docker images along with gradle build. This approach can be used to create Docker images of components where the consulting or customer teams have access to code generated using the Oracle Banking Microservices Architecture Extensibility framework.
Parent topic: Containerization of the Services Using Tomcat
3.1.2 Pipeline Integration in Jenkins
This topic describes about the pipeline integration in Jenkins.
The Docker image creation using Jib plugin can be automated in the Continuous Integration pipeline. The Continuous Integration pipeline is used to run automated tasks that build a source code at preconfigure intervals to enable build automation for an application. The Jenkins Pipeline can be enhanced to support the automated deployment of Docker images in a Continuous Deployment pipeline.
Prerequisites
Before proceeding, make sure that the below installations and configurations are done.
- Jenkins installation
- Docker engine installation on Jenkins VM
- Network connectivity between docker registry and Jenkins VM
- Gradle plugin for Jenkins installation
- CredHelper Configuration
Automated Build – Continuous Integration
The gradel build step should be added as a stage in Jenkins to trigger the automated build for a service. This results in the image being created and pushed to the mentioned Docker registry.
stage('Build and Publish Docker Image') {
steps {
script {
/* provide the Dockerfile and the context of the build which is the directory which contains the Dockerfile */
def image = docker.build( docker_image_name, "-f " + dockerfile_path + "/Dockerfile " + dockerfile_path)
/* once the image is complete, this runs the image and you can verify if the image is correct by adding tests */
image.inside {
sh 'echo "Put Tests for your new image here"'
}
/* Replace the docker repo with your repo and the login with a cre-dential in
your Jenkins that has permission to push to your docker repo */
docker.withRegistry('https://' + docker_registry + '/v2/', docker_registry_login)
{
image.push(docker_image_version)
}
}
}
}
Automated Deployment – Continuous Deployment
This topic describes about automated deployment for Continuous Deployment.
The codes used to auto-deploy an image on a VM with a vanilla Docker installation is detailed in the below Jenkins file.
def docker_image_name = "<image_name:image_version>"
def remote = [:]
remote.name = "dkx"
remote.host = "<docker_hostname>"
remote.allowAnyHosts = true
remote.user = "<username>"
remote.password = "<passwd>"
stage('Login to remote box') {
steps {
withCredentials([usernamePassword(credentialsId: 'sshUserAcct',
passwordVariable: 'password', usernameVariable: 'userName')]) {
sshCommand remote: remote, command: 'docker pull
<docker_registry_name>/' + docker_image_name
sshCommand remote: remote, command: 'docker run -d -p 80:8080
<docker_registry_name>/' + docker_image_name
}
}
}
Parent topic: Containerization of the Services Using Tomcat
3.1.3 Using War Artifacts Delivered in OSDC
This topic describes about the usage of War Artifacts delivered in OSDC.
This approach used if a consulting or partner installation team does not have access to the source code service and need to containerize product applications. This approach uses war files shipped under the Product Installer in the OSDC portal. This topic describes the individual steps to create docker images for each service.
Prerequisites
Before proceeding, make sure that the below steps are done.
- Make sure that the Docker Engine is up and running on the VM to perform the following operations.
- Make sure that the Proxy setting in
/etc/environment
file is updated using root permissions.
Create Docker file in Tomcat
Create a sample Docker file as follows:
- Create a separate directory structure for each service.
$mkdir <service_name>/docker
$cd <service_name>/docker
- Copy the service's war file from the installer to the path
<service_name>/docker
.$cp <service_name>.war <service_name>/docker/
- Create a Docker file in the docker directory for the service.
$vi Dockerfile
Note:
Services Dockerfile should have "tomcat:<tag_name>" as a base image.FROM tomcat:<tag>
- Pass the appropriate build arguments to docker.
# application_context - This value represents the context root of the Plato application. This value must be passed as an argument in the docker file.ARG application_context=<application context name> ARG war_file_name=<microservices war file name> ARG shutdown_port=<tomcat server shutdown port value> ARG http_port=<tomcat server http port value> ARG redirect_port=<tomcat server redirect port value> ARG ajp_port=<tomcat server redirect port value>
# war_file_name - This value represents the name of the war file of the application that is present in the local system where the docker image is being built
# shutdown_port - This value represents the shutdown port in the Tomcat server.
# http_port - This value represents the HTTP port on which the application will be available for accessing via REST API.
# redirect_port - This value represents the redirect port in the Tomcat server.
# ajp_port - This value represents the AJP port in the Tomcat server.Note:
The port values are not mandatory to give in case the docker image is getting built for deployment in Kubernetes but it is mandatory in case of docker-compose because the container port values should unique for the same. The port values are not passed/mentioned in the Docker file then the default will be used for while building the image. - Expose the container
http_port
EXPOSE <http_port>
- The completed services's Docker file is shown below.
ARG application_context=plato-discovery-service ARG war_file_name=plato-discovery-service-1.0.3.war ARG shutdown_port=5008 ARG http_port=5005 ARG redirect_port=5007 ARG ajp_port=5006
COPY plato-discovery-service-1.0.3.war /usr/local/tomcat/webapps/
EXPOSE 5005
CMD["catalina.sh", "run"]
Test the Docker Image
- Run the Docker image using the below option:
docker run -d -p 80:8080 <docker_registry_name>/<image_name:image_version>
- To pass env variable to your service use the below options:
docker run -d -p <port> -v <Host Path>:/opt/logs/ <image> -e ds_jndi_1=jdbc/PLATO
ds_db_host_1=<DBHOST> ds_db_port_1=<DB_HOST_PORT> ds_db_serviceid_1=<SID>
ds_db_username_1=<USERNAME> ds_db_password_1=<PASSWORD>
docker run -d -v <Host Path>:/opt/logs/ --env-file <file> <image>
Parent topic: Containerization of the Services Using Tomcat
3.2 Containerization of the Services Using WebLogic
This topic describes about the various options to build the service containers using Oracle Weblogic images.
- Using Pre-Built WebLogic Images
This topic describes about the steps to deploy the services on a WebLogic Server running in a Docker container. - Run WebLogic Containers Using WebLogic Kubernetes Operator
This topic describes the process to run WebLogic containers using WebLogic Kubernetes operator.
3.2.1 Using Pre-Built WebLogic Images
This topic describes about the steps to deploy the services on a WebLogic Server running in a Docker container.
Prerequisites
Before proceeding, make sure that the below steps are completed.
- Make sure that the proxy settings is verified on the VM where Weblogic image need to run.
- Make sure that the user is logged in to the Oracle Container Registry portal, and accept the license agreements before pulling the Docker images.
- Sudo access to the VM to run commands as root.
Create a file domain.properties with
username=""
andpassword=""
.
Pull the WebLogic Docker Image
docker pull container-registry.oracle.com/middleware/weblogic:12.2.1.4
Run the WebLogic Image
docker run -d -p 7002:7001 -p 9004:9002 -v $PWD:/u01/oracle/properties
container-registry.oracle.com/middleware/weblogic:12.2.1.3
Deploy the Application
Access the console at <hostname>:9004/console
with admin credentials and deploy the service.
Create Domains in WebLogic and Deploy the Applications
Deploy the application in custom domains. For information on deploying applications, refer to the below documentation:
https://github.com/oracle/docker-images/tree/main/OracleWebLogic/samples/12213-domain-home-in-image
Parent topic: Containerization of the Services Using WebLogic
3.2.2 Run WebLogic Containers Using WebLogic Kubernetes Operator
This topic describes the process to run WebLogic containers using WebLogic Kubernetes operator.
Prerequisites
- Docker engine installation
- Kubernetes cluster
- Access to Kubernetes operator
Install and Manage WebLogic Domains using Kubernetes Operator
An operator is an application-specific controller that extends Kubernetes to create, configure, and manage instances of complex applications. The Oracle WebLogic Server Kubernetes Operator simplifies the management and operation of WebLogic domains and deployments.
For information on installation and management of weblogic domains, refer to https://oracle.github.io/weblogic-kubernetes-operator/.
Parent topic: Containerization of the Services Using WebLogic
3.3 Deploying Services without Docker Images
This topic describes about the process to deploy product services without Docker images.
- Deploying Applications to Tomcat without Docker Images
This topic describes about the process to deploy the applications to Tomcat without docker images. - Deploying Applications to WebLogic without Docker Images
This topic describes about the process to deploy the applications to WebLogic without docker images.
3.3.1 Deploying Applications to Tomcat without Docker Images
This topic describes about the process to deploy the applications to Tomcat without docker images.
Prerequisites
Make sure that the below installation is done.
- Tomcat installation
- Jenkins installation
Manual deployment
- Download and place the individual war files for services in a common directory.
- Follow the steps in the below link to deploy the individual service wars.
https://tomcat.apache.org/tomcat-10.0-doc/deployer-howto.html
Deployment using scripts
Alternatively, the war files can be configured to be deployed using a Jenkins pipeline. The deploy to container plugin should be used for configuration.
Parent topic: Deploying Services without Docker Images
3.3.2 Deploying Applications to WebLogic without Docker Images
This topic describes about the process to deploy the applications to WebLogic without docker images.
Prerequisites
Make sure that the below installation is done.
- WebLogic installation
- Jenkins installation
Manual Deployment
Perform the following steps:
- Download and place the individual war files for services in a common directory.
- Follow the steps in the below link to deploy the individual service wars.
https://docs.oracle.com/cd/E19424-01/820-4807/war-weblogic/index.html
Deployment using Jenkins
Alternatively, the war files can be configured to be deployed using a Jenkins pipeline. The Deploy WebLogic should be used for configuration. It is recommended to see if the version of the plugin has any vulnerabilities.
Parent topic: Deploying Services without Docker Images
3.4 Deploying Services on Private Cloud using Docker Images
This topic describes about the process to deploy the services on private cloud using docker images.
When deploying the services on Docker image in the private cloud, it is important to build custom images of WebLogic and Tomcat using openjdk 8
unless the appropriate license requirements are met with the built jdk versions in WebLogic.
For WebLogic, refer to https://github.com/oracle/docker-images/tree/main/OracleWebLogic and follow the steps to build the base WebLogic images.
For Tomcat, refer to https://hub.docker.com/_/tomcat and follow the steps to build the base tomcat images.
The pre-built OpenJDK 8 image is available in this link.