The SOA deployment scripts demonstrate the creation of an Oracle SOA Suite domain home on an existing Kubernetes persistent volume (PV) and persistent volume claim (PVC). The scripts also generate the domain YAML file, which can then be used to start the Kubernetes artifacts of the corresponding domain.
Before you begin, complete the following steps:
The sample scripts for Oracle SOA Suite domain deployment are available at ${WORKDIR}/weblogic-kubernetes-operator/kubernetes/samples/scripts/create-soa-domain
.
You must edit create-domain-inputs.yaml
(or a copy of it) to provide the details for your domain.
Refer to the configuration parameters below to understand the information that you must
provide in this file.
The following parameters can be provided in the inputs file.
Parameter | Definition | Default |
---|---|---|
sslEnabled |
Boolean indicating whether to enable SSL for each WebLogic Server instance. | false |
adminPort |
Port number for the Administration Server inside the Kubernetes cluster. | 7001 |
adminServerSSLPort |
SSL port number of the Administration Server inside the Kubernetes cluster. | 7002 |
adminNodePort |
Port number of the Administration Server outside the Kubernetes cluster. | 30701 |
adminServerName |
Name of the Administration Server. | AdminServer |
clusterName |
Name of the WebLogic cluster instance to generate for the domain. By default the cluster name is soa_cluster for the SOA domain type. You can update this to osb_cluster for an OSB domain type or soa_cluster for SOAESS or SOAOSB or SOAESSOSB domain types. |
soa_cluster |
configuredManagedServerCount |
Number of Managed Server instances to generate for the domain. | 5 |
createDomainFilesDir |
Directory on the host machine to locate all the files to create a WebLogic domain, including the script that is specified in the createDomainScriptName property. By default, this directory is set to the relative path wlst , and the create script will use the built-in WLST offline scripts in the wlst directory to create the WebLogic domain. An absolute path is also supported to point to an arbitrary directory in the file system. The built-in scripts can be replaced by the user-provided scripts as long as those files are in the specified directory. Files in this directory are put into a Kubernetes config map, which in turn is mounted to the createDomainScriptsMountPath , so that the Kubernetes pod can use the scripts and supporting files to create a domain home. |
wlst |
createDomainScriptsMountPath |
Mount path where the create domain scripts are located inside a pod. The create-domain.sh script creates a Kubernetes job to run the script (specified in the createDomainScriptName property) in a Kubernetes pod to create a domain home. Files in the createDomainFilesDir directory are mounted to this location in the pod, so that the Kubernetes pod can use the scripts and supporting files to create a domain home. |
/u01/weblogic |
createDomainScriptName |
Script that the create domain script uses to create a WebLogic domain. The create-domain.sh script creates a Kubernetes job to run this script to create a domain home. The script is located in the in-pod directory that is specified in the createDomainScriptsMountPath property. If you need to provide your own scripts to create the domain home, instead of using the built-it scripts, you must use this property to set the name of the script that you want the create domain job to run. |
create-domain-job.sh |
domainHome |
Home directory of the SOA domain. If not specified, the value is derived from the domainUID as /shared/domains/<domainUID> . |
/u01/oracle/user_projects/domains/soainfra |
domainPVMountPath |
Mount path of the domain persistent volume. | /u01/oracle/user_projects |
domainUID |
Unique ID that will be used to identify this particular domain. Used as the name of the generated WebLogic domain as well as the name of the Kubernetes domain resource. This ID must be unique across all domains in a Kubernetes cluster. This ID cannot contain any character that is not valid in a Kubernetes service name. | soainfra |
domainType |
Type of the domain. Mandatory input for Oracle SOA Suite domains. You must provide one of the supported domain type values: soa (deploys a SOA domain),osb (deploys an OSB (Oracle Service Bus) domain),soaess (deploys a SOA domain with Enterprise Scheduler (ESS)),soaosb (deploys a domain with SOA and OSB), and soaessosb (deploys a domain with SOA, OSB, and ESS). |
soa |
exposeAdminNodePort |
Boolean indicating if the Administration Server is exposed outside of the Kubernetes cluster. | false |
exposeAdminT3Channel |
Boolean indicating if the T3 administrative channel is exposed outside the Kubernetes cluster. | false |
httpAccessLogInLogHome |
Boolean indicating if server HTTP access log files should be written to the same directory as logHome . Otherwise, server HTTP access log files will be written to the directory specified in the WebLogic domain home configuration. |
true |
image |
SOA Suite Docker image. The operator requires Oracle SOA Suite 12.2.1.4. Refer to Obtain the Oracle SOA Suite Docker image for details on how to obtain or create the image. | soasuite:12.2.1.4 |
imagePullPolicy |
WebLogic Docker image pull policy. Legal values are IfNotPresent , Always , or Never . |
IfNotPresent |
imagePullSecretName |
Name of the Kubernetes secret to access the Docker Store to pull the WebLogic Server Docker image. The presence of the secret will be validated when this parameter is specified. | |
includeServerOutInPodLog |
Boolean indicating whether to include the server .out to the pod’s stdout. | true |
initialManagedServerReplicas |
Number of Managed Servers to initially start for the domain. | 2 |
javaOptions |
Java options for starting the Administration Server and Managed Servers. A Java option can have references to one or more of the following pre-defined variables to obtain WebLogic domain information: $(DOMAIN_NAME) , $(DOMAIN_HOME) , $(ADMIN_NAME) , $(ADMIN_PORT) , and $(SERVER_NAME) . If sslEnabled is set to true and the WebLogic demo certificate is used, add -Dweblogic.security.SSL.ignoreHostnameVerification=true to allow the managed servers to connect to the Administration Server while booting up. The WebLogic generated demo certificate in this environment typically contains a host name that is different from the runtime container’s host name. |
-Dweblogic.StdoutDebugEnabled=false |
logHome |
The in-pod location for the domain log, server logs, server out, and Node Manager log files. If not specified, the value is derived from the domainUID as /shared/logs/<domainUID> . |
/u01/oracle/user_projects/domains/logs/soainfra |
managedServerNameBase |
Base string used to generate Managed Server names. By default the managedServerNameBase is soa_server for the SOA domain type. You can update this to osb_server for an OSB domain type or soa_server for SOAESS or SOAOSB or SOAESSOSB domain types. |
soa_server |
managedServerPort |
Port number for each Managed Server. By default the managedServerPort is 8001 for the SOA domain type. You can update this to 9001 for an OSB domain type or 8001 for SOAESS or SOAOSB or SOAESSOSB domain types. |
8001 |
managedServerSSLPort |
SSL port number for each Managed Server. By default the managedServerSSLPort is 8002 for the SOA domain type. You can update this to 9002 for an OSB domain type or 8002 for SOAESS or SOAOSB or SOAESSOSB domain types. |
8002 |
namespace |
Kubernetes namespace in which to create the domain. | soans |
persistentVolumeClaimName |
Name of the persistent volume claim created to host the domain home. If not specified, the value is derived from the domainUID as <domainUID>-weblogic-sample-pvc . |
soainfra-domain-pvc |
productionModeEnabled |
Boolean indicating if production mode is enabled for the domain. | true |
serverStartPolicy |
Determines which WebLogic Server instances will be started. Legal values are NEVER , IF_NEEDED , ADMIN_ONLY . |
IF_NEEDED |
t3ChannelPort |
Port for the t3 channel of the NetworkAccessPoint. | 30012 |
t3PublicAddress |
Public address for the T3 channel. This should be set to the public address of the Kubernetes cluster. This would typically be a load balancer address. For development environments only: In a single server (all-in-one) Kubernetes deployment, this may be set to the address of the master, or at the very least, it must be set to the address of one of the worker nodes. | If not provided, the script will attempt to set it to the IP address of the Kubernetes cluster |
weblogicCredentialsSecretName |
Name of the Kubernetes secret for the Administration Server’s user name and password. If not specified, then the value is derived from the domainUID as <domainUID>-weblogic-credentials . |
soainfra-domain-credentials |
weblogicImagePullSecretName |
Name of the Kubernetes secret for the Docker Store, used to pull the WebLogic Server image. | |
serverPodCpuRequest , serverPodMemoryRequest , serverPodCpuCLimit , serverPodMemoryLimit |
The maximum amount of compute resources allowed, and minimum amount of compute resources required, for each server pod. Please refer to the Kubernetes documentation on Managing Compute Resources for Containers for details. |
Resource requests and resource limits are not specified. |
rcuSchemaPrefix |
The schema prefix to use in the database, for example SOA1 . You may wish to make this the same as the domainUID in order to simplify matching domains to their RCU schemas. |
SOA1 |
rcuDatabaseURL |
The database URL. | oracle-db.default.svc.cluster.local:1521/devpdb.k8s |
rcuCredentialsSecret |
The Kubernetes secret containing the database credentials. | soainfra-rcu-credentials |
persistentStore |
The persistent store for ‘JMS servers’ and ‘Transaction log store’ in the domain. Legal values are jdbc , file . |
jdbc |
Note that the names of the Kubernetes resources in the generated YAML files may be formed with the
value of some of the properties specified in the create-inputs.yaml
file. Those properties include
the adminServerName
, clusterName
and managedServerNameBase
. If those values contain any
characters that are invalid in a Kubernetes service name, those characters are converted to
valid values in the generated YAML files. For example, an uppercase letter is converted to a
lowercase letter and an underscore ("_")
is converted to a hyphen ("-")
.
The sample demonstrates how to create an Oracle SOA Suite domain home and associated Kubernetes resources for a domain that has one cluster only. In addition, the sample provides the capability for users to supply their own scripts to create the domain home for other use cases. The generated domain YAML file could also be modified to cover more use cases.
Run the create domain script, specifying your inputs file and an output directory to store the generated artifacts:
$ ./create-domain.sh \
-i create-domain-inputs.yaml \
-o <path to output-directory>
The script will perform the following steps:
Create a directory for the generated Kubernetes YAML files for this domain if it does not
already exist. The path name is <path to output-directory>/weblogic-domains/<domainUID>
.
If the directory already exists, its contents must be removed before using this script.
Create a Kubernetes job that will start up a utility Oracle SOA Suite container and run offline WLST scripts to create the domain on the shared storage.
Run and wait for the job to finish.
Create a Kubernetes domain YAML file, domain.yaml
, in the “output” directory that was created above.
This YAML file can be used to create the Kubernetes resource using the kubectl create -f
or kubectl apply -f
command:
$ kubectl apply -f <path to output-directory>/weblogic-domains/<domainUID>/domain.yaml
Create a convenient utility script, delete-domain-job.yaml
, to clean up the domain home
created by the create script.
The default domain created by the script has the following characteristics:
AdminServer
listening on port 7001
.soa_cluster
of size 5.soa_server1
and soa_server2
, listening on port 8001
./shared/logs/<domainUID>
.The create domain script will verify that the domain was created, and will report failure if there was any error. However, it may be desirable to manually verify the domain, even if just to gain familiarity with the various Kubernetes objects that were created by the script.
To confirm that the domain was created, enter the following command:
$ kubectl describe domain DOMAINUID -n NAMESPACE
Replace DOMAINUID
with the domainUID
and NAMESPACE
with the actual namespace.
In the Status
section of the output, the available servers and clusters are listed.
Note that if this command is issued very soon after the script finishes, there may be
no servers available yet, or perhaps only the Administration Server but no Managed Servers.
The operator will start up the Administration Server first and wait for it to become ready
before starting the Managed Servers.
Enter the following command to see the pods running the servers:
$ kubectl get pods -n NAMESPACE
Here is an example of the output of this command. You can verify that an Administration Server and two Managed Servers for each cluster (SOA and OSB) are running for soaessosb
domain type.
$ kubectl get pods -n soans
NAME READY STATUS RESTARTS AGE
soainfra-adminserver 1/1 Running 0 53m
soainfra-osb-server1 1/1 Running 0 50m
soainfra-osb-server2 1/1 Running 0 50m
soainfra-soa-server1 1/1 Running 0 50m
soainfra-soa-server2 1/1 Running 0 50m
Enter the following command to see the services for the domain:
$ kubectl get services -n NAMESPACE
Here is an example of the output of this command. You can verify that services for Administration Server and Managed Servers (for SOA and OSB clusters) are created for soaessosb
domain type.