Oracle supports the deployment of the following Oracle Fusion Middleware products on Kubernetes. Click on the appropriate document link below to get started on setting up the product.
The Oracle WebLogic Kubernetes Operator (the “operator”) supports deployment of Oracle SOA Suite components such as Oracle Service-Oriented Architecture (SOA), Oracle Service Bus, and Oracle Enterprise Scheduler (ESS). Follow the instructions in this guide to set up these Oracle SOA Suite domains on Kubernetes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/24.2.2/index.json b/24.2.2/index.json
new file mode 100644
index 000000000..62b40f642
--- /dev/null
+++ b/24.2.2/index.json
@@ -0,0 +1,274 @@
+[
+{
+ "uri": "/fmw-kubernetes/24.2.2/soa-domains/edg-guide/topology/",
+ "title": "Topology",
+ "tags": [],
+ "description": "Topology for Oracle SOA Suite Enterprise Deployment on Kubernetes.",
+ "content": "Assumptions The most relevant assumptions for the Oracle SOA Suite Kubernetes Enterprise Deployment Guide (EDG) topology are related to the database and web tiers. Typical on-premises production systems keep their high end database (such as RAC, RAC+DG, Exadata, Autonomous Database) out of the Kubernetes cluster and manage that tier separately. This implies that the database runs separately from the Kubernetes cluster hosting the application tier. The database provisioning and configuration process is out of the scope of the Oracle SOA Suite Kubernetes setup. Typically, it is administered and maintained by different teams and the Oracle SOA Suite Enterprise Deployment Guide would need to consume just the scan address and database service to be used for the RCU and data source creation. Similarly, the demilitarized zone (DMZ) will likely remain untouched: Customer investments in load balancers (LBRs) are well consolidated, and the security and DMZ policies are well established. Using an HTTP proxy in the DMZ has become a standard. Additionally, Single Sign On (such as OAM and others) may remain for some time and those are best addressed in the web tier than as part of the Kubernetes cluster.\nDue to total cost of ownership reasons, the Kubernetes control plane uses a stacked etcd. External etcd is also possible but, given RAFT protocol\u0026rsquo;s reliability, this option requires a significant amount of additional setup work and three additional nodes just to host the etcd system.\nTopology Diagram Tier Description Control Plane The control plane consists of three nodes where the Kubernetes API server is deployed, front-ended by a load balancer (LBR). The LBR exposes the required virtual IP address (VIP) and virtual server (VS) for both the Oracle SOA Suite and the control plane itself (although an internal-only VS can also be used). This URL must be site or data center agnostic in preparation for disaster protection. The control plane and worker nodes must be able to resolve this hostname name properly AND SHOULD NOT USE IPs for it. As explained in the assumptions section, the etcd tier is stacked with the kube-api servers. Each control plane node runs Kubernetes kube-api, kube-controller, kube-scheduler, and etcd instances pointing to local etcd mounts. The etcd has been tested by the Maximum Availability Architecture (MAA) team on DBFS, NFS, and local file systems. No significant performance differences were observed between the two options for an Oracle SOA Suite system. However, this decision may require additional analysis in each customer case depending on the usage by other apps in the same cluster. Using etcd directly on DBFS allows shipping etcd directly to secondary data centers and allows flashing back quickly to previous versions of the control plane using DB technology. However, it creates a dependency between etcd and the database that is discouraged. The etcd snapshots CAN, however, be placed on DBFS to simplify the continuous shipping of copies to secondary regions and leaving it to Data Guard. These are the options that will be applicable or not depending on the customer needs:\n Place etcd on root or local volumes, ship snapshots with regular rsyncs over reliable networks. Place etcd on NFS, ship snapshots with regular rsyncs over reliable networks. Place etcd on NFS or local volume, copy snapshots to DBFS for shipping to secondary. Application tier. Application Tier Oracle SOA Suite internal applications and custom deployments on SOA (composites) and WebLogic (ears, jars, wars) are run on three worker nodes in the Kubernetes cluster. The typical allocation on Kubernetes places the WebLogic Administration Server on the first node and each of the servers in the Oracle SOA Suite and/or Service Bus clusters in the other two. This can vary depending on the workloads and kube controller and scheduler decisions.\n$ kubectl get pods -A -o wide | grep soa soans soaedgdomain-adminserver 1/1 Running 0 19h 10.244.3.127 olk8-w1 \u0026lt;none\u0026gt; \u0026lt;none\u0026gt; soans soaedgdomain-create-soa-infra-domain-job-6pq9z 0/1 Completed 0 67d 10.244.4.2 olk8-w2 \u0026lt;none\u0026gt; \u0026lt;none\u0026gt; soans soaedgdomain-soa-server1 1/1 Running 0 22h 10.244.5.161 olk8-w3 \u0026lt;none\u0026gt; \u0026lt;none\u0026gt; soans soaedgdomain-soa-server2 1/1 Running 0 22h 10.244.4.178 olk8-w2 \u0026lt;none\u0026gt; \u0026lt;none\u0026gt; The application tier is critically dependent on the Kubernetes DNS pods to be able to resolve the scan address for the RAC database.\nA dual configuration for persistent volumes is used to avoid a single point of failure in the Oracle SOA Suite domain configuration. Two separate NFS devices are used for high availability. Refer to the Configure redundant persistent volume for details.\nThe internal Oracle SOA Suite and Service Bus clusters use some of the configuration best practices prescribed for on-premises systems. Refer to the Enterprise Deployment Guide for Oracle SOA Suite 12c (12.2.1.4):\n Automatic Service Migration is used for the Java Message Service (JMS) and Java Transaction API (JTA) Services.\n All the persistent stores are JDBC persistent stores.\n Node manager is used to monitor the managed server\u0026rsquo;s health.\n There are significant differences with an on-premises enterprise deployment. The most relevant are:\n WebLogic Kubernetes Operator is used to manage the lifecycle of the managed servers, instead of the WebLogic Administration Console or WLST.\n Scale out procedures are based on the Kubernetes cluster.\n The WebLogic Administration Server does NOT use its own/separate WebLogic domain directory.\n Listen addresses and hostnames are \u0026ldquo;virtual\u0026rdquo; out-of-the-box, which provides a significant advantage when considering disaster protection.\n The OHS/DMZ tier routes to the back-end WebLogic clusters and Administration Server, using a precise node port available in the different nodes.\n External subsystems: LBR, OHS, and Database Oracle SOA Suite interacts with the following external artifacts: front-end LBR, OHS/DMZ-proxy, Database, and external authenticators.\n The LBR is used both to route to kube-api and as a standard Oracle SOA Suite front end.\n The front-end LBR Oracle SOA Suite configuration is identical to an on-premises system. For more information, see the Enterprise Deployment Guide for Oracle SOA Suite 12c 12.2.1.4.\n For kube-api access, the LBR uses a layer4 (TCP) listener. This listener forwards to the backend control plane nodes. Note: Use hostnames and avoid IP address.\n The Database tier consists of a RAC Database that hosts JMS/JTA persistent stores, OPSS, and MDS information. The setup of this RAC database is out of the scope of these procedures. All the standard MAA best practices for database services, processes, and DB configuration for a SOA cluster are applicable on Kubernetes. For more details, see the Enterprise Deployment Guide for Oracle SOA Suite 12c 12.2.1.4.\n External auth providers can be used as described in the Oracle SOA Suite EDG procedures.\n Single Sign-On through OHS with OAM is possible, as in a standard on-premises Oracle SOA Suite deployment.\n OHS routes to precise node ports for the SOA Cluster, OSB Cluster, and Administration Server. This is based on the fact that Oracle SOA Suite exposes very few services, which do not change much through the system\u0026rsquo;s lifecycle. This also avoids overhead and dependencies on ingress and additional third party controllers. The OHS configuration is similar to a standard on-premises configuration, except that it disables the Dynamic Server list and uses the list of worker nodes with the precise node port for each cluster.\n "
+},
+{
+ "uri": "/fmw-kubernetes/24.2.2/soa-domains/installguide/prerequisites/",
+ "title": "Requirements and pricing",
+ "tags": [],
+ "description": "Understand the system requirements, limitations, licensing, and pricing for deploying and running Oracle SOA Suite domains with the WebLogic Kubernetes Operator, including the SOA cluster sizing.",
+ "content": "This section provides information about the system requirements, limitations, licensing, and pricing for deploying and running Oracle SOA Suite domains with the WebLogic Kubernetes Operator.\nSystem requirements for Oracle SOA Suite domains Release 24.2.2 has the following system requirements:\n Kubernetes 1.24.0+, 1.25.0+, 1.26.2+, 1.27.2+, and 1.28.2+ (check with kubectl version). Docker 19.03.11+ (check with docker version) or CRI-O 1.20.2+ (check with crictl version | grep RuntimeVersion). Flannel networking v0.13.0-amd64 or later (check with docker images | grep flannel), Calico networking v3.16.1 or later. Helm 3.10.2+ (check with helm version --client --short). WebLogic Kubernetes Operator 4.2.2 (see the operator releases 4.2.2 pages). You must have the cluster-admin role to install the operator. The operator does not need the cluster-admin role at runtime. For more information, see the role-based access control (RBAC) documentation. We do not currently support running SOA in non-Linux containers. Container images based on Oracle Linux 8 are now supported. My Oracle Support and the Oracle Container Registry host container images based on both Oracle Linux 7 and 8. Additionally, see the Oracle SOA Suite documentation for other requirements, such as database version. See here for resource sizing information for Oracle SOA Suite domains set up on a Kubernetes cluster.\nLimitations Compared to running a WebLogic Server domain in Kubernetes using the operator, the following limitations currently exist for Oracle SOA Suite domains:\n In this release, Oracle SOA Suite domains are supported using the domain on a persistent volume model only, where the domain home is located in a persistent volume (PV). The \u0026ldquo;domain in image\u0026rdquo; and \u0026ldquo;model in image\u0026rdquo; models are not supported. Also, \u0026ldquo;WebLogic Deploy Tooling (WDT)\u0026rdquo; based deployments are currently not supported. Only configured clusters are supported. Dynamic clusters are not supported for Oracle SOA Suite domains. Note that you can still use all of the scaling features, but you need to define the maximum size of your cluster at domain creation time. Mixed clusters (configured servers targeted to a dynamic cluster) are not supported. The WebLogic Logging Exporter project has been archived. Users are encouraged to use Fluentd or Logstash. The WebLogic Monitoring Exporter currently supports WebLogic MBean trees only. Support for JRF and Oracle SOA Suite MBeans is not available. Also, a metrics dashboard specific to Oracle SOA Suite is not available. Instead, use the WebLogic Server dashboard to monitor the Oracle SOA Suite server metrics in Grafana. Some features such as multicast, multitenancy, production redeployment, and Node Manager (although it is used internally for the liveness probe and to start WebLogic Server instances) are not supported in this release. Features such as Java Messaging Service whole server migration and consensus leasing are not supported in this release. Maximum availability architecture (Oracle SOA Suite EDG setup) is available for preview. Enabling or disabling the memory resiliency for Oracle Service Bus using the Enterprise Manager Console is not supported in this release. Zero downtime upgrade (ZDT) of the domain is not supported. For up-to-date information about the features of WebLogic Server that are supported in Kubernetes environments, see My Oracle Support Doc ID 2349228.1.\nPricing and licensing The WebLogic Kubernetes Operator and Oracle Linux are open source and free; WebLogic Server requires licenses in any environment. All WebLogic Server licenses are suitable for deploying WebLogic to containers and Kubernetes, including free single desktop Oracle Technology Network (OTN) developer licenses. See the following sections for more detailed information:\n Oracle SOA Suite Oracle Linux Oracle Java WebLogic Kubernetes Operator Oracle SOA Suite images Additional references Oracle SOA Suite Oracle SOA Suite is licensed as an option to Oracle WebLogic Suite. Valid licenses are needed in at least one of the following combinations:\n WebLogic Suite and Oracle SOA Suite WebLogic Suite and Oracle Service Bus WebLogic Suite and Oracle BPEL Engine For more information, see the Fusion Middleware Licensing Information User Manual - Oracle SOA Suite and the following sections.\nOracle Linux Oracle Linux is under open source license and is completely free to download and use.\nNote that Oracle SOA Suite licenses that include support do not include customer entitlements for direct access to Oracle Linux support or Unbreakable Linux Network (to directly access the standalone Oracle Linux patches). The latest Oracle Linux patches are included with the latest Oracle SOA Suite images.\nOracle Java Oracle support for Java is included with Oracle SOA Suite licenses when Java is used for running WebLogic and Coherence servers or clients.\nFor more information, see the Fusion Middleware Licensing Information User Manual.\nOracle SOA Suite images Oracle provides two different types of Oracle SOA Suite images:\n Critical Patch Update (CPU) images: Images with the latest Oracle SOA Suite, Fusion Middleware Infrastructure, Coherence PSUs, and other fixes released by the Critical Patch Update (CPU) program. CPU images are intended for production use.\n General Availability (GA) images: Images that are not intended for production use and do not include Oracle SOA Suite, WebLogic, Fusion Middleware Infrastructure, or Coherence PSUs.\n All Oracle SOA Suite licenses, including free Oracle Technology Network (OTN) developer licenses, include access to the latest General Availability (GA) Oracle SOA Suite images, which bundle Java SE.\nCustomers with access to Oracle SOA Suite support additionally have:\n Access to Critical Patch Update (CPU) Oracle SOA Suite images, which bundle Java SE. Access to Oracle SOA Suite patches. Oracle support for Oracle SOA Suite images. WebLogic Kubernetes Operator The WebLogic Kubernetes Operator is open source and free, licensed under the Universal Permissive license (UPL), Version 1.0. For support details, see Get help.\nAdditional references Supported Virtualization and Partitioning Technologies for Oracle Fusion Middleware (search for keyword \u0026lsquo;Kubernetes\u0026rsquo;) Running and Licensing Oracle Programs in Containers and Kubernetes "
+},
+{
+ "uri": "/fmw-kubernetes/24.2.2/",
+ "title": "Oracle Fusion Middleware on Kubernetes",
+ "tags": [],
+ "description": "This document lists all the Oracle Fusion Middleware products deployment supported on Kubernetes.",
+ "content": "Oracle Fusion Middleware on Kubernetes Oracle supports the deployment of the following Oracle Fusion Middleware products on Kubernetes. Click on the appropriate document link below to get started on setting up the product.\n Oracle SOA Suite The Oracle WebLogic Kubernetes Operator (the “operator”) supports deployment of Oracle SOA Suite components such as Oracle Service-Oriented Architecture (SOA), Oracle Service Bus, and Oracle Enterprise Scheduler (ESS). Follow the instructions in this guide to set up these Oracle SOA Suite domains on Kubernetes.\n "
+},
+{
+ "uri": "/fmw-kubernetes/24.2.2/soa-domains/release-notes/",
+ "title": "Release Notes",
+ "tags": [],
+ "description": "",
+ "content": "Review the latest changes and known issues for Oracle SOA Suite on Kubernetes.\nRecent changes Date Version Change May 31, 2024 24.2.2 Supports Oracle SOA Suite 12.2.1.4 domains deployment using April 2024 PSU and known bug fixes. Support for WebLogic Kubernetes Operator 4.2.2. Oracle SOA Suite 12.2.1.4 Docker image for this release can be downloaded from My Oracle Support (MOS patch 36568531 for Oracle Linux 7 and MOS patch 36568606 for Oracle Linux 8) and container-registry.oracle.com. February 29, 2024 24.1.2 Supports Oracle SOA Suite 12.2.1.4 domains deployment using January 2024 PSU and known bug fixes. Support for WebLogic Kubernetes Operator 4.1.7. Oracle SOA Suite 12.2.1.4 Docker image for this release can be downloaded from My Oracle Support (MOS patch 36182324 for Oracle Linux 7 and MOS patch 36182412 for Oracle Linux 8) and container-registry.oracle.com. November 30, 2023 23.4.2 Supports Oracle SOA Suite 12.2.1.4 domains deployment using October 2023 PSU and known bug fixes. Support for WebLogic Kubernetes Operator 4.1.4. Oracle SOA Suite 12.2.1.4 Docker image for this release can be downloaded from My Oracle Support (MOS patch 35908803 for Oracle Linux 7 and MOS patch 35915091 for Oracle Linux 8) and container-registry.oracle.com. August 31, 2023 23.3.2 Supports Oracle SOA Suite 12.2.1.4 domains deployment using July 2023 PSU and known bug fixes. Support for WebLogic Kubernetes Operator 4.1.0. Oracle SOA Suite 12.2.1.4 Docker image for this release can be downloaded from My Oracle Support (MOS patch 35729956 for Oracle Linux 7 and MOS patch 35730025 for Oracle Linux 8) and container-registry.oracle.com. May 31, 2023 23.2.2 Supports Oracle SOA Suite 12.2.1.4 domains deployment using April 2023 PSU and known bug fixes. Support for WebLogic Kubernetes Operator 4.0.6. Container images based on Oracle Linux 8 are now supported. Oracle SOA Suite 12.2.1.4 Docker image for this release can be downloaded from My Oracle Support (MOS patch 35269141 for Oracle Linux 7 and MOS patch 35285229 for Oracle Linux 8) and container-registry.oracle.com. February 28, 2023 23.1.2 Supports Oracle SOA Suite 12.2.1.4 domains deployment using January 2023 PSU and known bug fixes. Support for WebLogic Kubernetes Operator 4.0.4. Oracle SOA Suite 12.2.1.4 Docker image for this release can be downloaded from My Oracle Support (MOS patch 34980883) and container-registry.oracle.com. November 30, 2022 22.4.2 Supports Oracle SOA Suite 12.2.1.4 domains deployment using October 2022 PSU and known bug fixes. Support for WebLogic Kubernetes Operator 3.4.4. Oracle SOA Suite 12.2.1.4 container images are now only available from container-registry.oracle.com and are no longer available from My Oracle Support. August 31, 2022 22.3.2 Supports Oracle SOA Suite 12.2.1.4 domains deployment using July 2022 PSU and known bug fixes. Enterprise Deployment Guide as preview release. Oracle SOA Suite 12.2.1.4 Docker image for this release can be downloaded from My Oracle Support (MOS patch 34410491). May 31, 2022 22.2.2 Supports Oracle SOA Suite 12.2.1.4 domains deployment using April 2022 PSU and known bug fixes. Oracle SOA Suite 12.2.1.4 Docker image for this release can be downloaded from My Oracle Support (MOS patch 34077593). February 25, 2022 22.1.2 Supports Oracle SOA Suite 12.2.1.4 domains deployment using January 2022 PSU and known bug fixes. Oracle SOA Suite 12.2.1.4 Docker image for this release can be downloaded from My Oracle Support (MOS patch 33749496). November 30, 2021 21.4.2 Supports Oracle SOA Suite 12.2.1.4 domains deployment using October 2021 PSU and known bug fixes. Oracle SOA Suite 12.2.1.4 Docker image for this release can be downloaded from My Oracle Support (MOS patch 33467899). August 6, 2021 21.3.2 Supports Oracle SOA Suite 12.2.1.4 domains deployment using July 2021 PSU and known bug fixes. Oracle SOA Suite 12.2.1.4 Docker image for this release can be downloaded from My Oracle Support (MOS patch 33125465). May 31, 2021 21.2.2 Supports Oracle SOA Suite 12.2.1.4 domains deployment using April 2021 PSU and known bug fixes. Oracle SOA Suite 12.2.1.4 Docker image for this release can be downloaded from My Oracle Support (MOS patch 32794257). February 28, 2021 21.1.2 Supports Oracle SOA Suite 12.2.1.4 domains deployment using January 2021 PSU and known bug fixes. Oracle SOA Suite 12.2.1.4 Docker image for this release can be downloaded from My Oracle Support (MOS patch 32398542). November 30, 2020 20.4.2 Supports Oracle SOA Suite 12.2.1.4 domains deployment using October 2020 PSU and known bug fixes. Added HEALTHCHECK support for Oracle SOA Suite docker image. Oracle SOA Suite 12.2.1.4 Docker image for this release can be downloaded from My Oracle Support (MOS patch 32215749). October 3, 2020 20.3.3 Certified Oracle WebLogic Kubernetes Operator version 3.0.1. Kubernetes 1.14.8+, 1.15.7+, 1.16.0+, 1.17.0+, and 1.18.0+ support. Flannel is the only supported CNI in this release. SSL enabling for the Administration Server and Managed Servers is supported. Only Oracle SOA Suite 12.2.1.4 is supported. Known issues Overriding tuning parameters is not supported using configuration overrides Deployments in WebLogic administration console display unexpected error Enterprise Manager console may display ADF_FACES-30200 error Configure the external URL access for Oracle SOA Suite composite applications Configure the external access for the Oracle Enterprise Scheduler WebServices WSDL URLs Missing gif images in Oracle Service Bus console pipeline configuration page "
+},
+{
+ "uri": "/fmw-kubernetes/24.2.2/soa-domains/adminguide/deploying-composites/supportjdev/",
+ "title": "Deploy using JDeveloper",
+ "tags": [],
+ "description": "Deploy Oracle SOA Suite and Oracle Service Bus composite applications from Oracle JDeveloper to Oracle SOA Suite in the WebLogic Kubernetes Operator environment.",
+ "content": "Learn how to deploy Oracle SOA Suite and Oracle Service Bus composite applications from Oracle JDeveloper (running outside the Kubernetes network) to an Oracle SOA Suite instance in the WebLogic Kubernetes Operator environment.\nUse JDeveloper for development and test environments only. For a production environment, you should deploy using Application Control and WLST methods.\n Deploy Oracle SOA Suite and Oracle Service Bus composite applications to Oracle SOA Suite from JDeveloper To deploy Oracle SOA Suite and Oracle Service Bus composite applications from Oracle JDeveloper, the Administration Server must be configured to expose a T3 channel. The WebLogic Kubernetes Operator provides an option to expose a T3 channel for the Administration Server using the exposeAdminT3Channel setting during domain creation, then the matching T3 service can be used to connect. By default, when exposeAdminT3Channel is set, the WebLogic Kubernetes Operator environment exposes the NodePort for the T3 channel of the NetworkAccessPoint at 30012 (use t3ChannelPort to configure the port to a different value).\nIf you miss enabling exposeAdminT3Channel during domain creation, follow Expose a T3/T3S Channel for the Administration Server to expose a T3 channel manually.\nPrerequisites Get the Kubernetes cluster master address and verify the T3 port that will be used for creating application server connections. Use the following command to get the T3 port:\n$ kubectl get service \u0026lt;domainUID\u0026gt;-\u0026lt;AdministrationServerName\u0026gt;-external -n \u0026lt;namespace\u0026gt;-o jsonpath='{.spec.ports[0].nodePort}' For example:\n$ kubectl get service soainfra-adminserver-external -n soans -o jsonpath='{.spec.ports[0].nodePort}' Oracle SOA Suite in the WebLogic Kubernetes Operator environment is deployed in a Reference Configuration domain. If a SOA project is developed in Classic mode JDeveloper displays a Mismatch notification in the Deploy Composite Wizard. By default, JDeveloper is in Classic mode. To develop SOA projects in Reference Configuration mode, you must manually enable this feature in JDeveloper: a. From the File menu, select Tools, then Preferences. b. Select Reference Configuration Settings. c. Select Enable Reference Configuration settings in adapters.\n JDeveloper needs to access the Servers during deployment. In the WebLogic Kubernetes Operator environment, Administration and Managed Servers are pods and cannot be accessed directly by JDeveloper. As a workaround, you must configure the reachability of the Managed Servers:\nThe Managed Server T3 port is not exposed by default and opening this will have a security risk as the authentication method here is based on a userid/password. It is not recommended to do this on production instances.\n Decide on an external IP address to be used to configure access to the Managed Servers. Master or worker node IP address can be used to configure Managed Server reachability. In these steps, the Kubernetes cluster master IP is used for demonstration.\n Get the pod names of the Administration Server and Managed Servers (that is, \u0026lt;domainUID\u0026gt;-\u0026lt;server name\u0026gt;), which will be used to map in /etc/hosts.\n Update /etc/hosts (or in Windows, C:\\Windows\\System32\\Drivers\\etc\\hosts) on the host where JDeveloper is running with the entries below, where\n\u0026lt;Master IP\u0026gt; \u0026lt;Administration Server pod name\u0026gt; \u0026lt;Master IP\u0026gt; \u0026lt;Managed Server1 pod name\u0026gt; \u0026lt;Master IP\u0026gt; \u0026lt;Managed Server2 pod name\u0026gt; Sample /etc/hosts entries looks as follows, where X.X.X.X is the master node IP address:\nX.X.X.X soainfra-adminserver X.X.X.X soainfra-soa-server1 X.X.X.X soainfra-soa-server2 Get the Kubernetes service name of the Oracle SOA Suite cluster to access externally with the master IP (or external IP):\n$ kubectl get service \u0026lt;domainUID\u0026gt;-cluster-\u0026lt;soa-cluster\u0026gt; -n \u0026lt;namespace\u0026gt; For example:\n$ kubectl get service soainfra-cluster-soa-cluster -n soans Create a Kubernetes service to expose the Oracle SOA Suite cluster service (\u0026lt;domainUID\u0026gt;-cluster-\u0026lt;soa-cluster\u0026gt;) externally with same port as the Managed Server:\n$ kubectl expose service \u0026lt;domainUID\u0026gt;-cluster-\u0026lt;soa-cluster\u0026gt; --name \u0026lt;domainUID\u0026gt;-\u0026lt;soa-cluster\u0026gt;-ext --external-ip=\u0026lt;Master IP\u0026gt; -n \u0026lt;namespace\u0026gt; For example:\n$ kubectl expose service soainfra-cluster-soa-cluster --name soainfra-cluster-soa-cluster-ext --external-ip=X.X.X.X -n soans In a production environment, exposing the SOA cluster service with an external IP address is not recommended, as it can cause message drops on the SOA Managed Servers.\n Create an application server connection in JDeveloper Create a new application server connection (for example wls-k8s-op-connection) in JDeveloper: In the configuration page, provide the WebLogic Hostname as the Kubernetes Master Address.\n Update the Port as the T3 port (default is 30012) obtained in Prerequisites.\n Enter the WebLogic Domain value (domainUID).\n Test the connection to verify it is successful. Deploy SOA composite applications using JDeveloper In JDeveloper, right-click the SOA project you want to deploy and select Deploy to display the deployment wizard. In the Deployment Action page, select Deploy to Application Server and click Next. In the Deployment Configuration page, select the appropriate options and click Next. In the Select server page, select the application server connection (wls-k8s-op-connection) that was created earlier and click Next. If the Prerequisites were configured correctly, the lookup discovers the Managed Servers for deploying the composite. Using the application server connection, the Managed Servers (Oracle SOA Suite cluster) are listed on the SOA Servers page. Select the Oracle SOA Suite cluster and click Next. On the Summary page, click Finish to start deploying the composites to the Oracle SOA Suite cluster. Verify logs on JDeveloper to confirm successful deployment. Enter the soa-infra URLs in a browser to confirm the composites are deployed on both servers of the Oracle SOA Suite cluster. Deploy Oracle Service Bus composite applications using JDeveloper In JDeveloper, right-click the Oracle Service Bus project you want to deploy and select Deploy to display the deployment wizard. In the Deployment Action page, select Deploy to Application Server and click Next. In the Select Server page, select the application server connection (wls-k8s-op-connection) that was created earlier and click Next. On the Summary page, click Finish to start deploying the composites to the Oracle Service Bus cluster. In JDeveloper, verify logs to confirm successful deployment. In the Oracle Service Bus Console, click Launch Test Console to verify that the Oracle Service Bus composite application is deployed successfully. "
+},
+{
+ "uri": "/fmw-kubernetes/24.2.2/soa-domains/appendix/soa-cluster-sizing-info/",
+ "title": "Domain resource sizing",
+ "tags": [],
+ "description": "Describes the resourse sizing information for Oracle SOA Suite domains setup on Kubernetes cluster.",
+ "content": "Oracle SOA cluster sizing minimum requirements Oracle SOA Normal Usage Moderate Usage High Usage Administration Server No of CPU core(s) : 1, Memory : 4GB No of CPU core(s) : 1, Memory : 4GB No of CPU core(s) : 1, Memory : 4GB Number of Managed Servers 2 2 4 Configurations per Managed Server No of CPU core(s) : 2, Memory : 16GB No of CPU core(s) : 4, Memory : 16GB No of CPU core(s) : 6, Memory : 16-32GB PV Storage Minimum 250GB Minimum 250GB Minimum 500GB "
+},
+{
+ "uri": "/fmw-kubernetes/24.2.2/soa-domains/patch_and_upgrade/patch-an-image/",
+ "title": "Patch an image",
+ "tags": [],
+ "description": "Create a patched Oracle SOA Suite image using the WebLogic Image Tool.",
+ "content": "Oracle releases Oracle SOA Suite images regularly with the latest bundle and recommended interim patches in My Oracle Support (MOS). However, if you need to create images with new bundle and interim patches, you can build these images using the WebLogic Image Tool.\nIf you have access to the Oracle SOA Suite patches, you can patch an existing Oracle SOA Suite image with a bundle patch and interim patches. Oracle recommends that you use the WebLogic Image Tool to patch the Oracle SOA Suite image.\n Recommendations:\n Use the WebLogic Image Tool create feature for patching the Oracle SOA Suite Docker image with a bundle patch and multiple interim patches. This is the recommended approach because it optimizes the size of the image. Use the WebLogic Image Tool update feature for patching the Oracle SOA Suite Docker image with a single interim patch. Note that the patched image size may increase considerably due to additional image layers introduced by the patch application tool. Apply the patched Oracle SOA Suite image To update an Oracle SOA Suite domain with a patched image, first make sure the patched image is pulled or created and available on the nodes in your Kubernetes cluster. Once the patched image is available, you can follow these steps to update the Oracle SOA Suite domain with a patched image:\n Stop all servers Update user permissions of the domain PV storage Address post-installation requirements Apply the patched image Stop all servers Note: The following steps are applicable only for non-Zero Downtime Patching. For Zero Downtime Patching, go to Address post-installation requirements.\n Before applying the patch, stop all servers in the domain:\n In the domain.yaml configuration file, update the spec.serverStartPolicy field value to NEVER (for Operator 3.x) or Never (for Operator 4.x).\n Shut down the domain (stop all servers) by applying the updated domain.yaml file:\n$ kubectl apply -f domain.yaml Update user permissions of the domain PV storage The Oracle SOA Suite image for release 24.1.2 has an oracle user with UID 1000, with the default group set to root. Before applying the patched image, update the user permissions of the domain persistent volume (PV) to set the group to root:\n$ sudo chown -R 1000:0 /scratch/k8s_dir/SOA Address post-installation requirements If the patches in the patched Oracle SOA Suite image have any post-installation steps, follow these steps:\n Create a Kubernetes pod with domain home access Perform post-installation steps Create a Kubernetes pod with domain home access Get domain home persistence volume claim details for the Oracle SOA Suite domain.\nFor example, to list the persistent volume claim details in the namespace soans:\n$ kubectl get pvc -n soans Sample output showing the persistent volume claim is soainfra-domain-pvc:\nNAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE soainfra-domain-pvc Bound soainfra-domain-pv 10Gi RWX soainfra-domain-storage-class xxd Create a YAML soapostinstall.yaml using the domain home persistence volume claim.\nFor example, using soainfra-domain-pvc per the sample output:\n Note: Replace soasuite:12.2.1.4-30761841 with the patched image in the following sample YAML:\n apiVersion: v1 kind: Pod metadata: labels: run: soapostinstall name: soapostinstall namespace: soans spec: containers: - image: soasuite:12.2.1.4-30761841 name: soapostinstall command: [\u0026quot;/bin/bash\u0026quot;, \u0026quot;-c\u0026quot;, \u0026quot;sleep infinity\u0026quot;] imagePullPolicy: IfNotPresent volumeMounts: - name: soainfra-domain-storage-volume mountPath: /u01/oracle/user_projects volumes: - name: soainfra-domain-storage-volume persistentVolumeClaim: claimName: soainfra-domain-pvc Apply the YAML to create the Kubernetes pod:\n$ kubectl apply -f soapostinstall.yaml Perform post-installation steps If you need to perform any post-installation steps on the domain home:\n Start a bash shell in the soapostinstall pod:\n$ kubectl exec -it -n soans soapostinstall -- bash This opens a bash shell in the running soapostinstall pod:\n[oracle@soapostinstall oracle]$ Use the bash shell of the soapostinstall pod and perform the required steps on the domain home.\n After successful completion of the post-installation steps, you can delete the soapostinstall pod:\n$ kubectl delete -f soapostinstall.yaml Apply the patched image After completing the required SOA schema upgrade and post-installation steps, start up the domain:\n In the domain.yaml configuration file, update the image field value with the patched image:\nFor example:\n image: soasuite:12.2.1.4-30761841 In case of non-Zero Downtime Patching, update the spec.serverStartPolicy field value to IF_NEEDED (for Operator 3.x) or IfNeeded (for Operator 4.x) in domain.yaml.\n Apply the updated domain.yaml configuration file to start up the domain.\n$ kubectl apply -f domain.yaml Note: In case of non-Zero Downtime Patching, the complete domain startup happens, as the servers in the domain were stopped earlier. For Zero Downtime Patching, the servers in the domain are rolling restarted.\n Verify the domain is updated with the patched image:\n$ kubectl describe domain \u0026lt;domainUID\u0026gt; -n \u0026lt;domain-namespace\u0026gt;|grep \u0026quot;Image:\u0026quot; Sample output:\n$ kubectl describe domain soainfra -n soans |grep \u0026quot;Image:\u0026quot; Image: soasuite:12.2.1.4-30761841 $ "
+},
+{
+ "uri": "/fmw-kubernetes/24.2.2/soa-domains/adminguide/configure-load-balancer/",
+ "title": "Set up a load balancer",
+ "tags": [],
+ "description": "Configure different load balancers for Oracle SOA Suite domains.",
+ "content": "The WebLogic Kubernetes Operator supports ingress-based load balancers such as Traefik and NGINX (kubernetes/ingress-nginx). It also supports Apache web tier load balancer.\n Traefik Configure the ingress-based Traefik load balancer for Oracle SOA Suite domains.\n NGINX Configure the ingress-based NGINX load balancer for Oracle SOA Suite domains.\n Apache web tier Configure the Apache web tier load balancer for Oracle SOA Suite domains.\n "
+},
+{
+ "uri": "/fmw-kubernetes/24.2.2/soa-domains/adminguide/configure-load-balancer/traefik/",
+ "title": "Traefik",
+ "tags": [],
+ "description": "Configure the ingress-based Traefik load balancer for Oracle SOA Suite domains.",
+ "content": "This section provides information about how to install and configure the ingress-based Traefik load balancer (version 2.2.1 or later for production deployments) to load balance Oracle SOA Suite domain clusters. You can configure Traefik for non-SSL, SSL termination, and end-to-end SSL access of the application URL.\nFollow these steps to set up Traefik as a load balancer for an Oracle SOA Suite domain in a Kubernetes cluster:\n Install the Traefik (ingress-based) load balancer Create an Ingress for the domain Verify domain application URL access Uninstall the Traefik ingress Uninstall Traefik Install the Traefik (ingress-based) load balancer Use Helm to install the Traefik (ingress-based) load balancer. Use the values.yaml file in the sample but set kubernetes.namespaces specifically.\n$ cd ${WORKDIR} $ kubectl create namespace traefik $ helm repo add traefik https://helm.traefik.io/traefik --force-update Sample output:\n\u0026#34;traefik\u0026#34; has been added to your repositories Install Traefik:\n$ helm install traefik traefik/traefik \\ --namespace traefik \\ --values charts/traefik/values.yaml \\ --set \u0026#34;kubernetes.namespaces={traefik}\u0026#34; \\ --set \u0026#34;service.type=NodePort\u0026#34; --wait Click here to see the sample output. LAST DEPLOYED: Sun Sep 13 21:32:00 2020 NAMESPACE: traefik STATUS: deployed REVISION: 1 TEST SUITE: None A sample values.yaml for deployment of Traefik:\nimage: name: traefik pullPolicy: IfNotPresent ingressRoute: dashboard: enabled: true # Additional ingressRoute annotations (e.g. for kubernetes.io/ingress.class) annotations: {} # Additional ingressRoute labels (e.g. for filtering IngressRoute by custom labels) labels: {} providers: kubernetesCRD: enabled: true kubernetesIngress: enabled: true # IP used for Kubernetes Ingress endpoints ports: traefik: port: 9000 expose: true # The exposed port for this service exposedPort: 9000 # The port protocol (TCP/UDP) protocol: TCP web: port: 8000 # hostPort: 8000 expose: true exposedPort: 30305 nodePort: 30305 # The port protocol (TCP/UDP) protocol: TCP # Use nodeport if set. This is useful if you have configured Traefik in a # LoadBalancer # nodePort: 32080 # Port Redirections # Added in 2.2, you can make permanent redirects via entrypoints. # https://docs.traefik.io/routing/entrypoints/#redirection # redirectTo: websecure websecure: port: 8443 # # hostPort: 8443 expose: true exposedPort: 30443 # The port protocol (TCP/UDP) protocol: TCP nodePort: 30443 Verify the Traefik status and find the port number of the SSL and non-SSL services:\n$ kubectl get all -n traefik Click here to see the sample output. NAME READY STATUS RESTARTS AGE pod/traefik-5fc4947cf9-fbl9r 1/1 Running 5 7d17h NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/traefik NodePort 10.100.195.70 \u0026lt;none\u0026gt; 9000:31288/TCP,30305:30305/TCP,30443:30443/TCP 7d17h NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/traefik 1/1 1 1 7d17h NAME DESIRED CURRENT READY AGE replicaset.apps/traefik-5fc4947cf9 1 1 1 7d17h Access the Traefik dashboard through the URL http://\u0026lt;MASTERNODE-HOSTNAME\u0026gt;:31288, with the HTTP host traefik.example.com:\n$ curl -H \u0026#34;host: \u0026lt;MASTERNODE-HOSTNAME\u0026gt;\u0026#34; http://\u0026lt;MASTERNODE-HOSTNAME\u0026gt;:31288/dashboard/ Note: Make sure that you specify a fully qualified node name for \u0026lt;MASTERNODE-HOSTNAME\u0026gt;\n Configure Traefik to manage ingresses created in this namespace, where traefik is the Traefik namespace and soans is the namespace of the domain:\n $ helm upgrade traefik traefik/traefik --namespace traefik --reuse-values \\ --set \u0026#34;kubernetes.namespaces={traefik,soans}\u0026#34; Click here to see the sample output. Release \u0026#34;traefik\u0026#34; has been upgraded. Happy Helming! NAME: traefik LAST DEPLOYED: Sun Sep 13 21:32:12 2020 NAMESPACE: traefik STATUS: deployed REVISION: 2 TEST SUITE: None Create an ingress for the domain Create an ingress for the domain in the domain namespace by using the sample Helm chart. Here path-based routing is used for ingress. Sample values for default configuration are shown in the file ${WORKDIR}/charts/ingress-per-domain/values.yaml. By default, type is TRAEFIK, sslType is NONSSL, and domainType is soa. These values can be overridden by passing values through the command line or can be edited in the sample file values.yaml based on the type of configuration (NONSSL, SSL, and E2ESSL).\nIf needed, you can update the ingress YAML file to define more path rules (in section spec.rules.host.http.paths) based on the domain application URLs that need to be accessed. The template YAML file for the Traefik (ingress-based) load balancer is located at ${WORKDIR}/charts/ingress-per-domain/templates/traefik-ingress.yaml.\n Note: See here for all the configuration parameters.\n Choose an appropriate LOADBALANCER_HOSTNAME for accessing the Oracle SOA Suite domain application URLs.\n$ export LOADBALANCER_HOSTNAME=\u0026lt;LOADBALANCER_HOSTNAME\u0026gt; For example, if you are executing the commands from a master node terminal, where the master hostname is LOADBALANCER_HOSTNAME:\n$ export LOADBALANCER_HOSTNAME=$(hostname -f) Install ingress-per-domain using Helm for NONSSL configuration:\n$ cd ${WORKDIR} $ helm install soa-traefik-ingress \\ charts/ingress-per-domain \\ --namespace soans \\ --values charts/ingress-per-domain/values.yaml \\ --set \u0026#34;traefik.hostname=${LOADBALANCER_HOSTNAME}\u0026#34; Sample output:\nNAME: soa-traefik-ingress LAST DEPLOYED: Mon Jul 20 11:44:13 2020 NAMESPACE: soans STATUS: deployed REVISION: 1 TEST SUITE: None For secured access (SSL termination and E2ESSL) to the Oracle SOA Suite application, create a certificate, and generate a Kubernetes secret:\n$ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /tmp/tls1.key -out /tmp/tls1.crt -subj \u0026#34;/CN=*\u0026#34; $ kubectl -n soans create secret tls soainfra-tls-cert --key /tmp/tls1.key --cert /tmp/tls1.crt Create the Traefik TLSStore custom resource.\nIn case of SSL termination, Traefik should be configured to use the user-defined SSL certificate. If the user-defined SSL certificate is not configured, Traefik will create a default SSL certificate. To configure a user-defined SSL certificate for Traefik, use the TLSStore custom resource. The Kubernetes secret created with the SSL certificate should be referenced in the TLSStore object. Run the following command to create the TLSStore:\n$ cat \u0026lt;\u0026lt;EOF | kubectl apply -f - apiVersion: traefik.containo.us/v1alpha1 kind: TLSStore metadata: name: default namespace: soans spec: defaultCertificate: secretName: soainfra-tls-cert EOF Install ingress-per-domain using Helm for SSL configuration.\nThe Kubernetes secret name should be updated in the template file.\nThe template file also contains the following annotations:\ntraefik.ingress.kubernetes.io/router.entrypoints: websecure traefik.ingress.kubernetes.io/router.tls: \u0026#34;true\u0026#34; traefik.ingress.kubernetes.io/router.middlewares: soans-wls-proxy-ssl@kubernetescrd The entry point for SSL termination access and the Middleware name should be updated in the annotation. The Middleware name should be in the form \u0026lt;namespace\u0026gt;-\u0026lt;middleware name\u0026gt;@kubernetescrd.\n$ cd ${WORKDIR} $ helm install soa-traefik-ingress \\ charts/ingress-per-domain \\ --namespace soans \\ --values charts/ingress-per-domain/values.yaml \\ --set \u0026#34;traefik.hostname=${LOADBALANCER_HOSTNAME}\u0026#34; \\ --set sslType=SSL Sample output:\nNAME: soa-traefik-ingress LAST DEPLOYED: Mon Jul 20 11:44:13 2020 NAMESPACE: soans STATUS: deployed REVISION: 1 TEST SUITE: None Install ingress-per-domain using Helm for E2ESSL configuration.\n Note: To use the E2ESSL configuration, you must have created the Oracle SOA Suite domain with sslEnabled set to true. See Create Oracle SOA Suite domains for details.\n $ cd ${WORKDIR} $ helm install soa-traefik-ingress \\ charts/ingress-per-domain \\ --namespace soans \\ --values charts/ingress-per-domain/values.yaml \\ --set sslType=E2ESSL Sample output:\nNAME: soa-traefik-ingress LAST DEPLOYED: Fri Apr 9 09:47:27 2021 NAMESPACE: soans STATUS: deployed REVISION: 1 TEST SUITE: None For NONSSL access to the Oracle SOA Suite application, get the details of the services by the ingress:\n$ kubectl describe ingress soainfra-traefik -n soans Click here to see all services supported by the above deployed ingress. Name: soainfra-traefik Namespace: soans Address: Default backend: default-http-backend:80 (\u0026lt;error: endpoints \u0026#34;default-http-backend\u0026#34; not found\u0026gt;) Rules: Host Path Backends ---- ---- -------- www.example.com /console soainfra-adminserver:7011 (10.244.0.45:7011) /em soainfra-adminserver:7011 (10.244.0.45:7011) /weblogic/ready soainfra-adminserver:7011 (10.244.0.45:7011) soainfra-cluster-soa-cluster:8011 (10.244.0.46:8011,10.244.0.47:8011) /soa-infra soainfra-cluster-soa-cluster:8011 (10.244.0.46:8011,10.244.0.47:8011) /soa/composer soainfra-cluster-soa-cluster:8011 (10.244.0.46:8011,10.244.0.47:8011) /integration/worklistapp soainfra-cluster-soa-cluster:8011 (10.244.0.46:8011,10.244.0.47:8011) Annotations: kubernetes.io/ingress.class: traefik Events: \u0026lt;none\u0026gt; For SSL access to the Oracle SOA Suite application, get the details of the services by the above deployed ingress:\n$ kubectl describe ingress soainfra-traefik -n soans Click here to see all services supported by the above deployed ingress. ``` Name: soainfra-traefik Namespace: soans Address: Default backend: default-http-backend:80 (\u0026lt;error: endpoints \u0026quot;default-http-backend\u0026quot; not found\u0026gt;) TLS: soainfra-tls-cert terminates www.example.com Rules: Host Path Backends ---- ---- -------- www.example.com /console soainfra-adminserver:7011 () /em soainfra-adminserver:7011 () /weblogic/ready soainfra-adminserver:7011 () soainfra-cluster-soa-cluster:8011 () /soa-infra soainfra-cluster-soa-cluster:8011 () /soa/composer soainfra-cluster-soa-cluster:8011 () /integration/worklistapp soainfra-cluster-soa-cluster:8011 () Annotations: kubernetes.io/ingress.class: traefik meta.helm.sh/release-name: soa-traefik-ingress meta.helm.sh/release-namespace: soans traefik.ingress.kubernetes.io/router.entrypoints: websecure traefik.ingress.kubernetes.io/router.middlewares: soans-wls-proxy-ssl@kubernetescrd traefik.ingress.kubernetes.io/router.tls: true Events: \u0026lt;none\u0026gt; ``` For E2ESSL access to the Oracle SOA Suite application, get the details of the services by the above deployed ingress:\n$ kubectl describe IngressRouteTCP soainfra-traefik -n soans\t Click here to see all services supported by the above deployed ingress. ``` Name: soa-cluster-routetcp Namespace: soans Labels: app.kubernetes.io/managed-by=Helm Annotations: meta.helm.sh/release-name: soa-traefik-ingress meta.helm.sh/release-namespace: soans API Version: traefik.containo.us/v1alpha1 Kind: IngressRouteTCP Metadata: Creation Timestamp: 2021-04-09T09:47:27Z Generation: 1 Managed Fields: API Version: traefik.containo.us/v1alpha1 Fields Type: FieldsV1 fieldsV1: f:metadata: f:annotations: .: f:meta.helm.sh/release-name: f:meta.helm.sh/release-namespace: f:labels: .: f:app.kubernetes.io/managed-by: f:spec: .: f:entryPoints: f:routes: f:tls: .: f:passthrough: Manager: Go-http-client Operation: Update Time: 2021-04-09T09:47:27Z Resource Version: 548305 Self Link: /apis/traefik.containo.us/v1alpha1/namespaces/soans/ingressroutetcps/soa-cluster-routetcp UID: 933e524c-b773-474b-a87f-560d69f08d4b Spec: Entry Points: websecure Routes: Match: HostSNI(`HostName`) Services: Termination Delay: 400 Name: soainfra-adminserver Port: 7012 Weight: 3 Tls: Passthrough: true Events: \u0026lt;none\u0026gt; ``` To confirm that the load balancer noticed the new ingress and is successfully routing to the domain server pods, you can send a request to the URL for the \u0026ldquo;WebLogic ReadyApp framework\u0026rdquo;, which should return an HTTP 200 status code, as follows:\n$ curl -v http://${LOADBALANCER_HOSTNAME}:${LOADBALANCER_PORT}/weblogic/ready * Trying 149.87.129.203... \u0026gt; GET http://${LOADBALANCER_HOSTNAME}:${LOADBALANCER_PORT}/weblogic/ready HTTP/1.1 \u0026gt; User-Agent: curl/7.29.0 \u0026gt; Accept: */* \u0026gt; Proxy-Connection: Keep-Alive \u0026gt; host: ${LOADBALANCER_HOSTNAME} \u0026gt; \u0026lt; HTTP/1.1 200 OK \u0026lt; Date: Sat, 14 Mar 2020 08:35:03 GMT \u0026lt; Vary: Accept-Encoding \u0026lt; Content-Length: 0 \u0026lt; Proxy-Connection: Keep-Alive \u0026lt; * Connection #0 to host localhost left intact Verify domain application URL access For NONSSL configuration After setting up the Traefik (ingress-based) load balancer, verify that the domain application URLs are accessible through the non-SSL load balancer port 30305 for HTTP access. The sample URLs for Oracle SOA Suite domain of type soa are:\nhttp://${LOADBALANCER_HOSTNAME}:${LOADBALANCER_NON_SSLPORT}/weblogic/ready http://${LOADBALANCER_HOSTNAME}:${LOADBALANCER_NON_SSLPORT}/console http://${LOADBALANCER_HOSTNAME}:${LOADBALANCER_NON_SSLPORT}/em http://${LOADBALANCER_HOSTNAME}:${LOADBALANCER_NON_SSLPORT}/soa-infra http://${LOADBALANCER_HOSTNAME}:${LOADBALANCER_NON_SSLPORT}/soa/composer http://${LOADBALANCER_HOSTNAME}:${LOADBALANCER_NON_SSLPORT}/integration/worklistapp For SSL configuration After setting up the Traefik (ingress-based) load balancer, verify that the domain applications are accessible through the SSL load balancer port 30443 for HTTPS access. The sample URLs for Oracle SOA Suite domain of type soa are:\nhttps://${LOADBALANCER_HOSTNAME}:${LOADBALANCER_SSLPORT}/weblogic/ready https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER_SSLPORT}/console https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER_SSLPORT}/em https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER_SSLPORT}/soa-infra https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER_SSLPORT}/soa/composer https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER_SSLPORT}/integration/worklistapp For E2ESSL configuration After setting up the Traefik (ingress-based) load balancer, verify that the domain applications are accessible through the SSL load balancer port 30443 for HTTPS access.\n To access the application URLs from the browser, update /etc/hosts on the browser host (in Windows, C:\\Windows\\System32\\Drivers\\etc\\hosts) with the entries below\nX.X.X.X admin.org X.X.X.X soa.org X.X.X.X osb.org Note: The value of X.X.X.X is the host ipaddress on which this ingress is deployed.\n Note: If you are behind any corporate proxy, make sure to update the browser proxy settings appropriately to access the host names updated /etc/hosts file.\n The sample URLs for Oracle SOA Suite domain of type soa are:\nhttps://admin.org:${LOADBALANCER_SSLPORT}/weblogic/ready https://admin.org:${LOADBALANCER_SSLPORT}/console https://admin.org:${LOADBALANCER_SSLPORT}/em https://soa.org:${LOADBALANCER_SSLPORT}/soa-infra https://soa.org:${LOADBALANCER_SSLPORT}/soa/composer https://soa.org:${LOADBALANCER_SSLPORT}/integration/worklistapp Uninstall the Traefik ingress Uninstall and delete the ingress deployment:\n$ helm delete soa-traefik-ingress -n soans Uninstall Traefik $ helm delete traefik -n traefik "
+},
+{
+ "uri": "/fmw-kubernetes/24.2.2/soa-domains/edg-guide/setup-edg/",
+ "title": "Setup steps",
+ "tags": [],
+ "description": "Set up Oracle SOA Suite Enterprise Deployment on Kubernetes.",
+ "content": "This section provides recommended steps to set up Oracle SOA Suite enterprise deployment on Kubernetes to eliminate single points of failure and to provide high availability.\n Set up your Kubernetes cluster Prepare the environment Configure firewalls and network Load Oracle SOA Suite images on all the worker nodes Enable a shared storage location for the persistent volume Create a database and the appropriate database services Install and configure Oracle HTTP Server in the DMZ Configure a front-end load balancer Create worker nodes Apply operating system changes for Coherence Deploy WebLogic Kubernetes Operator and Oracle SOA Suite Configure redundant persistent volume Configure the required priority for mounts Set front-end addresses Enable FAN for GridLink data sources Configure ASM Configure coredns allocation Adjust server\u0026rsquo;s pods Liveness Probe Set up your Kubernetes cluster Prepare the environment for the Kubernetes control plane (Master nodes) Create the L4/TCP listener for the load balancer (LBR).\n Create the LBR backend pool with the list of control plane nodes that will be added (do not use IPs, always use hostnames).\n Note: We recommend maintaining the values of the following kube-api backend pool parameters within the prescribed range to minimize the downtime while restarting the Kubernetes control pane or performing maintenance operations.\n Healthcheck interval : Within 1000 milliseconds Healthcheck timeout : Within 900 milliseconds Enable the L4 LBR to route to the backend set/pool.\n Note: It is important that this is an L4/TCP listener, not an HTTP/HTTPS listener.\n Make sure that the nodes are in ready state.\n Create an ssh key (use a common ssh key to enable access from the node executing the setup to the control plane nodes).\n Allow traffic in intermediate firewalls between control plane nodes and the front-end LBR. Refer to the Kubernetes documentation for the required ports.\n Set up Master nodes Refer to the README to set up the master nodes.\n Note: It is recommended to set up the control plane (Master) with three nodes. See the Topology for more details.\n Prepare the environment Configure firewalls and network Allow traffic from the load balancer (LBR) to the Oracle HTTP Server (OHS) port that will be configured (7777 by default for OHS). Allow traffic from the OHS to the node port that will be configured in the worker nodes for the Administration Server (30701), SOA cluster (30801), and Service Bus cluster (30901). Allow traffic from the worker nodes to the control plane front-end kube-api virtual server port and also to the front-end Oracle SOA Suite. Allow traffic from worker nodes to the database listener and ONS port (1521 and 6200 by default, respectively). You can use the Enterprise Deployment Guide for Oracle SOA Suite on-premise as a reference.\nLoad Oracle SOA Suite images on all the worker nodes Refer to Obtain the Oracle SOA Suite Docker image to load the images on each worker node and tag appropriately.\nEnable a shared storage location for the persistent volume A shared storage device must be used from the different worker nodes. This storage hosts the Oracle SOA Suite domain directory. Initially, a single storage location is used to create a persistent volume that will host the Oracle SOA Suite domain. Mount this shared storage (NFS/NAS) from all the worker nodes using the same mount path in all of them.\nFor example, mount NFS1 (10.10.0.21:/k8nfs) in all the worker nodes to a share directory /k8nfs:\n$ grep \u0026#34;k8nfs nfs\u0026#34; /etc/fstab 10.10.0.21:/k8nfs /k8nfs nfs rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.10.0.21,mountvers=3,mountport=2048,mountproto=udp,local_lock=none,addr=10.10.0.21 Later, steps are provided to configure a second storage location for high availability.\nCreate a database and the appropriate database services The installation and creation of the RAC database is out of the scope of this document. Once the database is configured, the appropriate services must be created to access the schemas from the middle tier. It is critical that a precise non-default/administration service is created for Oracle SOA Suite. Refer to Preparing the Database for an Enterprise Deployment in the Enterprise Deployment Guide for Oracle SOA Suite 12.2.1.4.\nInstall and configure Oracle HTTP Server in the DMZ Follow the steps in the Enterprise Deployment Guide for Oracle SOA Suite to create two Oracle HTTP Server (OHS) instances in separate nodes from the worker nodes. To configure OHS with the back-end Kubernetes Oracle SOA Suite or Service Bus servers, you must use a port in the range of 30000 - 32767. You will use this port in the Oracle SOA Suite configuration scripts later on.\n Configuring Oracle HTTP Server to Route Requests to the Administration Server URL and WSMPM Configuring the Web Tier for the Oracle SOA Extended Domain Configuring the Web Tier for the Oracle Service Bus Extended Domain In this Kubernetes Enterprise Deployment Guide, OHS routes to node ports configured for each separate Oracle SOA Suite/Service Bus cluster in the SOA domain. OHS then routes to these node ports, which redirect to the pertaining server pods. The OHS directive for the configuration must disable DynamicServerList because the node ports are not really WebLogic listeners and it is the node port configuration that maintains an intelligent list of available WebLogic servers. The OHS directive for the soa-infra mount in OHS looks like this:\n\u0026lt;Location /soa-infra\u0026gt; WLSRequest ON DynamicServerList OFF WebLogicCluster workernode1:30801,workernode2:30801,workernode3:30801 WLProxySSL OFF WLProxySSLPassThrough OFF \u0026lt;/Location\u0026gt; Similarly, the other directives for other paths should reflect similar node port addresses.\nConfigure a front-end load balancer You can either use BigIp F5 LBR or any standard LBR, such as CISCO. Refer to the Enterprise Deployment Guide for Oracle SOA Suite for the required virtual servers: Preparing the Load Balancer and Firewalls for an Enterprise Deployment. The on-premises Enterprise Deployment Guide provides a detailed list of virtual servers/listeners that can be used for optimum isolation of services and traffic. For Kubernetes, at a minimum you should have a virtual server/listener for Oracle SOA Suite using the OHS listeners as back-end pool.\n Create the load balancer\u0026rsquo;s L7/http listener.\n Create a back-end pool with the list of OHS nodes/ports that will be used by Oracle SOA Suite (do not use IPs, always use hostnames).\n Enable the L7/http listener load balancer to route to the OHS back-end set/pool.\n Configure the front-end load balancer to route to the OHS pool.\n Create worker nodes Refer to Set up Worker nodes for details.\nApply operating system changes for Coherence Coherence requires specific settings to create clusters in a Kubernetes environment. Refer to the steps provided in the WebLogic Kubernetes Operator documentation.\nDeploy WebLogic Kubernetes Operator and Oracle SOA Suite The steps to deploy WebLogic Kubernetes Operator and the Oracle SOA Suite domain are automated with the scripts. Refer to the README for details.\nAfter successful Oracle SOA Suite domain creation and starting the servers, check the pods and the different services created. Once the Oracle SOA Suite managed servers reach RUNNING state (the pods are ready), check typical Oracle SOA Suite URLs using the front-end load balancer:\nSOA pods and services deployed and ready:\n$ kubectl get all -n soans NAME READY STATUS RESTARTS AGE pod/soaedgdomain-adminserver 1/1 Running 0 47h pod/soaedgdomain-create-soa-infra-domain-job-6pq9z 0/1 Completed 0 68d pod/soaedgdomain-soa-server1 1/1 Running 0 2d2h pod/soaedgdomain-soa-server2 1/1 Running 0 2d2h NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/soaedgdomain-adminserver ClusterIP None \u0026lt;none\u0026gt; 30012/TCP,7011/TCP 2d4h service/soaedgdomain-adminserver-ext NodePort 10.104.20.22 \u0026lt;none\u0026gt; 30012:30012/TCP,7011:30701/TCP 31d service/soaedgdomain-cluster-osb-cluster ClusterIP 10.100.97.127 \u0026lt;none\u0026gt; 9011/TCP 68d service/soaedgdomain-cluster-soa-cluster ClusterIP 10.101.101.113 \u0026lt;none\u0026gt; 8011/TCP 68d service/soaedgdomain-cluster-soa-cluster-node-port NodePort 10.105.51.223 \u0026lt;none\u0026gt; 8011:30801/TCP 68d service/soaedgdomain-osb-server1 ClusterIP 10.110.81.153 \u0026lt;none\u0026gt; 9011/TCP 2d4h service/soaedgdomain-osb-server2 ClusterIP 10.103.220.112 \u0026lt;none\u0026gt; 9011/TCP 2d4h service/soaedgdomain-osb-server3 ClusterIP 10.97.50.117 \u0026lt;none\u0026gt; 9011/TCP 2d4h service/soaedgdomain-osb-server4 ClusterIP 10.98.48.247 \u0026lt;none\u0026gt; 9011/TCP 2d4h service/soaedgdomain-osb-server5 ClusterIP 10.102.137.176 \u0026lt;none\u0026gt; 9011/TCP 2d4h service/soaedgdomain-soa-server1 ClusterIP None \u0026lt;none\u0026gt; 8011/TCP 2d4h service/soaedgdomain-soa-server2 ClusterIP None \u0026lt;none\u0026gt; 8011/TCP 2d4h service/soaedgdomain-soa-server3 ClusterIP 10.105.108.74 \u0026lt;none\u0026gt; 8011/TCP 2d4h service/soaedgdomain-soa-server4 ClusterIP 10.109.191.102 \u0026lt;none\u0026gt; 8011/TCP 2d4h service/soaedgdomain-soa-server5 ClusterIP 10.107.2.99 \u0026lt;none\u0026gt; 8011/TCP 2d4h NAME COMPLETIONS DURATION AGE job.batch/soaedgdomain-create-soa-infra-domain-job 1/1 4m24s 68d Configure redundant persistent volume To increase the flexibility in moving Oracle SOA Suite or Service Bus pods around in the Kubernetes cluster, we use node selectors where odd server pods (soa_server1, soa_server3, soa_server5, and so on) are assigned to node selector 1 and even server pods (soa_server2, soa_server4, soa_server6, and so on) are assigned to node selector 2. The resulting configuration is:\nTo use this configuration, follow these steps:\n Stop the Oracle SOA Suite domain. Refer to Scripts to start and stop a domain.\n Mount NFS1 in all even worker nodes and NFS2 in all odd worker nodes as in the diagram above. For example:\nMOUNT ON ODD NODE [opc@olk8-w1 ~]$ grep \u0026#34;k8nfs nfs\u0026#34; /etc/fstab 10.10.0.21:/k8nfs /k8nfs nfs rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.10.0.21,mountvers=3,mountport=2048,mountproto=udp,local_lock=none,addr=10.10.0.21 MOUNT ON EVEN NODE [opc@olk8-w2 ~]$ grep \u0026#34;k8nfs nfs\u0026#34; /etc/fstab 10.10.0.27:/k8nfs2 /k8nfs nfs rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.10.0.27,mo untvers=3,mountport=2048,mountproto=udp,local_lock=none,addr=10.10.0.27 MOUNT ON ODD NODE [opc@olk8-w3 ~]$ grep \u0026#34;k8nfs nfs\u0026#34; /etc/fstab 10.10.0.21:/k8nfs /k8nfs nfs rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.10.0.21,mountvers=3, mountport=2048,mountproto=udp,local_lock=none,addr=10.10.0.21 Copy the domain mount to an NFS replica, NFS2 (this can be done through a snapshot or through direct sftp/secure copy).\nFor example, if the domain is deployed in /k8nfs hosted by NFS1, after stopping the domain, secure copy the data present at /k8nfs on NFS1 to /k8nfs2 on NFS2:\n$ cd /k8nfs $ scp -R * user@[NFS2]:/k8nfs2 Label the odd nodes for NFS1 and the even nodes for NFS2.\nFor example, add the label diskgroup=dg1 for NFS1 and diskgroup=dg2 for NFS2:\n$ kubectl label nodes olk8-w1 diskgroup=dg1 $ kubectl label nodes olk8-w2 diskgroup=dg2 $ kubectl label nodes olk8-w3 diskgroup=dg1 Verify the added labels using the following command:\n$ kubectl get nodes --show-labels Sample output is:\nNAME STATUS ROLES AGE VERSION LABELS olk8-m1 Ready master 10d v1.XX.X beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=olk8-m1,kubernetes.io/os=linux,node-role.kubernetes.io/master= olk8-m2 Ready master 10d v1.XX.X beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=olk8-m2,kubernetes.io/os=linux,node-role.kubernetes.io/master= olk8-m3 Ready master 10d v1.XX.X beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=olk8-m3,kubernetes.io/os=linux,node-role.kubernetes.io/master= olk8-w1 Ready \u0026lt;none\u0026gt; 10d v1.XX.X beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,diskgroup=dg1,kubernetes.io/arch=amd64,kubernetes.io/hostname=olk8-w1,kubernetes.io/os=linux,name=admin olk8-w2 Ready \u0026lt;none\u0026gt; 10d v1.XX.X beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,diskgroup=dg2,kubernetes.io/arch=amd64,kubernetes.io/hostname=olk8-w2,kubernetes.io/os=linux,name=wls1 olk8-w3 Ready \u0026lt;none\u0026gt; 10d v1.XX.X beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,diskgroup=dg1,kubernetes.io/arch=amd64,kubernetes.io/hostname=olk8-w3,kubernetes.io/os=linux,name=wls2 To assign the appropriate selectors in the domain:\na. Edit the domain (domain.yaml).\nb. Alter the managed servers section for all the managed servers configured in the cluster, sample for soa_server1 and soa_server2 as shown below:\nmanagedServers: - serverName: soa_server1 serverPod: nodeSelector: diskgroup: dg1 - serverName: soa_server2 serverPod: nodeSelector: diskgroup: dg2 c. Apply the domain.yaml changes:\n$ kubectl apply -f domain.yaml IMPORTANT: Once this redundant PV configuration is in use, all changes that reside out of the config directory in the domain will need to be copied/synced to the secondary NAS mount manually. The managed servers using NFS2 in the diagram above will replicate only configuration changes that modify files/artifacts under the $DOMAIN_HOME/config directory. The rest of changes are NOT copied automatically by the WebLogic infrastructure.\n For example, if you deploy an ear and specify an upload or stage directory out of the config directory, the ear files will NOT be copied by WebLogic). Fileadapter composites will place output files in mounts accessible from the pods. The mount point and PV/PVC for the different Oracle SOA Suite server file locations need to be the same, hence a different one from the one used for the $DOMAIN_HOME location.\nConfigure the required priority for mounts When using block volume mounts for the Docker/CRIO images, it may occur that the mount takes time to complete on reboot. This is the case block volume with mount point being affected by network and storage latency. In this case, it is required to adjust the priority and dependency of the process on reboot, otherwise Docker will start and many images will be missing. To resolve this issue:\n Identify the systemd units for the mounts that the container will depend on, including the NFS where the Oracle SOA Suite domain will reside. Identify mount systemd units in the Operating System:\n$ cat /etc/fstab | grep \u0026#34;docker ext4\u0026#34; UUID=c07d39e4-5d8f-47af-b936-bf276cc43664 /docker ext4 defaults,_netdev,nofail 0 2 $ ls /run/systemd/generator/ | grep docker docker.mount scratch-docker.mount Add the units to the Docker/CRIO service as a dependency in the AFTER list. Identify mount systemd units in the operating system expand source:\n$ cat /lib/systemd/system/docker.service | grep After After=network-online.target firewalld.service containerd.service docker.mount This guarantees that the container will start only after the required mount is ready.\n Set front-end addresses For each of the Oracle SOA Suite (soa_cluster) and Service Bus (osb_cluster) clusters, set the appropriate front-end address as follows:\n Sign in to the WebLogic Administration Console.\n Navigate to domain_name -\u0026gt; environment -\u0026gt; clusters.\n Click the cluster name.\n Click the HTTP tab.\n Enter the Frontend Host and Frontend Port details.\n Note: Set the front-end details for each cluster and for the Administration Server.\n Enable FAN for GridLink data sources Data sources in the default deployment for Oracle SOA Suite on Kubernetes use generic data sources. With ONS auto-registration in 12.2 Database and later, it is only necessary to enable FAN for the data sources to convert to GridLink (GLDS). You can do this by using the WebLogic Administration Console or the following command and restarting the Administration Server and the managed servers:\ngrep -L fan-enabled $domain_home/config/jdbc/*.xml | xargs sed -i \u0026#34;s/\u0026lt;\\/jdbc-data-source\u0026gt;/\u0026lt;jdbc-oracle-params\u0026gt;\u0026lt;fan-enabled\u0026gt;true\u0026lt;\\/fan-enabled\u0026gt;\u0026lt;\\/jdbc-oracle-params\u0026gt;\u0026lt;\\/jdbc-data-source\u0026gt;/g\u0026#34; After the change is applied, verify that all data sources are marked as GridLink Data Sources in the WebLogic Administration Console.\nConfigure ASM Refer to the on-premises Enterprise Deployment Guide for steps to configure Automatic Service Migration.\nConfigure coredns allocation NOTE: This step is applicable to any Kubernetes system using coredns regardless of Oracle SOA Suite deployment. However, the worker node creation is implicit in the setup, hence it is applied in this context (post Oracle SOA Suite deployment).\n Configure replicas for cordens to spawn both control plane and master plane. If a restore operation is performed on the control plane, worker nodes may stop working properly. If the coredns lands entirely in the worker nodes, the control plane may not function correctly if they are brought down for maintenance. Place at least two coredns pods on the control plane and another two on the worker nodes. The coredns footprint is low.\nVIRT RES SHR S %CPU %MEM TIME+ COMMAND 146268 41684 29088 S 0.3 0.1 25:44.04 coredns According to the CoreDNS documentation, you can estimate the amount of memory required for a CoreDNS instance (using default settings) with the following formula:\nMB required (default settings) = (Pods + Services) / 1000 + 54 Hence, first label nodes in both control and worker plane.\n$ kubectl label nodes olk8-m1 area=dnsarea $ kubectl label nodes olk8-m2 area=dnsarea $ kubectl label nodes olk8-m3 area=dnsarea $ kubectl label nodes olk8-w1 area=dnsarea $ kubectl label nodes olk8-w2 area=dnsarea $ kubectl label nodes olk8-w3 area=dnsarea And then update the coredns deployment to use topology spread constraints\n NOTE: Topology spread constraints is beta starting in Kubernetes v1.18\n First, enable the feature gate in kube-api server and in kube-scheduler. Then, modify the coredns deployment for an appropriate spread of pods across worker and control plane nodes.\nThe coredns topology spread config details are:\nClick below for sample updated coredns deployment: Coredns deployment YAML $ kubectl get deployment coredns -n kube-system -o yaml apiVersion: apps/v1 kind: Deployment metadata: annotations: deployment.kubernetes.io/revision: \u0026quot;7\u0026quot; creationTimestamp: \u0026quot;2021-01-15T13:15:05Z\u0026quot; generation: 8 labels: area: dnsarea k8s-app: kube-dns managedFields: - apiVersion: apps/v1 fieldsType: FieldsV1 fieldsV1: f:metadata: f:labels: .: {} f:k8s-app: {} f:spec: f:progressDeadlineSeconds: {} f:revisionHistoryLimit: {} f:selector: f:matchLabels: .: {} f:k8s-app: {} f:strategy: f:rollingUpdate: .: {} f:maxSurge: {} f:maxUnavailable: {} f:type: {} f:template: f:metadata: f:labels: .: {} f:k8s-app: {} f:spec: f:containers: k:{\u0026quot;name\u0026quot;:\u0026quot;coredns\u0026quot;}: .: {} f:args: {} f:image: {} f:imagePullPolicy: {} f:livenessProbe: .: {} f:failureThreshold: {} f:httpGet: .: {} f:path: {} f:port: {} f:scheme: {} f:initialDelaySeconds: {} f:periodSeconds: {} f:successThreshold: {} f:timeoutSeconds: {} f:name: {} f:ports: .: {} k:{\u0026quot;containerPort\u0026quot;:53,\u0026quot;protocol\u0026quot;:\u0026quot;TCP\u0026quot;}: .: {} f:containerPort: {} f:name: {} f:protocol: {} k:{\u0026quot;containerPort\u0026quot;:53,\u0026quot;protocol\u0026quot;:\u0026quot;UDP\u0026quot;}: .: {} f:containerPort: {} f:name: {} f:protocol: {} k:{\u0026quot;containerPort\u0026quot;:9153,\u0026quot;protocol\u0026quot;:\u0026quot;TCP\u0026quot;}: .: {} f:containerPort: {} f:name: {} f:protocol: {} f:readinessProbe: .: {} f:failureThreshold: {} f:httpGet: .: {} f:path: {} f:port: {} f:scheme: {} f:periodSeconds: {} f:successThreshold: {} f:timeoutSeconds: {} f:resources: .: {} f:limits: .: {} f:memory: {} f:requests: .: {} f:cpu: {} f:memory: {} f:securityContext: .: {} f:allowPrivilegeEscalation: {} f:capabilities: .: {} f:add: {} f:drop: {} f:readOnlyRootFilesystem: {} f:terminationMessagePath: {} f:terminationMessagePolicy: {} f:volumeMounts: .: {} k:{\u0026quot;mountPath\u0026quot;:\u0026quot;/etc/coredns\u0026quot;}: .: {} f:mountPath: {} f:name: {} f:readOnly: {} f:dnsPolicy: {} f:nodeSelector: .: {} f:kubernetes.io/os: {} f:priorityClassName: {} f:restartPolicy: {} f:schedulerName: {} f:securityContext: {} f:serviceAccount: {} f:serviceAccountName: {} f:terminationGracePeriodSeconds: {} f:tolerations: {} f:volumes: .: {} k:{\u0026quot;name\u0026quot;:\u0026quot;config-volume\u0026quot;}: .: {} f:configMap: .: {} f:defaultMode: {} f:items: {} f:name: {} f:name: {} manager: kubeadm operation: Update time: \u0026quot;2021-01-15T13:15:05Z\u0026quot; - apiVersion: apps/v1 fieldsType: FieldsV1 fieldsV1: f:metadata: f:labels: f:area: {} f:spec: f:replicas: {} f:template: f:metadata: f:annotations: .: {} f:kubectl.kubernetes.io/restartedAt: {} f:labels: f:foo: {} f:spec: f:topologySpreadConstraints: .: {} k:{\u0026quot;topologyKey\u0026quot;:\u0026quot;area\u0026quot;,\u0026quot;whenUnsatisfiable\u0026quot;:\u0026quot;DoNotSchedule\u0026quot;}: .: {} f:labelSelector: .: {} f:matchLabels: .: {} f:foo: {} f:maxSkew: {} f:topologyKey: {} f:whenUnsatisfiable: {} manager: kubectl operation: Update time: \u0026quot;2021-01-28T16:00:21Z\u0026quot; - apiVersion: apps/v1 fieldsType: FieldsV1 fieldsV1: f:metadata: f:annotations: .: {} f:deployment.kubernetes.io/revision: {} f:status: f:availableReplicas: {} f:conditions: .: {} k:{\u0026quot;type\u0026quot;:\u0026quot;Available\u0026quot;}: .: {} f:lastTransitionTime: {} f:lastUpdateTime: {} f:message: {} f:reason: {} f:status: {} f:type: {} k:{\u0026quot;type\u0026quot;:\u0026quot;Progressing\u0026quot;}: .: {} f:lastTransitionTime: {} f:lastUpdateTime: {} f:message: {} f:reason: {} f:status: {} f:type: {} f:observedGeneration: {} f:readyReplicas: {} f:replicas: {} f:updatedReplicas: {} manager: kube-controller-manager operation: Update time: \u0026quot;2021-01-28T16:00:39Z\u0026quot; name: coredns namespace: kube-system resourceVersion: \u0026quot;2520507\u0026quot; selfLink: /apis/apps/v1/namespaces/kube-system/deployments/coredns uid: 79d24e61-98f4-434f-b682-132625b04c49 spec: progressDeadlineSeconds: 600 replicas: 4 revisionHistoryLimit: 10 selector: matchLabels: k8s-app: kube-dns strategy: rollingUpdate: maxSurge: 25% maxUnavailable: 1 type: RollingUpdate template: metadata: annotations: kubectl.kubernetes.io/restartedAt: \u0026quot;2021-01-28T15:29:48Z\u0026quot; creationTimestamp: null labels: foo: bar k8s-app: kube-dns spec: containers: - args: - -conf - /etc/coredns/Corefile image: k8s.gcr.io/coredns:1.6.7 imagePullPolicy: IfNotPresent livenessProbe: failureThreshold: 5 httpGet: path: /health port: 8080 scheme: HTTP initialDelaySeconds: 60 periodSeconds: 10 successThreshold: 1 timeoutSeconds: 5 name: coredns ports: - containerPort: 53 name: dns protocol: UDP - containerPort: 53 name: dns-tcp protocol: TCP - containerPort: 9153 name: metrics protocol: TCP readinessProbe: failureThreshold: 3 httpGet: path: /ready port: 8181 scheme: HTTP periodSeconds: 10 successThreshold: 1 timeoutSeconds: 1 resources: limits: memory: 170Mi requests: cpu: 100m memory: 70Mi securityContext: allowPrivilegeEscalation: false capabilities: add: - NET_BIND_SERVICE drop: - all readOnlyRootFilesystem: true terminationMessagePath: /dev/termination-log terminationMessagePolicy: File volumeMounts: - mountPath: /etc/coredns name: config-volume readOnly: true dnsPolicy: Default nodeSelector: kubernetes.io/os: linux priorityClassName: system-cluster-critical restartPolicy: Always schedulerName: default-scheduler securityContext: {} serviceAccount: coredns serviceAccountName: coredns terminationGracePeriodSeconds: 30 tolerations: - key: CriticalAddonsOnly operator: Exists - effect: NoSchedule key: node-role.kubernetes.io/master topologySpreadConstraints: - labelSelector: matchLabels: foo: bar maxSkew: 1 topologyKey: area whenUnsatisfiable: DoNotSchedule volumes: - configMap: defaultMode: 420 items: - key: Corefile path: Corefile name: coredns name: config-volume status: availableReplicas: 4 conditions: - lastTransitionTime: \u0026quot;2021-01-21T19:08:12Z\u0026quot; lastUpdateTime: \u0026quot;2021-01-21T19:08:12Z\u0026quot; message: Deployment has minimum availability. reason: MinimumReplicasAvailable status: \u0026quot;True\u0026quot; type: Available - lastTransitionTime: \u0026quot;2021-01-28T15:29:48Z\u0026quot; lastUpdateTime: \u0026quot;2021-01-28T16:00:39Z\u0026quot; message: ReplicaSet \u0026quot;coredns-84b49c57fd\u0026quot; has successfully progressed. reason: NewReplicaSetAvailable status: \u0026quot;True\u0026quot; type: Progressing observedGeneration: 8 readyReplicas: 4 replicas: 4 updatedReplicas: 4 \nThe labels and spread topology changes are:\nlabels: foo: bar k8s-app: kube-dns topologySpreadConstraints: - labelSelector: matchLabels: foo: bar maxSkew: 1 topologyKey: area whenUnsatisfiable: DoNotSchedule This guarantees an even distribution across the master and worker nodes, so that if the control plane is restored, the worker pods will continue without issues and the other way around.\nSample resulting coredns distribution:\n$ kubectl get pods -A -o wide | grep coredns kube-system coredns-84b49c57fd-4fz4g 1/1 Running 0 166m 10.244.1.20 olk8-m2 \u0026lt;none\u0026gt; \u0026lt;none\u0026gt; kube-system coredns-84b49c57fd-5mrkw 1/1 Running 0 165m 10.244.4.76 olk8-w2 \u0026lt;none\u0026gt; \u0026lt;none\u0026gt; kube-system coredns-84b49c57fd-5zm88 1/1 Running 0 165m 10.244.2.17 olk8-m3 \u0026lt;none\u0026gt; \u0026lt;none\u0026gt; kube-system coredns-84b49c57fd-nqlwb 1/1 Running 0 166m 10.244.4.75 olk8-w2 \u0026lt;none\u0026gt; \u0026lt;none\u0026gt; Adjust server\u0026rsquo;s pods Liveness Probe By default, the liveness probe is configured to check liveness every 45 seconds, which might cause requests to be routed to backend pods that are no longer available during outage scenarios. Recommended to adjust liveness probe values so that on hard node failures pods are marked as down faster. To configure a more aggressive probe, edit the domain and change the serverPods.livenessProbe values to the following:\nlivenessProbe: failureThreshold: 1 initialDelaySeconds: 30 periodSeconds: 5 successThreshold: 1 timeoutSeconds: 3 Refer WebLogic Kubernetes Operator documentation for details on how to customize the liveness probe.\n"
+},
+{
+ "uri": "/fmw-kubernetes/24.2.2/soa-domains/installguide/",
+ "title": "Install Guide",
+ "tags": [],
+ "description": "",
+ "content": "Install the WebLogic Kubernetes Operator and prepare and deploy Oracle SOA Suite domains.\n Requirements and pricing Understand the system requirements, limitations, licensing, and pricing for deploying and running Oracle SOA Suite domains with the WebLogic Kubernetes Operator, including the SOA cluster sizing.\n Prepare your environment Prepare for creating Oracle SOA Suite domains, including required secrets creation, persistent volume and volume claim creation, database creation, and database schema creation.\n Create Oracle SOA Suite domains Create an Oracle SOA Suite domain home on an existing PV or PVC, and create the domain resource YAML file for deploying the generated Oracle SOA Suite domain.\n "
+},
+{
+ "uri": "/fmw-kubernetes/24.2.2/soa-domains/appendix/quickstart-deployment-on-prem/",
+ "title": "Quick start deployment on-premise",
+ "tags": [],
+ "description": "Describes how to quickly get an Oracle SOA Suite domain instance running (using the defaults, nothing special) for development and test purposes.",
+ "content": "Use this Quick Start to create an Oracle SOA Suite domain deployment in a Kubernetes cluster (on-premise environments) with the WebLogic Kubernetes Operator. Note that this walkthrough is for demonstration purposes only, not for use in production. These instructions assume that you are already familiar with Kubernetes. If you need more detailed instructions, refer to the Install Guide.\nHardware requirements The Linux kernel supported for deploying and running Oracle SOA Suite domains with the operator is Oracle Linux 8 and Red Hat Enterprise Linux 8. Refer to the prerequisites for more details.\nFor this exercise, the minimum hardware requirements to create a single-node Kubernetes cluster and then deploy the soaosb (Oracle SOA Suite, Oracle Service Bus, and Enterprise Scheduler (ESS)) domain type with one Managed Server for Oracle SOA Suite and one for the Oracle Service Bus cluster, along with Oracle Database running as a container are:\n Hardware Size RAM 32GB Disk Space 250GB+ CPU core(s) 6 See here for resource sizing information for Oracle SOA Suite domains set up on a Kubernetes cluster.\nSet up Oracle SOA Suite in an on-premise environment Use the steps in this topic to create a single-instance on-premise Kubernetes cluster and then create an Oracle SOA Suite soaosb domain type, which deploys a domain with Oracle SOA Suite, Oracle Service Bus, and Oracle Enterprise Scheduler (ESS).\n Step 1 - Prepare a virtual machine for the Kubernetes cluster Step 2 - Set up a single instance Kubernetes cluster Step 3 - Get scripts and images Step 4 - Install the WebLogic Kubernetes Operator Step 5 - Install the Traefik (ingress-based) load balancer Step 6 - Create and configure an Oracle SOA Suite domain 1. Prepare a virtual machine for the Kubernetes cluster For illustration purposes, these instructions are for Oracle Linux 8. If you are using a different flavor of Linux, you will need to adjust the steps accordingly.\nThese steps must be run with the root user, unless specified otherwise. Any time you see YOUR_USERID in a command, you should replace it with your actual userid.\n 1.1 Prerequisites Choose the directories where your Kubernetes files will be stored. The Kubernetes directory is used for the /var/lib/kubelet file system and persistent volume storage.\n$ export kubelet_dir=/u01/kubelet $ mkdir -p $kubelet_dir $ ln -s $kubelet_dir /var/lib/kubelet Verify that IPv4 forwarding is enabled on your host.\nNote: Replace eth0 with the ethernet interface name of your compute resource if it is different.\n$ /sbin/sysctl -a 2\u0026gt;\u0026amp;1|grep -s \u0026#39;net.ipv4.conf.eth0.forwarding\u0026#39; $ /sbin/sysctl -a 2\u0026gt;\u0026amp;1|grep -s \u0026#39;net.ipv4.conf.lo.forwarding\u0026#39; $ /sbin/sysctl -a 2\u0026gt;\u0026amp;1|grep -s \u0026#39;net.ipv4.ip_nonlocal_bind\u0026#39; For example: Verify that all are set to 1:\n$ net.ipv4.conf.eth0.forwarding = 1 $ net.ipv4.conf.lo.forwarding = 1 $ net.ipv4.ip_nonlocal_bind = 1 Solution: Set all values to 1 immediately:\n$ /sbin/sysctl net.ipv4.conf.eth0.forwarding=1 $ /sbin/sysctl net.ipv4.conf.lo.forwarding=1 $ /sbin/sysctl net.ipv4.ip_nonlocal_bind=1 To preserve the settings permanently: Update the above values to 1 in files in /usr/lib/sysctl.d/, /run/sysctl.d/, and /etc/sysctl.d/.\n Verify the iptables rule for forwarding.\nKubernetes uses iptables to handle many networking and port forwarding rules. A standard container installation may create a firewall rule that prevents forwarding.\nVerify if the iptables rule to accept forwarding traffic is set:\n$ /sbin/iptables -L -n | awk \u0026#39;/Chain FORWARD / {print $4}\u0026#39; | tr -d \u0026#34;)\u0026#34; If the output is \u0026ldquo;DROP\u0026rdquo;, then run the following command:\n$ /sbin/iptables -P FORWARD ACCEPT Verify if the iptables rule is properly set to \u0026ldquo;ACCEPT\u0026rdquo;:\n$ /sbin/iptables -L -n | awk \u0026#39;/Chain FORWARD / {print $4}\u0026#39; | tr -d \u0026#34;)\u0026#34; Disable and stop firewalld:\n$ systemctl disable firewalld $ systemctl stop firewalld 1.2 Install CRI-O and Podman Note: If you have already configured CRI-O and Podman, continue to Install and configure Kubernetes.\n Make sure that you have the right operating system version:\n$ uname -a $ more /etc/oracle-release Example output:\nLinux xxxxxx 5.15.0-100.96.32.el8uek.x86_64 #2 SMP Tue Feb 27 18:08:15 PDT 2024 x86_64 x86_64 x86_64 GNU/Linux Oracle Linux Server release 8.6 Installing CRI-O:\n### Add OLCNE( Oracle Cloud Native Environment ) Repository to dnf config-manager. This allows dnf to install the additional packages required for CRI-O installation. $ dnf config-manager --add-repo https://yum.oracle.com/repo/OracleLinux/OL9/olcne18/x86_64 ### Installing cri-o $ dnf install -y cri-o Note: To install a different version of CRI-O or on a different operating system, see CRI-O Installation Instructions.\n Start the CRI-O service:\nSet up Kernel Modules and Proxies\n### Enable kernel modules overlay and br_netfilter which are required for Kubernetes Container Network Interface (CNI) plugins $ modprobe overlay $ modprobe br_netfilter ### To automatically load these modules at system start up create config as below $ cat \u0026lt;\u0026lt;EOF \u0026gt; /etc/modules-load.d/crio.conf overlay br_netfilter EOF $ sysctl --system ### Set the environmental variable CONTAINER_RUNTIME_ENDPOINT to crio.sock to use crio as the container runtime $ export CONTAINER_RUNTIME_ENDPOINT=unix:///var/run/crio/crio.sock ### Setup Proxy for CRIO service $ cat \u0026lt;\u0026lt;EOF \u0026gt; /etc/sysconfig/crio http_proxy=http://REPLACE-WITH-YOUR-COMPANY-PROXY-HOST:PORT https_proxy=http://REPLACE-WITH-YOUR-COMPANY-PROXY-HOST:PORT HTTPS_PROXY=http://REPLACE-WITH-YOUR-COMPANY-PROXY-HOST:PORT HTTP_PROXY=http://REPLACE-WITH-YOUR-COMPANY-PROXY-HOST:PORT no_proxy=localhost,127.0.0.0/8,ADD-YOUR-INTERNAL-NO-PROXY-LIST,/var/run/crio/crio.sock NO_PROXY=localhost,127.0.0.0/8,ADD-YOUR-INTERNAL-NO-PROXY-LIST,/var/run/crio/crio.sock EOF Set the runtime for CRI-O\n### Setting the runtime for crio ## Update crio.conf $ vi /etc/crio/crio.conf ## Append following under [crio.runtime] conmon_cgroup = \u0026#34;kubepods.slice\u0026#34; cgroup_manager = \u0026#34;systemd\u0026#34; ## Uncomment following under [crio.network] network_dir=\u0026#34;/etc/cni/net.d\u0026#34; plugin_dirs=[ \u0026#34;/opt/cni/bin\u0026#34;, \u0026#34;/usr/libexec/cni\u0026#34;, ] Start the CRI-O Service\n## Restart crio service $ systemctl restart crio.service $ systemctl enable --now crio Installing Podman:\nOn Oracle Linux 8, if podman is not available, then install Podman and related tools with following command syntax:\n$ sudo dnf module install container-tools:ol8 On Oracle Linux 9, if podman is not available, then install Podman and related tools with following command syntax:\n$ sudo dnf install container-tools Since the setup uses \u0026ldquo;docker\u0026rdquo; CLI commands, on Oracle Linux 8/9, install the podman-docker package if not available, that effectively aliases the docker command to podman,with following command syntax:\n$ sudo dnf install podman-docker Configure Podman rootless:\nFor using podman with your User ID (Rootless environment), Podman requires the user running it to have a range of UIDs listed in the files /etc/subuid and /etc/subgid. Rather than updating the files directly, the usermod program can be used to assign UIDs and GIDs to a user with the following commands:\n$ sudo /sbin/usermod --add-subuids 100000-165535 --add-subgids 100000-165535 \u0026lt;REPLACE_USER_ID\u0026gt; $ podman system migrate Note: The above \u0026ldquo;podman system migrate\u0026rdquo; need to be executed with your User ID and not root.\n Verify the user-id addition\n$ cat /etc/subuid $ cat /etc/subgid Expected similar output\nopc:100000:65536 \u0026lt;user-id\u0026gt;:100000:65536 1.3 Install and Configure Kubernetes Add the external Kubernetes repository:\n$ cat \u0026lt;\u0026lt;EOF | sudo tee /etc/yum.repos.d/kubernetes.repo [kubernetes] name=Kubernetes baseurl=https://pkgs.k8s.io/core:/stable:/v1.28/rpm/ enabled=1 gpgcheck=1 gpgkey=https://pkgs.k8s.io/core:/stable:/v1.28/rpm/repodata/repomd.xml.key exclude=kubelet kubeadm kubectl cri-tools kubernetes-cni EOF Set SELinux in permissive mode (effectively disabling it):\n$ export PATH=/sbin:$PATH $ setenforce 0 $ sed -i \u0026#39;s/^SELINUX=enforcing$/SELINUX=permissive/\u0026#39; /etc/selinux/config Export proxy and enable kubelet:\n### Get the nslookup IP address of the master node to use with apiserver-advertise-address during setting up Kubernetes master ### as the host may have different internal ip (hostname -i) and nslookup $HOSTNAME $ ip_addr=`nslookup $(hostname -f) | grep -m2 Address | tail -n1| awk -F: \u0026#39;{print $2}\u0026#39;| tr -d \u0026#34; \u0026#34;` $ echo $ip_addr ### Set the proxies $ export NO_PROXY=localhost,127.0.0.0/8,ADD-YOUR-INTERNAL-NO-PROXY-LIST,/var/run/crio/crio.sock,$ip_addr,.svc $ export no_proxy=localhost,127.0.0.0/8,ADD-YOUR-INTERNAL-NO-PROXY-LIST,/var/run/crio/crio.sock,$ip_addr,.svc $ export http_proxy=http://REPLACE-WITH-YOUR-COMPANY-PROXY-HOST:PORT $ export https_proxy=http://REPLACE-WITH-YOUR-COMPANY-PROXY-HOST:PORT $ export HTTPS_PROXY=http://REPLACE-WITH-YOUR-COMPANY-PROXY-HOST:PORT $ export HTTP_PROXY=http://REPLACE-WITH-YOUR-COMPANY-PROXY-HOST:PORT ### Install the kubernetes components and enable the kubelet service so that it automatically restarts on reboot $ dnf install -y kubeadm kubelet kubectl $ systemctl enable --now kubelet Ensure net.bridge.bridge-nf-call-iptables is set to 1 in your sysctl to avoid traffic routing issues:\n$ cat \u0026lt;\u0026lt;EOF \u0026gt; /etc/sysctl.d/k8s.conf net.bridge.bridge-nf-call-ip6tables = 1 net.bridge.bridge-nf-call-iptables = 1 net.ipv4.ip_forward = 1 EOF $ sysctl --system Disable swap check:\n$ sed -i \u0026#39;s/KUBELET_EXTRA_ARGS=/KUBELET_EXTRA_ARGS=\u0026#34;--fail-swap-on=false\u0026#34;/\u0026#39; /etc/sysconfig/kubelet $ cat /etc/sysconfig/kubelet ### Reload and restart kubelet $ systemctl daemon-reload $ systemctl restart kubelet Pull the images using crio:\nkubeadm config images pull --cri-socket unix:///var/run/crio/crio.sock 1.4 Set up Helm Install Helm v3.10.2+.\na. Download Helm from https://github.com/helm/helm/releases.\nFor example, to download Helm v3.10.2:\n$ wget https://get.helm.sh/helm-v3.10.2-linux-amd64.tar.gz b. Unpack tar.gz:\n$ tar -zxvf helm-v3.10.2-linux-amd64.tar.gz c. Find the Helm binary in the unpacked directory, and move it to its desired destination:\n$ mv linux-amd64/helm /usr/bin/helm Run helm version to verify its installation:\n$ helm version version.BuildInfo{Version:\u0026#34;v3.10.2\u0026#34;, GitCommit:\u0026#34;50f003e5ee8704ec937a756c646870227d7c8b58\u0026#34;, GitTreeState:\u0026#34;clean\u0026#34;, GoVersion:\u0026#34;go1.18.8\u0026#34;} 2. Set up a single instance Kubernetes cluster Notes:\n These steps must be run with the root user, unless specified otherwise! If you choose to use a different CIDR block (that is, other than 10.244.0.0/16 for the --pod-network-cidr= in the kubeadm init command), then also update NO_PROXY and no_proxy with the appropriate value. Also make sure to update kube-flannel.yaml with the new value before deploying. Replace the following with appropriate values: ADD-YOUR-INTERNAL-NO-PROXY-LIST REPLACE-WITH-YOUR-COMPANY-PROXY-HOST:PORT 2.1 Set up the master node Create a shell script that sets up the necessary environment variables. You can append this to the user’s .bashrc so that it will run at login. You must also configure your proxy settings here if you are behind an HTTP proxy:\n## grab my IP address to pass into kubeadm init, and to add to no_proxy vars ip_addr=`nslookup $(hostname -f) | grep -m2 Address | tail -n1| awk -F: \u0026#39;{print $2}\u0026#39;| tr -d \u0026#34; \u0026#34;` export pod_network_cidr=\u0026#34;10.244.0.0/16\u0026#34; export service_cidr=\u0026#34;10.96.0.0/12\u0026#34; export PATH=$PATH:/sbin:/usr/sbin ### Set the proxies export NO_PROXY=localhost,.svc,127.0.0.0/8,ADD-YOUR-INTERNAL-NO-PROXY-LIST,/var/run/crio/crio.sock,$ip_addr,$pod_network_cidr,$service_cidr export no_proxy=localhost,.svc,127.0.0.0/8,ADD-YOUR-INTERNAL-NO-PROXY-LIST,/var/run/crio/crio.sock,$ip_addr,$pod_network_cidr,$service_cidr export http_proxy=http://REPLACE-WITH-YOUR-COMPANY-PROXY-HOST:PORT export https_proxy=http://REPLACE-WITH-YOUR-COMPANY-PROXY-HOST:PORT export HTTPS_PROXY=http://REPLACE-WITH-YOUR-COMPANY-PROXY-HOST:PORT export HTTP_PROXY=http://REPLACE-WITH-YOUR-COMPANY-PROXY-HOST:PORT Source the script to set up your environment variables:\n$ . ~/.bashrc To implement command completion, add the following to the script:\n$ [ -f /usr/share/bash-completion/bash_completion ] \u0026amp;\u0026amp; . /usr/share/bash-completion/bash_completion $ source \u0026lt;(kubectl completion bash) Run kubeadm init to create the master node:\n$ kubeadm init \\ --pod-network-cidr=$pod_network_cidr \\ --apiserver-advertise-address=$ip_addr \\ --ignore-preflight-errors=Swap \u0026gt; /tmp/kubeadm-init.out 2\u0026gt;\u0026amp;1 Log in to the terminal with YOUR_USERID:YOUR_GROUP. Then set up the ~/.bashrc similar to steps 1 to 3 with YOUR_USERID:YOUR_GROUP.\n Note that from now on we will be using YOUR_USERID:YOUR_GROUP to execute any kubectl commands and not root.\n Set up YOUR_USERID:YOUR_GROUP to access the Kubernetes cluster:\n$ mkdir -p $HOME/.kube $ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config $ sudo chown $(id -u):$(id -g) $HOME/.kube/config Verify that YOUR_USERID:YOUR_GROUP is set up to access the Kubernetes cluster using the kubectl command:\n$ kubectl get nodes Note: At this step, the node is not in ready state as we have not yet installed the pod network add-on. After the next step, the node will show status as Ready.\n Install a pod network add-on (flannel) so that your pods can communicate with each other.\n Note: If you are using a different CIDR block than 10.244.0.0/16, then download and update kube-flannel.yml with the correct CIDR address before deploying into the cluster:\n $ wget https://github.com/flannel-io/flannel/releases/download/v0.25.1/kube-flannel.yml $ ### Update the CIDR address if you are using a CIDR block other than the default 10.244.0.0/16 $ kubectl apply -f kube-flannel.yml Verify that the master node is in Ready status:\n$ kubectl get nodes Sample output:\nNAME STATUS ROLES AGE VERSION mymasternode Ready control-plane 12h v1.27.2 or:\n$ kubectl get pods -n kube-system Sample output:\nNAME READY STATUS RESTARTS AGE pod/coredns-86c58d9df4-58p9f 1/1 Running 0 3m59s pod/coredns-86c58d9df4-mzrr5 1/1 Running 0 3m59s pod/etcd-mymasternode 1/1 Running 0 3m4s pod/kube-apiserver-node 1/1 Running 0 3m21s pod/kube-controller-manager-mymasternode 1/1 Running 0 3m25s pod/kube-flannel-ds-6npx4 1/1 Running 0 49s pod/kube-proxy-4vsgm 1/1 Running 0 3m59s pod/kube-scheduler-mymasternode 1/1 Running 0 2m58s To schedule pods on the master node, taint the node:\n$ kubectl taint nodes --all node-role.kubernetes.io/control-plane- Congratulations! Your Kubernetes cluster environment is ready to deploy your Oracle SOA Suite domain.\nRefer to the official documentation to set up a Kubernetes cluster.\n3. Get scripts and images 3.1 Set up the source code repository to deploy Oracle SOA Suite domains Create a working directory to set up the source code:\n$ mkdir $HOME/soa_24.2.2 $ cd $HOME/soa_24.2.2 Download the WebLogic Kubernetes Operator source code and Oracle SOA Suite Kubernetes deployment scripts from the SOA repository. Required artifacts are available at OracleSOASuite/kubernetes.\n$ git clone https://github.com/oracle/fmw-kubernetes.git $ export WORKDIR=$HOME/soa_24.2.2/fmw-kubernetes/OracleSOASuite/kubernetes 3.2 Get required Docker images and add them to your local registry Pull the WebLogic Kubernetes Operator image:\n$ podman pull ghcr.io/oracle/weblogic-kubernetes-operator:4.2.2 Obtain the Oracle Database image and Oracle SOA Suite Docker image from the Oracle Container Registry:\na. For first time users, to pull an image from the Oracle Container Registry, navigate to https://container-registry.oracle.com and log in using the Oracle Single Sign-On (SSO) authentication service. If you do not already have SSO credentials, you can create an Oracle Account using: https://profile.oracle.com/myprofile/account/create-account.jspx.\nUse the web interface to accept the Oracle Standard Terms and Restrictions for the Oracle software images that you intend to deploy. Your acceptance of these terms are stored in a database that links the software images to your Oracle Single Sign-On login credentials.\nTo obtain the image, log in to the Oracle Container Registry:\n$ podman login container-registry.oracle.com b. Find and then pull the Oracle Database image for 12.2.0.1:\n$ podman pull container-registry.oracle.com/database/enterprise:12.2.0.1-slim c. Find and then pull the prebuilt Oracle SOA Suite image 12.2.1.4 install image:\n$ podman pull container-registry.oracle.com/middleware/soasuite:12.2.1.4 Note: This image does not contain any Oracle SOA Suite product patches and can only be used for test and development purposes.\n 4. Install the WebLogic Kubernetes Operator 4.1 Prepare for the WebLogic Kubernetes Operator. Create a namespace opns for the operator:\n$ kubectl create namespace opns Create a service account op-sa for the operator in the operator’s namespace:\n$ kubectl create serviceaccount -n opns op-sa 4.2 Install the WebLogic Kubernetes Operator Use Helm to install and start the operator from the directory you just cloned:\n$ cd ${WORKDIR} $ helm install weblogic-kubernetes-operator charts/weblogic-operator \\ --namespace opns \\ --set image=ghcr.io/oracle/weblogic-kubernetes-operator:4.2.2 \\ --set serviceAccount=op-sa \\ --wait 4.3 Verify the WebLogic Kubernetes Operator Verify that the operator’s pod is running by listing the pods in the operator’s namespace. You should see one for the operator:\n$ kubectl get pods -n opns Verify that the operator is up and running by viewing the operator pod\u0026rsquo;s logs:\n$ kubectl logs -n opns -c weblogic-operator deployments/weblogic-operator The WebLogic Kubernetes Operator v4.2.2 has been installed. Continue with the load balancer and Oracle SOA Suite domain setup.\n5. Install the Traefik (ingress-based) load balancer The WebLogic Kubernetes Operator supports these load balancers: Traefik, NGINX, and Apache. Samples are provided in the documentation.\nThis Quick Start demonstrates how to install the Traefik ingress controller to provide load balancing for an Oracle SOA Suite domain.\n Create a namespace for Traefik:\n$ kubectl create namespace traefik Set up Helm for 3rd party services:\n$ helm repo add traefik https://helm.traefik.io/traefik --force-update Install the Traefik operator in the traefik namespace with the provided sample values:\n$ cd ${WORKDIR} $ helm install traefik traefik/traefik \\ --namespace traefik \\ --values charts/traefik/values.yaml \\ --set \u0026#34;kubernetes.namespaces={traefik}\u0026#34; \\ --set \u0026#34;service.type=NodePort\u0026#34; \\ --wait 6. Create and configure an Oracle SOA Suite domain 6.1 Prepare for an Oracle SOA Suite domain Create a namespace that can host Oracle SOA Suite domains. Label the namespace with weblogic-operator=enabled to manage the domain.\n$ kubectl create namespace soans $ kubectl label namespace soans weblogic-operator=enabled Create Kubernetes secrets.\na. Create a Kubernetes secret for the domain in the same Kubernetes namespace as the domain. In this example, the username is weblogic, the password is Welcome1, and the namespace is soans:\n$ cd ${WORKDIR}/create-weblogic-domain-credentials $ ./create-weblogic-credentials.sh \\ -u weblogic \\ -p Welcome1 \\ -n soans \\ -d soainfra \\ -s soainfra-domain-credentials b. Create a Kubernetes secret for the RCU in the same Kubernetes namespace as the domain:\n Schema user : SOA1 Schema password : Oradoc_db1 DB sys user password : Oradoc_db1 Domain name : soainfra Domain Namespace : soans Secret name : soainfra-rcu-credentials $ cd ${WORKDIR}/create-rcu-credentials $ ./create-rcu-credentials.sh \\ -u SOA1 \\ -p Oradoc_db1 \\ -a sys \\ -q Oradoc_db1 \\ -d soainfra \\ -n soans \\ -s soainfra-rcu-credentials Create the Kubernetes persistence volume and persistence volume claim.\na. Create the Oracle SOA Suite domain home directory. Determine if a user already exists on your host system with uid:gid of 1000:0:\n$ sudo getent passwd 1000 If this command returns a username (which is the first field), you can skip the following useradd command. If not, create the oracle user with useradd:\n$ sudo useradd -u 1000 -g 0 oracle Create the directory that will be used for the Oracle SOA Suite domain home:\n$ sudo mkdir /scratch/k8s_dir $ sudo chown -R 1000:0 /scratch/k8s_dir b. The create-pv-pvc-inputs.yaml has the following values by default:\n baseName: domain domainUID: soainfra namespace: soans weblogicDomainStoragePath: /scratch/k8s_dir Review and update if any changes required.\n$ cd ${WORKDIR}/create-weblogic-domain-pv-pvc $ vim create-pv-pvc-inputs.yaml c. Run the create-pv-pvc.sh script to create the PV and PVC configuration files:\n$ cd ${WORKDIR}/create-weblogic-domain-pv-pvc $ ./create-pv-pvc.sh -i create-pv-pvc-inputs.yaml -o output d. Create the PV and PVC using the configuration files created in the previous step:\n$ kubectl create -f output/pv-pvcs/soainfra-domain-pv.yaml $ kubectl create -f output/pv-pvcs/soainfra-domain-pvc.yaml Install and configure the database for the Oracle SOA Suite domain.\nThis step is required only when a standalone database is not already set up and you want to use the database in a container.\nThe Oracle Database Docker images are supported only for non-production use. For more details, see My Oracle Support note: Oracle Support for Database Running on Docker (Doc ID 2216342.1). For production, it is suggested to use a standalone database. This example provides steps to create the database in a container.\n a. Create a secret with your desired password (for example, Oradoc_db1):\n$ kubectl create secret generic oracle-db-secret --from-literal=\u0026#39;password=Oradoc_db1\u0026#39; b. Create a database in a container:\n$ cd ${WORKDIR}/create-oracle-db-service $ ./start-db-service.sh -a oracle-db-secret -i container-registry.oracle.com/database/enterprise:12.2.0.1-slim -p none Once the database is successfully created, you can use the database connection string oracle-db.default.svc.cluster.local:1521/devpdb.k8s as an rcuDatabaseURL parameter in the create-domain-inputs.yaml file.\nc. Create Oracle SOA Suite schemas for the domain type (for example, soaosb).\nCreate a secret that contains the database\u0026rsquo;s SYSDBA username and password.\n$ kubectl -n default create secret generic oracle-rcu-secret \\ --from-literal=\u0026#39;sys_username=sys\u0026#39; \\ --from-literal=\u0026#39;sys_password=Oradoc_db1\u0026#39; \\ --from-literal=\u0026#39;password=Oradoc_db1\u0026#39; To install the Oracle SOA Suite schemas, run the create-rcu-schema.sh script with the following inputs:\n -s \u0026lt;RCU PREFIX\u0026gt; -t \u0026lt;SOA domain type\u0026gt; -d \u0026lt;Oracle Database URL\u0026gt; -i \u0026lt;SOASuite image\u0026gt; -n \u0026lt;Namespace\u0026gt; -c \u0026lt;Name of credentials secret containing SYSDBA username and password and RCU schema owner password\u0026gt; -r \u0026lt;Comma-separated variables\u0026gt; -l \u0026lt;Timeout limit in seconds. (optional). (default: 300)\u0026gt; For example:\n$ cd ${WORKDIR}/create-rcu-schema $ ./create-rcu-schema.sh \\ -s SOA1 \\ -t soaosb \\ -d oracle-db.default.svc.cluster.local:1521/devpdb.k8s \\ -i container-registry.oracle.com/middleware/soasuite:12.2.1.4 \\ -n default \\ -c oracle-rcu-secret \\ -r SOA_PROFILE_TYPE=SMALL,HEALTHCARE_INTEGRATION=NO Now the environment is ready to start the Oracle SOA Suite domain creation.\n6.2 Create an Oracle SOA Suite domain The sample scripts for Oracle SOA Suite domain deployment are available at ${WORKDIR}/create-soa-domain/domain-home-on-pv. You must edit create-domain-inputs.yaml (or a copy of it) to provide the details for your domain.\nUpdate create-domain-inputs.yaml with the following values for domain creation:\n domainType: soaosb initialManagedServerReplicas: 1 $ cd ${WORKDIR}/create-soa-domain/domain-home-on-pv/ $ cp create-domain-inputs.yaml create-domain-inputs.yaml.orig $ sed -i -e \u0026#34;s:domainType\\: soa:domainType\\: soaosb:g\u0026#34; create-domain-inputs.yaml $ sed -i -e \u0026#34;s:initialManagedServerReplicas\\: 2:initialManagedServerReplicas\\: 1:g\u0026#34; create-domain-inputs.yaml $ sed -i -e \u0026#34;s:image\\: soasuite\\:12.2.1.4:image\\: container-registry.oracle.com/middleware/soasuite\\:12.2.1.4:g\u0026#34; create-domain-inputs.yaml Run the create-domain.sh script to create a domain:\n$ cd ${WORKDIR}/create-soa-domain/domain-home-on-pv/ $ ./create-domain.sh -i create-domain-inputs.yaml -o output Create a Kubernetes domain object:\nOnce the create-domain.sh is successful, it generates output/weblogic-domains/soainfra/domain.yaml, which you can use to create the Kubernetes resource domain to start the domain and servers:\n$ cd ${WORKDIR}/create-soa-domain/domain-home-on-pv $ kubectl create -f output/weblogic-domains/soainfra/domain.yaml Verify that the Kubernetes domain object named soainfra is created:\n$ kubectl get domain -n soans NAME AGE soainfra 3m18s Once you create the domain, the introspect pod is created. This inspects the domain home and then starts the soainfra-adminserver pod. Once the soainfra-adminserver pod starts successfully, the Managed Server pods are started in parallel. Watch the soans namespace for the status of domain creation:\n$ kubectl get pods -n soans -w Verify that the Oracle SOA Suite domain server pods and services are created and in Ready state:\n$ kubectl get all -n soans 6.3 Configure Traefik to access Oracle SOA Suite domain services Configure Traefik to manage ingresses created in the Oracle SOA Suite domain namespace (soans):\n$ helm upgrade traefik traefik/traefik \\ --reuse-values \\ --namespace traefik \\ --set \u0026#34;kubernetes.namespaces={traefik,soans}\u0026#34; \\ --wait Create an ingress for the domain in the domain namespace by using the sample Helm chart:\n$ cd ${WORKDIR} $ export LOADBALANCER_HOSTNAME=$(hostname -f) $ helm install soa-traefik-ingress charts/ingress-per-domain \\ --namespace soans \\ --values charts/ingress-per-domain/values.yaml \\ --set \u0026#34;traefik.hostname=${LOADBALANCER_HOSTNAME}\u0026#34; \\ --set domainType=soaosb Verify the created ingress per domain details:\n$ kubectl describe ingress soainfra-traefik -n soans 6.4 Verify that you can access the Oracle SOA Suite domain URL Get the LOADBALANCER_HOSTNAME for your environment:\n$ export LOADBALANCER_HOSTNAME=$(hostname -f) Verify the following URLs are available for Oracle SOA Suite domains of domain type soaosb:\nCredentials:\nusername: weblogic password: Welcome1\nhttp://${LOADBALANCER_HOSTNAME}:30305/console http://${LOADBALANCER_HOSTNAME}:30305/em http://${LOADBALANCER_HOSTNAME}:30305/servicebus http://${LOADBALANCER_HOSTNAME}:30305/soa-infra http://${LOADBALANCER_HOSTNAME}:30305/soa/composer http://${LOADBALANCER_HOSTNAME}:30305/integration/worklistapp http://${LOADBALANCER_HOSTNAME}:30305/ess http://${LOADBALANCER_HOSTNAME}:30305/EssHealthCheck "
+},
+{
+ "uri": "/fmw-kubernetes/24.2.2/soa-domains/installguide/prepare-your-environment/",
+ "title": "Prepare your environment",
+ "tags": [],
+ "description": "Prepare for creating Oracle SOA Suite domains, including required secrets creation, persistent volume and volume claim creation, database creation, and database schema creation.",
+ "content": "To prepare your Oracle SOA Suite in Kubernetes environment, complete the following steps.\nRefer to the troubleshooting page to troubleshoot issues during the domain deployment process.\n Set up your Kubernetes cluster\n Install Helm\n Get dependent images\n Set up the code repository to deploy Oracle SOA Suite domains\n Obtain the Oracle SOA Suite Docker image\n Install the WebLogic Kubernetes Operator\n Prepare the environment for Oracle SOA Suite domains\na. Create a namespace for an Oracle SOA Suite domain\nb. Create a persistent storage for an Oracle SOA Suite domain\nc. Create a Kubernetes secret with domain credentials\nd. Create a Kubernetes secret with the RCU credentials\ne. Configure access to your database\nf. Run the Repository Creation Utility to set up your database schemas\n Create an Oracle SOA Suite domain\n Set up your Kubernetes cluster Refer the official Kubernetes set up documentation to set up a production grade Kubernetes cluster.\nInstall Helm The operator uses Helm to create and deploy the necessary resources and then run the operator in a Kubernetes cluster. For Helm installation and usage information, see here.\nGet dependent images Obtain dependent images and add them to your local registry.\n For first time users, to pull an image from the Oracle Container Registry, navigate to https://container-registry.oracle.com and log in using the Oracle Single Sign-On (SSO) authentication service. If you do not already have an SSO account, you can create an Oracle Account here.\nUse the web interface to accept the Oracle Standard Terms and Restrictions for the Oracle software images that you intend to deploy. Your acceptance of these terms are stored in a database that links the software images to your Oracle Single Sign-On login credentials.\nLog in to the Oracle Container Registry (container-registry.oracle.com) from your Docker client:\n$ docker login container-registry.oracle.com Pull the operator image:\n$ docker pull ghcr.io/oracle/weblogic-kubernetes-operator:4.2.2 Set up the code repository to deploy Oracle SOA Suite domains Oracle SOA Suite domain deployment on Kubernetes leverages the WebLogic Kubernetes Operator infrastructure. To deploy an Oracle SOA Suite domain, you must set up the deployment scripts.\n Create a working directory to set up the source code:\n$ mkdir $HOME/soa_24.2.2 $ cd $HOME/soa_24.2.2 Download the WebLogic Kubernetes Operator source code and Oracle SOA Suite Kubernetes deployment scripts from the SOA repository. Required artifacts are available at OracleSOASuite/kubernetes.\n$ git clone https://github.com/oracle/fmw-kubernetes.git $ export WORKDIR=$HOME/soa_24.2.2/fmw-kubernetes/OracleSOASuite/kubernetes Obtain the Oracle SOA Suite Docker image The Oracle SOA Suite image with the latest bundle patch and required interim patches is prebuilt by Oracle and includes Oracle SOA Suite 12.2.1.4.0, the April Patch Set Update (PSU), and other fixes released with the Critical Patch Update (CPU) program. The Oracle Container Registry hosts container images based on both Oracle Linux 7 (ol7) and 8 (ol8). These are the only images supported for production deployments. Obtain the Oracle SOA Suite images using either of the following methods:\n Download from Oracle Container Registry:\n Log in to Oracle Container Registry, navigate to Middleware \u0026gt; soasuite_cpu and accept the license agreement if not already done.\n Log in to the Oracle Container Registry (container-registry.oracle.com) from your Docker client:\n$ docker login container-registry.oracle.com Pull the Oracle Linux 7 or 8 based images:\nFor example:\n$ docker pull container-registry.oracle.com/middleware/soasuite_cpu:12.2.1.4-jdk8-\u0026lt;ol7 or ol8\u0026gt;-\u0026lt;TAG\u0026gt; Download from My Oracle Support:\n Download patch 36568531 for Oracle Linux 7 based container image or 36568606 for Oracle Linux 8 based container image from My Oracle Support (MOS).\n Unzip the downloaded patch zip file.\n Load the image archive using the docker load command.\nFor example:\n$ docker load \u0026lt; soasuite-12.2.1.4-jdk8-\u0026lt;ol7 or ol8\u0026gt;-\u0026lt;TAG\u0026gt;.tar Loaded image: oracle/soasuite:12.2.1.4-jdk8-\u0026lt;ol7 or ol8\u0026gt;-\u0026lt;TAG\u0026gt; $ Run the docker inspect command to verify that the downloaded image is the latest released image. The value of label com.oracle.weblogic.imagetool.buildid must match to 5df3985f-352e-4e52-a326-4fbd59d123cd for Oracle Linux 7 based container image and 5e7ed71b-35f9-474a-a496-32420fe14728 for Oracle Linux 8 based container image.\nFor example:\n$ docker inspect --format=\u0026#39;{{ index .Config.Labels \u0026#34;com.oracle.weblogic.imagetool.buildid\u0026#34; }}\u0026#39; oracle/soasuite:12.2.1.4-jdk8-ol7-240430.081145 5df3985f-352e-4e52-a326-4fbd59d123cd $ If you want to build and use an Oracle SOA Suite Docker image with any additional bundle patch or interim patches that are not part of the image obtained from My Oracle Support, then follow these steps to create the image.\n Note: The default Oracle SOA Suite image name used for Oracle SOA Suite domains deployment is soasuite:release-version. The image obtained must be tagged accordingly using the docker tag command. If you want to use a different name for the image, make sure to update the new image tag name in the create-domain-inputs.yaml file and also in other instances where the soasuite:release-version image name is used.\n Install the WebLogic Kubernetes Operator The WebLogic Kubernetes Operator supports the deployment of Oracle SOA Suite domains in the Kubernetes environment. Follow the steps in this document to install the operator.\n Note: Optionally, you can follow these steps to send the contents of the operator\u0026rsquo;s logs to Elasticsearch.\n In the following example commands to install the WebLogic Kubernetes Operator, opns is the namespace and op-sa is the service account created for the operator:\n$ kubectl create namespace opns $ kubectl create serviceaccount -n opns op-sa $ cd ${WORKDIR} $ helm install weblogic-kubernetes-operator charts/weblogic-operator --set image=ghcr.io/oracle/weblogic-kubernetes-operator:4.2.2 --namespace opns --set serviceAccount=op-sa --set \u0026quot;javaLoggingLevel=FINE\u0026quot; --wait This Helm release deploys the operator with the default behavior of managing Oracle SOA Suite domains in all Kubernetes namespaces with the label weblogic-operator=enabled.\nPrepare the environment for Oracle SOA Suite domains Create a namespace for an Oracle SOA Suite domain Create a Kubernetes namespace (for example, soans) for the domain unless you intend to use the default namespace. Label the namespace with weblogic-operator=enabled to manage the domain. Use the new namespace in the remaining steps in this section. For details, see Prepare to run a domain.\n$ kubectl create namespace soans $ kubectl label namespace soans weblogic-operator=enabled Create a persistent storage for an Oracle SOA Suite domain In the Kubernetes namespace you created, create the PV and PVC for the domain by running the create-pv-pvc.sh script. Follow the instructions for using the script to create a dedicated PV and PVC for the Oracle SOA Suite domain.\n Review the configuration parameters for PV creation here. Based on your requirements, update the values in the create-pv-pvc-inputs.yaml file located at ${WORKDIR}/create-weblogic-domain-pv-pvc/. Sample configuration parameter values for an Oracle SOA Suite domain are:\n baseName: domain domainUID: soainfra namespace: soans weblogicDomainStorageType: HOST_PATH weblogicDomainStoragePath: /scratch/k8s_dir/SOA Ensure that the path for the weblogicDomainStoragePath property exists and have the ownership for 1000:0. If not, you need to create it as follows:\n$ sudo mkdir /scratch/k8s_dir/SOA $ sudo chown -R 1000:0 /scratch/k8s_dir/SOA Run the create-pv-pvc.sh script:\n$ cd ${WORKDIR}/create-weblogic-domain-pv-pvc $ ./create-pv-pvc.sh -i create-pv-pvc-inputs.yaml -o output_soainfra The create-pv-pvc.sh script will create a subdirectory pv-pvcs under the given /path/to/output-directory directory and creates two YAML configuration files for PV and PVC. Apply these two YAML files to create the PV and PVC Kubernetes resources using the kubectl create -f command:\n$ kubectl create -f output_soainfra/pv-pvcs/soainfra-domain-pv.yaml $ kubectl create -f output_soainfra/pv-pvcs/soainfra-domain-pvc.yaml Create a Kubernetes secret with domain credentials Create the Kubernetes secrets username and password of the administrative account in the same Kubernetes namespace as the domain:\n $ cd ${WORKDIR}/create-weblogic-domain-credentials $ ./create-weblogic-credentials.sh -u weblogic -p Welcome1 -n soans -d soainfra -s soainfra-domain-credentials For more details, see this document.\nYou can check the secret with the kubectl get secret command.\nFor example:\n Click here to see the sample secret description. $ kubectl get secret soainfra-domain-credentials -o yaml -n soans apiVersion: v1 data: password: T3JhZG9jX2RiMQ== sys_password: T3JhZG9jX2RiMQ== sys_username: c3lz username: U09BMQ== kind: Secret metadata: creationTimestamp: \u0026quot;2020-06-25T14:08:16Z\u0026quot; labels: weblogic.domainName: soainfra weblogic.domainUID: soainfra managedFields: - apiVersion: v1 fieldsType: FieldsV1 fieldsV1: f:data: .: {} f:password: {} f:sys_password: {} f:sys_username: {} f:username: {} f:metadata: f:labels: .: {} f:weblogic.domainName: {} f:weblogic.domainUID: {} f:type: {} manager: kubectl operation: Update time: \u0026quot;2020-06-25T14:08:16Z\u0026quot; name: soainfra-rcu-credentials namespace: soans resourceVersion: \u0026quot;265386\u0026quot; selfLink: /api/v1/namespaces/soans/secrets/soainfra-rcu-credentials uid: 2d93941c-656b-43a4-8af2-78ca8be0f293 type: Opaque Create a Kubernetes secret with the RCU credentials You also need to create a Kubernetes secret containing the credentials for the database schemas. When you create your domain, it will obtain the RCU credentials from this secret.\nUse the provided sample script to create the secret:\n$ cd ${WORKDIR}/create-rcu-credentials $ ./create-rcu-credentials.sh \\ -u SOA1 \\ -p Oradoc_db1 \\ -a sys \\ -q Oradoc_db1 \\ -d soainfra \\ -n soans \\ -s soainfra-rcu-credentials The parameter values are:\n -u username for schema owner (regular user), required. -p password for schema owner (regular user), required. -a username for SYSDBA user, required. -q password for SYSDBA user, required. -d domainUID. Example: soainfra -n namespace. Example: soans -s secretName. Example: soainfra-rcu-credentials You can confirm the secret was created as expected with the kubectl get secret command.\nFor example:\n Click here to see the sample secret description. $ kubectl get secret soainfra-rcu-credentials -o yaml -n soans apiVersion: v1 data: password: T3JhZG9jX2RiMQ== sys_password: T3JhZG9jX2RiMQ== sys_username: c3lz username: U09BMQ== kind: Secret metadata: creationTimestamp: \u0026#34;2020-06-25T14:08:16Z\u0026#34; labels: weblogic.domainName: soainfra weblogic.domainUID: soainfra managedFields: - apiVersion: v1 fieldsType: FieldsV1 fieldsV1: f:data: .: {} f:password: {} f:sys_password: {} f:sys_username: {} f:username: {} f:metadata: f:labels: .: {} f:weblogic.domainName: {} f:weblogic.domainUID: {} f:type: {} manager: kubectl operation: Update time: \u0026#34;2020-06-25T14:08:16Z\u0026#34; name: soainfra-rcu-credentials namespace: soans resourceVersion: \u0026#34;265386\u0026#34; selfLink: /api/v1/namespaces/soans/secrets/soainfra-rcu-credentials uid: 2d93941c-656b-43a4-8af2-78ca8be0f293 type: Opaque Configure access to your database Oracle SOA Suite domains require a database with the necessary schemas installed in them. The Repository Creation Utility (RCU) allows you to create those schemas. You must set up the database before you create your domain. There are no additional requirements added by running Oracle SOA Suite in Kubernetes; the same existing requirements apply.\nFor production deployments, you must set up and use the standalone (non-container) based database running outside of Kubernetes.\nBefore creating a domain, you will need to set up the necessary schemas in your database.\nRun the Repository Creation Utility to set up your database schemas Create schemas The RCU pod requires that you create a secret in the same namespace as the RCU pod that contains the database\u0026rsquo;s SYSDBA username and password in its sys_username and sys_password fields, and also contains a password of your choice for RCU schemas in its password field.\nFor example:\n$ kubectl -n default create secret generic oracle-rcu-secret \\ --from-literal=\u0026#39;sys_username=sys\u0026#39; \\ --from-literal=\u0026#39;sys_password=MY_SYS_PASSWORD\u0026#39; \\ --from-literal=\u0026#39;password=MY_RCU_SCHEMA_PASSWORD\u0026#39; To create the database schemas for Oracle SOA Suite, run the create-rcu-schema.sh script.\nFor example:\n$ cd ${WORKDIR}/create-rcu-schema $ ./create-rcu-schema.sh -h usage: ./create-rcu-schema.sh -s \u0026lt;schemaPrefix\u0026gt; [-t \u0026lt;schemaType\u0026gt;] [-d \u0026lt;dburl\u0026gt;] [-n \u0026lt;namespace\u0026gt;] [-c \u0026lt;credentialsSecretName\u0026gt;] [-p \u0026lt;docker-store\u0026gt;] [-i \u0026lt;image\u0026gt;] [-u \u0026lt;imagePullPolicy\u0026gt;] [-o \u0026lt;rcuOutputDir\u0026gt;] [-r \u0026lt;customVariables\u0026gt;] [-l \u0026lt;timeoutLimit\u0026gt;] [-h] -s RCU Schema Prefix (required) -t RCU Schema Type (optional) (supported values: osb,soa,soaosb) -d RCU Oracle Database URL (optional) (default: oracle-db.default.svc.cluster.local:1521/devpdb.k8s) -n Namespace for RCU pod (optional) (default: default) -c Name of credentials secret (optional) (default: oracle-rcu-secret) Must contain SYSDBA username at key \u0026#39;sys_username\u0026#39;, SYSDBA password at key \u0026#39;sys_password\u0026#39;, and RCU schema owner password at key \u0026#39;password\u0026#39;. -p OracleSOASuite ImagePullSecret (optional) (default: none) -i OracleSOASuite Image (optional) (default: soasuite:release-version) -u OracleSOASuite ImagePullPolicy (optional) (default: IfNotPresent) -o Output directory for the generated YAML file (optional) (default: rcuoutput) -r Comma-separated custom variables in the format variablename=value (optional) (default: none) -l Timeout limit in seconds (optional) (default: 300) -h Help NOTE: The c, p, i, u, and o arguments are ignored if an RCU pod is already running in the namespace. $ ./create-rcu-schema.sh \\ -s SOA1 \\ -t soaosb \\ -d oracle-db.default.svc.cluster.local:1521/devpdb.k8s \\ -n default \\ -c oracle-rcu-secret \\ -i soasuite:12.2.1.4 \\ -r SOA_PROFILE_TYPE=SMALL,HEALTHCARE_INTEGRATION=NO For Oracle SOA Suite domains, the create-rcu-schema.sh script supports:\n domain types: soa, osb, and soaosb. You must specify one of these using the -t flag. For Oracle SOA Suite you must specify the Oracle SOA schema profile type using the -r flag. For example, -r SOA_PROFILE_TYPE=SMALL. Supported values for SOA_PROFILE_TYPE are SMALL, MED, and LARGE. Note: To use the LARGE schema profile type, make sure that the partitioning feature is enabled in the Oracle Database.\n Make sure that you maintain the association between the database schemas and the matching domain just like you did in a non-Kubernetes environment. There is no specific functionality provided to help with this.\nDrop schemas If you want to drop a schema, you can use the drop-rcu-schema.sh script.\nFor example:\n$ cd ${WORKDIR}/create-rcu-schema $ ./drop-rcu-schema.sh -h usage: ./drop-rcu-schema.sh -s \u0026lt;schemaPrefix\u0026gt; [-t \u0026lt;schemaType\u0026gt;] [-d \u0026lt;dburl\u0026gt;] [-n \u0026lt;namespace\u0026gt;] [-c \u0026lt;credentialsSecretName\u0026gt;] [-p \u0026lt;docker-store\u0026gt;] [-i \u0026lt;image\u0026gt;] [-u \u0026lt;imagePullPolicy\u0026gt;] [-o \u0026lt;rcuOutputDir\u0026gt;] [-r \u0026lt;customVariables\u0026gt;] [-h] -s RCU Schema Prefix (required) -t RCU Schema Type (optional) (supported values: osb,soa,soaosb) -d RCU Oracle Database URL (optional) (default: oracle-db.default.svc.cluster.local:1521/devpdb.k8s) -n Namespace for RCU pod (optional) (default: default) -c Name of credentials secret (optional) (default: oracle-rcu-secret) Must contain SYSDBA username at key \u0026#39;sys_username\u0026#39;, SYSDBA password at key \u0026#39;sys_password\u0026#39;, and RCU schema owner password at key \u0026#39;password\u0026#39;. -p OracleSOASuite ImagePullSecret (optional) (default: none) -i OracleSOASuite Image (optional) (default: soasuite:release-version) -u OracleSOASuite ImagePullPolicy (optional) (default: IfNotPresent) -o Output directory for the generated YAML file (optional) (default: rcuoutput) -r Comma-separated custom variables in the format variablename=value (optional) (default: none) -h Help NOTE: The c, p, i, u, and o arguments are ignored if an RCU pod is already running in the namespace. $ ./drop-rcu-schema.sh \\ -s SOA1 \\ -t soaosb \\ -d oracle-db.default.svc.cluster.local:1521/devpdb.k8s \\ -n default \\ -c oracle-rcu-secret \\ -r SOA_PROFILE_TYPE=SMALL,HEALTHCARE_INTEGRATION=NO For Oracle SOA Suite domains, the drop-rcu-schema.sh script supports:\n Domain types: soa, osb, and soaosb. You must specify one of these using the -t flag. For Oracle SOA Suite, you must specify the Oracle SOA schema profile type using the -r flag. For example, -r SOA_PROFILE_TYPE=SMALL. Supported values for SOA_PROFILE_TYPE are SMALL, MED, and LARGE. Create an Oracle SOA Suite domain Now that you have your Docker images and you have created your RCU schemas, you are ready to create your domain. To continue, follow the instructions in Create Oracle SOA Suite domains.\n"
+},
+{
+ "uri": "/fmw-kubernetes/24.2.2/soa-domains/adminguide/deploying-composites/deploy-using-maven-ant/",
+ "title": "Deploy using Maven and Ant",
+ "tags": [],
+ "description": "Deploy Oracle SOA Suite and Oracle Service Bus composite applications using the Maven and Ant based approach in an Oracle SOA Suite deployment.",
+ "content": "Learn how to deploy Oracle SOA Suite and Oracle Service Bus composite applications using the Maven and Ant based approach in an Oracle SOA Suite in WebLogic Kubernetes Operator environment.\nBefore deploying composite applications, we need to create a Kubernetes pod in the same cluster where the Oracle SOA Suite domain is running, so that composite applications can be deployed using the internal Kubernetes Service for the Administration Server URL.\nPlace the SOA/Oracle Service Bus composite project at a share location (for example at /share/soa-deploy) mounted at /composites inside container. Make sure to provide oracle user ( uid: 1000 and gid: 0) permission to directory /share/soa-deploy, so that it is accessible and writable inside the container.\n$ sudo chown -R 1000:0 /share/soa-deploy Follow the steps in this section to create a container and then use it to deploy Oracle SOA Suite and Oracle Service Bus composite applications using Maven or Ant.\nCreate a composite deployment container Before creating a Kubernetes pod, make sure that the Oracle SOA Suite Docker image is available on a node, or you can create an image pull secret so that the pod can pull the Docker image on the host where it gets created.\n Create an image pull secret to pull image soasuite:12.2.1.4 by the Kubernetes pod:\n$ kubectl create secret docker-registry image-secret -n soans --docker-server=your-registry.com --docker-username=xxxxxx --docker-password=xxxxxxx --docker-email=my@company.com Create a PersistentVolume and PersistentVolumeClaim (soadeploy-pv.yaml and soadeploy-pvc.yaml) with sample composites for build and deploy placed at /share/soa-deploy.\na) Create a PersistentVolume with the sample provided (soadeploy-pv.yaml), which uses NFS (you can use hostPath or any other supported PV type):\napiVersion: v1 kind: PersistentVolume metadata: name: soadeploy-pv spec: storageClassName: soadeploy-storage-class capacity: storage: 10Gi accessModes: - ReadWriteMany # Valid values are Retain, Delete or Recycle persistentVolumeReclaimPolicy: Retain # hostPath: nfs: server: X.X.X.X path: \u0026quot;/share/soa-deploy\u0026quot; b) Apply the YAML:\n$ kubectl apply -f soadeploy-pv.yaml c) Create a PersistentVolumeClaim (soadeploy-pvc.yaml):\nkind: PersistentVolumeClaim apiVersion: v1 metadata: name: soadeploy-pvc namespace: soans spec: storageClassName: soadeploy-storage-class accessModes: - ReadWriteMany resources: requests: storage: 10Gi d) Apply the YAML:\n$ kubectl apply -f soadeploy-pvc.yaml Create a composite deploy pod using soadeploy.yaml to mount the composites inside pod at /composites:\napiVersion: v1 kind: Pod metadata: labels: run: soadeploy name: soadeploy namespace: soans spec: imagePullSecrets: - name: image-secret containers: - image: soasuite:12.2.1.4 name: soadeploy env: - name: M2_HOME value: /u01/oracle/oracle_common/modules/org.apache.maven_3.2.5 command: [\u0026quot;/bin/bash\u0026quot;, \u0026quot;-c\u0026quot;, \u0026quot;echo 'export PATH=$PATH:$M2_HOME/bin' \u0026gt;\u0026gt; $HOME/.bashrc; sleep infinity\u0026quot;] imagePullPolicy: IfNotPresent volumeMounts: - name: mycomposite mountPath: /composites volumes: - name: mycomposite persistentVolumeClaim: claimName: soadeploy-pvc Create the pod:\n$ kubectl apply -f soadeploy.yaml Once the Kubernetes pod is deployed, exec into the pod to perform Maven/Ant based build and deploy:\n$ kubectl exec -it -n soans soadeploy -- bash Maven based build and deploy Note: Make sure to execute these commands inside the soadeploy pod.\n Set up proxy details for Maven to pull dependencies from the internet.\nIf your environment is not running behind a proxy, then skip this step. Otherwise, replace REPLACE-WITH-PROXY-HOST, REPLACE-WITH-PROXY-PORT and the value for nonProxyHosts attribute per your environment and create the settings.xml:\n$ mkdir $HOME/.m2 $ cat \u0026lt;\u0026lt;EOF \u0026gt; $HOME/.m2/settings.xml \u0026lt;settings\u0026gt; \u0026lt;proxies\u0026gt; \u0026lt;proxy\u0026gt; \u0026lt;active\u0026gt;true\u0026lt;/active\u0026gt; \u0026lt;protocol\u0026gt;http\u0026lt;/protocol\u0026gt; \u0026lt;host\u0026gt;REPLACE-WITH-PROXY-HOST\u0026lt;/host\u0026gt; \u0026lt;port\u0026gt;REPLACE-WITH-PROXY-PORT\u0026lt;/port\u0026gt; \u0026lt;nonProxyHosts\u0026gt;soainfra-cluster-soa-cluster|soainfra-adminserver\u0026lt;/nonProxyHosts\u0026gt; \u0026lt;/proxy\u0026gt; \u0026lt;/proxies\u0026gt; \u0026lt;/settings\u0026gt; EOF For Oracle SOA Suite composite applications Set up the environment for Maven:\n#Perform Maven Sync $ cd /u01/oracle/oracle_common/plugins/maven/com/oracle/maven/oracle-maven-sync/12.2.1/ $ mvn install:install-file \\ -DpomFile=oracle-maven-sync-12.2.1.pom \\ -Dfile=oracle-maven-sync-12.2.1.jar #install Maven plugin $ mvn help:describe \\ -Dplugin=com.oracle.maven:oracle-maven-sync \\ -Ddetail #push libraries into internal repository $ mvn com.oracle.maven:oracle-maven-sync:push \\ -DoracleHome=/u01/oracle \\ -DtestingOnly=false $ mvn archetype:crawl \\ -Dcatalog=$HOME/.m2/archetype-catalog.xml \\ -DarchetypeArtifactId=oracle-soa-application \\ -DarchetypeVersion=12.2.1-4-0 Build the SOA Archive (SAR) for your sample deployment available at /composites/mavenproject/my-soa-app:\n$ cd /composites/mavenproject/my-soa-app $ mvn package The SAR will be generated at /composites/mavenproject/my-soa-app/my-project/target/sca_my-project.jar.\n Deploy into the Oracle SOA Suite instance. For example, if the instance URL is http://soainfra-cluster-soa-cluster:8011 with credentials username: weblogic and password: Welcome1, enter the following commands:\n$ cd /composites/mavenproject/my-soa-app $ mvn pre-integration-test \\ -DoracleServerUrl=http://soainfra-cluster-soa-cluster:8011 \\ -DsarLocation=/composites/mavenproject/my-soa-app/my-project/target/sca_my-project.jar \\ -Doverwrite=true \\ -DforceDefault=true \\ -Dcomposite.partition=default \\ -Duser=weblogic -Dpassword=Welcome1 For Oracle Service Bus composite applications Set up the environment for Maven:\n#Perform Maven Sync $ cd /u01/oracle/oracle_common/plugins/maven/com/oracle/maven/oracle-maven-sync/12.2.1/ $ mvn install:install-file \\ -DpomFile=oracle-maven-sync-12.2.1.pom \\ -Dfile=oracle-maven-sync-12.2.1.jar #push libraries into internal repository $ mvn com.oracle.maven:oracle-maven-sync:push \\ -DoracleHome=$ORACLE_HOME $ mvn archetype:crawl \\ -Dcatalog=$HOME/.m2/archetype-catalog.xml #Verify the mvn setup $ mvn help:describe \\ -DgroupId=com.oracle.servicebus.plugin \\ -DartifactId=oracle-servicebus-plugin \\ -Dversion=12.2.1-4-0 Build the Oracle Service Bus Archive (sbconfig.sbar)\nBuild sbconfig.sbar for your sample deployment, available at /composites/mavenproject/HelloWorldSB:\n$ cd /composites/mavenproject/HelloWorldSB $ mvn com.oracle.servicebus.plugin:oracle-servicebus-plugin:package The Oracle Service Bus Archive (SBAR) will be generated at /composites/mavenproject/HelloWorldSB/.data/maven/sbconfig.sbar.\n Deploy the generated sbconfig.sbar into the Oracle Service Bus instance. For example, if the Administration URL is http://soainfra-adminserver:7011 with credentials username: weblogic and password: Welcome1, enter the following commands: :\n$ cd /composites/mavenproject/HelloWorldSB $ mvn pre-integration-test \\ -DoracleServerUrl=t3://soainfra-adminserver:7011 \\ -DoracleUsername=weblogic -DoraclePassword=Welcome1 Ant based build and deploy Note: Make sure to execute these commands inside the soadeploy pod.\n For Oracle SOA Suite composite applications Build an Oracle SOA Suite composite application using Ant. For example, if the composite application to be deployed is available at /composites/antproject/Project, enter the following commands:\n$ cd /u01/oracle/soa/bin $ ant -f ant-sca-package.xml \\ -DcompositeDir=/composites/antproject/Project \\ -DcompositeName=Project \\ -Drevision=0.1 The SOA Archive is generated at /composites/antproject/Project/deploy/sca_Project_rev0.1.jar, which will be used for deploying.\n Deploy into the Oracle SOA Suite instance using Ant:\n$ cd /u01/oracle/soa/bin $ ant -f ant-sca-deploy.xml \\ -DserverURL=http://soainfra-cluster-soa-cluster:8011 \\ -DsarLocation=/composites/antproject/Project/deploy/sca_Project_rev0.1.jar \\ -Doverwrite=true \\ -Duser=weblogic -Dpassword=Welcome1 For Oracle Service Bus composite applications See Developing Services Using Oracle Service Bus to deploy Oracle Service Bus composite applications using Ant.\n"
+},
+{
+ "uri": "/fmw-kubernetes/24.2.2/soa-domains/adminguide/enable-additional-url-access/",
+ "title": "Enable additional URL access",
+ "tags": [],
+ "description": "Extend an existing ingress to enable additional application URL access for Oracle SOA Suite domains.",
+ "content": "This section provides information about how to extend an existing ingress (Non-SSL and SSL termination) to enable additional application URL access for Oracle SOA Suite domains.\nThe ingress per domain created in the steps in Set up a load balancer exposes the application paths defined in template YAML files present at ${WORKDIR}/charts/ingress-per-domain/templates/.\nTo extend an existing ingress with additional application URL access:\n Update the template YAML file at ${WORKDIR}/charts/ingress-per-domain/templates/ to define additional path rules.\nFor example, to extend an existing NGINX-based ingress with additional paths /path1 and /path2 of an Oracle SOA Suite cluster, update nginx-ingress-nonssl.yaml, nginx-ingress-ssl.yaml, or nginx-ingress-e2essl.yaml accordingly with additional paths:\n# Copyright (c) 2020, 2022, Oracle and/or its affiliates. # Licensed under the Universal Permissive License v 1.0 as shown at https://oss.oracle.com/licenses/upl. {{- if eq .Values.type \u0026quot;NGINX\u0026quot; }} {{- if (eq .Values.sslType \u0026quot;NONSSL\u0026quot;) }} --- apiVersion: networking.k8s.io/v1 kind: Ingress . . spec: rules: - host: '{{ .Values.nginx.hostname }}' http: paths: # Add new paths -- start - path: /path1 backend: service: name: '{{ .Values.wlsDomain.domainUID }}-cluster-{{ .Values.wlsDomain.soaClusterName | lower | replace \u0026quot;_\u0026quot; \u0026quot;-\u0026quot; }}' port: number: {{ .Values.wlsDomain.soaManagedServerPort }} - path: /path2 backend: service: name: '{{ .Values.wlsDomain.domainUID }}-cluster-{{ .Values.wlsDomain.soaClusterName | lower | replace \u0026quot;_\u0026quot; \u0026quot;-\u0026quot; }}' port: number: {{ .Values.wlsDomain.soaManagedServerPort }} # Add new paths -- end - path: /console backend: . . {{- end }} Get the Helm release name for the ingress installed in your domain namespace:\n$ helm ls -n \u0026lt;domain_namespace\u0026gt; For example, in the soans namespace:\n$ helm ls -n soans Sample output, showing the Helm release name for a NGINX-based ingress as soa-nginx-ingress:\nNAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION soa-nginx-ingress soans 1 2021-02-17 13:42:03.252742314 +0000 UTC deployed ingress-per-domain-0.1.0 1.0 $ To extend the existing ingress per domain with additional paths defined in the template YAML, use the helm upgrade command:\n$ cd ${WORKDIR} $ helm upgrade \u0026lt;helm_release_for_ingress\u0026gt; \\ charts/ingress-per-domain \\ --namespace \u0026lt;domain_namespace\u0026gt; \\ --reuse-values Note: helm_release_for_ingress is the ingress name used in the corresponding helm install command for the ingress installation.\n Sample command for a NGINX-based ingress soa-nginx-ingress in the soans namespace:\n$ cd ${WORKDIR} $ helm upgrade soa-nginx-ingress \\ charts/ingress-per-domain \\ --namespace soans \\ --reuse-values This will upgrade the existing ingress to pick up the additional paths updated in the template YAML.\n Verify that additional paths are updated into the existing ingress.\na. Get the existing ingress deployed in the domain namespace:\n$ kubectl get ingress -n \u0026lt;domain_namespace\u0026gt; For example, in the soans namespace:\n$ kubectl get ingress -n soans Sample output, showing the existing ingress as soainfra-nginx:\nNAME CLASS HOSTS ADDRESS PORTS AGE soainfra-nginx \u0026lt;none\u0026gt; domain1.org 10.109.211.160 80, 443 xxd b. Describe the ingress object and verify that new paths are available and pointing to desired backends.\nSample command and output, showing path and backend details for /path1 and /path2:\n$ kubectl describe ingress soainfra-nginx -n soans|grep path /path1 soainfra-cluster-soa-cluster:8011 (172.17.0.19:8011,172.17.0.20:8011) /path2 soainfra-cluster-soa-cluster:8011 (172.17.0.19:8011,172.17.0.20:8011) "
+},
+{
+ "uri": "/fmw-kubernetes/24.2.2/soa-domains/adminguide/configure-load-balancer/nginx/",
+ "title": "NGINX",
+ "tags": [],
+ "description": "Configure the ingress-based NGINX load balancer for Oracle SOA Suite domains.",
+ "content": "This section provides information about how to install and configure the ingress-based NGINX load balancer to load balance Oracle SOA Suite domain clusters. You can configure NGINX for non-SSL, SSL termination, and end-to-end SSL access of the application URL.\nFollow these steps to set up NGINX as a load balancer for an Oracle SOA Suite domain in a Kubernetes cluster:\nSee the official installation document for prerequisites.\n Install the NGINX load balancer for non-SSL and SSL termination configuration Generate secret for SSL access Install NGINX load balancer for end-to-end SSL configuration Configure NGINX to manage ingresses Verify domain application URL access Uninstall NGINX ingress Uninstall NGINX To get repository information, enter the following Helm commands:\n$ helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx $ helm repo update Install the NGINX load balancer for non-SSL and SSL termination configuration Deploy the ingress-nginx controller by using Helm on the domain namespace:\n$ helm install nginx-ingress -n soans \\ --set controller.service.type=NodePort \\ --set controller.admissionWebhooks.enabled=false \\ ingress-nginx/ingress-nginx Click here to see the sample output. NAME: nginx-ingress LAST DEPLOYED: Thu May 5 13:27:30 2022 NAMESPACE: soans STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: The ingress-nginx controller has been installed. Get the application URL by running these commands: export HTTP_NODE_PORT=$(kubectl --namespace soans get services -o jsonpath=\u0026quot;{.spec.ports[0].nodePort}\u0026quot; nginx-ingress-ingress-nginx-controller) export HTTPS_NODE_PORT=$(kubectl --namespace soans get services -o jsonpath=\u0026quot;{.spec.ports[1].nodePort}\u0026quot; nginx-ingress-ingress-nginx-controller) export NODE_IP=$(kubectl --namespace soans get nodes -o jsonpath=\u0026quot;{.items[0].status.addresses[1].address}\u0026quot;) echo \u0026quot;Visit http://$NODE_IP:$HTTP_NODE_PORT to access your application via HTTP.\u0026quot; echo \u0026quot;Visit https://$NODE_IP:$HTTPS_NODE_PORT to access your application via HTTPS.\u0026quot; An example ingress that makes use of the controller: apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example namespace: foo spec: ingressClassName: nginx rules: - host: www.example.com http: paths: - pathType: Prefix backend: service: name: exampleService port: number: 80 path: / # This section is only required if TLS is to be enabled for the ingress tls: - hosts: - www.example.com secretName: example-tls If TLS is enabled for the ingress, a secret containing the certificate and key must also be provided: apiVersion: v1 kind: Secret metadata: name: example-tls namespace: foo data: tls.crt: \u0026lt;base64 encoded cert\u0026gt; tls.key: \u0026lt;base64 encoded key\u0026gt; type: kubernetes.io/tls Generate secret for SSL access For secured access (SSL and E2ESSL) to the Oracle SOA Suite application, create a certificate and generate secrets:\n$ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /tmp/tls1.key -out /tmp/tls1.crt -subj \u0026#34;/CN=domain1.org\u0026#34; $ kubectl -n soans create secret tls soainfra-tls-cert --key /tmp/tls1.key --cert /tmp/tls1.crt Note: The value of CN is the host on which this ingress is to be deployed and secret name should be \u0026lt;domainUID\u0026gt;-tls-cert.\n Install NGINX load balancer for end-to-end SSL configuration Deploy the ingress-nginx controller by using Helm on the domain namespace:\n$ helm install nginx-ingress -n soans \\ --set controller.extraArgs.default-ssl-certificate=soans/soainfra-tls-cert \\ --set controller.service.type=NodePort \\ --set controller.admissionWebhooks.enabled=false \\ --set controller.extraArgs.enable-ssl-passthrough=true \\ ingress-nginx/ingress-nginx Click here to see the sample output. NAME: nginx-ingress LAST DEPLOYED: Thu May 5 12:21:50 2022 NAMESPACE: soans STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: The ingress-nginx controller has been installed. Get the application URL by running these commands: export HTTP_NODE_PORT=$(kubectl --namespace soans get services -o jsonpath=\u0026#34;{.spec.ports[0].nodePort}\u0026#34; nginx-ingress-ingress-nginx-controller) export HTTPS_NODE_PORT=$(kubectl --namespace soans get services -o jsonpath=\u0026#34;{.spec.ports[1].nodePort}\u0026#34; nginx-ingress-ingress-nginx-controller) export NODE_IP=$(kubectl --namespace soans get nodes -o jsonpath=\u0026#34;{.items[0].status.addresses[1].address}\u0026#34;) echo \u0026#34;Visit http://$NODE_IP:$HTTP_NODE_PORTto access your application via HTTP.\u0026#34; echo \u0026#34;Visit https://$NODE_IP:$HTTPS_NODE_PORTto access your application via HTTPS.\u0026#34; An example Ingress that makes use of the controller: apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example namespace: foo spec: ingressClassName: nginx rules: - host: www.example.com http: paths: - pathType: Prefix backend: service: name: exampleService port: number: 80 path: / # This section is only required if TLS is to be enabled for the Ingress tls: - hosts: - www.example.com secretName: example-tls If TLS is enabled for the Ingress, a Secret containing the certificate and key must also be provided: apiVersion: v1 kind: Secret metadata: name: example-tls namespace: foo data: tls.crt: \u0026lt;base64 encoded cert\u0026gt; tls.key: \u0026lt;base64 encoded key\u0026gt; type: kubernetes.io/tls Check the status of the deployed ingress controller:\n$ kubectl --namespace soans get services | grep ingress-nginx-controller Sample output:\nnginx-ingress-ingress-nginx-controller NodePort 10.106.186.235 \u0026lt;none\u0026gt; 80:32125/TCP,443:31376/TCP 19m Configure NGINX to manage ingresses Choose an appropriate LOADBALANCER_HOSTNAME for accessing the Oracle SOA Suite domain application URLs.\n$ export LOADBALANCER_HOSTNAME=\u0026lt;LOADBALANCER_HOSTNAME\u0026gt; For example, if you are executing the commands from a master node terminal, where the master hostname is LOADBALANCER_HOSTNAME:\n$ export LOADBALANCER_HOSTNAME=$(hostname -f) Create an ingress for the domain in the domain namespace by using the sample Helm chart. Here path-based routing is used for ingress. Sample values for default configuration are shown in the file ${WORKDIR}/charts/ingress-per-domain/values.yaml. By default, type is TRAEFIK , sslType is NONSSL, and domainType is soa. These values can be overridden by passing values through the command line or can be edited in the sample file values.yaml.\nIf needed, you can update the ingress YAML file to define more path rules (in section spec.rules.host.http.paths) based on the domain application URLs that need to be accessed. Update the template YAML file for the NGINX load balancer located at ${WORKDIR}/charts/ingress-per-domain/templates/nginx-ingress.yaml.\n Note: See here for all the configuration parameters.\n $ cd ${WORKDIR} $ helm install soa-nginx-ingress charts/ingress-per-domain \\ --namespace soans \\ --values charts/ingress-per-domain/values.yaml \\ --set \u0026#34;nginx.hostname=${LOADBALANCER_HOSTNAME}\u0026#34; \\ --set type=NGINX Sample output:\nNAME: soa-nginx-ingress LAST DEPLOYED: Fri Jul 24 09:34:03 2020 NAMESPACE: soans STATUS: deployed REVISION: 1 TEST SUITE: None Install ingress-per-domain using Helm for SSL termination configuration:\n$ cd ${WORKDIR} $ helm install soa-nginx-ingress charts/ingress-per-domain \\ --namespace soans \\ --values charts/ingress-per-domain/values.yaml \\ --set \u0026#34;nginx.hostname=${LOADBALANCER_HOSTNAME}\u0026#34; \\ --set type=NGINX --set sslType=SSL Sample output:\nNAME: soa-nginx-ingress LAST DEPLOYED: Fri Jul 24 09:34:03 2020 NAMESPACE: soans STATUS: deployed REVISION: 1 TEST SUITE: None Install ingress-per-domain using Helm for E2ESSL configuration.\n Note: To use the E2ESSL configuration, you must have created the Oracle SOA Suite domain with sslEnabled set to true. See Create Oracle SOA Suite domains.\n $ cd ${WORKDIR} $ helm install soa-nginx-ingress charts/ingress-per-domain \\ --namespace soans \\ --values charts/ingress-per-domain/values.yaml \\ --set type=NGINX --set sslType=E2ESSL Sample output:\nNAME: soa-nginx-ingress LAST DEPLOYED: Fri Jul 24 09:34:03 2020 NAMESPACE: soans STATUS: deployed REVISION: 1 TEST SUITE: None For NONSSL access to the Oracle SOA Suite application, get the details of the services by the ingress:\n$ kubectl describe ingress soainfra-nginx -n soans Click here to see the sample output of the services supported by the above deployed ingress. Name: soainfra-nginx Namespace: soans Address: 100.111.150.225 Default backend: default-http-backend:80 (\u0026lt;error: endpoints \u0026quot;default-http-backend\u0026quot; not found\u0026gt;) Rules: Host Path Backends ---- ---- -------- domain1.org /console soainfra-adminserver:7011 (10.244.0.45:7011) /em soainfra-adminserver:7011 (10.244.0.45:7011) /weblogic/ready soainfra-adminserver:7011 (10.244.0.45:7011) / soainfra-cluster-soa-cluster:8011 (10.244.0.46:8011,10.244.0.47:8011) /soa-infra soainfra-cluster-soa-cluster:8011 (10.244.0.46:8011,10.244.0.47:8011) /soa/composer soainfra-cluster-soa-cluster:8011 (10.244.0.46:8011,10.244.0.47:8011) /integration/worklistapp soainfra-cluster-soa-cluster:8011 (10.244.0.46:8011,10.244.0.47:8011) Annotations: \u0026lt;none\u0026gt; Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal CREATE 2m32s nginx-ingress-controller Ingress soans/soainfra-nginx Normal UPDATE 94s nginx-ingress-controller Ingress soans/soainfra-nginx For SSL access to the Oracle SOA Suite application, get the details of the services by the above deployed ingress:\n$ kubectl describe ingress soainfra-nginx -n soans Click here to see the sample output of the services supported by the above deployed ingress. Name: soainfra-nginx Namespace: soans Address: 100.111.150.225 Default backend: default-http-backend:80 (\u0026lt;error: endpoints \u0026quot;default-http-backend\u0026quot; not found\u0026gt;) TLS: soainfra-tls-cert terminates domain1.org Rules: Host Path Backends ---- ---- -------- domain1.org /console soainfra-adminserver:7011 (10.244.0.45:7011) /em soainfra-adminserver:7011 (10.244.0.45:7011) /weblogic/ready soainfra-adminserver:7011 (10.244.0.45:7011) / soainfra-cluster-soa-cluster:8011 (10.244.0.46:8011,10.244.0.47:8011) /soa-infra soainfra-cluster-soa-cluster:8011 (10.244.0.46:8011,10.244.0.47:8011) /soa/composer soainfra-cluster-soa-cluster:8011 (10.244.0.46:8011,10.244.0.47:8011) /integration/worklistapp soainfra-cluster-soa-cluster:8011 (10.244.0.46:8011,10.244.0.47:8011) Annotations: kubernetes.io/ingress.class: nginx nginx.ingress.kubernetes.io/configuration-snippet: more_set_input_headers \u0026quot;X-Forwarded-Proto: https\u0026quot;; more_set_input_headers \u0026quot;WL-Proxy-SSL: true\u0026quot;; nginx.ingress.kubernetes.io/ingress.allow-http: false Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal CREATE 3m47s nginx-ingress-controller Ingress soans/soainfra-nginx Normal UPDATE 3m25s nginx-ingress-controller Ingress soans/soainfra-nginx For E2ESSL access to the Oracle SOA Suite application, get the details of the services by the above deployed ingress:\n$ kubectl describe ingress soainfra-nginx-e2essl -n soans Click here to see the sample output of the services supported by the above deployed ingress. Name: soainfra-nginx-e2essl-admin Namespace: soans Address: Default backend: default-http-backend:80 (\u0026lt;error: endpoints \u0026quot;default-http-backend\u0026quot; not found\u0026gt;) TLS: soainfra-tls-cert terminates admin.org Rules: Host Path Backends ---- ---- -------- admin.org soainfra-adminserver-nginx-ssl:7012 (10.244.0.247:7012) Annotations: kubernetes.io/ingress.class: nginx meta.helm.sh/release-name: soa-nginx-ingress meta.helm.sh/release-namespace: soans nginx.ingress.kubernetes.io/ssl-passthrough: true Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Sync 4s nginx-ingress-controller Scheduled for sync Name: soainfra-nginx-e2essl-soa Namespace: soans Address: Default backend: default-http-backend:80 (\u0026lt;error: endpoints \u0026quot;default-http-backend\u0026quot; not found\u0026gt;) TLS: soainfra-tls-cert terminates soa.org Rules: Host Path Backends ---- ---- -------- soa.org / soainfra-cluster-soa-cluster:8012 (10.244.0.249:8012) Annotations: kubernetes.io/ingress.class: nginx meta.helm.sh/release-name: soa-nginx-ingress meta.helm.sh/release-namespace: soans nginx.ingress.kubernetes.io/ssl-passthrough: true Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Sync 4s nginx-ingress-controller Scheduled for sync Verify domain application URL access NONSSL configuration Get the LOADBALANCER_NON_SSLPORT NodePort of NGINX using the command:\n$ LOADBALANCER_NON_SSLPORT=$(kubectl --namespace soans get services -o jsonpath=\u0026#34;{.spec.ports[0].nodePort}\u0026#34; nginx-ingress-ingress-nginx-controller) $ echo ${LOADBALANCER_NON_SSLPORT} Verify that the Oracle SOA Suite domain application URLs are accessible through the LOADBALANCER_NON_SSLPORT:\nhttp://${LOADBALANCER_HOSTNAME}:${LOADBALANCER_NON_SSLPORT}/weblogic/ready http://${LOADBALANCER_HOSTNAME}:${LOADBALANCER_NON_SSLPORT}/console http://${LOADBALANCER_HOSTNAME}:${LOADBALANCER_NON_SSLPORT}/em http://${LOADBALANCER_HOSTNAME}:${LOADBALANCER_NON_SSLPORT}/soa-infra http://${LOADBALANCER_HOSTNAME}:${LOADBALANCER_NON_SSLPORT}/soa/composer http://${LOADBALANCER_HOSTNAME}:${LOADBALANCER_NON_SSLPORT}/integration/worklistapp SSL configuration Get the LOADBALANCER_SSLPORT NodePort of NGINX using the command:\n$ LOADBALANCER_SSLPORT=$(kubectl --namespace soans get services -o jsonpath=\u0026#34;{.spec.ports[1].nodePort}\u0026#34; nginx-ingress-ingress-nginx-controller) $ echo ${LOADBALANCER_SSLPORT} Verify that the Oracle SOA Suite domain application URLs are accessible through the LOADBALANCER_SSLPORT:\nhttps://${LOADBALANCER_HOSTNAME}:${LOADBALANCER_SSLPORT}/weblogic/ready https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER_SSLPORT}/console https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER_SSLPORT}/em https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER_SSLPORT}/soa-infra https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER_SSLPORT}/soa/composer https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER_SSLPORT}/integration/worklistapp E2ESSL configuration To access the SOA Suite domain application URLs from a remote browser, update the browser host config file /etc/hosts (In Windows, C:\\Windows\\System32\\Drivers\\etc\\hosts) with the IP address of the host on which the ingress is deployed with below entries:\nX.X.X.X admin.org X.X.X.X soa.org X.X.X.X osb.org Note:\n The value of X.X.X.X is the host IP address on which this ingress is deployed. If you are behind any corporate proxy, make sure to update the browser proxy settings appropriately to access the host names updated /etc/hosts file. Get the LOADBALANCER_SSLPORT NodePort of NGINX using the command:\n$ LOADBALANCER_SSLPORT=$(kubectl --namespace soans get services -o jsonpath=\u0026#34;{.spec.ports[1].nodePort}\u0026#34; nginx-ingress-ingress-nginx-controller) $ echo ${LOADBALANCER_SSLPORT} Verify that the Oracle SOA Suite domain application URLs are accessible through LOADBALANCER_SSLPORT:\nhttps://admin.org:${LOADBALANCER_SSLPORT}/weblogic/ready https://admin.org:${LOADBALANCER_SSLPORT}/console https://admin.org:${LOADBALANCER_SSLPORT}/em https://soa.org:${LOADBALANCER_SSLPORT}/soa-infra https://soa.org:${LOADBALANCER_SSLPORT}/soa/composer https://soa.org:${LOADBALANCER_SSLPORT}/integration/worklistapp Note: This is the default host name. If you have updated the host name in values.yaml, then use the updated values.\n Uninstall NGINX ingress Uninstall and delete the ingress-nginx deployment:\n$ helm delete soa-nginx-ingress -n soans Uninstall NGINX $ helm delete nginx-ingress -n soans "
+},
+{
+ "uri": "/fmw-kubernetes/24.2.2/soa-domains/patch_and_upgrade/upgrade-operator-release/",
+ "title": "Upgrade an operator release",
+ "tags": [],
+ "description": "Upgrade the WebLogic Kubernetes Operator release to a newer version.",
+ "content": "To upgrade the WebLogic Kubernetes operator, use the helm upgrade command with new Helm chart and operator image. See the steps here to pull the operator image and set up the Oracle SOA Suite repository that contains the operator chart. To upgrade the operator run the following command:\n$ cd ${WORKDIR} $ helm upgrade \\ --reuse-values \\ --set image=ghcr.io/oracle/weblogic-kubernetes-operator:4.1.7 \\ --namespace weblogic-operator-namespace \\ --wait \\ weblogic-kubernetes-operator \\ charts/weblogic-operator Note: When the WebLogic Kubernetes Operator is upgraded from release version 3.2.1 to 3.3.0 or later, it may be expected that the Administration Server pod in the domain gets restarted.\n Post upgrade steps When you upgrade a 3.x operator to 4.0, the upgrade process creates a WebLogic Domain resource conversion webhook deployment and its associated resources in the same namespace. If the conversion webhook deployment already exists in another namespace, then a new conversion webhook deployment is not created. The webhook automatically and transparently upgrades the existing WebLogic Domains from the 3.x schema to the 4.0 schema. For more information, see WebLogic Domain resource conversion webhook.\nIf you have a single WebLogic Kubernetes Operator per Kubernetes cluster (most common use case), you can upgrade directly from any 3.x operator release to 4.1.7. The Helm chart for 4.1.7 automatically installs the schema conversion webhook.\nIf there is more than one WebLogic Kubernetes Operator in a single Kubernetes cluster:\n You must upgrade every operator to at least version 3.4.1 before upgrading any operator to 4.0.0. As the 4.0.x Helm chart also installs a singleton schema conversion webhook that is shared by all 4.0.x operators in the cluster, use the webhookOnly Helm chart option to install this webhook in its own namespace prior to installing any of the 4.0.0 operators, and also use the preserveWebhook Helm chart option with each operator to prevent an operator uninstall from uninstalling the shared webhook. The operator provides a utility that can be used to convert existing “v8” Domain YAML files to “v9”. Several Helm chart default values have been changed. If you upgrade 3.x installations using the --reuse-values option during the Helm upgrade, the installations will continue to use the values from their original installation. If you are still using an older operator version (from 3.1.1) the T3 channel Kubernetes service name extension is changed from -external to -ext. If the Administration Server was configured to expose a T3 channel in your domain, then follow these steps to recreate the Kubernetes service (for T3 channel) with the new name -ext.\n Note: If these steps are not performed, then the domain restart using spec.serverStartPolicy fails to bring up the servers.\n Get the existing Kubernetes service name for the T3 channel from the domain namespace. For example, if the domainUID is soainfra, and the Administration Server name is adminserver, then the service is:\nsoainfra-adminserver-external Delete the existing Kubernetes service for T3 channel, so that operator 3.1.1 creates a new one:\n$ kubectl delete service \u0026lt;T3 channel service\u0026gt; --namespace \u0026lt;domain-namespace\u0026gt; For example, if the domainUID is soainfra, the Administration Server name is adminserver and domain namespace is soans, then the command is:\n$ kubectl delete service soainfra-adminserver-external --namespace soans Now, the operator automatically creates a new Kubernetes service with -ext instead of -external:\nsoainfra-adminserver-ext "
+},
+{
+ "uri": "/fmw-kubernetes/24.2.2/soa-domains/adminguide/deploying-composites/deploy-artifacts/",
+ "title": "Deploy using composites in a persistent volume or image",
+ "tags": [],
+ "description": "Deploy Oracle SOA Suite and Oracle Service Bus composite applications artifacts in a persistent volume or in an image.",
+ "content": "Learn how to deploy Oracle SOA Suite and Oracle Service Bus composite applications artifacts in a Kubernetes persistent volume or in an image to an Oracle SOA Suite environment deployed using a WebLogic Kubernetes Operator.\nThe deployment methods described in Deploy using JDeveloper and Deploy using Maven and Ant are manual processes. If you have the deployment artifacts (archives) already built, then you can package them either into a Kubernetes persistent volume or in an image and use this automated process to deploy the artifacts to an Oracle SOA Suite domain.\nPrepare to use the deploy artifacts script The sample scripts for deploying artifacts are available at ${WORKDIR}/create-soa-domain/domain-home-on-pv/\nYou must edit deploy-artifacts-inputs.yaml (or a copy of it) to provide the details of your domain and artifacts. Refer to the configuration parameters below to understand the information that you must provide in this file.\nConfiguration parameters The following parameters can be provided in the inputs file.\n Parameter Definition Default adminPort Port number of the Administration Server inside the Kubernetes cluster. 7011 adminServerName Name of the Administration Server. AdminServer domainUID Unique ID that is used to identify the domain. This ID cannot contain any characters that are 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 artifacts into an Oracle SOA Suite domain), osb (deploys artifacts into an Oracle Service Bus domain), or soaosb (deploys artifacts into both Oracle SOA Suite and Oracle Service Bus domains). soa soaClusterName Name of the SOA WebLogic Server cluster instance in the domain. By default, the cluster name is soa_cluster. This configuration parameter is applicable only for soa and soaosb domain types. soa_cluster image SOA Suite Docker image. The artifacts deployment process 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 Oracle SOA Suite Docker image pull policy. Valid values are IfNotPresent, Always, Never. IfNotPresent imagePullSecretName Name of the Kubernetes secret to access the Docker Store to pull the Oracle SOA Suite Docker image. The presence of the secret will be validated when this parameter is specified. weblogicCredentialsSecretName Name of the Kubernetes secret for the Administration Server\u0026rsquo;s user name and password. If not specified, then the value is derived from the domainUID as \u0026lt;domainUID\u0026gt;-weblogic-credentials. soainfra-domain-credentials namespace Kubernetes namespace in which the domain was created. soans artifactsSourceType The deploy artifacts source type. Set to PersistentVolume for deploy artifacts available in a persistent volume and Image for deploy artifacts available as an image. Image persistentVolumeClaimName Name of the persistent volume claim created that hosts the deployment artifacts. If not specified, the value is derived from the domainUID as \u0026lt;domainUID\u0026gt;-deploy-artifacts-pvc. soainfra-deploy-artifacts-pvc artifactsImage Deploy artifacts image. Required if artifactsSourceType is Image. artifacts:12.2.1.4 artifactsImagePullPolicy Deploy artifacts image pull policy. Valid values are IfNotPresent, Always, Never. IfNotPresent artifactsImagePullSecretName Name of the Kubernetes secret to access the deploy artifacts image. The presence of the secret will be validated when this parameter is specified. deployScriptFilesDir Directory on the host machine to locate the required files to deploy artifacts to the Oracle SOA Suite domain, including the script that is specified in the deployScriptName parameter. By default, this directory is set to the relative path deploy. deploy deployScriptsMountPath Mount path where the deploy artifacts scripts are located inside a pod. The deploy-artifacts.sh script creates a Kubernetes job to run the script (specified by the deployScriptName parameter) in a Kubernetes pod to deploy the artifacts. Files in the deployScriptFilesDir directory are mounted to this location in the pod, so that the Kubernetes pod can use the scripts and supporting files to deploy artifacts. /u01/weblogic deployScriptName Script that the deploy artifacts script uses to deploy artifacts to the Oracle SOA Suite domain. For Oracle SOA Suite, the script placed in the soa directory is used. For Oracle Service Bus, the script placed in the osb directory is used. The deploy-artifacts.sh script creates a Kubernetes job to run this script to deploy artifacts. The script is located in the in-pod directory that is specified by the deployScriptsMountPath parameter. deploy.sh soaArtifactsArchivePath Directory inside container where Oracle SOA Suite archives are placed. /u01/sarchives osbArtifactsArchivePath Directory inside container where Oracle Service Bus archives are placed. /u01/sbarchives The sample demonstrates how to deploy Oracle SOA Suite composites or Oracle Service Bus applications to an Oracle SOA Suite domain home.\nRun the deploy artifacts script Run the deploy artifacts script, specifying your inputs file and an output directory to store the generated artifacts:\n$ ./deploy-artifacts.sh \\ -i deploy-artifacts-inputs.yaml \\ -o \u0026lt;path to output-directory\u0026gt; The script performs the following steps:\n Creates a directory for the generated Kubernetes YAML files for the artifacts deployment process if it does not already exist. The path name is \u0026lt;path to output-directory\u0026gt;/weblogic-domains/\u0026lt;domainUID\u0026gt;/\u0026lt;YYYYMMDD-hhmmss\u0026gt;. If the directory already exists, its contents must be removed before running this script. Creates a Kubernetes job that starts a utility Oracle SOA Suite container and run scripts to deploy artifacts provided either in an image or in a persistent volume. Deploy artifacts from an image Create an image with artifacts\na. A sample Dockerfile to create the artifacts in an image is available at $WORKDIR/create-soa-domain/domain-home-on-pv/deploy-docker-file. This expects the Oracle SOA Suite related archives to be available in the soa directory and Oracle Service Bus archives to be available in the osb directory.\nb. Create the soa directory and copy the Oracle SOA Suite archives to be deployed to the directory:\n$ cd $WORKDIR/create-soa-domain/domain-home-on-pv/deploy-docker-file $ mkdir soa $ cp /path/sca_sampleBPEL.jar soa c. Create the osb directory and copy the Oracle Service Bus archives to be deployed to the directory:\n$ cd $WORKDIR/create-soa-domain/domain-home-on-pv/deploy-docker-file $ mkdir osb $ cp /path/simple_sbconfig.jar osb d. Create the image using build.sh. This script creates the image with default tag 12.2.1.4 (artifacts:12.2.1.4):\n$ cd $WORKDIR/create-soa-domain/domain-home-on-pv/deploy-docker-file $ ./build.sh -h Usage: build.sh -t [tag] Builds a Docker Image with Oracle SOA/OSB artifacts Parameters: -h: view usage -t: tag for image, default is 12.2.1.4 Click here to see sample output of script with tag 12.2.1.4-v1 ``` $ ./build.sh -t 12.2.1.4-v1 Sending build context to Docker daemon 36.35kB Step 1/13 : FROM busybox ---\u0026gt; 16ea53ea7c65 Step 2/13 : ARG SOA_ARTIFACTS_ARCHIVE_PATH=/u01/sarchives ---\u0026gt; Using cache ---\u0026gt; 411edf07f267 Step 3/13 : ARG OSB_ARTIFACTS_ARCHIVE_PATH=/u01/sbarchives ---\u0026gt; Using cache ---\u0026gt; c4214b9cf0ae Step 4/13 : ARG USER=oracle ---\u0026gt; Using cache ---\u0026gt; c8ebcd5ee546 Step 5/13 : ARG USERID=1000 ---\u0026gt; Using cache ---\u0026gt; 5780beb0c3cf Step 6/13 : ARG GROUP=root ---\u0026gt; Using cache ---\u0026gt; 048e67c71f92 Step 7/13 : ENV SOA_ARTIFACTS_ARCHIVE_PATH=${SOA_ARTIFACTS_ARCHIVE_PATH} ---\u0026gt; Using cache ---\u0026gt; 31ae33cfd9bb Step 8/13 : ENV OSB_ARTIFACTS_ARCHIVE_PATH=${OSB_ARTIFACTS_ARCHIVE_PATH} ---\u0026gt; Using cache ---\u0026gt; 79602bf64dc0 Step 9/13 : RUN adduser -D -u ${USERID} -G $GROUP $USER ---\u0026gt; Using cache ---\u0026gt; 07c12cea52f9 Step 10/13 : COPY soa/ ${SOA_ARTIFACTS_ARCHIVE_PATH}/ ---\u0026gt; bfeb138516d8 Step 11/13 : COPY osb/ ${OSB_ARTIFACTS_ARCHIVE_PATH}/ ---\u0026gt; 0359a11f8f76 Step 12/13 : RUN chown -R $USER:$GROUP ${SOA_ARTIFACTS_ARCHIVE_PATH}/ ${OSB_ARTIFACTS_ARCHIVE_PATH}/ ---\u0026gt; Running in 285fb2bd8434 Removing intermediate container 285fb2bd8434 ---\u0026gt; 2e8d8c337de0 Step 13/13 : USER $USER ---\u0026gt; Running in c9db494e46ab Removing intermediate container c9db494e46ab ---\u0026gt; 40295aa15317 Successfully built 40295aa15317 Successfully tagged artifacts:12.2.1.4-v1 INFO: Artifacts image for Oracle SOA suite is ready to be extended. --\u0026gt; artifacts:12.2.1.4-v1 INFO: Build completed in 4 seconds. ``` Update the image details in deploy-artifacts-inputs.yaml for parameter artifactsImage and invoke deploy-artifacts.sh to perform deployment of artifacts.\n Click here to see sample output of deployment for domainType of soaosb $ ./deploy-artifacts.sh -i deploy-artifacts-inputs.yaml -o out-deploy Input parameters being used export version=\u0026quot;deploy-artifacts-inputs-v1\u0026quot; export adminPort=\u0026quot;7011\u0026quot; export adminServerName=\u0026quot;AdminServer\u0026quot; export domainUID=\u0026quot;soainfra\u0026quot; export domainType=\u0026quot;soaosb\u0026quot; export soaClusterName=\u0026quot;soa_cluster\u0026quot; export soaManagedServerPort=\u0026quot;8011\u0026quot; export image=\u0026quot;soasuite:12.2.1.4\u0026quot; export imagePullPolicy=\u0026quot;IfNotPresent\u0026quot; export weblogicCredentialsSecretName=\u0026quot;soainfra-domain-credentials\u0026quot; export namespace=\u0026quot;soans\u0026quot; export artifactsSourceType=\u0026quot;Image\u0026quot; export artifactsImage=\u0026quot;artifacts:12.2.1.4-v1\u0026quot; export artifactsImagePullPolicy=\u0026quot;IfNotPresent\u0026quot; export deployScriptsMountPath=\u0026quot;/u01/weblogic\u0026quot; export deployScriptName=\u0026quot;deploy.sh\u0026quot; export deployScriptFilesDir=\u0026quot;deploy\u0026quot; export soaArtifactsArchivePath=\u0026quot;/u01/sarchives\u0026quot; export osbArtifactsArchivePath=\u0026quot;/u01/sbarchives\u0026quot; Generating out-deploy/deploy-artifacts/soainfra/20211022-152335/deploy-artifacts-job.yaml Checking to see if the secret soainfra-domain-credentials exists in namespace soans configmap/soainfra-deploy-scripts-soa-job-cm created Checking the configmap soainfra-deploy-scripts-soa-job-cm was created configmap/soainfra-deploy-scripts-soa-job-cm labeled configmap/soainfra-deploy-scripts-osb-job-cm created Checking the configmap soainfra-deploy-scripts-osb-job-cm was created configmap/soainfra-deploy-scripts-osb-job-cm labeled Checking if object type job with name soainfra-deploy-artifacts-job-20211022-152335 exists Deploying artifacts by creating the job out-deploy/deploy-artifacts/soainfra/20211022-152335/deploy-artifacts-job.yaml job.batch/soainfra-deploy-artifacts-job-20211022-152335 created Waiting for the job to complete... status on iteration 1 of 20 for soainfra pod soainfra-deploy-artifacts-job-20211022-152335-r7ffj status is NotReady status on iteration 2 of 20 for soainfra pod soainfra-deploy-artifacts-job-20211022-152335-r7ffj status is Completed configmap \u0026quot;soainfra-deploy-scripts-soa-job-cm\u0026quot; deleted configmap \u0026quot;soainfra-deploy-scripts-osb-job-cm\u0026quot; deleted The following files were generated: out-deploy/deploy-artifacts/soainfra/20211022-152335/deploy-artifacts-inputs.yaml out-deploy/deploy-artifacts/soainfra/20211022-152335/deploy-artifacts-job.yaml Completed $ kubectl get all -n soans|grep deploy pod/soainfra-deploy-artifacts-job-20211022-152335-r7ffj 0/2 Completed 0 15m job.batch/soainfra-deploy-artifacts-job-20211022-152335 1/1 43s 15m $ Note: When you are running the script for domainType soaosb, a deployment pod is created with two containers, one for Oracle SOA Suite artifacts deployments and another for Oracle Service Bus artifacts deployments. When the deployment completes for one container while other container is still running, the pod status will move from Ready to NotReady. Once both the deployments complete successfully, the status of the pod moves to Completed.\n Deploy artifacts from a persistent volume Copy the artifacts for Oracle SOA Suite to the soa directory and Oracle Service Bus to the osb directory at the share location. For example, with location /share, artifacts for Oracle SOA Suite are in /share/soa and Oracle Service Bus are in /share/osb.\n$ ls /share/soa sca_sampleBPEL.jar $ $ ls /share/osb/ simple_sbconfig.jar $ Create a PersistentVolume with the sample provided (artifacts-pv.yaml):\napiVersion: v1 kind: PersistentVolume metadata: name: soainfra-deploy-artifacts-pv spec: storageClassName: deploy-storage-class capacity: storage: 10Gi accessModes: - ReadOnlyMany persistentVolumeReclaimPolicy: Retain hostPath: path: \u0026quot;/share\u0026quot; $ kubectl apply -f artifacts-pv.yaml Create a PersistentVolumeClaim with the sample provided (artifacts-pvc.yaml):\napiVersion: v1 kind: PersistentVolumeClaim metadata: name: soainfra-deploy-artifacts-pvc namespace: soans spec: storageClassName: deploy-storage-class accessModes: - ReadOnlyMany resources: requests: storage: 10Gi $ kubectl apply -f artifacts-pvc.yaml Update the artifactsSourceType to PersistentVolume and provide the name for persistentVolumeClaimName in deploy-artifacts-inputs.yaml.\n Invoke deploy-artifacts.sh to deploy artifacts for artifacts present in persistentVolumeClaimName.\n Click here to see sample output of deployment for domainType of soaosb $ ./deploy-artifacts.sh -i deploy-artifacts-inputs.yaml -o out-deploy Input parameters being used export version=\u0026quot;deploy-artifacts-inputs-v1\u0026quot; export adminPort=\u0026quot;7011\u0026quot; export adminServerName=\u0026quot;AdminServer\u0026quot; export domainUID=\u0026quot;soainfra\u0026quot; export domainType=\u0026quot;soaosb\u0026quot; export soaClusterName=\u0026quot;soa_cluster\u0026quot; export soaManagedServerPort=\u0026quot;8011\u0026quot; export image=\u0026quot;soasuite:12.2.1.4\u0026quot; export imagePullPolicy=\u0026quot;IfNotPresent\u0026quot; export weblogicCredentialsSecretName=\u0026quot;soainfra-domain-credentials\u0026quot; export namespace=\u0026quot;soans\u0026quot; export artifactsSourceType=\u0026quot;PersistentVolume\u0026quot; export persistentVolumeClaimName=\u0026quot;soainfra-deploy-artifacts-pvc\u0026quot; export deployScriptsMountPath=\u0026quot;/u01/weblogic\u0026quot; export deployScriptName=\u0026quot;deploy.sh\u0026quot; export deployScriptFilesDir=\u0026quot;deploy\u0026quot; export soaArtifactsArchivePath=\u0026quot;/u01/sarchives\u0026quot; export osbArtifactsArchivePath=\u0026quot;/u01/sbarchives\u0026quot; Generating out-deploy/deploy-artifacts/soainfra/20211022-164735/deploy-artifacts-job.yaml Checking to see if the secret soainfra-domain-credentials exists in namespace soans configmap/soainfra-deploy-scripts-soa-job-cm created Checking the configmap soainfra-deploy-scripts-soa-job-cm was created configmap/soainfra-deploy-scripts-soa-job-cm labeled configmap/soainfra-deploy-scripts-osb-job-cm created Checking the configmap soainfra-deploy-scripts-osb-job-cm was created configmap/soainfra-deploy-scripts-osb-job-cm labeled Checking if object type job with name soainfra-deploy-artifacts-job-20211022-164735 exists Deploying artifacts by creating the job out-deploy/deploy-artifacts/soainfra/20211022-164735/deploy-artifacts-job.yaml job.batch/soainfra-deploy-artifacts-job-20211022-164735 created Waiting for the job to complete... status on iteration 1 of 20 for soainfra pod soainfra-deploy-artifacts-job-20211022-164735-66fvn status is NotReady status on iteration 2 of 20 for soainfra pod soainfra-deploy-artifacts-job-20211022-164735-66fvn status is Completed configmap \u0026quot;soainfra-deploy-scripts-soa-job-cm\u0026quot; deleted configmap \u0026quot;soainfra-deploy-scripts-osb-job-cm\u0026quot; deleted The following files were generated: out-deploy/deploy-artifacts/soainfra/20211022-164735/deploy-artifacts-inputs.yaml out-deploy/deploy-artifacts/soainfra/20211022-164735/deploy-artifacts-job.yaml Completed $ kubectl get all -n soans |grep deploy pod/soainfra-deploy-artifacts-job-20211022-164735-66fvn 0/2 Completed 0 3m1s job.batch/soainfra-deploy-artifacts-job-20211022-164735 1/1 37s 3m1s $ Note: When you are running the script for domainType of soaosb, a deployment pod is created with two containers, one for Oracle SOA Suite artifacts deployments and one for Oracle Service Bus artifacts deployments. When the deployment completes for one container while other container is still running, the pod status moves from Ready to NotReady. Once both the deployments successfully complete, the status of the pod moves to Completed.\n Verify the deployment logs To confirm the deployment of artifacts was successful, verify the output using the kubectl logs command:\n Note: Replace \u0026lt;YYYYMMDD-hhmmss\u0026gt;, \u0026lt;domainUID\u0026gt; and \u0026lt;namespace\u0026gt; with values for your environment.\n For Oracle SOA Suite artifacts:\n$ kubectl logs job.batch/\u0026lt;domainUID\u0026gt;-deploy-artifacts-job-\u0026lt;YYYYMMDD-hhmmss\u0026gt; -n \u0026lt;namespace\u0026gt; soa-deploy-artifacts-job For Oracle Service Bus artifacts:\n$ kubectl logs job.batch/\u0026lt;domainUID\u0026gt;-deploy-artifacts-job-\u0026lt;YYYYMMDD-hhmmss\u0026gt; -n \u0026lt;namespace\u0026gt; osb-deploy-artifacts-job "
+},
+{
+ "uri": "/fmw-kubernetes/24.2.2/soa-domains/installguide/create-soa-domains/",
+ "title": "Create Oracle SOA Suite domains",
+ "tags": [],
+ "description": "Create an Oracle SOA Suite domain home on an existing PV or PVC, and create the domain resource YAML file for deploying the generated Oracle SOA Suite domain.",
+ "content": "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.\nPrerequisites Before you begin, complete the following steps:\n Review the Domain resource documentation. Review the requirements and limitations. Ensure that you have executed all the preliminary steps in Prepare your environment. Ensure that the database and the WebLogic Kubernetes Operator are running. Prepare to use the create domain script The sample scripts for Oracle SOA Suite domain deployment are available at ${WORKDIR}/create-soa-domain.\nYou 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.\nConfiguration parameters The following parameters can be provided in the inputs file.\n Note: In versions 24.2.2 and above, the default ports used to create the domain are updated.\n Parameter Definition Default sslEnabled Boolean value that indicates whether SSL must be enabled for each WebLogic Server instance. To enable end-to-end SSL access during load balancer setup, set sslEnabled to true and also, set appropriate value for the javaOptions property as detailed in this table. false adminPort Port number for the Administration Server inside the Kubernetes cluster. 7011 adminServerSSLPort SSL port number of the Administration Server inside the Kubernetes cluster. 7012 adminNodePort Port number of the Administration Server outside the Kubernetes cluster. 30701 adminServerName Name of the Administration Server. AdminServer configuredManagedServerCount Number of Managed Server instances to generate for the domain. 5 soaClusterName Name of the SOA WebLogic Server cluster instance to generate for the domain. By default, the cluster name is soa_cluster. This configuration parameter is applicable only for soa and soaosb domain types. soa_cluster osbClusterName Name of the Oracle Service Bus WebLogic Server cluster instance to generate for the domain. By default, the cluster name is osb_cluster. This configuration parameter is applicable only for osb and soaosb domain types. osb_cluster createDomainFilesDir Directory on the host machine to locate all the files to create a WebLogic Server domain, including the script that is specified in the createDomainScriptName parameter. 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 Server 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 by the createDomainScriptName parameter) 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 Server 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 by the createDomainScriptsMountPath parameter. If you need to provide your own scripts to create the domain home, instead of using the built-in 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/\u0026lt;domainUID\u0026gt;. /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 Server 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 with Enterprise Scheduler (ESS)), osb (deploys an Oracle Service Bus domain), and soaosb (deploys a domain with SOA, Oracle Service Bus, and Enterprise Scheduler (ESS)). soa exposeAdminNodePort Boolean value indicating if the Administration Server is exposed outside of the Kubernetes cluster. false exposeAdminT3Channel Boolean value indicating if the T3 administrative channel is exposed outside the Kubernetes cluster. false httpAccessLogInLogHome Boolean value indicating if server HTTP access log files should be written to the same directory as logHome. If false, server HTTP access log files will be written to the directory specified in the WebLogic Server 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:release-version imagePullPolicy Oracle SOA Suite Docker image pull policy. Valid values are IfNotPresent, Always, 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 value indicating whether to include the server .out to the pod\u0026rsquo;s stdout. true initialManagedServerReplicas Number of Managed Servers to initially start for the domain. 1 javaOptions Java options for initiating the Administration Server and Managed Servers. A Java option can have references to one or more of the following predefined variables to obtain WebLogic Server domain information: $(DOMAIN_NAME), $(DOMAIN_HOME), $(ADMIN_NAME), $(ADMIN_PORT), and $(SERVER_NAME). If sslEnabled is set to true, add -Dweblogic.ssl.Enabled=true -Dweblogic.security.SSL.ignoreHostnameVerification=true to allow the Managed Servers to connect to the Administration Server while booting up. In this environment, the demo certificate generated by the WebLogic Server contains a host name that is different from the runtime container\u0026rsquo;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/\u0026lt;domainUID\u0026gt;. /u01/oracle/user_projects/domains/logs/soainfra soaManagedServerNameBase Base string used to generate Managed Server names in the SOA cluster. The default value is soa_server. This configuration parameter is applicable only for soa and soaosb domain types. soa_server osbManagedServerNameBase Base string used to generate Managed Server names in the Oracle Service Bus cluster. The default value is osb_server. This configuration parameter is applicable only for osb and soaosb domain types. osb_server soaManagedServerPort Port number for each Managed Server in the SOA cluster. This configuration parameter is applicable only for soa and soaosb domain types. 8011 osbManagedServerPort Port number for each Managed Server in the Oracle Service Bus cluster. This configuration parameter is applicable only for osb and soaosb domain types. 9011 soaManagedServerSSLPort SSL port number for each Managed Server in the SOA cluster. This configuration parameter is applicable only for soa and soaosb domain types. 8012 osbManagedServerSSLPort SSL port number for each Managed Server in the Oracle Service Bus cluster. This configuration parameter is applicable only for osb and soaosb domain types. 9012 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 \u0026lt;domainUID\u0026gt;-weblogic-sample-pvc. soainfra-domain-pvc productionModeEnabled Boolean value indicating if production mode is enabled for the domain. true secureEnabled Boolean value indicating if secure mode is enabled for the domain. This value has significance only with Oracle SOA Suite 14.1.2.0.0. false serverStartPolicy Determines which WebLogic Server instances will be started. Valid values are Never, IfNeeded, or AdminOnly. IfNeeded 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\u0026rsquo;s user name and password. If not specified, then the value is derived from the domainUID as \u0026lt;domainUID\u0026gt;-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. 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 \u0026lsquo;JMS servers\u0026rsquo; and \u0026lsquo;Transaction log store\u0026rsquo; in the domain. Valid 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-domain-inputs.yaml file. Those properties include the adminServerName, soaClusterName, and soaManagedServerNameBase etc. 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 (\u0026quot;_\u0026quot;) is converted to a hyphen (\u0026quot;-\u0026quot;).\nThe sample demonstrates how to create an Oracle SOA Suite domain home and associated Kubernetes resources for the domain. 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.\nRun the create domain script Run the create domain script, specifying your inputs file and an output directory to store the generated artifacts:\n$ ./create-domain.sh \\ -i create-domain-inputs.yaml \\ -o \u0026lt;path to output-directory\u0026gt; The script will perform the following steps:\n Create a directory for the generated Kubernetes YAML files for this domain if it does not already exist. The path name is \u0026lt;path to output-directory\u0026gt;/weblogic-domains/\u0026lt;domainUID\u0026gt;. 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 \u0026ldquo;output\u0026rdquo; directory that was created above. Create a convenient utility script, delete-domain-job.yaml, to clean up the domain home created by the create script. Start the domain The domain.yaml created by create-domain.sh script above has details about the Oracle SOA Suite Domain and Cluster Kubernetes resources. You can create Oracle SOA Suite Domain using the kubectl create -f or kubectl apply -f command:\n``` $ kubectl apply -f \u0026lt;path to output-directory\u0026gt;/weblogic-domains/\u0026lt;domainUID\u0026gt;/domain.yaml ``` The default domain created by the script has the following characteristics:\n An Administration Server named AdminServer listening on port 7011. A configured cluster named soa_cluster of size 5. Managed Server, named soa_server1 listening on port 8011. Log files that are located in /shared/logs/\u0026lt;domainUID\u0026gt;. SOA Infra, SOA Composer, and WorklistApp applications deployed. Refer to the troubleshooting page to troubleshoot issues during the domain creation.\n Verify the results The create domain script verifies that the domain was created, and reports failure if there is an 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.\nGenerated YAML files with the default inputs Click here to see sample content of the generated `domain.yaml` for `soaosb` domainType that creates SOA and Oracle Service Bus clusters. $ cat output/weblogic-domains/soainfra/domain.yaml # Copyright (c) 2020, 2023, Oracle and/or its affiliates. # Licensed under the Universal Permissive License v 1.0 as shown at https://oss.oracle.com/licenses/upl. # # This is an example of how to define a Domain resource. # apiVersion: \u0026quot;weblogic.oracle/v9\u0026quot; kind: Domain metadata: name: soainfra namespace: soans labels: weblogic.domainUID: soainfra spec: # The WebLogic Domain Home domainHome: /u01/oracle/user_projects/domains/soainfra # The domain home source type # Set to PersistentVolume for domain-in-pv, Image for domain-in-image, or FromModel for model-in-image domainHomeSourceType: PersistentVolume # The WebLogic Server image that the Operator uses to start the domain image: \u0026quot;soasuite:12.2.1.4\u0026quot; # imagePullPolicy defaults to \u0026quot;Always\u0026quot; if image version is :latest imagePullPolicy: IfNotPresent # Identify which secret contains the credentials for pulling an image #imagePullSecrets: #- name: # Identify which secret contains the WebLogic Admin credentials (note that there is an example of # how to create that secret at the end of this topic) webLogicCredentialsSecret: name: soainfra-domain-credentials # Whether to include the server out file into the pod's stdout, default is true includeServerOutInPodLog: true # Whether to enable log home logHomeEnabled: true # Whether to write HTTP access log file to log home httpAccessLogInLogHome: true # The in-pod location for domain log, server logs, server out, introspector out, and Node Manager log files logHome: /u01/oracle/user_projects/domains/logs/soainfra # An (optional) in-pod location for data storage of default and custom file stores. # If not specified or the value is either not set or empty (e.g. dataHome: \u0026quot;\u0026quot;) then the # data storage directories are determined from the WebLogic domain home configuration. dataHome: \u0026quot;\u0026quot; # serverStartPolicy legal values are \u0026quot;Never\u0026quot;, \u0026quot;IfNeeded\u0026quot;, or \u0026quot;AdminOnly\u0026quot; # This determines which WebLogic Servers the Operator will start up when it discovers this Domain # - \u0026quot;Never\u0026quot; will not start any server in the domain # - \u0026quot;AdminOnly\u0026quot; will start up only the administration server (no managed servers will be started) # - \u0026quot;IfNeeded\u0026quot; will start all non-clustered servers, including the administration server and clustered servers up to the replica count serverStartPolicy: IfNeeded serverPod: # an (optional) list of environment variable to be set on the servers env: - name: JAVA_OPTIONS value: \u0026quot;-Dweblogic.StdoutDebugEnabled=false\u0026quot; - name: USER_MEM_ARGS value: \u0026quot;-Djava.security.egd=file:/dev/./urandom -Xms256m -Xmx1024m \u0026quot; volumes: - name: weblogic-domain-storage-volume persistentVolumeClaim: claimName: soainfra-domain-pvc volumeMounts: - mountPath: /u01/oracle/user_projects name: weblogic-domain-storage-volume # adminServer is used to configure the desired behavior for starting the administration server. adminServer: # adminService: # channels: # The Admin Server's NodePort # - channelName: default # nodePort: 30701 # Uncomment to export the T3Channel as a service # - channelName: T3Channel # References to Cluster resources that describe the lifecycle options for all # the Managed Server members of a WebLogic cluster, including Java # options, environment variables, additional Pod content, and the ability to # explicitly start, stop, or restart cluster members. The Cluster resource # must describe a cluster that already exists in the WebLogic domain # configuration. clusters: - name: soainfra-osb-cluster - name: soainfra-soa-cluster --- # This is an example of how to define a Cluster resource. apiVersion: \u0026quot;weblogic.oracle/v1\u0026quot; kind: Cluster metadata: name: soainfra-osb-cluster # Update this with the namespace your domain will run in: namespace: soans labels: # Update this with the `domainUID` of your domain: weblogic.domainUID: soainfra spec: clusterName: osb_cluster serverService: precreateService: true serverPod: env: # This parameter can be used to pass in new system properties; use the space delimiter to append multiple values. # Do not change this value, only append new values to it. - name: K8S_REFCONF_OVERRIDES value: \u0026quot;-Doracle.sb.tracking.resiliency.MemoryMetricEnabled=false \u0026quot; replicas: 1 # The number of managed servers to start for unlisted clusters # replicas: 1 --- # This is an example of how to define a Cluster resource. apiVersion: \u0026quot;weblogic.oracle/v1\u0026quot; kind: Cluster metadata: name: soainfra-soa-cluster # Update this with the namespace your domain will run in: namespace: soans labels: # Update this with the `domainUID` of your domain: weblogic.domainUID: soainfra spec: clusterName: soa_cluster serverService: precreateService: true serverPod: env: # This parameter can be used to pass in new system properties; use the space delimiter to append multiple values. # Do not change this value, only append new values to it. - name: K8S_REFCONF_OVERRIDES value: \u0026quot;-Doracle.soa.tracking.resiliency.MemoryMetricEnabled=false \u0026quot; replicas: 1 # The number of managed servers to start for unlisted clusters # replicas: 1 Verify the domain To confirm that the domain was created, enter the following command:\n$ kubectl describe domain DOMAINUID -n NAMESPACE Replace DOMAINUID with the domainUID and NAMESPACE with the actual namespace.\n Click here to see a sample domain description. $ kubectl describe domain soainfra -n soans bash-4.2# kubectl describe domain soainfra -n soans Name: soainfra Namespace: soans Labels: weblogic.domainUID=soainfra Annotations: \u0026lt;none\u0026gt; API Version: weblogic.oracle/v9 Kind: Domain Metadata: Creation Timestamp: 2023-02-03T13:12:56Z Generation: 1 Managed Fields: API Version: weblogic.oracle/v9 Fields Type: FieldsV1 fieldsV1: f:metadata: f:labels: .: f:weblogic.domainUID: f:spec: .: f:clusters: f:dataHome: f:domainHome: f:domainHomeSourceType: f:failureRetryIntervalSeconds: f:failureRetryLimitMinutes: f:httpAccessLogInLogHome: f:image: f:imagePullPolicy: f:includeServerOutInPodLog: f:logHome: f:logHomeEnabled: f:logHomeLayout: f:maxClusterConcurrentShutdown: f:maxClusterConcurrentStartup: f:maxClusterUnavailable: f:replicas: f:serverPod: .: f:env: f:volumeMounts: f:volumes: f:serverStartPolicy: f:webLogicCredentialsSecret: .: f:name: Manager: kubectl-create Operation: Update Time: 2023-02-03T13:12:56Z API Version: weblogic.oracle/v9 Fields Type: FieldsV1 fieldsV1: f:status: .: f:clusters: f:conditions: f:observedGeneration: f:servers: f:startTime: Manager: Kubernetes Java Client Operation: Update Subresource: status Time: 2023-02-03T13:21:29Z Resource Version: 39889912 UID: 141ec231-dbcf-4afe-8912-e142278f9a79 Spec: Clusters: Name: soainfra-osb-cluster Name: soainfra-soa-cluster Data Home: Domain Home: /u01/oracle/user_projects/domains/soainfra Domain Home Source Type: PersistentVolume Failure Retry Interval Seconds: 120 Failure Retry Limit Minutes: 1440 Http Access Log In Log Home: true Image: soasuite:12.2.1.4 Image Pull Policy: IfNotPresent Include Server Out In Pod Log: true Log Home: /u01/oracle/user_projects/domains/logs/soainfra Log Home Enabled: true Log Home Layout: ByServers Max Cluster Concurrent Shutdown: 1 Max Cluster Concurrent Startup: 0 Max Cluster Unavailable: 1 Replicas: 1 Server Pod: Env: Name: JAVA_OPTIONS Value: -Dweblogic.StdoutDebugEnabled=false Name: USER_MEM_ARGS Value: -Djava.security.egd=file:/dev/./urandom -Xms256m -Xmx1024m Volume Mounts: Mount Path: /u01/oracle/user_projects Name: weblogic-domain-storage-volume Volumes: Name: weblogic-domain-storage-volume Persistent Volume Claim: Claim Name: soainfra-domain-pvc Server Start Policy: IfNeeded Web Logic Credentials Secret: Name: soainfra-domain-credentials Status: Clusters: Cluster Name: osb_cluster Conditions: Last Transition Time: 2023-02-03T13:21:25.985058Z Status: True Type: Available Last Transition Time: 2023-02-03T13:21:25.985176Z Status: True Type: Completed Label Selector: weblogic.domainUID=soainfra,weblogic.clusterName=osb_cluster Maximum Replicas: 5 Minimum Replicas: 0 Observed Generation: 1 Ready Replicas: 1 Replicas: 1 Replicas Goal: 1 Cluster Name: soa_cluster Conditions: Last Transition Time: 2023-02-03T13:21:25.985247Z Status: True Type: Available Last Transition Time: 2023-02-03T13:21:25.985324Z Status: True Type: Completed Label Selector: weblogic.domainUID=soainfra,weblogic.clusterName=soa_cluster Maximum Replicas: 5 Minimum Replicas: 0 Observed Generation: 1 Ready Replicas: 1 Replicas: 1 Replicas Goal: 1 Conditions: Last Transition Time: 2023-02-03T13:21:25.984952Z Status: True Type: Available Last Transition Time: 2023-02-03T13:21:29.921800Z Status: True Type: Completed Observed Generation: 1 Servers: Health: Activation Time: 2023-02-03T13:17:40.865000Z Overall Health: ok Subsystems: Subsystem Name: ServerRuntime Symptoms: Node Name: devhost Pod Phase: Running Pod Ready: True Server Name: AdminServer State: RUNNING State Goal: RUNNING Cluster Name: osb_cluster Health: Activation Time: 2023-02-03T13:20:24.163000Z Overall Health: ok Subsystems: Subsystem Name: ServerRuntime Symptoms: Node Name: devhost Pod Phase: Running Pod Ready: True Server Name: osb_server1 State: RUNNING State Goal: RUNNING Cluster Name: osb_cluster Server Name: osb_server2 State: SHUTDOWN State Goal: SHUTDOWN Cluster Name: osb_cluster Server Name: osb_server3 State: SHUTDOWN State Goal: SHUTDOWN Cluster Name: osb_cluster Server Name: osb_server4 State: SHUTDOWN State Goal: SHUTDOWN Cluster Name: osb_cluster Server Name: osb_server5 State: SHUTDOWN State Goal: SHUTDOWN Cluster Name: soa_cluster Health: Activation Time: 2023-02-03T13:21:18.284000Z Overall Health: ok Subsystems: Subsystem Name: ServerRuntime Symptoms: Node Name: devhost Pod Phase: Running Pod Ready: True Server Name: soa_server1 State: RUNNING State Goal: RUNNING Cluster Name: soa_cluster Server Name: soa_server2 State: SHUTDOWN State Goal: SHUTDOWN Cluster Name: soa_cluster Server Name: soa_server3 State: SHUTDOWN State Goal: SHUTDOWN Cluster Name: soa_cluster Server Name: soa_server4 State: SHUTDOWN State Goal: SHUTDOWN Cluster Name: soa_cluster Server Name: soa_server5 State: SHUTDOWN State Goal: SHUTDOWN Start Time: 2023-02-03T13:13:28.055432Z Events: \u0026lt;none\u0026gt; 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.\nVerify the pods Enter the following command to see the pods running the servers:\n$ kubectl get pods -n NAMESPACE Here is an example of the output of this command. You can verify that an Administration Server and a Managed Server for each cluster (SOA and Oracle Service Bus) are running for soaosb domain type.\n$ 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-soa-server1 1/1 Running 0 50m Verify the services Enter the following command to see the services for the domain:\n$ 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 Oracle Service Bus clusters) are created for soaosb domain type.\n Click here to see a sample list of services. $ kubectl get services -n soans NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE soainfra-adminserver ClusterIP None \u0026lt;none\u0026gt; 30012/TCP,7011/TCP,7012/TCP 54m soainfra-cluster-osb-cluster ClusterIP 10.100.138.57 \u0026lt;none\u0026gt; 9011/TCP,9012/TCP 51m soainfra-cluster-soa-cluster ClusterIP 10.99.117.240 \u0026lt;none\u0026gt; 8011/TCP,8012/TCP 51m soainfra-osb-server1 ClusterIP None \u0026lt;none\u0026gt; 9011/TCP,9012/TCP 51m soainfra-osb-server2 ClusterIP 10.108.50.145 \u0026lt;none\u0026gt; 9011/TCP,9012/TCP 51m soainfra-osb-server3 ClusterIP 10.108.71.8 \u0026lt;none\u0026gt; 9011/TCP,9012/TCP 51m soainfra-osb-server4 ClusterIP 10.100.1.144 \u0026lt;none\u0026gt; 9011/TCP,9012/TCP 51m soainfra-osb-server5 ClusterIP 10.108.57.147 \u0026lt;none\u0026gt; 9011/TCP,9012/TCP 51m soainfra-soa-server1 ClusterIP None \u0026lt;none\u0026gt; 8011/TCP,8012/TCP 51m soainfra-soa-server2 ClusterIP 10.97.165.179 \u0026lt;none\u0026gt; 8011/TCP,8012/TCP 51m soainfra-soa-server3 ClusterIP 10.98.160.126 \u0026lt;none\u0026gt; 8011/TCP,8012/TCP 51m soainfra-soa-server4 ClusterIP 10.105.164.133 \u0026lt;none\u0026gt; 8011/TCP,8012/TCP 51m soainfra-soa-server5 ClusterIP 10.109.168.179 \u0026lt;none\u0026gt; 8011/TCP,8012/TCP 51m "
+},
+{
+ "uri": "/fmw-kubernetes/24.2.2/soa-domains/adminguide/",
+ "title": "Administration Guide",
+ "tags": [],
+ "description": "Describes how to use some of the common utility tools and configurations to administer Oracle SOA Suite domains.",
+ "content": "Administer Oracle SOA Suite domains in Kubernetes.\n Set up a load balancer Configure different load balancers for Oracle SOA Suite domains.\n Enable additional URL access Extend an existing ingress to enable additional application URL access for Oracle SOA Suite domains.\n Configure SSL certificates Create and configure custom SSL certificates for Oracle SOA Suite domains.\n Monitor a domain and publish logs Monitor an Oracle SOA Suite domain and publish the WebLogic Server logs to Elasticsearch.\n Expose the T3/T3S protocol Create a T3/T3S channel and the corresponding Kubernetes service to expose the T3/T3S protocol for the Administration Server and Managed Servers in an Oracle SOA Suite domain.\n Deploy composite applications Deploy composite applications for Oracle SOA Suite and Oracle Service Bus domains.\n Persist adapter customizations Persist the customizations done for Oracle SOA Suite adapters.\n Perform WLST operations Perform WLST administration operations using a helper pod running in the same Kubernetes cluster as the Oracle SOA Suite domain.\n "
+},
+{
+ "uri": "/fmw-kubernetes/24.2.2/soa-domains/adminguide/configure-load-balancer/apache/",
+ "title": "Apache web tier",
+ "tags": [],
+ "description": "Configure the Apache web tier load balancer for Oracle SOA Suite domains.",
+ "content": "This section provides information about how to install and configure the Apache web tier to load balance Oracle SOA Suite domain clusters. You can configure Apache web tier for non-SSL and SSL termination access of the application URL.\nFollow these steps to set up the Apache web tier as a load balancer for an Oracle SOA Suite domain in a Kubernetes cluster:\n Build the Apache web tier image Create the Apache plugin configuration file Prepare the certificate and private key Install the Apache web tier Helm chart Verify domain application URL access Uninstall Apache web tier Build the Apache web tier image Refer to the sample, to build the Apache web tier Docker image.\nCreate the Apache plugin configuration file The configuration file named custom_mod_wl_apache.conf should have all the URL routing rules for the Oracle SOA Suite applications deployed in the domain that needs to be accessible externally. Update this file with values based on your environment. The file content is similar to below.\n Click here to see the sample content of the configuration file custom_mod_wl_apache.conf for soa domain # Copyright (c) 2020 Oracle and/or its affiliates. # # Licensed under the Universal Permissive License v 1.0 as shown at https://oss.oracle.com/licenses/upl. # \u0026lt;IfModule mod_weblogic.c\u0026gt; WebLogicHost \u0026lt;WEBLOGIC_HOST\u0026gt; WebLogicPort 7011 \u0026lt;/IfModule\u0026gt; # Directive for weblogic admin Console deployed on WebLogic Admin Server \u0026lt;Location /console\u0026gt; SetHandler weblogic-handler WebLogicHost soainfra-adminserver WebLogicPort 7011 \u0026lt;/Location\u0026gt; \u0026lt;Location /em\u0026gt; SetHandler weblogic-handler WebLogicHost soainfra-adminserver WebLogicPort 7011 \u0026lt;/Location\u0026gt; \u0026lt;Location /servicebus\u0026gt; SetHandler weblogic-handler WebLogicHost soainfra-adminserver WebLogicPort 7011 \u0026lt;/Location\u0026gt; \u0026lt;Location /lwpfconsole\u0026gt; SetHandler weblogic-handler WebLogicHost soainfra-adminserver WebLogicPort 7011 \u0026lt;/Location\u0026gt; \u0026lt;Location /xbusrouting\u0026gt; SetHandler weblogic-handler WebLogicHost soainfra-adminserver WebLogicPort 7011 \u0026lt;/Location\u0026gt; \u0026lt;Location /xbustransform\u0026gt; SetHandler weblogic-handler WebLogicHost soainfra-adminserver WebLogicPort 7011 \u0026lt;/Location\u0026gt; \u0026lt;Location /weblogic/ready\u0026gt; SetHandler weblogic-handler WebLogicHost soainfra-adminserver WebLogicPort 7011 \u0026lt;/Location\u0026gt; # Directive for all applications deployed on weblogic cluster with a prepath defined by LOCATION variable. # For example, if the LOCATION is set to \u0026#39;/weblogic\u0026#39;, all applications deployed on the cluster can be accessed via # http://myhost:myport/weblogic/application_end_url # where \u0026#39;myhost\u0026#39; is the IP of the machine that runs the Apache web tier, and # \u0026#39;myport\u0026#39; is the port that the Apache web tier is publicly exposed to. # Note that LOCATION cannot be set to \u0026#39;/\u0026#39; unless this is the only Location module configured. \u0026lt;Location /soa-infra\u0026gt; WLSRequest On WebLogicCluster soainfra-cluster-soa-cluster:8011 PathTrim /weblogic1 \u0026lt;/Location\u0026gt; \u0026lt;Location /soa/composer\u0026gt; WLSRequest On WebLogicCluster soainfra-cluster-soa-cluster:8011 PathTrim /weblogic1 \u0026lt;/Location\u0026gt; \u0026lt;Location /integration/worklistapp\u0026gt; WLSRequest On WebLogicCluster soainfra-cluster-soa-cluster:8011 PathTrim /weblogic1 \u0026lt;/Location\u0026gt; \u0026lt;Location /ess\u0026gt; WLSRequest On WebLogicCluster soainfra-cluster-soa-cluster:8011 PathTrim /weblogic1 \u0026lt;/Location\u0026gt; \u0026lt;Location /EssHealthCheck\u0026gt; WLSRequest On WebLogicCluster soainfra-cluster-soa-cluster:8011 PathTrim /weblogic1 \u0026lt;/Location\u0026gt; # Directive for all application deployed on weblogic cluster with a prepath defined by LOCATION2 variable # For example, if the LOCATION2 is set to \u0026#39;/weblogic2\u0026#39;, all applications deployed on the cluster can be accessed via # http://myhost:myport/weblogic2/application_end_url # where \u0026#39;myhost\u0026#39; is the IP of the machine that runs the Apache web tier, and # \u0026#39;myport\u0026#39; is the port that the Apache webt ier is publicly exposed to. #\u0026lt;Location /weblogic2\u0026gt; #WLSRequest On #WebLogicCluster domain2-cluster-cluster-1:8021 #PathTrim /weblogic2 #\u0026lt;/Location\u0026gt; Create a PV and PVC (pv-claim-name) that can be used to store the custom_mod_wl_apache.conf. Refer to the Sample for creating a PV or PVC.\n Prepare the certificate and private key (For the SSL termination configuration only) Run the following commands to generate your own certificate and private key using openssl.\n$ cd ${WORKDIR} $ cd charts/apache-samples/custom-sample $ export VIRTUAL_HOST_NAME=WEBLOGIC_HOST $ export SSL_CERT_FILE=WEBLOGIC_HOST.crt $ export SSL_CERT_KEY_FILE=WEBLOGIC_HOST.key $ sh certgen.sh NOTE: Replace WEBLOGIC_HOST with the host name on which Apache web tier is to be installed.\n Click here to see the output of the certifcate generation $ls certgen.sh custom_mod_wl_apache.conf custom_mod_wl_apache.conf_orig input.yaml README.md $ sh certgen.sh Generating certs for WEBLOGIC_HOST Generating a 2048 bit RSA private key ........................+++ .......................................................................+++ unable to write \u0026#39;random state\u0026#39; writing new private key to \u0026#39;apache-sample.key\u0026#39; ----- $ ls certgen.sh custom_mod_wl_apache.conf_orig WEBLOGIC_HOST.info config.txt input.yaml WEBLOGIC_HOST.key custom_mod_wl_apache.conf WEBLOGIC_HOST.crt README.md Prepare input values for the Apache web tier Helm chart.\nRun the following commands to prepare the input value file for the Apache web tier Helm chart.\n$ base64 -i ${SSL_CERT_FILE} | tr -d \u0026#39;\\n\u0026#39; $ base64 -i ${SSL_CERT_KEY_FILE} | tr -d \u0026#39;\\n\u0026#39; $ touch input.yaml Update the input parameters file, charts/apache-samples/custom-sample/input.yaml.\n Click here to see the snapshot of the sample input.yaml file $ cat apache-samples/custom-sample/input.yaml # Use this to provide your own Apache web tier configuration as needed; simply define this # Persistence Volume which contains your own custom_mod_wl_apache.conf file. persistentVolumeClaimName: \u0026lt;pv-claim-name\u0026gt; # The VirtualHostName of the Apache HTTP server. It is used to enable custom SSL configuration. virtualHostName: \u0026lt;WEBLOGIC_HOST\u0026gt; # The customer-supplied certificate to use for Apache web tier SSL configuration. # The value must be a string containing a base64 encoded certificate. Run following command to get it. # base64 -i ${SSL_CERT_FILE} | tr -d \u0026#39;\\n\u0026#39; customCert: \u0026lt;cert_data\u0026gt; # The customer-supplied private key to use for Apache web tier SSL configuration. # The value must be a string containing a base64 encoded key. Run following command to get it. # base64 -i ${SSL_KEY_FILE} | tr -d \u0026#39;\\n\u0026#39; customKey: \u0026lt;key_data\u0026gt; Install the Apache web tier Helm chart Install the Apache web tier Helm chart to the domain namespace (for example soans) with the specified input parameters:\n$ cd ${WORKDIR}/charts $ helm install apache-webtier --values apache-samples/custom-sample/input.yaml --namespace soans apache-webtier --set image=oracle/apache:12.2.1.3 Check the status of the Apache web tier:\n$ kubectl get all -n soans | grep apache Sample output of the status of the Apache web tier:\npod/apache-webtier-apache-webtier-65f69dc6bc-zg5pj 1/1 Running 0 22h service/apache-webtier-apache-webtier NodePort 10.108.29.98 \u0026lt;none\u0026gt; 80:30305/TCP,4433:30443/TCP 22h deployment.apps/apache-webtier-apache-webtier 1/1 1 1 22h replicaset.apps/apache-webtier-apache-webtier-65f69dc6bc 1 1 1 22h Verify domain application URL access After the Apache web tier load balancer is running, verify that the domain applications are accessible through the load balancer port 30305/30443. The application URLs for domain of type soa are:\n Note: Port 30305 is the LOADBALANCER-Non-SSLPORT and port 30443 is LOADBALANCER-SSLPORT.\n NONSSL configuration http://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-Non-SSLPORT}/weblogic/ready http://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-Non-SSLPORT}/console http://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-Non-SSLPORT}/em http://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-Non-SSLPORT}/soa-infra http://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-Non-SSLPORT}/soa/composer http://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-Non-SSLPORT}/integration/worklistapp SSL configuration https://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-SSLPORT}/weblogic/ready https://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-SSLPORT}/console https://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-SSLPORT}/em https://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-SSLPORT}/soa-infra https://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-SSLPORT}/soa/composer https://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-SSLPORT}/integration/worklistapp Uninstall Apache web tier $ helm delete apache-webtier -n soans "
+},
+{
+ "uri": "/fmw-kubernetes/24.2.2/soa-domains/adminguide/configuring-custom-ssl-certificates/",
+ "title": "Configure SSL certificates",
+ "tags": [],
+ "description": "Create and configure custom SSL certificates for Oracle SOA Suite domains.",
+ "content": "Secure Socket Layer (SSL) provides a secured communication for data sent over unsecured networks. In an SSL termination scenario, you can configure SSL between the client browser and the load balancer in your Oracle SOA Suite instance to ensure that applications are accessed securely. In an SSL end-to-end scenario, an Oracle SOA Suite domain is configured to use a self-signed SSL certificate that was generated during domain creation. Clients will typically receive a message indicating that the signing CA for the certificate is unknown and not trusted.\nThis section provides details on how to create and configure custom (CA-issued) SSL certificates for Oracle SOA Suite domains in both SSL end-to-end and SSL termination scenarios.\n Create custom SSL certificates in an SSL end-to-end scenario Create custom SSL certificates in an SSL termination at a load balancer Create custom SSL certificates in an SSL end-to-end scenario These steps describe how to replace the identity and trust keystore of an Oracle SOA Suite domain with a custom identity and custom trust keystore and register with digital certificates procured from any third party authority.\nIn this documentation, the registered domain is mydomain.com and the CA signed certificates are taken from mydomain.\nCreate a custom identity and custom trust keystore and generate a certificate signing request (CSR) To create a custom identity and custom trust keystore and generate a CSR:\n Log in to the Enterprise Manager (EM) Console and access the Keystores page by opening WebLogic Domain \u0026gt; Security \u0026gt; Keystore.\n Under the system stripe, click Create Keystore to create a new keystore.\n Provide the following details for custom identity:\nKeystore Name: custIdentity Protection: Select the Password option. Keystore Password: Enter the password. Confirm Password: Confirm the password.\n Click Create Keystore to create another new keystore.\n Provide the following details for custom trust:\n Keystore Name: custTrust Protection: Select the Password option. Keystore Password: Enter the password. Confirm Password: Confirm the password. Click Manage on the custIdentity keystore name and provide the password that you specified previously.\n Click Generate Keypair to create a new key pair, and provide the following details for custIdentity with alias as custIdentity and password:\n Alias Name: custIdentity Common Name: Common name, for example, soak8s.mydomain.com (Registered domain name) Organizational Unit: Name of the organizational unit Organization: Organization name Enter City, State, and Country names Key Type: RSA Key Size: 2048 Password: Enter the password Click OK to generate the keypair.\n Select the newly created keypair and click Generate CSR.\n Export the created CSR, share it with Certificate Authority, such as digicert CA, and get root, intermediate, and signed certificates. The certificate is generated for the domain name you used in the Common Name field.\n It is not mandatory to create identity and trust keystore under the system stripe that comes with default provisioning. You can create a new custom stripe and create identity and trust keystores under it.\nShare the CSR with CA to get CA-signed certificates Select the new keypair under the custIdentity and click Generate CSR.\n Export the created CSR and share it with the Certificate Authority and get root, intermediate, and signed certificates. The certificate is generated for the domain name you used in the Common Name field.\n Download the certificates shared in the zip file from the CA. The zip file contains one of the following:\n the three certificates individually - root, intermediate, and signed certificates root and intermediate certificates in one chain and signed certificate separately Double-click the certificate chain for root and intermediate certificates. You can see the full chain when you click on the certification path.\n Extract the root and intermediate certificates individually by going to the certification path, select the certificate to be extracted (root or intermediate) and click View Certificate.\n On the View Certificates pop-up, select the Details tab and click Copy to File.\n In the Certificate Export wizard, click Next, then select Base 64 encoded X.509 (CER), and then click Next. Export the certificate.\n Name the exported certificate as root and intermediate certificates respectively.\n Import CA certificates Certificate Authority (CA) certificates must be imported in the following order: first the signed server certificate, then the intermediate certificate, and then the root certificate.\nTo import CA certificates:\n Use WLST commands to import the certificate chain in the identity keystore (custIdentity):\na. Combine the three certificates into a single text file called chain.pem in the following order: signed server certificate, followed by intermediate certificate, followed by root certificate:\n-----BEGIN CERTIFICATE----- \u0026lt;signed server certificate\u0026gt; -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- \u0026lt;intermediate certificate\u0026gt; -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- \u0026lt;root certificate\u0026gt; -----END CERTIFICATE----- b. Place the chain.pem in /tmp from where you will be executing the kubectl commands (for example, on the master node).\nc. Enter the following command to change the file ownership to 1000:1000 user/group:\n$ sudo chown 1000:1000 /tmp/chain.pem d. Copy /tmp/chain.pem into the Administration Server pod (for example, soainfra-adminserver):\n$ kubectl cp /tmp/chain.pem soans/soainfra-adminserver:/tmp/chain.pem e. Exec into the Administration Server pod to perform all operations:\n$ kubectl exec -it soainfra-adminserver -n soans -- bash f. Start WLST and access the Oracle Platform Security Services (OPSS) key store service:\n$ cd /u01/oracle/oracle_common/common/bin/ $ ./wlst.sh : : wls:/offline\u0026gt; connect(\u0026quot;weblogic\u0026quot;,\u0026quot;Welcome1\u0026quot;,\u0026quot;t3://soainfra-adminserver:7011\u0026quot;) : : wls:/soainfra/serverConfig/\u0026gt; svc = getOpssService(name='KeyStoreService') g. Use the WLST importKeyStoreCertificate command to import chain.pem:\nsvc.importKeyStoreCertificate(appStripe='stripe', name='keystore', password='password', alias='alias', keypassword='keypassword', type='entrytype',filepath='absolute_file_path') For example:\nwls:/soainfra/serverConfig/\u0026gt; svc.importKeyStoreCertificate(appStripe='system', name='custIdentity', password=welcome1, alias='custIdentity', keypassword='welcome1', type='CertificateChain', filepath='/tmp/chain.pem') e. Exit WLST:\nexit() Use Oracle Enterprise Manager to import the certificate chain into the trust keystore (custTrust):\na. Log in to the Enterprise Manager Console and access the Keystores page by opening WebLogic domain \u0026gt; Security \u0026gt; Keystore.\nb. Select the trust keystore (custTrust) and click Manage.\nc. Click Import Certificate and import the certificates in this order:\n the signed server certificate as a trusted certificate (alias mySignedCert)\n the intermediate certificate from CA as a trusted certificate (alias myInterCA)\n the root certificate from CA as a trusted certificate (alias myRootCA)\n Synchronize the local keystore with the security store Synchronize keystores to synchronize information between the domain home and the Oracle Platform Security Services (OPSS) store in the database.\nTo synchronize keystores:\n Exec into the Administration server pod (for example, soainfra-adminserver): $ kubectl exec -it soainfra-adminserver -n soans -- bash Start WLST and access the Oracle Platform Security Services (OPSS) keystore service: $ cd /u01/oracle/oracle_common/common/bin/ $ ./wlst.sh : : wls:/offline\u0026gt; connect(\u0026quot;weblogic\u0026quot;,\u0026quot;Welcome1\u0026quot;,\u0026quot;t3://soainfra-adminserver:7011\u0026quot;) : : wls:/soainfra/serverConfig/\u0026gt; svc = getOpssService(name='KeyStoreService') Enter the following commands to synchronize the custom identity and custom trust keystores: Note: This step is necessary only if you are using the system stripe. You do not need to synchronize the keystores if you are using a custom stripe.\n wls:/soainfra/serverConfig/\u0026gt; svc.listKeyStoreAliases(appStripe=\u0026quot;system\u0026quot;, name=\u0026quot;custIdentity\u0026quot;, password=\u0026quot; ****\u0026quot;, type=\u0026quot;*\u0026quot;) wls:/soainfra/serverConfig/\u0026gt; syncKeyStores(appStripe='system',keystoreFormat='KSS') wls:/soainfra/serverConfig/\u0026gt; svc.listKeyStoreAliases (appStripe=\u0026quot;system\u0026quot;, name=\u0026quot;myKSSTrust\u0026quot;, password=\u0026quot;****\u0026quot;, type=\u0026quot;*\u0026quot;) wls:/soainfra/serverConfig/\u0026gt; syncKeyStores(appStripe='system',keystoreFormat='KSS') Update the WebLogic keystores with custom identity and trust To update the WebLogic keystores with custom identity and custom trust:\n In the WebLogic Server Administration Console, open Servers \u0026gt; AdminServer \u0026gt; Configurations \u0026gt; Keystores tab.\n Change the Keystores to Custom Identity and Custom Trust and Save.\n Provide the values for Custom Identity:\n Custom Identity Keystore: kss://system/custidentity Custom Identity KeyStore Type: KSS Custom Identity PassPhrase: enter password given while creating the custIdentity keystore. Confirm Custom Identity PassPhrase: reenter the password. Provide the values for Custom Trust:\n Custom Trust Keystore: kss://system/custTrust Custom Trust KeyStore Type: KSS Custom Trust PassPhrase: enter password given while creating the custTrust keystore. Confirm Custom Trust PassPhrase: reenter the password. Click Save and then Activate changes.\n Open the SSL tab and provide the following details:\n Private Key Alias: custIdentity (this is the alias given while creating the key pair in the custIdentity keystore.) Private Key PassPhrase: enter password given while creating the key pair under the custIdentity keystore. Confirm Private Key PassPhrase: reenter the password. In the Advanced section, change Hostname Verification to None. Click Save and Activate changes.\n Repeat steps 1 to 7 for all Managed Servers.\n Restart the domain.\n Once the servers are up and running, you can check if the SSL URLs show the updated certificates.\n For more details, refer to:\n Administering Oracle SOA Cloud Service Administering Oracle Fusion Middleware Create custom SSL certificates in an SSL termination at a load balancer This section provides references to configure a custom SSL certificate at a load balancer.\nThere are multiple CA vendors in the marketplace today, each offering different levels of service at varying price points. Research and choose a CA vendor that meets your service-level and budget requirements.\nFor a CA vendor to issue you a CA-issued SSL certificate, you must provide the following information:\n Your custom domain name. Public information associated with the domain confirming you as the owner. Email address associated with the custom domain for verification. Create a Certificate Signing Request (CSR) for your load balancer and submit the CSR to the CA vendor. After receiving the CA-issued certificate, refer to Administering Oracle SOA Cloud Service to import the CA-issued SSL certificate to the load balancer. If you are using openssl to create the certificates, you can refer to Manually Generate a Certificate Signing Request (CSR) Using OpenSSL to submit the CSR to the CA vendor.\n"
+},
+{
+ "uri": "/fmw-kubernetes/24.2.2/soa-domains/appendix/docker-k8s-hardening/",
+ "title": "Security hardening",
+ "tags": [],
+ "description": "Review resources for the Docker and Kubernetes cluster hardening.",
+ "content": "Securing a Kubernetes cluster involves hardening on multiple fronts - securing the API servers, etcd, nodes, container images, container run-time, and the cluster network. Apply principles of defense in depth, principle of least privilege, and minimize the attack surface. Use security tools such as Kube-Bench to verify the cluster\u0026rsquo;s security posture. Since Kubernetes is evolving rapidly refer to Kubernetes Security Overview for the latest information on securing a Kubernetes cluster. Also ensure the deployed Docker containers follow the Docker Security guidance.\nThis section provides references on how to securely configure Docker and Kubernetes.\nReferences Docker hardening\n https://docs.docker.com/engine/security/security/ https://blog.aquasec.com/docker-security-best-practices Kubernetes hardening\n https://kubernetes.io/docs/concepts/security/overview/ https://kubernetes.io/docs/concepts/security/pod-security-standards/ https://blogs.oracle.com/developers/5-best-practices-for-kubernetes-security Security best practices for Oracle WebLogic Server Running in Docker and Kubernetes\n https://blogs.oracle.com/weblogicserver/security-best-practices-for-weblogic-server-running-in-docker-and-kubernetes "
+},
+{
+ "uri": "/fmw-kubernetes/24.2.2/soa-domains/patch_and_upgrade/upgrade-k8s-cluster/",
+ "title": "Upgrade a Kubernetes cluster",
+ "tags": [],
+ "description": "Upgrade the underlying Kubernetes cluster version in a running SOA Kubernetes environment.",
+ "content": "These instructions describe how to upgrade a Kubernetes cluster created using kubeadm on which an Oracle SOA Suite domain is deployed. A rolling upgrade approach is used to upgrade nodes (master and worker) of the Kubernetes cluster.\nIt is expected that there will be a down time during the upgrade of the Kubernetes cluster as the nodes need to be drained as part of the upgrade process.\n Prerequisites Review Prerequisites and ensure that your Kubernetes cluster is ready for upgrade. Make sure your environment meets all prerequisites. Make sure the database used for the SOA domain deployment is up and running during the upgrade process. Upgrade the Kubernetes version An upgrade of Kubernetes is supported from one MINOR version to the next MINOR version, or between PATCH versions of the same MINOR. For example, you can upgrade from 1.x to 1.x+1, but not from 1.x to 1.x+2. To upgrade a Kubernetes version, first all the master nodes of the Kubernetes cluster must be upgraded sequentially, followed by the sequential upgrade of each worker node.\n See here for Kubernetes official documentation to upgrade from 1.23 to 1.24 See here for Kubernetes official documentation to upgrade from 1.24 to 1.25 See here for Kubernetes official documentation to upgrade from 1.25 to 1.26 See here for Kubernetes official documentation to upgrade from 1.26 to 1.27 "
+},
+{
+ "uri": "/fmw-kubernetes/24.2.2/soa-domains/patch_and_upgrade/",
+ "title": "Patch and upgrade",
+ "tags": [],
+ "description": "",
+ "content": "Patch an existing Oracle SOA Suite image or upgrade the infrastructure, such as upgrading the underlying Kubernetes cluster to a new release and upgrading the WebLogic Kubernetes Operator release.\n Patch an image Create a patched Oracle SOA Suite image using the WebLogic Image Tool.\n Upgrade an operator release Upgrade the WebLogic Kubernetes Operator release to a newer version.\n Upgrade a Kubernetes cluster Upgrade the underlying Kubernetes cluster version in a running SOA Kubernetes environment.\n "
+},
+{
+ "uri": "/fmw-kubernetes/24.2.2/soa-domains/",
+ "title": "Oracle SOA Suite",
+ "tags": [],
+ "description": "The Oracle WebLogic Kubernetes Operator (the “operator”) supports deployment of Oracle SOA Suite components such as Oracle Service-Oriented Architecture (SOA), Oracle Service Bus, and Oracle Enterprise Scheduler (ESS). Follow the instructions in this guide to set up these Oracle SOA Suite domains on Kubernetes.",
+ "content": "The WebLogic Kubernetes Operator (the “operator”) supports deployment of Oracle SOA Suite components such as Oracle Service-Oriented Architecture (SOA), Oracle Service Bus, and Oracle Enterprise Scheduler (ESS). Currently the operator supports these domain types:\n soa : Deploys a SOA domain with Oracle Enterprise Scheduler (ESS) osb : Deploys an Oracle Service Bus domain soaosb : Deploys a domain with SOA, Oracle Service Bus, and Oracle Enterprise Scheduler (ESS) In this release, Oracle SOA Suite domains are supported using the “domain on a persistent volume” model only, where the domain home is located in a persistent volume (PV).\nThe operator has several key features to assist you with deploying and managing Oracle SOA Suite domains in a Kubernetes environment. You can:\n Create Oracle SOA Suite instances in a Kubernetes persistent volume (PV). This PV can reside in an NFS file system or other Kubernetes volume types. Start servers based on declarative startup parameters and desired states. Expose the Oracle SOA Suite services and composites for external access. Scale Oracle SOA Suite domains by starting and stopping Managed Servers on demand, or by integrating with a REST API. Publish operator and WebLogic Server logs to Elasticsearch and interact with them in Kibana. Monitor the Oracle SOA Suite instance using Prometheus and Grafana. Current production release The current production release for the Oracle SOA Suite domains deployment on Kubernetes is 24.2.2. This release uses the WebLogic Kubernetes Operator version 4.2.2.\nRecent changes and known issues See the Release Notes for recent changes and known issues for Oracle SOA Suite domains deployment on Kubernetes.\nPricing and licensing See here for pricing and licensing details.\nLimitations See here for limitations in this release.\nAbout this documentation This documentation includes sections targeted to different audiences. To help you find what you are looking for more easily, please consult this table of contents:\n Quick Start explains how to quickly get an Oracle SOA Suite domain instance running using default settings. Note that this is only for development and test purposes.\n Install Guide and Administration Guide provide detailed information about all aspects of using the Kubernetes operator including:\n Installing and configuring the operator. Using the operator to create and manage Oracle SOA Suite domains. Configuring Kubernetes load balancers. Configuring custom SSL certificates. Configuring Elasticsearch and Kibana to access the operator and WebLogic Server log files. Deploying composite applications for Oracle SOA Suite and Oracle Service Bus. Patching an Oracle SOA Suite Docker image. Removing domains. And much more! Enterprise Deployment Guide (preview release) provides information on the topology and set up steps for Oracle SOA Suite Enterprise Deployment on Kubernetes.\n Documentation for earlier releases To view documentation for an earlier release, see:\n Version 24.1.2 Version 23.4.2 Version 23.3.2 Version 23.2.2 Version 23.1.2 Version 22.4.2 Version 22.3.2 Version 22.2.2 Version 22.1.2 Version 21.4.2 Version 21.3.2 Version 21.2.2 Version 21.1.2 Version 20.4.2 Version 20.3.3 Additional reading Oracle SOA Suite domains deployment on Kubernetes leverages the WebLogic Kubernetes Operator framework.\n To develop an understanding of the operator, including design, architecture, domain life cycle management, and configuration overrides, review the operator documentation. To learn more about the Oracle SOA Suite architecture and components, see Understanding Oracle SOA Suite. To review the known issues and common questions for Oracle SOA Suite domains deployment on Kubernetes, see the frequently asked questions. "
+},
+{
+ "uri": "/fmw-kubernetes/24.2.2/soa-domains/adminguide/monitoring-soa-domains/",
+ "title": "Monitor a domain and publish logs",
+ "tags": [],
+ "description": "Monitor an Oracle SOA Suite domain and publish the WebLogic Server logs to Elasticsearch.",
+ "content": "After the Oracle SOA Suite domain is set up, you can:\n Monitor the Oracle SOA Suite instance using Prometheus and Grafana Publish WebLogic Server logs into Elasticsearch Publish SOA server diagnostics logs into Elasticsearch Monitor the Oracle SOA Suite instance using Prometheus and Grafana Using the WebLogic Monitoring Exporter you can scrape runtime information from a running Oracle SOA Suite instance and monitor them using Prometheus and Grafana.\nSet up monitoring Follow these steps to set up monitoring for an Oracle SOA Suite instance. For more details on WebLogic Monitoring Exporter, see here.\nPublish WebLogic Server logs into Elasticsearch WebLogic Server logs can be published to Elasticsearch using Fluentd. See Fluentd configuration steps.\nPublish SOA server diagnostics logs into Elasticsearch This section shows you how to publish diagnostics logs to Elasticsearch and view them in Kibana. For publishing operator logs, see this sample.\nPrerequisites If you have not already set up Elasticsearch and Kibana for logs collection, refer to this document and complete the setup.\nPublish to Elasticsearch The diagnostics or other logs can be pushed to Elasticsearch server using logstash pod. The logstash pod should have access to the shared domain home or the log location. In case of the Oracle SOA Suite domain, the persistent volume of the domain home can be used in the logstash pod. To create the logstash pod, follow these steps:\n Get the domain home persistence volume claim details of the domain home of the Oracle SOA Suite domain. The following command lists the persistent volume claim details in the namespace - soans. In the example below, the persistent volume claim is soainfra-domain-pvc:\n$ kubectl get pvc -n soans Sample output:\nNAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE soainfra-domain-pvc Bound soainfra-domain-pv 10Gi RWX soainfra-domain-storage-class xxd Create the logstash configuration file (logstash.conf). Below is a sample logstash configuration to push diagnostic logs of all servers available at DOMAIN_HOME/servers/\u0026lt;server_name\u0026gt;/logs/-diagnostic.log:\ninput { file { path =\u0026gt; \u0026quot;/u01/oracle/user_projects/domains/soainfra/servers/**/logs/*-diagnostic.log\u0026quot; start_position =\u0026gt; beginning } } filter { grok { match =\u0026gt; [ \u0026quot;message\u0026quot;, \u0026quot;\u0026lt;%{DATA:log_timestamp}\u0026gt; \u0026lt;%{WORD:log_level}\u0026gt; \u0026lt;%{WORD:thread}\u0026gt; \u0026lt;%{HOSTNAME:hostname}\u0026gt; \u0026lt;%{HOSTNAME:servername}\u0026gt; \u0026lt;%{DATA:timer}\u0026gt; \u0026lt;\u0026lt;%{DATA:kernel}\u0026gt;\u0026gt; \u0026lt;\u0026gt; \u0026lt;%{DATA:uuid}\u0026gt; \u0026lt;%{NUMBER:timestamp}\u0026gt; \u0026lt;%{DATA:misc}\u0026gt; \u0026lt;%{DATA:log_number}\u0026gt; \u0026lt;%{DATA:log_message}\u0026gt;\u0026quot; ] } } output { elasticsearch { hosts =\u0026gt; [\u0026quot;elasticsearch.default.svc.cluster.local:9200\u0026quot;] } } Copy the logstash.conf into /u01/oracle/user_projects/domains so that it can be used for logstash deployment, using the Administration Server pod (for example soainfra-adminserver pod in namespace soans):\n$ kubectl cp logstash.conf soans/soainfra-adminserver:/u01/oracle/user_projects/domains --namespace soans Create a deployment YAML (logstash.yaml) for the logstash pod using the domain home persistence volume claim. Make sure to point the logstash configuration file to the correct location (for example, copy logstash.conf to /u01/oracle/user_projects/domains/logstash.conf) and also the correct domain home persistence volume claim. Below is a sample logstash deployment YAML:\napiVersion: apps/v1 kind: Deployment metadata: name: logstash-soa namespace: soans spec: selector: matchLabels: app: logstash-soa template: # create pods using pod definition in this template metadata: labels: app: logstash-soa spec: volumes: - name: soainfra-domain-storage-volume persistentVolumeClaim: claimName: soainfra-domain-pvc - name: shared-logs emptyDir: {} containers: - name: logstash image: logstash:6.6.0 command: [\u0026quot;/bin/sh\u0026quot;] args: [\u0026quot;/usr/share/logstash/bin/logstash\u0026quot;, \u0026quot;-f\u0026quot;, \u0026quot;/u01/oracle/user_projects/domains/logstash.conf\u0026quot;] imagePullPolicy: IfNotPresent volumeMounts: - mountPath: /u01/oracle/user_projects name: soainfra-domain-storage-volume - name: shared-logs mountPath: /shared-logs ports: - containerPort: 5044 name: logstash Deploy logstash to start publish logs to Elasticsearch:\n$ kubectl create -f logstash.yaml Now, you can view the diagnostics logs using Kibana with index pattern \u0026ldquo;logstash-*\u0026rdquo;.\n "
+},
+{
+ "uri": "/fmw-kubernetes/24.2.2/soa-domains/create-or-update-image/",
+ "title": "Create or update an image",
+ "tags": [],
+ "description": "Create or update an Oracle SOA Suite Docker image used for deploying Oracle SOA Suite domains. An Oracle SOA Suite Docker image can be created using the WebLogic Image Tool or using the Dockerfile approach.",
+ "content": "If you have access to the My Oracle Support (MOS), and there is a need to build a new image with a patch (bundle or interim), it is recommended to use the WebLogic Image Tool to build an Oracle SOA Suite image for production deployments.\n Create or update an Oracle SOA Suite Docker image using the WebLogic Image Tool Set up the WebLogic Image Tool Create an image Update an image Create an Oracle SOA Suite Docker image using Dockerfile Create or update an Oracle SOA Suite Docker image using the WebLogic Image Tool Using the WebLogic Image Tool, you can create a new Oracle SOA Suite Docker image (can include patches as well) or update an existing image with one or more patches (bundle patch and interim patches).\n Recommendations:\n Use create for creating a new Oracle SOA Suite Docker image either: without any patches or, containing the Oracle SOA Suite binaries, bundle patch and interim patches. This is the recommended approach if you have access to the Oracle SOA Suite patches because it optimizes the size of the image. Use update for patching an existing Oracle SOA Suite Docker image with a single interim patch. Note that the patched image size may increase considerably due to additional image layers introduced by the patch application tool. Set up the WebLogic Image Tool Prerequisites Set up the WebLogic Image Tool Validate setup WebLogic Image Tool build directory WebLogic Image Tool cache Set up additional build scripts Prerequisites Verify that your environment meets the following prerequisites:\n Docker client and daemon on the build machine, with minimum Docker version 18.03.1.ce. Bash version 4.0 or later, to enable the command complete feature. JAVA_HOME environment variable set to the appropriate JDK location. Set up the WebLogic Image Tool To set up the WebLogic Image Tool:\n Create a working directory and change to it. In these steps, this directory is imagetool-setup.\n$ mkdir imagetool-setup $ cd imagetool-setup Download the latest version of the WebLogic Image Tool from the releases page.\n Unzip the release ZIP file to the imagetool-setup directory.\n Execute the following commands to set up the WebLogic Image Tool on a Linux environment:\n$ cd imagetool-setup/imagetool/bin $ source setup.sh Validate setup To validate the setup of the WebLogic Image Tool:\n Enter the following command to retrieve the version of the WebLogic Image Tool:\n$ imagetool --version Enter imagetool then press the Tab key to display the available imagetool commands:\n$ imagetool \u0026lt;TAB\u0026gt; cache create help rebase update WebLogic Image Tool build directory The WebLogic Image Tool creates a temporary Docker context directory, prefixed by wlsimgbuilder_temp, every time the tool runs. Under normal circumstances, this context directory will be deleted. However, if the process is aborted or the tool is unable to remove the directory, it is safe for you to delete it manually. By default, the WebLogic Image Tool creates the Docker context directory under the user\u0026rsquo;s home directory. If you prefer to use a different directory for the temporary context, set the environment variable WLSIMG_BLDDIR:\n$ export WLSIMG_BLDDIR=\u0026#34;/path/to/buid/dir\u0026#34; WebLogic Image Tool cache The WebLogic Image Tool maintains a local file cache store. This store is used to look up where the Java, WebLogic Server installers, and WebLogic Server patches reside in the local file system. By default, the cache store is located in the user\u0026rsquo;s $HOME/cache directory. Under this directory, the lookup information is stored in the .metadata file. All automatically downloaded patches also reside in this directory. You can change the default cache store location by setting the environment variable WLSIMG_CACHEDIR:\n$ export WLSIMG_CACHEDIR=\u0026#34;/path/to/cachedir\u0026#34; Set up additional build scripts Creating an Oracle SOA Suite Docker image using the WebLogic Image Tool requires additional container scripts for Oracle SOA Suite domains.\n Clone the docker-images repository to set up those scripts. In these steps, this directory is DOCKER_REPO:\n$ cd imagetool-setup $ git clone https://github.com/oracle/docker-images.git Copy the additional WebLogic Image Tool build files from the operator source repository to the imagetool-setup location:\n$ mkdir -p imagetool-setup/docker-images/OracleSOASuite/imagetool/12.2.1.4.0 $ cd imagetool-setup/docker-images/OracleSOASuite/imagetool/12.2.1.4.0 $ cp -rf ${WORKDIR}/imagetool-scripts/* . Note: If you want to create the image continue with the following steps, otherwise to update the image see update an image.\n Create an image After setting up the WebLogic Image Tool and required build scripts, follow these steps to use the WebLogic Image Tool to create a new Oracle SOA Suite Docker image.\nDownload the Oracle SOA Suite installation binaries and patches You must download the required Oracle SOA Suite installation binaries and patches as listed below from the Oracle Software Delivery Cloud and save them in a directory of your choice. In these steps, this directory is download location.\nThe installation binaries and patches required for release 24.2.2 are:\n JDK:\n jdk-8u411-linux-x64.tar.gz Fusion Middleware Infrastructure installer:\n fmw_12.2.1.4.0_infrastructure.jar Oracle SOA Suite installers:\n fmw_12.2.1.4.0_soa.jar fmw_12.2.1.4.0_osb.jar fmw_12.2.1.4.0_b2bhealthcare.jar In this release, Oracle B2B is not supported to be configured, but the installer is required for completeness.\n Fusion Middleware Infrastructure patches:\n p28186730_1394215_Generic.zip (OPATCH 13.9.4.2.15 FOR EM 13.4, 13.5 AND FMW/WLS 12.2.1.3.0, 12.2.1.4.0 AND 14.1.1.0.0) p36440005_122140_Generic.zip (WLS PATCH SET UPDATE 12.2.1.4.240325) p36468190_122140_Generic.zip (FMW Thirdparty Bundle Patch 12.2.1.4.240401) p36316422_122140_Generic.zip (OPSS BUNDLE PATCH 12.2.1.4.240220) p36402397_122140_Generic.zip (OWSM BUNDLE PATCH 12.2.1.4.240313) p36348444_122140_Generic.zip (ADF BUNDLE PATCH 12.2.1.4.240228) p36410345_122140_Generic.zip (Coherence 12.2.1.4 Cumulative Patch 21 (12.2.1.4.21)) p33093748_122140_Generic.zip (FMW PLATFORM 12.2.1.4.0 SPU FOR APRCPU2021) p35965629_122140_Linux-x86-64.zip (ADR FOR WEBLOGIC SERVER 12.2.1.4.0 CPU JAN 2024) p32720458_122140_Generic.zip (JDBC One Off) p36187017_122140_Generic.zip (RDA release 24.2-2024416 for FMW 12.2.1.4.0) p36349529_122140_Generic.zip (WebCenter Core Bundle Patch 12.2.1.4.240227 ) p34065178_122140_Generic.zip (OVD One Off) p34542329_122140_Generic.zip (EM One Off) p34765492_122140_Generic.zip (EM One Off) p36426672_122140_Generic.zip (WLS One Off) p34809489_122140_Generic.zip (JDEV One Off) Oracle SOA Suite and Oracle Service Bus patches\n p36484199_122140_Generic.zip (SOA Bundle Patch 12.2.1.4.240404) p35950186_122140_Generic.zip (OSB BUNDLE PATCH 12.2.1.4.231026) p33404495_122140_Generic.zip (SOA One-off) p32827327_122140_Generic.zip (OSB One-off) p32808126_122140_Generic.zip (SOA/ESS One-off) p31713053_122140_Linux-x86-64.zip (One-off patch) Update required build files The following files in the code repository location \u0026lt;imagetool-setup-location\u0026gt;/docker-images/OracleSOASuite/imagetool/12.2.1.4.0 are used for creating the image:\n additionalBuildCmds.txt buildArgs In the buildArgs file, update all occurrences of %DOCKER_REPO% with the docker-images repository location, which is the complete path of \u0026lt;imagetool-setup-location\u0026gt;/docker-images.\nFor example, update:\n%DOCKER_REPO%/OracleSOASuite/imagetool/12.2.1.4.0/\nto:\n\u0026lt;imagetool-setup-location\u0026gt;/docker-images/OracleSOASuite/imagetool/12.2.1.4.0/\n Similarly, update the placeholders %JDK_VERSION% and %BUILDTAG% with appropriate values.\n Update the response file \u0026lt;imagetool-setup-location\u0026gt;/docker-images/OracleFMWInfrastructure/dockerfiles/12.2.1.4/install.file to add the parameter INSTALL_TYPE=\u0026quot;Fusion Middleware Infrastructure\u0026quot; in the [GENERIC] section.\n Create the image Add a JDK package to the WebLogic Image Tool cache:\n$ imagetool cache addInstaller --type jdk --version 8u411 --path \u0026lt;download location\u0026gt;/jdk-8u401-linux-x64.tar.gz Add the downloaded installation binaries to the WebLogic Image Tool cache:\n$ imagetool cache addInstaller --type fmw --version 12.2.1.4.0 --path \u0026lt;download location\u0026gt;/fmw_12.2.1.4.0_infrastructure.jar $ imagetool cache addInstaller --type soa --version 12.2.1.4.0 --path \u0026lt;download location\u0026gt;/fmw_12.2.1.4.0_soa.jar $ imagetool cache addInstaller --type osb --version 12.2.1.4.0 --path \u0026lt;download location\u0026gt;/fmw_12.2.1.4.0_osb.jar $ imagetool cache addInstaller --type b2b --version 12.2.1.4.0 --path \u0026lt;download location\u0026gt;/fmw_12.2.1.4.0_b2bhealthcare.jar Add the downloaded OPatch patch to the WebLogic Image Tool cache:\n$ imagetool cache addEntry --key 28186730_13.9.4.2.15 --value \u0026lt;download location\u0026gt;/p28186730_1394215_Generic.zip Append the --opatchBugNumber flag and the OPatch patch key to the create command in the buildArgs file:\n--opatchBugNumber 28186730_13.9.4.2.15 Add the downloaded product patches to the WebLogic Image Tool cache:\n$ imagetool cache addEntry --key 31713053_12.2.1.4.0 --value \u0026lt;download location\u0026gt;/p31713053_122140_Linux-x86-64.zip $ imagetool cache addEntry --key 32720458_12.2.1.4.0 --value \u0026lt;download location\u0026gt;/p32720458_122140_Generic.zip $ imagetool cache addEntry --key 32808126_12.2.1.4.0 --value \u0026lt;download location\u0026gt;/p32808126_122140_Generic.zip $ imagetool cache addEntry --key 32827327_12.2.1.4.0 --value \u0026lt;download location\u0026gt;/p32827327_122140_Generic.zip $ imagetool cache addEntry --key 33093748_12.2.1.4.0 --value \u0026lt;download location\u0026gt;/p33093748_122140_Generic.zip $ imagetool cache addEntry --key 33404495_12.2.1.4.0 --value \u0026lt;download location\u0026gt;/p33404495_122140_Generic.zip $ imagetool cache addEntry --key 36316422_12.2.1.4.0 --value \u0026lt;download location\u0026gt;/p36316422_122140_Generic.zip $ imagetool cache addEntry --key 34065178_12.2.1.4.0 --value \u0026lt;download location\u0026gt;/p34065178_122140_Generic.zip $ imagetool cache addEntry --key 34542329_12.2.1.4.0 --value \u0026lt;download location\u0026gt;/p34542329_122140_Generic.zip $ imagetool cache addEntry --key 34765492_12.2.1.4.0 --value \u0026lt;download location\u0026gt;/p34765492_122140_Generic.zip $ imagetool cache addEntry --key 34809489_12.2.1.4.0 --value \u0026lt;download location\u0026gt;/p34809489_122140_Generic.zip $ imagetool cache addEntry --key 36426672_12.2.1.4.0 --value \u0026lt;download location\u0026gt;/p36426672_122140_Generic.zip $ imagetool cache addEntry --key 36402397_12.2.1.4.0 --value \u0026lt;download location\u0026gt;/p36402397_122140_Generic.zip $ imagetool cache addEntry --key 36187017_12.2.1.4.0 --value \u0026lt;download location\u0026gt;/p36187017_122140_Generic.zip $ imagetool cache addEntry --key 35950186_12.2.1.4.0 --value \u0026lt;download location\u0026gt;/p35950186_122140_Generic.zip $ imagetool cache addEntry --key 35965629_12.2.1.4.0 --value \u0026lt;download location\u0026gt;/p35965629_122140_Linux-x86-64.zip $ imagetool cache addEntry --key 36034300_12.2.1.4.0 --value \u0026lt;download location\u0026gt;/p36034300_122140_Generic.zip $ imagetool cache addEntry --key 36038320_12.2.1.4.0 --value \u0026lt;download location\u0026gt;/p36038320_122140_Generic.zip $ imagetool cache addEntry --key 36068046_12.2.1.4.0 --value \u0026lt;download location\u0026gt;/p36068046_122140_Generic.zip $ imagetool cache addEntry --key 36074941_12.2.1.4.0 --value \u0026lt;download location\u0026gt;/p36074941_122140_Generic.zip $ imagetool cache addEntry --key 36086980_12.2.1.4.0 --value \u0026lt;download location\u0026gt;/p36086980_122140_Generic.zip $ imagetool cache addEntry --key 36155700_12.2.1.4.0 --value \u0026lt;download location\u0026gt;/p36155700_122140_Generic.zip Append the --patches flag and the product patch keys to the create command in the buildArgs file. The --patches list must be a comma-separated collection of patch --key values used in the imagetool cache addEntry commands above.\nSample --patches list for the product patches added in to the cache:\n--patches 31713053_12.2.1.4.0,32720458_12.2.1.4.0,32808126_12.2.1.4.0,32827327_12.2.1.4.0,33093748_12.2.1.4.0,33404495_12.2.1.4.0,33950717_12.2.1.4.0,34065178_12.2.1.4.0,34542329_12.2.1.4.0,34765492_12.2.1.4.0,34809489_12.2.1.4.0,35474754_12.2.1.4.0,35868571_12.2.1.4.0,35922290_12.2.1.4.0,35950186_12.2.1.4.0,35965629_12.2.1.4.0,36034300_12.2.1.4.0,36038320_12.2.1.4.0,36068046_12.2.1.4.0,36074941_12.2.1.4.0,36086980_12.2.1.4.0,36155700_12.2.1.4.0 Example buildArgs file after appending the OPatch patch and product patches:\ncreate --jdkVersion 8u401 --type soa_osb_b2b --version 12.2.1.4.0 --tag oracle/soasuite:12.2.1.4.0 --pull --fromImage ghcr.io/oracle/oraclelinux:7-slim --chown oracle:root --additionalBuildCommands \u0026lt;imagetool-setup-location\u0026gt;/docker-images/OracleSOASuite/imagetool/12.2.1.4.0/additionalBuildCmds.txt --additionalBuildFiles \u0026lt;imagetool-setup-location\u0026gt;/docker-images/OracleSOASuite/dockerfiles/12.2.1.4/container-scripts --installerResponseFile \u0026lt;imagetool-setup-location\u0026gt;/docker-images/OracleFMWInfrastructure/dockerfiles/12.2.1.4/install.file,\u0026lt;imagetool-setup-location\u0026gt;/docker-images/OracleSOASuite/dockerfiles/12.2.1.4/install/soasuite.response,\u0026lt;imagetool-setup-location\u0026gt;/docker-images/OracleSOASuite/dockerfiles/12.2.1.4/install/osb.response,\u0026lt;imagetool-setup-location\u0026gt;/docker-images/OracleSOASuite/dockerfiles/12.2.1.4/install/b2b.response --patches 31713053_12.2.1.4.0,32720458_12.2.1.4.0,32808126_12.2.1.4.0,32827327_12.2.1.4.0,33093748_12.2.1.4.0,33404495_12.2.1.4.0,33950717_12.2.1.4.0,34065178_12.2.1.4.0,34542329_12.2.1.4.0,34765492_12.2.1.4.0,34809489_12.2.1.4.0,35474754_12.2.1.4.0,35868571_12.2.1.4.0,35922290_12.2.1.4.0,35950186_12.2.1.4.0,35965629_12.2.1.4.0,36034300_12.2.1.4.0,36038320_12.2.1.4.0,36068046_12.2.1.4.0,36074941_12.2.1.4.0,36086980_12.2.1.4.0,36155700_12.2.1.4.0 Note: In the buildArgs file:\n --jdkVersion value must match the --version value used in the imagetool cache addInstaller command for --type jdk. --version value must match the --version value used in the imagetool cache addInstaller command for --type soa. --pull always pulls the latest base Linux image oraclelinux:7-slim from the Docker registry. This flag can be removed if you want to use the Linux image oraclelinux:7-slim, which is already available on the host where the SOA image is created. Refer to this page for the complete list of options available with the WebLogic Image Tool create command.\n Create the Oracle SOA Suite image:\n$ imagetool @\u0026lt;absolute path to buildargs file\u0026gt; Note: Make sure that the absolute path to the buildargs file is prepended with a @ character, as shown in the example above.\n For example:\n$ imagetool @\u0026lt;imagetool-setup-location\u0026gt;/docker-images/OracleSOASuite/imagetool/12.2.1.4.0/buildArgs Click here to see the sample Dockerfile generated with the `imagetool` command. ########## BEGIN DOCKERFILE ########## # Copyright (c) 2019, 2021, Oracle and/or its affiliates. # Licensed under the Universal Permissive License v 1.0 as shown at https://oss.oracle.com/licenses/upl. # FROM ghcr.io/oracle/oraclelinux:7-slim as os_update LABEL com.oracle.weblogic.imagetool.buildid=\u0026quot;b4554a25-22dd-4793-b121-9989bd4be40a\u0026quot; USER root # Use package manager to make sure that unzip, tar, and other required packages are installed # # Copyright (c) 2021, Oracle and/or its affiliates. # # Licensed under the Universal Permissive License v 1.0 as shown at https://oss.oracle.com/licenses/upl. # # Ensure necessary OS packages are installed RUN yum -y --downloaddir=/tmp/imagetool install gzip tar unzip libaio jq findutils diffutils hostname \\ \u0026amp;\u0026amp; yum -y --downloaddir=/tmp/imagetool clean all \\ \u0026amp;\u0026amp; rm -rf /var/cache/yum/* \\ \u0026amp;\u0026amp; rm -rf /tmp/imagetool # Create the Oracle user that will be the owner of the installed software # # Copyright (c) 2021, Oracle and/or its affiliates. # # Licensed under the Universal Permissive License v 1.0 as shown at https://oss.oracle.com/licenses/upl. # # Create user and group RUN if [ -z \u0026quot;$(getent group root)\u0026quot; ]; then hash groupadd \u0026amp;\u0026gt; /dev/null \u0026amp;\u0026amp; groupadd root || exit -1 ; fi \\ \u0026amp;\u0026amp; if [ -z \u0026quot;$(getent passwd oracle)\u0026quot; ]; then hash useradd \u0026amp;\u0026gt; /dev/null \u0026amp;\u0026amp; useradd -g root oracle || exit -1; fi \\ \u0026amp;\u0026amp; mkdir -p /u01 \\ \u0026amp;\u0026amp; chown oracle:root /u01 \\ \u0026amp;\u0026amp; chmod 775 /u01 # If Java is not already in the base image, install it # Copyright (c) 2021, Oracle and/or its affiliates. # Licensed under the Universal Permissive License v 1.0 as shown at https://oss.oracle.com/licenses/upl. # # Installing Java FROM os_update as jdk_build LABEL com.oracle.weblogic.imagetool.buildid=\u0026quot;b4554a25-22dd-4793-b121-9989bd4be40a\u0026quot; ENV JAVA_HOME=/u01/jdk COPY --chown=oracle:root jdk-8u301-linux-x64.tar.gz /tmp/imagetool/ USER oracle RUN tar xzf /tmp/imagetool/jdk-8u301-linux-x64.tar.gz -C /u01 \\ \u0026amp;\u0026amp; $(test -d /u01/jdk* \u0026amp;\u0026amp; mv /u01/jdk* /u01/jdk || mv /u01/graal* /u01/jdk) \\ \u0026amp;\u0026amp; rm -rf /tmp/imagetool \\ \u0026amp;\u0026amp; rm -f /u01/jdk/javafx-src.zip /u01/jdk/src.zip # If an Oracle Home is not already in the base image, install the middleware components # Copyright (c) 2021, Oracle and/or its affiliates. # Licensed under the Universal Permissive License v 1.0 as shown at https://oss.oracle.com/licenses/upl. # # Installing Middleware FROM os_update as wls_build LABEL com.oracle.weblogic.imagetool.buildid=\u0026quot;b4554a25-22dd-4793-b121-9989bd4be40a\u0026quot; ENV JAVA_HOME=/u01/jdk \\ ORACLE_HOME=/u01/oracle \\ OPATCH_NO_FUSER=true RUN mkdir -p /u01/oracle \\ \u0026amp;\u0026amp; mkdir -p /u01/oracle/oraInventory \\ \u0026amp;\u0026amp; chown oracle:root /u01/oracle/oraInventory \\ \u0026amp;\u0026amp; chown oracle:root /u01/oracle COPY --from=jdk_build --chown=oracle:root /u01/jdk /u01/jdk/ COPY --chown=oracle:root fmw_12.2.1.4.0_infrastructure.jar install.file /tmp/imagetool/ COPY --chown=oracle:root fmw_12.2.1.4.0_soa.jar soasuite.response /tmp/imagetool/ COPY --chown=oracle:root fmw_12.2.1.4.0_osb.jar osb.response /tmp/imagetool/ COPY --chown=oracle:root fmw_12.2.1.4.0_b2bhealthcare.jar b2b.response /tmp/imagetool/ COPY --chown=oracle:root oraInst.loc /u01/oracle/ USER oracle RUN echo \u0026quot;INSTALLING MIDDLEWARE\u0026quot; \\ \u0026amp;\u0026amp; echo \u0026quot;INSTALLING fmw\u0026quot; \\ \u0026amp;\u0026amp; \\ /u01/jdk/bin/java -Xmx1024m -jar /tmp/imagetool/fmw_12.2.1.4.0_infrastructure.jar -silent ORACLE_HOME=/u01/oracle \\ -responseFile /tmp/imagetool/install.file -invPtrLoc /u01/oracle/oraInst.loc -ignoreSysPrereqs -force -novalidation \\ \u0026amp;\u0026amp; echo \u0026quot;INSTALLING soa\u0026quot; \\ \u0026amp;\u0026amp; \\ /u01/jdk/bin/java -Xmx1024m -jar /tmp/imagetool/fmw_12.2.1.4.0_soa.jar -silent ORACLE_HOME=/u01/oracle \\ -responseFile /tmp/imagetool/soasuite.response -invPtrLoc /u01/oracle/oraInst.loc -ignoreSysPrereqs -force -novalidation \\ \u0026amp;\u0026amp; echo \u0026quot;INSTALLING osb\u0026quot; \\ \u0026amp;\u0026amp; \\ /u01/jdk/bin/java -Xmx1024m -jar /tmp/imagetool/fmw_12.2.1.4.0_osb.jar -silent ORACLE_HOME=/u01/oracle \\ -responseFile /tmp/imagetool/osb.response -invPtrLoc /u01/oracle/oraInst.loc -ignoreSysPrereqs -force -novalidation \\ \u0026amp;\u0026amp; echo \u0026quot;INSTALLING b2b\u0026quot; \\ \u0026amp;\u0026amp; \\ /u01/jdk/bin/java -Xmx1024m -jar /tmp/imagetool/fmw_12.2.1.4.0_b2bhealthcare.jar -silent ORACLE_HOME=/u01/oracle \\ -responseFile /tmp/imagetool/b2b.response -invPtrLoc /u01/oracle/oraInst.loc -ignoreSysPrereqs -force -novalidation \\ \u0026amp;\u0026amp; test $? -eq 0 \\ \u0026amp;\u0026amp; chmod -R g+r /u01/oracle \\ || (grep -vh \u0026quot;NOTIFICATION\u0026quot; /tmp/OraInstall*/install*.log \u0026amp;\u0026amp; exit 1) # # Copyright (c) 2021, Oracle and/or its affiliates. # # Licensed under the Universal Permissive License v 1.0 as shown at https://oss.oracle.com/licenses/upl. # # Update OPatch and apply WebLogic patches COPY --chown=oracle:root p28186730_1394214_Generic.zip /tmp/imagetool/opatch/ RUN cd /tmp/imagetool/opatch \\ \u0026amp;\u0026amp; /u01/jdk/bin/jar -xf /tmp/imagetool/opatch/p28186730_1394214_Generic.zip \\ \u0026amp;\u0026amp; /u01/jdk/bin/java -jar /tmp/imagetool/opatch/6880880/opatch_generic.jar -silent -ignoreSysPrereqs -force -novalidation oracle_home=/u01/oracle \\ \u0026amp;\u0026amp; rm -rf /tmp/imagetool COPY --chown=oracle:root patches/* /tmp/imagetool/patches/ # Apply all patches provided at the same time RUN /u01/oracle/OPatch/opatch napply -silent -oh /u01/oracle -nonrollbackable -phBaseDir /tmp/imagetool/patches \\ \u0026amp;\u0026amp; test $? -eq 0 \\ \u0026amp;\u0026amp; /u01/oracle/OPatch/opatch util cleanup -silent -oh /u01/oracle FROM os_update as final_build ENV ORACLE_HOME=/u01/oracle \\ JAVA_HOME=/u01/jdk \\ PATH=${PATH}:/u01/jdk/bin:/u01/oracle/oracle_common/common/bin:/u01/oracle/wlserver/common/bin:/u01/oracle LABEL com.oracle.weblogic.imagetool.buildid=\u0026quot;b4554a25-22dd-4793-b121-9989bd4be40a\u0026quot; COPY --from=jdk_build --chown=oracle:root /u01/jdk /u01/jdk/ COPY --from=wls_build --chown=oracle:root /u01/oracle /u01/oracle/ USER oracle WORKDIR /u01/oracle #ENTRYPOINT /bin/bash ENV ORACLE_HOME=/u01/oracle \\ VOLUME_DIR=/u01/oracle/user_projects \\ SCRIPT_FILE=/u01/oracle/container-scripts/* \\ HEALTH_SCRIPT_FILE=/u01/oracle/container-scripts/get_healthcheck_url.sh \\ JAVA_OPTIONS=\u0026quot;-Doracle.jdbc.fanEnabled=false -Dweblogic.StdoutDebugEnabled=false\u0026quot; \\ PATH=$PATH:/u01/oracle/container-scripts:/u01/oracle/oracle_common/modules/thirdparty/org.apache.ant/1.10.5.0.0/apache-ant-1.10.5/bin USER root RUN mkdir -p $VOLUME_DIR \u0026amp;\u0026amp; chown oracle:root /u01 $VOLUME_DIR \u0026amp;\u0026amp; \\ mkdir -p /u01/oracle/container-scripts COPY --chown=oracle:root files/container-scripts/ /u01/oracle/container-scripts/ RUN chmod +xr $SCRIPT_FILE USER oracle RUN if [ -f \u0026quot;${ORACLE_HOME}/soa/soa/thirdparty/edifecs/XEngine_8_4_1_23.tar.gz\u0026quot; ]; then \\ cd $ORACLE_HOME/soa/soa/thirdparty/edifecs \u0026amp;\u0026amp; \\ tar -zxvf XEngine_8_4_1_23.tar.gz; \\ else \\ echo -e \u0026quot;\\nXEngine_8_4_1_23.tar.gz not present in ${ORACLE_HOME}/soa/soa/thirdparty/edifecs directory. Skipping untar.\u0026quot;; \\ fi HEALTHCHECK --start-period=5m --interval=1m CMD curl -k -s --fail `$HEALTH_SCRIPT_FILE` || exit 1 WORKDIR ${ORACLE_HOME} CMD [\u0026quot;/u01/oracle/container-scripts/createDomainAndStart.sh\u0026quot;] ########## END DOCKERFILE ########## Check the created image using the docker images command:\n$ docker images | grep soasuite Update an image After setting up the WebLogic Image Tool and required build scripts, use the WebLogic Image Tool to update an existing Oracle SOA Suite Docker image:\n Enter the following command to add the OPatch patch to the WebLogic Image Tool cache:\n$ imagetool cache addEntry --key 28186730_13.9.4.2.14 --value \u0026lt;download location\u0026gt;/p28186730_1394214_Generic.zip Execute the imagetool cache addEntry command for each patch to add the required patch(es) to the WebLogic Image Tool cache. For example, to add patch p30761841_122140_Generic.zip:\n$ imagetool cache addEntry --key=30761841_12.2.1.4.0 --value \u0026lt;downloaded-patches-location\u0026gt;/p30761841_122140_Generic.zip Provide the following arguments to the WebLogic Image Tool update command:\n –-fromImage - Identify the image that needs to be updated. In the example below, the image to be updated is soasuite:12.2.1.4. –-patches - Multiple patches can be specified as a comma-separated list. --tag - Specify the new tag to be applied for the image being built. Refer here for the complete list of options available with the WebLogic Image Tool update command.\n Note: The WebLogic Image Tool cache should have the latest OPatch zip. The WebLogic Image Tool will update the OPatch if it is not already updated in the image.\n Examples Click here to see the example \u0026#39;update\u0026#39; command: $ imagetool update --fromImage soasuite:12.2.1.4 --chown oracle:root --tag=soasuite:12.2.1.4-30761841 --patches=30761841_12.2.1.4.0 --opatchBugNumber=28186730_13.9.4.2.14 [INFO ] Image Tool build ID: bd21dc73-b775-4186-ae03-8219bf02113e [INFO ] Temporary directory used for docker build context: \u0026lt;work-directory\u0026gt;/wlstmp/wlsimgbuilder_temp1117031733123594064 [INFO ] Using patch 28186730_13.9.4.2.14 from cache: \u0026lt;downloaded-patches-location\u0026gt;/p28186730_1394214_Generic.zip [WARNING] skipping patch conflict check, no support credentials provided [WARNING] No credentials provided, skipping validation of patches [INFO ] Using patch 30761841_12.2.1.4.0 from cache: \u0026lt;downloaded-patches-location\u0026gt;/p30761841_122140_Generic.zip [INFO ] docker cmd = docker build --force-rm=true --no-cache --tag soasuite:12.2.1.4-30761841 --build-arg http_proxy=http://\u0026lt;YOUR-COMPANY-PROXY\u0026gt; --build-arg https_proxy=http://\u0026lt;YOUR-COMPANY-PROXY\u0026gt; --build-arg no_proxy=\u0026lt;IP addresses and Domain address for no_proxy\u0026gt;,/var/run/docker.sock \u0026lt;work-directory\u0026gt;/wlstmp/wlsimgbuilder_temp1117031733123594064 Sending build context to Docker daemon 53.47MB Step 1/7 : FROM soasuite:12.2.1.4 as FINAL_BUILD ---\u0026gt; 445b649a3459 Step 2/7 : USER root ---\u0026gt; Running in 27f45e6958c3 Removing intermediate container 27f45e6958c3 ---\u0026gt; 150ae0161d46 Step 3/7 : ENV OPATCH_NO_FUSER=true ---\u0026gt; Running in daddfbb8fd9e Removing intermediate container daddfbb8fd9e ---\u0026gt; a5fc6b74be39 Step 4/7 : LABEL com.oracle.weblogic.imagetool.buildid=\u0026quot;bd21dc73-b775-4186-ae03-8219bf02113e\u0026quot; ---\u0026gt; Running in cdfec79c3fd4 Removing intermediate container cdfec79c3fd4 ---\u0026gt; 4c773aeb956f Step 5/7 : USER oracle ---\u0026gt; Running in ed3432e43e89 Removing intermediate container ed3432e43e89 ---\u0026gt; 54fe6b07c447 Step 6/7 : COPY --chown=oracle:oracle patches/* /tmp/imagetool/patches/ ---\u0026gt; d6d12f02a9be Step 7/7 : RUN /u01/oracle/OPatch/opatch napply -silent -oh /u01/oracle -phBaseDir /tmp/imagetool/patches \u0026amp;\u0026amp; /u01/oracle/OPatch/opatch util cleanup -silent -oh /u01/oracle \u0026amp;\u0026amp; rm -rf /tmp/imagetool ---\u0026gt; Running in a79addca4d2f Oracle Interim Patch Installer version 13.9.4.2.14 Copyright (c) 2020, Oracle Corporation. All rights reserved. Oracle Home : /u01/oracle Central Inventory : /u01/oracle/oraInventory from : /u01/oracle/oraInst.loc OPatch version : 13.9.4.2.14 OUI version : 13.9.4.0.0 Log file location : /u01/oracle/cfgtoollogs/opatch/opatch2020-06-01_10-56-13AM_1.log OPatch detects the Middleware Home as \u0026quot;/u01/oracle\u0026quot; Verifying environment and performing prerequisite checks... OPatch continues with these patches: 30761841 Do you want to proceed? [y|n] Y (auto-answered by -silent) User Responded with: Y All checks passed. Please shutdown Oracle instances running out of this ORACLE_HOME on the local system. (Oracle Home = '/u01/oracle') Is the local system ready for patching? [y|n] Y (auto-answered by -silent) User Responded with: Y Backing up files... Applying interim patch '30761841' to OH '/u01/oracle' ApplySession: Optional component(s) [ oracle.org.bouncycastle.bcprov.ext.jdk15on, 1.55.0.0.0 ] , [ oracle.org.bouncycastle.bcprov.ext.jdk15on, 1.55.0.0.0 ] , [ oracle.org.bouncycastle.bcprov.ext.jdk15on, 1.5.0.0.0 ] , [ oracle.org.bouncycastle.bcprov.ext.jdk15on, 1.5.0.0.0 ] , [ oracle.org.bouncycastle.bcprov.jdk15on, 1.55.0.0.0 ] , [ oracle.org.bouncycastle.bcprov.jdk15on, 1.55.0.0.0 ] , [ oracle.org.bouncycastle.bcprov.jdk15on, 1.52.0.0.0 ] , [ oracle.org.bouncycastle.bcprov.jdk15on, 1.52.0.0.0 ] , [ oracle.org.bouncycastle.bcprov.ext.jdk15on, 1.48.0.0.0 ] , [ oracle.org.bouncycastle.bcprov.ext.jdk15on, 1.48.0.0.0 ] , [ oracle.org.bouncycastle.bcpkix.jdk15on, 1.49.0.0.0 ] , [ oracle.org.bouncycastle.bcpkix.jdk15on, 1.49.0.0.0 ] , [ oracle.org.bouncycastle.bcprov.jdk15on, 1.51.0.0.0 ] , [ oracle.org.bouncycastle.bcprov.jdk15on, 1.51.0.0.0 ] , [ oracle.org.bouncycastle.bcprov.jdk15on, 1.54.0.0.0 ] , [ oracle.org.bouncycastle.bcprov.jdk15on, 1.54.0.0.0 ] , [ oracle.org.bouncycastle.bcprov.ext.jdk15on, 1.54.0.0.0 ] , [ oracle.org.bouncycastle.bcprov.ext.jdk15on, 1.54.0.0.0 ] , [ oracle.org.bouncycastle.bcpkix.jdk15on, 1.5.0.0.0 ] , [ oracle.org.bouncycastle.bcpkix.jdk15on, 1.5.0.0.0 ] , [ oracle.org.bouncycastle.bcpkix.jdk15on, 1.54.0.0.0 ] , [ oracle.org.bouncycastle.bcpkix.jdk15on, 1.54.0.0.0 ] , [ oracle.org.bouncycastle.bcpkix.jdk15on, 1.55.0.0.0 ] , [ oracle.org.bouncycastle.bcpkix.jdk15on, 1.55.0.0.0 ] , [ oracle.org.bouncycastle.bcprov.jdk15on, 1.49.0.0.0 ] , [ oracle.org.bouncycastle.bcprov.jdk15on, 1.49.0.0.0 ] , [ oracle.org.bouncycastle.bcprov.jdk15on, 1.5.0.0.0 ] , [ oracle.org.bouncycastle.bcprov.jdk15on, 1.5.0.0.0 ] not present in the Oracle Home or a higher version is found. Patching component oracle.org.bouncycastle.bcprov.jdk15on, 1.60.0.0.0... Patching component oracle.org.bouncycastle.bcprov.jdk15on, 1.60.0.0.0... Patching component oracle.org.bouncycastle.bcprov.ext.jdk15on, 1.60.0.0.0... Patching component oracle.org.bouncycastle.bcprov.ext.jdk15on, 1.60.0.0.0... Patching component oracle.org.bouncycastle.bcpkix.jdk15on, 1.60.0.0.0... Patching component oracle.org.bouncycastle.bcpkix.jdk15on, 1.60.0.0.0... Patch 30761841 successfully applied. Log file location: /u01/oracle/cfgtoollogs/opatch/opatch2020-06-01_10-56-13AM_1.log OPatch succeeded. Oracle Interim Patch Installer version 13.9.4.2.14 Copyright (c) 2020, Oracle Corporation. All rights reserved. Oracle Home : /u01/oracle Central Inventory : /u01/oracle/oraInventory from : /u01/oracle/oraInst.loc OPatch version : 13.9.4.2.14 OUI version : 13.9.4.0.0 Log file location : /u01/oracle/cfgtoollogs/opatch/opatch2020-06-01_10-57-19AM_1.log OPatch detects the Middleware Home as \u0026quot;/u01/oracle\u0026quot; Invoking utility \u0026quot;cleanup\u0026quot; OPatch will clean up 'restore.sh,make.txt' files and 'scratch,backup' directories. You will be still able to rollback patches after this cleanup. Do you want to proceed? [y|n] Y (auto-answered by -silent) User Responded with: Y Backup area for restore has been cleaned up. For a complete list of files/directories deleted, Please refer log file. OPatch succeeded. Removing intermediate container a79addca4d2f ---\u0026gt; 2ef2a67a685b Successfully built 2ef2a67a685b Successfully tagged soasuite:12.2.1.4-30761841 [INFO ] Build successful. Build time=112s. Image tag=soasuite:12.2.1.4-30761841 Click here to see the example Dockerfile generated by the WebLogic Image Tool with the \u0026#39;--dryRun\u0026#39; option: $ imagetool update --fromImage soasuite:12.2.1.4 --chown oracle:root --tag=soasuite:12.2.1.4-30761841 --patches=30761841_12.2.1.4.0 --opatchBugNumber=28186730_13.9.4.2.14 --dryRun [INFO ] Image Tool build ID: f9feea35-c52c-4974-b155-eb7f34d95892 [INFO ] Temporary directory used for docker build context: \u0026lt;work-directory\u0026gt;/wlstmp/wlsimgbuilder_temp1799120592903014749 [INFO ] Using patch 28186730_13.9.4.2.14 from cache: \u0026lt;downloaded-patches-location\u0026gt;/p28186730_1394214_Generic.zip [WARNING] skipping patch conflict check, no support credentials provided [WARNING] No credentials provided, skipping validation of patches [INFO ] Using patch 30761841_12.2.1.4.0 from cache: \u0026lt;downloaded-patches-location\u0026gt;/p30761841_122140_Generic.zip [INFO ] docker cmd = docker build --force-rm=true --no-cache --tag soasuite:12.2.1.4-30761841 --build-arg http_proxy=http://www.yourcompany.proxy.com:80 --build-arg https_proxy=http://www.yourcompany.proxy.com:80 --build-arg no_proxy=10.250.109.251,localhost,127.0.0.1,/var/run/docker.sock \u0026lt;work-directory\u0026gt;/wlstmp/wlsimgbuilder_temp1799120592903014749 ########## BEGIN DOCKERFILE ########## # # Copyright (c) 2019, 2020, Oracle and/or its affiliates. # # Licensed under the Universal Permissive License v 1.0 as shown at https://oss.oracle.com/licenses/upl. # # FROM soasuite:12.2.1.4 as FINAL_BUILD USER root ENV OPATCH_NO_FUSER=true LABEL com.oracle.weblogic.imagetool.buildid=\u0026quot;f9feea35-c52c-4974-b155-eb7f34d95892\u0026quot; USER oracle COPY --chown=oracle:oracle patches/* /tmp/imagetool/patches/ RUN /u01/oracle/OPatch/opatch napply -silent -oh /u01/oracle -phBaseDir /tmp/imagetool/patches \\ \u0026amp;\u0026amp; /u01/oracle/OPatch/opatch util cleanup -silent -oh /u01/oracle \\ \u0026amp;\u0026amp; rm -rf /tmp/imagetool ########## END DOCKERFILE ########## Check the built image using the docker images command:\n$ docker images | grep soasuite soasuite 12.2.1.4-30761841 2ef2a67a685b About a minute ago 4.84GB $ Create an Oracle SOA Suite Docker image using Dockerfile For test and development purposes, you can create an Oracle SOA Suite image using the Dockerfile. Consult the README file for important prerequisite steps, such as building or pulling the Server JRE Docker image, Oracle FMW Infrastructure Docker image, and downloading the Oracle SOA Suite installer and bundle patch binaries.\nA prebuilt Oracle Fusion Middleware Infrastructure image, container-registry.oracle.com/middleware/fmw-infrastructure:12.2.1.4, is available at container-registry.oracle.com. We recommend that you pull and rename this image to build the Oracle SOA Suite image.\n$ docker pull container-registry.oracle.com/middleware/fmw-infrastructure:12.2.1.4 $ docker tag container-registry.oracle.com/middleware/fmw-infrastructure:12.2.1.4 oracle/fmw-infrastructure:12.2.1.4.0 Follow these steps to build an Oracle Fusion Middleware Infrastructure image, and then the Oracle SOA Suite image as a layer on top of that:\n Make a local clone of the sample repository:\n$ git clone https://github.com/oracle/docker-images Build the oracle/fmw-infrastructure:12.2.1.4 image:\n$ cd docker-images/OracleFMWInfrastructure/dockerfiles $ sh buildDockerImage.sh -v 12.2.1.4 -s This will produce an image named oracle/fmw-infrastructure:12.2.1.4.\n Tag the image as follows:\n$ docker tag oracle/fmw-infrastructure:12.2.1.4 oracle/fmw-infrastructure:12.2.1.4.0 Download the Oracle SOA Suite installer from the Oracle Technology Network or e-delivery.\n Note: Copy the installer binaries to the same location as the Dockerfile.\n To build the Oracle SOA Suite image with patches, you must download and drop the patch zip files (for example, p29928100_122140_Generic.zip) into the patches/ folder under the version that is required. For example, for 12.2.1.4.0 the folder is 12.2.1.4/patches. Similarly, to build the image by including the OPatch patch, download and drop the OPatch patch zip file (for example, p28186730_1394214_Generic.zip) into the opatch_patch/ folder.\n Create the Oracle SOA Suite image by running the provided script:\n$ cd docker-images/OracleSOASuite/dockerfiles $ ./buildDockerImage.sh -v 12.2.1.4 -s The image produced will be named oracle/soasuite:12.2.1.4. The samples and instructions assume the Oracle SOA Suite image is named soasuite:12.2.1.4. You must rename your image to match this name, or update the samples to refer to the image you created.\n$ docker tag oracle/soasuite:12.2.1.4 soasuite:12.2.1.4 "
+},
+{
+ "uri": "/fmw-kubernetes/24.2.2/soa-domains/adminguide/enablingt3/",
+ "title": "Expose the T3/T3S protocol",
+ "tags": [],
+ "description": "Create a T3/T3S channel and the corresponding Kubernetes service to expose the T3/T3S protocol for the Administration Server and Managed Servers in an Oracle SOA Suite domain.",
+ "content": " Oracle strongly recommends that you do not expose non-HTTPS traffic (T3/T3s/LDAP/IIOP/IIOPs) outside of the external firewall. You can control this access using a combination of network channels and firewalls.\n You can create T3/T3S channels and the corresponding Kubernetes service to expose the T3/T3S protocol for the Administration Server and Managed Servers in an Oracle SOA Suite domain.\nThe WebLogic Kubernetes Operator provides an option to expose a T3 channel for the Administration Server using the exposeAdminT3Channel setting during domain creation, then the matching T3 service can be used to connect. By default, when exposeAdminT3Channel is set, the WebLogic Kubernetes Operator environment exposes the NodePort for the T3 channel of the NetworkAccessPoint at 30012 (use t3ChannelPort to configure the port to a different value).\nIf you miss enabling exposeAdminT3Channel during domain creation, follow these steps to create a T3 channel for Administration Server manually.\nExpose a T3/T3S Channel for the Administration Server To create a custom T3/T3S channel for the Administration Server that has a listen port listen_port and a paired public port public_port:\n Create t3_admin_config.py with the following content:\nadmin_pod_name = sys.argv[1] admin_port = sys.argv[2] user_name = sys.argv[3] password = sys.argv[4] listen_port = sys.argv[5] public_port = sys.argv[6] public_address = sys.argv[7] AdminServerName = sys.argv[8] channelType = sys.argv[9] print(\u0026#39;custom admin_pod_name : [%s]\u0026#39; % admin_pod_name); print(\u0026#39;custom admin_port : [%s]\u0026#39; % admin_port); print(\u0026#39;custom user_name : [%s]\u0026#39; % user_name); print(\u0026#39;custom password : ********\u0026#39;); print(\u0026#39;public address : [%s]\u0026#39; % public_address); print(\u0026#39;channel listen port : [%s]\u0026#39; % listen_port); print(\u0026#39;channel public listen port : [%s]\u0026#39; % public_port); connect(user_name, password, \u0026#39;t3://\u0026#39; + admin_pod_name + \u0026#39;:\u0026#39; + admin_port) edit() startEdit() cd(\u0026#39;/\u0026#39;) cd(\u0026#39;Servers/%s/\u0026#39; % AdminServerName ) if channelType == \u0026#39;t3\u0026#39;: create(\u0026#39;T3Channel_AS\u0026#39;,\u0026#39;NetworkAccessPoint\u0026#39;) cd(\u0026#39;NetworkAccessPoints/T3Channel_AS\u0026#39;) set(\u0026#39;Protocol\u0026#39;,\u0026#39;t3\u0026#39;) set(\u0026#39;ListenPort\u0026#39;,int(listen_port)) set(\u0026#39;PublicPort\u0026#39;,int(public_port)) set(\u0026#39;PublicAddress\u0026#39;, public_address) print(\u0026#39;Channel T3Channel_AS added\u0026#39;) elif channelType == \u0026#39;t3s\u0026#39;:\tcreate(\u0026#39;T3SChannel_AS\u0026#39;,\u0026#39;NetworkAccessPoint\u0026#39;) cd(\u0026#39;NetworkAccessPoints/T3SChannel_AS\u0026#39;) set(\u0026#39;Protocol\u0026#39;,\u0026#39;t3s\u0026#39;) set(\u0026#39;ListenPort\u0026#39;,int(listen_port)) set(\u0026#39;PublicPort\u0026#39;,int(public_port)) set(\u0026#39;PublicAddress\u0026#39;, public_address) set(\u0026#39;HttpEnabledForThisProtocol\u0026#39;, true) set(\u0026#39;OutboundEnabled\u0026#39;, false) set(\u0026#39;Enabled\u0026#39;, true) set(\u0026#39;TwoWaySSLEnabled\u0026#39;, true) set(\u0026#39;ClientCertificateEnforced\u0026#39;, false) else: print(\u0026#39;channelType [%s] not supported\u0026#39;,channelType) activate() disconnect() Copy t3_admin_config.py into the domain home (for example, /u01/oracle/user_projects/domains/soainfra) of the Administration Server pod (for example, soainfra-adminserver in soans namespace).\n $ kubectl cp t3_admin_config.py soans/soainfra-adminserver:/u01/oracle/user_projects/domains/soainfra Run wlst.sh t3_admin_config.py by using exec into the Administration Server pod with the following parameters:\n admin_pod_name: soainfra-adminserver # Administration Server pod admin_port: 7011 user_name: weblogic password: Welcome1 # weblogic password listen_port: 30014 # New port for T3 Administration Server public_port: 30014 # Kubernetes NodePort which will be used to expose T3 port externally public_address: AdminServerName: AdminServer # Give administration Server name channelType: t3 # t3 or t3s protocol channel $ kubectl exec -it \u0026lt;Administration Server pod\u0026gt; -n \u0026lt;namespace\u0026gt; -- /u01/oracle/oracle_common/common/bin/wlst.sh \u0026lt;domain_home\u0026gt;/t3_admin_config.py \u0026lt;Administration Server pod\u0026gt; \u0026lt;Administration Server port\u0026gt; weblogic \u0026lt;password for weblogic\u0026gt; \u0026lt;t3 port on Administration Server\u0026gt; \u0026lt;t3 nodeport\u0026gt; \u0026lt;master_ip\u0026gt; \u0026lt;AdminServerName\u0026gt; \u0026lt;channelType t3 or t3s\u0026gt; For example:\n$ kubectl exec -it soainfra-adminserver -n soans -- /u01/oracle/oracle_common/common/bin/wlst.sh /u01/oracle/user_projects/domains/soainfra/t3_admin_config.py soainfra-adminserver 7011 weblogic Welcome1 30014 30014 xxx.xxx.xxx.xxx AdminServer t3 Create t3_admin_svc.yaml with the following contents to expose T3 at NodePort 30014 for domainName and domainUID as soainfra and domain deployed in soans namespace:\n Note: For T3S, replace NodePort 30014 with the appropriate value used with public_port while creating the T3S channel using wlst.sh in the previous step.\n apiVersion: v1 kind: Service metadata: name: soainfra-adminserver-t3-external namespace: soans labels: weblogic.serverName: AdminServer weblogic.domainName: soainfra weblogic.domainUID: soainfra spec: type: NodePort selector: weblogic.domainName: soainfra weblogic.domainUID: soainfra weblogic.serverName: AdminServer ports: - name: t3adminport protocol: TCP port: 30014 targetPort: 30014 nodePort: 30014 Create the NodePort service for port 30014:\n$ kubectl create -f t3_admin_svc.yaml Verify that you can access T3 for the Administration Server with the following URL:\nt3://\u0026lt;master_ip\u0026gt;:30014 Similarly, you can access T3S as follows:\na. First get the certificates from the Administration Server to be used for secured (T3S) connection from the client. You can export the certificate from the Administration Server with WLST commands. For example, to export the default demoidentity:\n Note: If you are using the custom SSL certificate, replace the steps accordingly.\n $ kubectl exec -it soainfra-adminserver -n soans -- bash $ /u01/oracle/oracle_common/common/bin/wlst.sh $ connect('weblogic','Welcome1','t3://soainfra-adminserver:7011') $ svc = getOpssService(name='KeyStoreService') $ svc.exportKeyStoreCertificate(appStripe='system', name='demoidentity', password='DemoIdentityKeyStorePassPhrase', alias='DemoIdentity', type='Certificate', filepath='/tmp/cert.txt/') These steps download the certificate at /tmp/cert.txt.\nb. Use the same certificates from the client side and connect using t3s. For example:\n$ export JAVA_HOME=/u01/jdk $ keytool -import -v -trustcacerts -alias soadomain -file cert.txt -keystore $JAVA_HOME/jre/lib/security/cacerts -keypass changeit -storepass changeit $ export WLST_PROPERTIES=\u0026quot;-Dweblogic.security.SSL.ignoreHostnameVerification=true\u0026quot; $ cd $ORACLE_HOME/oracle_common/common/bin $ ./wlst.sh Initializing WebLogic Scripting Tool (WLST) ... Welcome to WebLogic Server Administration Scripting Shell Type help() for help on available commands $ wls:/offline\u0026gt; connect('weblogic','Welcome1','t3s://\u0026lt;Master IP address\u0026gt;:30014') Expose T3/T3S for Managed Servers To create a custom T3/T3S channel for all Managed Servers, with a listen port listen_port and a paired public port public_port:\n Create t3_ms_config.py with the following content:\nadmin_pod_name = sys.argv[1] admin_port = sys.argv[2] user_name = sys.argv[3] password = sys.argv[4] listen_port = sys.argv[5] public_port = sys.argv[6] public_address = sys.argv[7] managedNameBase = sys.argv[8] ms_count = sys.argv[9] channelType = sys.argv[10] print(\u0026#39;custom host : [%s]\u0026#39; % admin_pod_name); print(\u0026#39;custom port : [%s]\u0026#39; % admin_port); print(\u0026#39;custom user_name : [%s]\u0026#39; % user_name); print(\u0026#39;custom password : ********\u0026#39;); print(\u0026#39;public address : [%s]\u0026#39; % public_address); print(\u0026#39;channel listen port : [%s]\u0026#39; % listen_port); print(\u0026#39;channel public listen port : [%s]\u0026#39; % public_port); connect(user_name, password, \u0026#39;t3://\u0026#39; + admin_pod_name + \u0026#39;:\u0026#39; + admin_port) edit() startEdit() for index in range(0, int(ms_count)): cd(\u0026#39;/\u0026#39;) msIndex = index+1 cd(\u0026#39;/\u0026#39;) name = \u0026#39;%s%s\u0026#39; % (managedNameBase, msIndex) cd(\u0026#39;Servers/%s/\u0026#39; % name ) if channelType == \u0026#39;t3\u0026#39;: create(\u0026#39;T3Channel_MS\u0026#39;,\u0026#39;NetworkAccessPoint\u0026#39;) cd(\u0026#39;NetworkAccessPoints/T3Channel_MS\u0026#39;) set(\u0026#39;Protocol\u0026#39;,\u0026#39;t3\u0026#39;) set(\u0026#39;ListenPort\u0026#39;,int(listen_port)) set(\u0026#39;PublicPort\u0026#39;,int(public_port)) set(\u0026#39;PublicAddress\u0026#39;, public_address) print(\u0026#39;Channel T3Channel_MS added ...for \u0026#39; + name) elif channelType == \u0026#39;t3s\u0026#39;:\tcreate(\u0026#39;T3SChannel_MS\u0026#39;,\u0026#39;NetworkAccessPoint\u0026#39;) cd(\u0026#39;NetworkAccessPoints/T3SChannel_MS\u0026#39;) set(\u0026#39;Protocol\u0026#39;,\u0026#39;t3s\u0026#39;) set(\u0026#39;ListenPort\u0026#39;,int(listen_port)) set(\u0026#39;PublicPort\u0026#39;,int(public_port)) set(\u0026#39;PublicAddress\u0026#39;, public_address) set(\u0026#39;HttpEnabledForThisProtocol\u0026#39;, true) set(\u0026#39;OutboundEnabled\u0026#39;, false) set(\u0026#39;Enabled\u0026#39;, true) set(\u0026#39;TwoWaySSLEnabled\u0026#39;, true) set(\u0026#39;ClientCertificateEnforced\u0026#39;, false) print(\u0026#39;Channel T3SChannel_MS added ...for \u0026#39; + name) else: print(\u0026#39;Protocol [%s] not supported\u0026#39; % channelType) activate() disconnect() Copy t3_ms_config.py into the domain home (for example, /u01/oracle/user_projects/domains/soainfra) of the Administration Server pod (for example, soainfra-adminserver in soans namespace).\n$ kubectl cp t3_ms_config.py soans/soainfra-adminserver:/u01/oracle/user_projects/domains/soainfra Run wlst.sh t3_ms_config.py by exec into the Administration Server pod with the following parameters:\n admin_pod_name: soainfra-adminserver # Administration Server pod admin_port: 7011 user_name: weblogic password: Welcome1 # weblogic password listen_port: 30016 # New port for T3 Managed Servers public_port: 30016 # Kubernetes NodePort which will be used to expose T3 port externally public_address: managedNameBase: soa_server # Give Managed Server base name. For osb_cluster this will be osb_server ms_count: 5 # Number of configured Managed Servers channelType: t3 # channelType is t3 or t3s $ kubectl exec -it \u0026lt;Administration Server pod\u0026gt; -n \u0026lt;namespace\u0026gt; -- /u01/oracle/oracle_common/common/bin/wlst.sh \u0026lt;domain_home\u0026gt;/t3_ms_config.py \u0026lt;Administration Server pod\u0026gt; \u0026lt;Administration Server port\u0026gt; weblogic \u0026lt;password for weblogic\u0026gt; \u0026lt;t3 port on Managed Server\u0026gt; \u0026lt;t3 nodeport\u0026gt; \u0026lt;master_ip\u0026gt; \u0026lt;managedNameBase\u0026gt; \u0026lt;ms_count\u0026gt; \u0026lt;channelType t3 or t3s\u0026gt; For example:\n$ kubectl exec -it soainfra-adminserver -n soans -- /u01/oracle/oracle_common/common/bin/wlst.sh /u01/oracle/user_projects/domains/soainfra/t3_ms_config.py soainfra-adminserver 7011 weblogic Welcome1 30016 30016 xxx.xxx.xxx.xxx soa_server 5 t3 Create t3_ms_svc.yaml with the following contents to expose T3 at Managed Server port 30016 for domainName, domainUID as soainfra, and clusterName as soa_cluster for the SOA cluster. Similarly, you can create the Kubernetes service with clusterName as osb_cluster for an Oracle Service Bus cluster:\n Note: For T3S, replace NodePort 30016 with the appropriate value used with public_port while creating the T3S channel using wlst.sh in the previous step.\n apiVersion: v1 kind: Service metadata: name: soainfra-soa-cluster-t3-external namespace: soans labels: weblogic.clusterName: soa_cluster weblogic.domainName: soainfra weblogic.domainUID: soainfra spec: type: NodePort selector: weblogic.domainName: soainfra weblogic.domainUID: soainfra weblogic.clusterName: soa_cluster ports: - name: t3soaport protocol: TCP port: 30016 targetPort: 30016 nodePort: 30016 Create the NodePort service for port 30016:\n$ kubectl create -f t3_ms_svc.yaml Verify that you can access T3 for the Managed Server with the following URL:\nt3://\u0026lt;master_ip\u0026gt;:30016 Similarly, you can access T3S as follows:\na. First get the certificates from the Administration Server to be used for secured (t3s) connection from client. You can export the certificate from the Administration Server with wlst commands. Sample commands to export the default demoidentity:\n Note: In case you are using the custom SSL certificate, replaces the steps accordingly\n $ kubectl exec -it soainfra-adminserver -n soans -- bash $ /u01/oracle/oracle_common/common/bin/wlst.sh $ connect('weblogic','Welcome1','t3://soainfra-adminserver:7011') $ svc = getOpssService(name='KeyStoreService') $ svc.exportKeyStoreCertificate(appStripe='system', name='demoidentity', password='DemoIdentityKeyStorePassPhrase', alias='DemoIdentity', type='Certificate', filepath='/tmp/cert.txt/') The above steps download the certificate at /tmp/cert.txt.\nb. Use the same certificates from the client side and connect using t3s. For example:\n$ export JAVA_HOME=/u01/jdk $ keytool -import -v -trustcacerts -alias soadomain -file cert.txt -keystore $JAVA_HOME/jre/lib/security/cacerts -keypass changeit -storepass changeit $ export WLST_PROPERTIES=\u0026quot;-Dweblogic.security.SSL.ignoreHostnameVerification=true\u0026quot; $ cd $ORACLE_HOME/oracle_common/common/bin $ ./wlst.sh Initializing WebLogic Scripting Tool (WLST) ... Welcome to WebLogic Server Administration Scripting Shell Type help() for help on available commands $ wls:/offline\u0026gt; connect('weblogic','Welcome1','t3s://\u0026lt;Master IP address\u0026gt;:30016') Remove T3/T3S configuration For Administration Server Create t3_admin_delete.py with the following content:\nadmin_pod_name = sys.argv[1] admin_port = sys.argv[2] user_name = sys.argv[3] password = sys.argv[4] AdminServerName = sys.argv[5] channelType = sys.argv[6] print(\u0026#39;custom admin_pod_name : [%s]\u0026#39; % admin_pod_name); print(\u0026#39;custom admin_port : [%s]\u0026#39; % admin_port); print(\u0026#39;custom user_name : [%s]\u0026#39; % user_name); print(\u0026#39;custom password : ********\u0026#39;); connect(user_name, password, \u0026#39;t3://\u0026#39; + admin_pod_name + \u0026#39;:\u0026#39; + admin_port) edit() startEdit() cd(\u0026#39;/\u0026#39;) cd(\u0026#39;Servers/%s/\u0026#39; % AdminServerName ) if channelType == \u0026#39;t3\u0026#39;: delete(\u0026#39;T3Channel_AS\u0026#39;,\u0026#39;NetworkAccessPoint\u0026#39;) elif channelType == \u0026#39;t3s\u0026#39;: delete(\u0026#39;T3SChannel_AS\u0026#39;,\u0026#39;NetworkAccessPoint\u0026#39;) else: print(\u0026#39;channelType [%s] not supported\u0026#39;,channelType) activate() disconnect() Copy t3_admin_delete.py into the domain home (for example, /u01/oracle/user_projects/domains/soainfra) of the Administration Server pod (for example, soainfra-adminserver in soans namespace).\n$ kubectl cp t3_admin_delete.py soans/soainfra-adminserver:/u01/oracle/user_projects/domains/soainfra Run wlst.sh t3_admin_delete.py by exec into the Administration Server pod with the following parameters:\n admin_pod_name: soainfra-adminserver # Administration Server pod admin_port: 7011 user_name: weblogic password: Welcome1 # weblogic password AdminServerName: AdminServer # Give administration Server name channelType: t3 # T3 channel $ kubectl exec -it \u0026lt;Administration Server pod\u0026gt; -n \u0026lt;namespace\u0026gt; -- /u01/oracle/oracle_common/common/bin/wlst.sh \u0026lt;domain_home\u0026gt;/t3_admin_delete.py \u0026lt;Administration Server pod\u0026gt; \u0026lt;Administration Server port\u0026gt; weblogic \u0026lt;password for weblogic\u0026gt; \u0026lt;AdminServerName\u0026gt; \u0026lt;protocol t3 or t3s\u0026gt; For example:\n$ kubectl exec -it soainfra-adminserver -n soans -- /u01/oracle/oracle_common/common/bin/wlst.sh /u01/oracle/user_projects/domains/soainfra/t3_admin_delete.py soainfra-adminserver 7011 weblogic Welcome1 AdminServer t3 Delete the NodePort service for port 30014:\n$ kubectl delete -f t3_admin_svc.yaml For Managed Servers These steps delete the custom T3/T3S channel created by Expose T3/T3S for Managed Servers for all Managed Servers.\n Create t3_ms_delete.py with the following content:\nadmin_pod_name = sys.argv[1] admin_port = sys.argv[2] user_name = sys.argv[3] password = sys.argv[4] managedNameBase = sys.argv[5] ms_count = sys.argv[6] channelType = sys.argv[7] print(\u0026#39;custom host : [%s]\u0026#39; % admin_pod_name); print(\u0026#39;custom port : [%s]\u0026#39; % admin_port); print(\u0026#39;custom user_name : [%s]\u0026#39; % user_name); print(\u0026#39;custom password : ********\u0026#39;); connect(user_name, password, \u0026#39;t3://\u0026#39; + admin_pod_name + \u0026#39;:\u0026#39; + admin_port) edit() startEdit() for index in range(0, int(ms_count)): cd(\u0026#39;/\u0026#39;) msIndex = index+1 cd(\u0026#39;/\u0026#39;) name = \u0026#39;%s%s\u0026#39; % (managedNameBase, msIndex) cd(\u0026#39;Servers/%s/\u0026#39; % name ) if channelType == \u0026#39;t3\u0026#39;: delete(\u0026#39;T3Channel_MS\u0026#39;,\u0026#39;NetworkAccessPoint\u0026#39;) elif channelType == \u0026#39;t3s\u0026#39;: delete(\u0026#39;T3SChannel_MS\u0026#39;,\u0026#39;NetworkAccessPoint\u0026#39;) else: print(\u0026#39;Protocol [%s] not supported\u0026#39; % channelType) activate() disconnect() Copy t3_ms_delete.py into the domain home (for example, /u01/oracle/user_projects/domains/soainfra) of the Administration Server pod (for example, soainfra-adminserver in soans namespace).\n$ kubectl cp t3_ms_delete.py soans/soainfra-adminserver:/u01/oracle/user_projects/domains/soainfra Run wlst.sh t3_ms_delete.py by exec into the Administration Server pod with the following parameters:\n admin_pod_name: soainfra-adminserver # Administration Server pod admin_port: 7011 user_name: weblogic password: Welcome1 # weblogic password managedNameBase: soa_server # Give Managed Server base name. For osb_cluster this will be osb_server ms_count: 5 # Number of configured Managed Servers channelType: t3 # channelType is t3 or t3s $ kubectl exec -it \u0026lt;Administration Server pod\u0026gt; -n \u0026lt;namespace\u0026gt; -- /u01/oracle/oracle_common/common/bin/wlst.sh \u0026lt;domain_home\u0026gt;/t3_ms_delete.py \u0026lt;Administration Server pod\u0026gt; \u0026lt;Administration Server port\u0026gt; weblogic \u0026lt;password for weblogic\u0026gt; \u0026lt;t3 port on Managed Server\u0026gt; \u0026lt;t3 nodeport\u0026gt; \u0026lt;master_ip\u0026gt; \u0026lt;managedNameBase\u0026gt; \u0026lt;ms_count\u0026gt; \u0026lt;channelType t3 or t3s\u0026gt; For example:\n$ kubectl exec -it soainfra-adminserver -n soans -- /u01/oracle/oracle_common/common/bin/wlst.sh /u01/oracle/user_projects/domains/soainfra/t3_ms_delete.py soainfra-adminserver 7011 weblogic Welcome1 soa_server 5 t3 Delete the NodePort service for port 30016 (or the NodePort used while creating the Kubernetes service):\n$ kubectl delete -f t3_ms_svc.yaml "
+},
+{
+ "uri": "/fmw-kubernetes/24.2.2/soa-domains/adminguide/deploying-composites/",
+ "title": "Deploy composite applications",
+ "tags": [],
+ "description": "Deploy composite applications for Oracle SOA Suite and Oracle Service Bus domains.",
+ "content": "Learn how to deploy the composite applications for Oracle SOA Suite and Oracle Service Bus domains.\n Deploy using JDeveloper Deploy Oracle SOA Suite and Oracle Service Bus composite applications from Oracle JDeveloper to Oracle SOA Suite in the WebLogic Kubernetes Operator environment.\n Deploy using Maven and Ant Deploy Oracle SOA Suite and Oracle Service Bus composite applications using the Maven and Ant based approach in an Oracle SOA Suite deployment.\n Deploy using composites in a persistent volume or image Deploy Oracle SOA Suite and Oracle Service Bus composite applications artifacts in a persistent volume or in an image.\n "
+},
+{
+ "uri": "/fmw-kubernetes/24.2.2/soa-domains/cleanup-domain-setup/",
+ "title": "Uninstall",
+ "tags": [],
+ "description": "Clean up the Oracle SOA Suite domain setup.",
+ "content": "Learn how to clean up the Oracle SOA Suite domain setup.\nRemove the domain Remove the domain\u0026rsquo;s ingress (for example, Traefik ingress) using Helm:\n$ helm uninstall soa-domain-ingress -n sample-domain1-ns For example:\n$ helm uninstall soainfra-traefik -n soans Remove the domain resources by using the sample delete-weblogic-domain-resources.sh script present at ${WORKDIR}/delete-domain:\n$ cd ${WORKDIR}/delete-domain $ ./delete-weblogic-domain-resources.sh -d sample-domain1 For example:\n$ cd ${WORKDIR}/delete-domain $ ./delete-weblogic-domain-resources.sh -d soainfra Use kubectl to confirm that the server pods and domain resource are deleted:\n$ kubectl get pods -n sample-domain1-ns $ kubectl get domains -n sample-domain1-ns $ kubectl get clusters -n sample-domain1-ns For example:\n$ kubectl get pods -n soans $ kubectl get domains -n soans $ kubectl get clusters -n soans Drop the RCU schemas Follow these steps to drop the RCU schemas created for Oracle SOA Suite domains.\nRemove the domain namespace Configure the installed ingress load balancer (for example, Traefik) to stop managing the ingresses in the domain namespace:\n$ helm upgrade traefik traefik/traefik \\ --namespace traefik \\ --reuse-values \\ --set \u0026#34;kubernetes.namespaces={traefik}\u0026#34; \\ --wait Delete the domain namespace:\n$ kubectl delete namespace sample-domain1-ns For example:\n$ kubectl delete namespace soans Remove the operator Remove the operator:\n$ helm uninstall sample-weblogic-operator -n sample-weblogic-operator-ns For example:\n$ helm uninstall weblogic-kubernetes-operator -n opns Remove the operator\u0026rsquo;s namespace:\n$ kubectl delete namespace sample-weblogic-operator-ns For example:\n$ kubectl delete namespace opns Remove the load balancer Remove the installed ingress based load balancer (for example, Traefik):\n$ helm uninstall traefik -n traefik Remove the Traefik namespace:\n$ kubectl delete namespace traefik Delete the domain home To remove the domain home that is generated using the create-domain.sh script, with appropriate privileges manually delete the contents of the storage attached to the domain home persistent volume (PV).\nFor example, for the domain\u0026rsquo;s persistent volume of type host_path:\n$ rm -rf /scratch/k8s_dir/SOA/* "
+},
+{
+ "uri": "/fmw-kubernetes/24.2.2/soa-domains/edg-guide/",
+ "title": "Enterprise Deployment Guide",
+ "tags": [],
+ "description": "Enterprise Deployment Guide for Oracle SOA Suite on Kubernetes.",
+ "content": " This Enterprise Deployment Guide is for preview release.\n This section provides information on the Enterprise Deployment Guide (single data center reference in Maximum Availability Architectures Guide).\n Topology Topology for Oracle SOA Suite Enterprise Deployment on Kubernetes.\n Setup steps Set up Oracle SOA Suite Enterprise Deployment on Kubernetes.\n "
+},
+{
+ "uri": "/fmw-kubernetes/24.2.2/soa-domains/adminguide/persisting-soa-adapters-customizations/",
+ "title": "Persist adapter customizations",
+ "tags": [],
+ "description": "Persist the customizations done for Oracle SOA Suite adapters.",
+ "content": "The lifetime for any customization done in a file on a server pod is up to the lifetime of that pod. The changes are not persisted once the pod goes down or is restarted.\nFor example, the following configuration updates DbAdapter.rar to create a new connection instance and creates data source CoffeeShop on the Administration Console for the same with jdbc/CoffeeShopDS.\nFile location: /u01/oracle/soa/soa/connectors/DbAdapter.rar\n\u0026lt;connection-instance\u0026gt; \u0026lt;jndi-name\u0026gt;eis/DB/CoffeeShop\u0026lt;/jndi-name\u0026gt; \u0026lt;connection-properties\u0026gt; \u0026lt;properties\u0026gt; \u0026lt;property\u0026gt; \u0026lt;name\u0026gt;XADataSourceName\u0026lt;/name\u0026gt; \u0026lt;value\u0026gt;jdbc/CoffeeShopDS\u0026lt;/value\u0026gt; \u0026lt;/property\u0026gt; \u0026lt;property\u0026gt; \u0026lt;name\u0026gt;DataSourceName\u0026lt;/name\u0026gt; \u0026lt;value\u0026gt;\u0026lt;/value\u0026gt; \u0026lt;/property\u0026gt; \u0026lt;property\u0026gt; \u0026lt;name\u0026gt;PlatformClassName\u0026lt;/name\u0026gt; \u0026lt;value\u0026gt;org.eclipse.persistence.platform.database.Oracle10Platform\u0026lt;/value\u0026gt; \u0026lt;/property\u0026gt; \u0026lt;/properties\u0026gt; \u0026lt;/connection-properties\u0026gt; \u0026lt;/connection-instance\u0026gt; If you need to persist the customizations for any of the adapter files under the SOA Oracle Home in the server pod, use one of the following methods.\nMethod 1: Customize the Adapter file using the WebLogic Administration Console: Log in to the WebLogic Administration Console, and go to Deployments \u0026gt; ABC.rar \u0026gt; Configuration \u0026gt; Outbound Connection Pools.\n Click New to create a new connection, then provide a new connection name, and click Finish.\n Go back to the new connection, update the properties as required, and save.\n Under Deployments, select ABC.rar, then Update.\nThis step asks for the Plan.xml location. This location by default will be in ${ORACLE_HOME}/soa/soa which is not under Persistent Volume (PV). Therefore, provide the domain\u0026rsquo;s PV location such as {DOMAIN_HOME}/soainfra/servers.\nNow the Plan.xml will be persisted under this location for each Managed Server.\n Method 2: Customize the Adapter file on the Worker Node: Copy ABC.rar from the server pod to a PV path:\n$ kubectl cp \u0026lt;namespace\u0026gt;/\u0026lt;SOA Managed Server pod name\u0026gt;:\u0026lt;full path of .rar file\u0026gt; \u0026lt;destination path inside PV\u0026gt; For example:\n$ kubectl cp soans/soainfra-soa-server1:/u01/oracle/soa/soa/connectors/ABC.rar ${DockerVolume}/domains/soainfra/servers/ABC.rar or do a normal file copy between these locations after entering (using kubectl exec) in to the Managed Server pod.\n Unrar ABC.rar.\n Update the new connection details in the weblogic-ra.xml file under META_INF.\n In the WebLogic Administration Console, under Deployments, select ABC.rar, then Update.\n Select the ABC.rar path as the new location, which is ${DOMAIN_HOME}/user_projects/domains/soainfra/servers/ABC.rar and click Update.\n Verify that the plan.xml or updated .rar should be persisted in the PV.\n "
+},
+{
+ "uri": "/fmw-kubernetes/24.2.2/soa-domains/faq/",
+ "title": "Frequently Asked Questions",
+ "tags": [],
+ "description": "This section describes known issues for Oracle SOA Suite domain deployment on Kubernetes. It also provides answers to frequently asked questions.",
+ "content": "Overriding tuning parameters is not supported using configuration overrides The WebLogic Kubernetes Operator enables you to override some of the domain configuration using configuration overrides (also called situational configuration). See supported overrides. Overriding the tuning parameters such as MaxMessageSize and PAYLOAD, for Oracle SOA Suite domains is not supported using the configuration overrides feature. However, you can override them using the following steps:\n Specify the new value using the environment variable K8S_REFCONF_OVERRIDES in serverPod.env section in domain.yaml configuration file (example path: \u0026lt;domain-creation-output-directory\u0026gt;/weblogic-domains/soainfra/domain.yaml) based on the servers to which the changes are to be applied.\nFor example, to override the value at the Administration Server pod level:\nspec: adminServer: serverPod: env: - name: K8S_REFCONF_OVERRIDES value: \u0026#34;-Dweblogic.MaxMessageSize=78787878\u0026#34; - name: USER_MEM_ARGS value: \u0026#39;-Djava.security.egd=file:/dev/./urandom -Xms512m -Xmx1024m \u0026#39; serverStartState: RUNNING For example, to override the value at a specific cluster level (soa_cluster or osb_cluster):\napiVersion: \u0026#34;weblogic.oracle/v1\u0026#34; kind: Cluster metadata: name: soainfra-soa-cluster # Update this with the namespace your domain will run in: namespace: soans labels: # Update this with the `domainUID` of your domain: weblogic.domainUID: soainfra spec: clusterName: soa_cluster serverService: precreateService: true serverPod: env: - name: K8S_REFCONF_OVERRIDES value: \u0026#34;-Dsoa.payload.threshold.kb=102410\u0026#34; Note: When multiple system properties are specified for serverPod.env.value, make sure each system property is separated by a space.\n Apply the updated domain.yaml file:\n$ kubectl apply -f domain.yaml Note: The server pod(s) will be automatically restarted (rolling restart).\n Deployments in the WebLogic Server Administration Console may display unexpected error In an Oracle SOA Suite environment deployed using the operator, accessing Deployments from the WebLogic Server Administration Console home page may display the error message Unexpected error encountered while obtaining monitoring information for applications. This error does not have any functional impact and can be ignored. You can verify that the applications are in Active state from the Control tab in Summary of deployments page.\nEnterprise Manager Console may display ADF_FACES-30200 error In an Oracle SOA Suite environment deployed using the operator, the Enterprise Manager Console may intermittently display the following error when the domain servers are restarted:\nADF_FACES-30200: For more information, please see the server\u0026#39;s error log for an entry beginning with: The UIViewRoot is null. Fatal exception during PhaseId: RESTORE_VIEW 1. You can refresh the Enterprise Manager Console URL to successfully log in to the Console.\nConfigure the external URL access for Oracle SOA Suite composite applications For Oracle SOA Suite composite applications to access the external URLs over the internet (if your cluster is behind a http proxy server), you must configure the following proxy parameters for Administration Server and Managed Server pods.\n-Dhttp.proxyHost=www-your-proxy.com -Dhttp.proxyPort=proxy-port -Dhttps.proxyHost=www-your-proxy.com -Dhttps.proxyPort=proxy-port -Dhttp.nonProxyHosts=\u0026#34;localhost|soainfra-adminserver|soainfra-soa-server1|soainfra-osb-server1|...soainfra-soa-serverN|*.svc.cluster.local|*.your.domain.com|/var/run/docker.sock\u0026#34; To do this, edit the domain.yaml configuration file and append the proxy parameters to the spec.serverPod.env.JAVA_OPTIONS environment variable value.\nFor example:\nserverPod: env: - name: JAVA_OPTIONS value: -Dweblogic.StdoutDebugEnabled=false -Dweblogic.ssl.Enabled=true -Dweblogic.security.SSL.ignoreHostnameVerification=true -Dhttp.proxyHost=www-your-proxy.com -Dhttp.proxyPort=proxy-port -Dhttps.proxyHost=www-your-proxy.com -Dhttps.proxyPort=proxy-port -Dhttp.nonProxyHosts=\u0026#34;localhost|soainfra-adminserver|soainfra-soa-server1|soainfra-osb-server1|...soainfra-soa-serverN|*.svc.cluster.local|*.your.domain.com|/var/run/docker.sock\u0026#34; - name: USER_MEM_ARGS value: \u0026#39;-Djava.security.egd=file:/dev/./urandom -Xms256m -Xmx1024m \u0026#39; volumeMounts: Note: The -Dhttp.nonProxyHosts parameter must have the pod names of the Administration Server and each Managed Server. For example: soainfra-adminserver, soainfra-soa-server1, soainfra-osb-server1, and so on.\n Apply the updated domain.yaml file:\n$ kubectl apply -f domain.yaml Note: The server pod(s) will be automatically restarted (rolling restart).\n Configure the external access for the Oracle Enterprise Scheduler WebServices WSDL URLs In an Oracle SOA Suite domain deployed including the Oracle Enterprise Scheduler (ESS) component, the following ESS WebServices WSDL URLs shown in the table format in the ess/essWebServicesWsdl.jsp page are not reachable outside the Kubernetes cluster.\nESSWebService EssAsyncCallbackService EssWsJobAsyncCallbackService Follow these steps to configure the external access for the Oracle Enterprise Scheduler WebServices WSDL URLs:\n Log in to the Administration Console URL of the domain.\nFor example: http://\u0026lt;LOADBALANCER-HOST\u0026gt;:\u0026lt;port\u0026gt;/console In the Home Page, click Clusters. Then click the soa_cluster. Click the HTTP tab and then click Lock \u0026amp; Edit in the Change Center panel. Update the following values: Frontend Host: host name of the load balancer. For example, domain1.example.com. Frontend HTTP Port: load balancer port. For example, 30305. Frontend HTTPS Port: load balancer https port. For example, 30443. Click Save. Click Activate Changes in the Change Center panel. Restart the servers in the SOA cluster. Note: Do not restart servers from the Administration Console.\n Missing gif images in Oracle Service Bus console pipeline configuration page In an Oracle SOA Suite domain environment upgraded to the release 21.1.2, some gif images are not rendered in the Oracle Serice Bus console pipeline configuration page, as their corresponding url paths are not exposed via the Ingress path rules in the earlier releases (for Non-SSL and SSL termination). To resolve this issue, perform the following steps to apply the latest ingress configuration:\n$ cd ${WORKDIR} $ helm upgrade \u0026lt;helm_release_for_ingress\u0026gt; \\ charts/ingress-per-domain \\ --namespace \u0026lt;domain_namespace\u0026gt; \\ --reuse-values Note: helm_release_for_ingress is the ingress name used in the corresponding helm install command for the ingress installation.\n For example, to upgrade the NGINX based ingress configuration:\n$ cd ${WORKDIR} $ helm upgrade soa-nginx-ingress \\ charts/ingress-per-domain \\ --namespace soans \\ --reuse-values WebLogic Kubernetes Operator FAQs See the general frequently asked questions for using the WebLogic Kubernetes Operator.\n"
+},
+{
+ "uri": "/fmw-kubernetes/24.2.2/soa-domains/adminguide/performing-wlst-operations/",
+ "title": "Perform WLST operations",
+ "tags": [],
+ "description": "Perform WLST administration operations using a helper pod running in the same Kubernetes cluster as the Oracle SOA Suite domain.",
+ "content": "You can use the WebLogic Scripting Tool (WLST) to manage a domain running in a Kubernetes cluster. Some of the many ways to do this are provided here.\nIf the Administration Server was configured to expose a T3 channel using exposeAdminT3Channel when creating the domain, refer to Use WLST.\nIf you do not want to expose additional ports and perform WLST administration operations using the existing Kubernetes services created by the WebLogic Server Kubernetes operator, then follow this documentation. Here we will be creating and using a helper pod in the same Kubernetes cluster as the Oracle SOA Suite domain to perform WLST operations.\n Note: To avoid any misconfigurations, Oracle recommends that you do not use the Administration Server pod directly for WLST operations.\n Create a Kubernetes helper pod Perform WLST operations Sample WLST operations Create a Kubernetes helper pod Before creating a Kubernetes helper pod, make sure that the Oracle SOA Suite Docker image is available on the node, or you can create an image pull secret so that the pod can pull the Docker image on the host where it gets created.\n Create an image pull secret to pull image soasuite:12.2.1.4 by the helper pod.\nNote: Skip this step if you are not using an image pull secret.\n$ kubectl create secret docker-registry \u0026lt;secret-name\u0026gt; --namespace soans \\ --docker-server=\u0026lt;docker-registry-name\u0026gt; \\ --docker-username=\u0026lt;docker-user\u0026gt; \\ --docker-password=\u0026lt;docker-user\u0026gt; \\ --docker-email=\u0026lt;email-id\u0026gt; For example:\n$ kubectl create secret docker-registry image-secret --namespace soans \\ --docker-server=your-registry.com \\ --docker-username=xxxxxx \\ --docker-password=xxxxxxx \\ --docker-email=my@company.com Create a helper pod.\n$ kubectl run helper \\ --image \u0026lt;image_name\u0026gt; \\ --namespace \u0026lt;domain_namespace\u0026gt; \\ --overrides='{ \u0026quot;apiVersion\u0026quot;: \u0026quot;v1\u0026quot;, \u0026quot;spec\u0026quot;: { \u0026quot;imagePullSecrets\u0026quot;: [{\u0026quot;name\u0026quot;: \u0026quot;\u0026lt;secret-name\u0026gt;\u0026quot;}] } }' \\ -- sleep infinity For example:\n$ kubectl run helper \\ --image soasuite:12.2.1.4 \\ --namespace soans \\ --overrides='{ \u0026quot;apiVersion\u0026quot;: \u0026quot;v1\u0026quot;, \u0026quot;spec\u0026quot;: { \u0026quot;imagePullSecrets\u0026quot;: [{\u0026quot;name\u0026quot;: \u0026quot;image-secret\u0026quot;}] } }' \\ -- sleep infinity Note: If you are not using the image pull secret, remove --overrides='{ \u0026quot;apiVersion\u0026quot;: \u0026quot;v1\u0026quot;, \u0026quot;spec\u0026quot;: { \u0026quot;imagePullSecrets\u0026quot;: [{\u0026quot;name\u0026quot;: \u0026quot;\u0026lt;secret-name\u0026gt;\u0026quot;}] } }' .\n Perform WLST operations Once the Kubernetes helper pod is deployed, you can exec into the pod, connect to servers using t3 or t3s and perform WLST operations. By default, t3s is not enabled for the Administration Server or Managed Servers. If you enabled SSL with sslEnabled when creating the domain, then you can use t3s to perform WLST operations.\nInteractive mode Start a bash shell in the helper pod:\n$ kubectl exec -it helper -n \u0026lt;domain_namespace\u0026gt; -- /bin/bash For example:\n$ kubectl exec -it helper -n soans -- /bin/bash This opens a bash shell in the running helper pod:\n[oracle@helper oracle]$ Invoke WLST:\n[oracle@helper oracle]$ cd $ORACLE_HOME/oracle_common/common/bin [oracle@helper bin]$ ./wlst.sh The output will look similar to the following:\n[oracle@helper bin]$ ./wlst.sh Initializing WebLogic Scripting Tool (WLST) ... Jython scans all the jar files it can find at first startup. Depending on the system, this process may take a few minutes to complete, and WLST may not return a prompt right away. Welcome to WebLogic Server Administration Scripting Shell Type help() for help on available commands wls:/offline\u0026gt; Connect using t3:\na. To connect to the Administration Server or Managed Servers using t3, you can use the Kubernetes services created by the WebLogic Server Kubernetes operator:\nwls:/offline\u0026gt; connect('weblogic','\u0026lt;password\u0026gt;','t3://\u0026lt;domainUID\u0026gt;-\u0026lt;WebLogic Server Name\u0026gt;:\u0026lt;Server Port\u0026gt;') For example, if the domainUID is soainfra, Administration Server name is AdminServer, and Administration Server port is 7011, then you can connect to the Administration Server using t3:\nwls:/offline\u0026gt; connect('weblogic','\u0026lt;password\u0026gt;','t3://soainfra-adminserver:7011') The output will look similar to the following:\nwls:/offline\u0026gt; connect('weblogic','\u0026lt;password\u0026gt;','t3://soainfra-adminserver:7011') Connecting to t3://soainfra-adminserver:7011 with userid weblogic ... Successfully connected to Admin Server \u0026quot;AdminServer\u0026quot; that belongs to domain \u0026quot;soainfra\u0026quot;. Warning: An insecure protocol was used to connect to the server. To ensure on-the-wire security, the SSL port or Admin port should be used instead. wls:/soainfra/serverConfig/\u0026gt; b. To connect a WebLogic Server cluster (SOA or Oracle Service Bus) using t3, you can use the Kubernetes services created by the WebLogic Server Kubernetes operator:\nwls:/offline\u0026gt; connect('weblogic','\u0026lt;password\u0026gt;','t3://\u0026lt;domainUID\u0026gt;-cluster-\u0026lt;Cluster name\u0026gt;:\u0026lt;Managed Server Port\u0026gt;') For example, if the domainUID is soainfra, SOA cluster name is soa-cluster, and SOA Managed Server port is 8011, then you can connect to SOA Cluster using t3:\nwls:/offline\u0026gt; connect('weblogic','\u0026lt;password\u0026gt;','t3://soainfra-cluster-soa-cluster:8011') The output will look similar to the following:\nwls:/offline\u0026gt; connect('weblogic','\u0026lt;password\u0026gt;','t3://soainfra-cluster-soa-cluster:8011') Connecting to t3://soainfra-cluster-soa-cluster:8011 with userid weblogic ... Successfully connected to Managed Server \u0026quot;soa_server1\u0026quot; that belongs to domain \u0026quot;soainfra\u0026quot;. Warning: An insecure protocol was used to connect to the server. To ensure on-the-wire security, the SSL port or Admin port should be used instead. wls:/soainfra/serverConfig/\u0026gt; Connect using t3s.\nIf you enabled SSL with sslEnabled when creating the domain, then you can use t3s to perform WLST operations:\na. Obtain the certificate from the Administration Server to be used for a secured (t3s) connection from the client by exporting the certificate from the Administration Server using WLST commands. Sample commands to export the default demoidentity:\n[oracle@helper oracle]$ cd $ORACLE_HOME/oracle_common/common/bin [oracle@helper bin]$ ./wlst.sh . . wls:/offline\u0026gt; connect('weblogic','\u0026lt;password\u0026gt;','t3://soainfra-adminserver:7011') . . wls:/soainfra/serverConfig/\u0026gt; svc = getOpssService(name='KeyStoreService') wls:/soainfra/serverConfig/\u0026gt; svc.exportKeyStoreCertificate(appStripe='system', name='demoidentity', password='DemoIdentityKeyStorePassPhrase', alias='DemoIdetityKeyStorePassPhrase', type='Certificate', filepath='/tmp/cert.txt/') These commands download the certificate for the default demoidentity certificate at /tmp/cert.txt.\nb. Import the certificate to the Java trust store:\n[oracle@helper oracle]$ export JAVA_HOME=/u01/jdk [oracle@helper oracle]$ keytool -import -v -trustcacerts -alias soadomain -file /tmp/cert.txt -keystore $JAVA_HOME/jre/lib/security/cacerts -keypass changeit -storepass changeit c. Connect to WLST and set the required environment variable before connecting using t3s:\n[oracle@helper oracle]$ export WLST_PROPERTIES=\u0026quot;-Dweblogic.security.SSL.ignoreHostnameVerification=true\u0026quot; [oracle@helper oracle]$ cd $ORACLE_HOME/oracle_common/common/bin [oracle@helper bin]$ ./wlst.sh d. Access t3s for the Administration Server.\nFor example, if the domainUID is soainfra, Administration Server name is AdminServer, and Administration Server SSL port is 7012, connect to the Administration Server as follows:\nwls:/offline\u0026gt; connect('weblogic','\u0026lt;password\u0026gt;','t3s://soainfra-adminserver:7012') e. Access t3s for the SOA cluster.\nFor example, if the domainUID is soainfra, SOA cluster name is soa-cluster, and SOA Managed Server SSL port is 8012, connect to the SOA cluster as follows:\nwls:/offline\u0026gt; connect('weblogic','\u0026lt;password\u0026gt;','t3s://soainfra-cluster-soa-cluster:8012') Script mode In script mode, scripts contain WLST commands in a text file with a .py file extension (for example, mywlst.py). Before invoking WLST using the script file, you must copy the .py file into the helper pod.\nTo copy the .py file into the helper pod using WLST operations in script mode:\n Create a .py file containing all the WLST commands.\n Copy the .py file into the helper pod:\n$ kubectl cp \u0026lt;filename\u0026gt;.py \u0026lt;domain namespace\u0026gt;/helper:\u0026lt;directory\u0026gt; For example:\n$ kubectl cp mywlst.py soans/helper:/u01/oracle Run wlst.sh on the .py file by exec into the helper pod:\n$ kubectl exec -it helper -n \u0026lt;domain_namespace\u0026gt; -- /bin/bash [oracle@helper oracle]$ cd $ORACLE_HOME/oracle_common/common/bin [oracle@helper oracle]$ ./wlst.sh \u0026lt;directory\u0026gt;/\u0026lt;filename\u0026gt;.py Note: Refer to Interactive mode for details on how to connect using t3 or t3s.\nSample WLST operations For a full list of WLST operations, refer to WebLogic Server WLST Online and Offline Command Reference.\nDisplay servers $ kubectl exec -it helper -n soans -- /bin/bash [oracle@helper oracle]$ cd $ORACLE_HOME/oracle_common/common/bin [oracle@helper bin]$ ./wlst.sh Initializing WebLogic Scripting Tool (WLST) ... Jython scans all the jar files it can find at first startup. Depending on the system, this process may take a few minutes to complete, and WLST may not return a prompt right away. Welcome to WebLogic Server Administration Scripting Shell Type help() for help on available commands wls:/offline\u0026gt; connect('weblogic','Welcome1','t3://soainfra-adminserver:7011') Connecting to t3://soainfra-adminserver:7011 with userid weblogic ... Successfully connected to Admin Server \u0026quot;AdminServer\u0026quot; that belongs to domain \u0026quot;soainfra\u0026quot;. Warning: An insecure protocol was used to connect to the server. To ensure on-the-wire security, the SSL port or Admin port should be used instead. wls:/soainfra/serverConfig/\u0026gt; cd('/Servers') wls:/soainfra/serverConfig/Servers\u0026gt; ls() dr-- AdminServer dr-- osb_server1 dr-- osb_server2 dr-- osb_server3 dr-- osb_server4 dr-- osb_server5 dr-- soa_server1 dr-- soa_server2 dr-- soa_server3 dr-- soa_server4 dr-- soa_server5 wls:/soainfra/serverConfig/Servers\u0026gt; "
+},
+{
+ "uri": "/fmw-kubernetes/24.2.2/soa-domains/appendix/",
+ "title": "Appendix",
+ "tags": [],
+ "description": "",
+ "content": "This section provides information on miscellaneous tasks related to Oracle SOA Suite domains deployment on Kubernetes.\n Domain resource sizing Describes the resourse sizing information for Oracle SOA Suite domains setup on Kubernetes cluster.\n Quick start deployment on-premise Describes how to quickly get an Oracle SOA Suite domain instance running (using the defaults, nothing special) for development and test purposes.\n Security hardening Review resources for the Docker and Kubernetes cluster hardening.\n "
+},
+{
+ "uri": "/fmw-kubernetes/24.2.2/soa-domains/troubleshooting/",
+ "title": "Troubleshooting",
+ "tags": [],
+ "description": "Describes common issues that may occur during Oracle SOA Suite deployment on Kubernetes and the steps to troubleshoot them.",
+ "content": "This document describes common issues that may occur during the deployment of Oracle SOA Suite on Kubernetes and the steps to troubleshoot them. Also refer to the FAQs page for frequent issues and steps to resolve them.\n WebLogic Kubernetes Operator installation failure RCU schema creation failure Domain creation failure Common domain creation issues Server pods not started after applying domain configuration file Ingress controller not serving the domain urls Security warnings reported in WebLogic Administration console Disable Remote Anonymous RMI T3 and IIOP Requests Oracle Service Bus OWSM policy error WebLogic Kubernetes Operator installation failure If the WebLogic Kubernetes Operator installation failed with timing out:\n Check the status of the operator Helm release using the command helm ls -n \u0026lt;operator-namespace\u0026gt;. Check if the operator pod is successfully created in the operator namespace. Describe the operator pod using kubectl describe pod \u0026lt;operator-pod-name\u0026gt; -n \u0026lt;operator-namespace\u0026gt; to identify any obvious errors. RCU schema creation failure When creating the RCU schema using create-rcu-schema.sh, the possible causes for RCU schema creation failure are:\n Database is not up and running Incorrect database connection URL used Invalid database credentials used Schema prefix already exists Make sure that all the above causes are reviewed and corrected as needed.\nAlso drop the existing schema with the same prefix before rerunning the create-rcu-schema.sh with correct values.\nDomain creation failure If the Oracle SOA Suite domain creation fails when running create-domain.sh, perform the following steps to diagnose the issue:\n Run the following command to diagnose the create domain job:\n$ kubectl logs jobs/\u0026lt;domain_job\u0026gt; -n \u0026lt;domain_namespace\u0026gt; For example:\n$ kubectl logs jobs/soainfra-create-soa-infra-domain-job -n soans Also run:\n$ kubectl describe pod \u0026lt;domain_job\u0026gt; -n \u0026lt;domain_namespace\u0026gt; For example:\n$ kubectl describe pod soainfra-create-soa-infra-domain-job-mcc6v -n soans Use the output to diagnose the problem and resolve the issue.\n Clean up the failed domain creation:\n Delete the failed domain creation job in the domain namespace using the command kubectl delete job \u0026lt;domain-creation-job-name\u0026gt; -n \u0026lt;domain-namespace\u0026gt;. Delete the contents of the domain home directory Drop the existing RCU schema Recreate the domain:\n Recreate the RCU schema Make sure the Persistent Volume and Persistent Volume Claim used for the domain are created with correct permissions and bound together. Rerun the create domain script Common domain creation issues A common domain creation issue is error Failed to build JDBC Connection object in the create domain job logs.\n Click here to see the error stack trace: Configuring the Service Table DataSource... fmwDatabase jdbc:oracle:thin:@orclcdb.soainfra-domain-ns-293-10202010:1521/orclpdb1 Getting Database Defaults... Error: getDatabaseDefaults() failed. Do dumpStack() to see details. Error: runCmd() failed. Do dumpStack() to see details. Problem invoking WLST - Traceback (innermost last): File \u0026quot;/u01/weblogic/..2021_10_20_20_29_37.256759996/createSOADomain.py\u0026quot;, line 943, in ? File \u0026quot;/u01/weblogic/..2021_10_20_20_29_37.256759996/createSOADomain.py\u0026quot;, line 75, in createSOADomain File \u0026quot;/u01/weblogic/..2021_10_20_20_29_37.256759996/createSOADomain.py\u0026quot;, line 695, in extendSoaB2BDomain File \u0026quot;/u01/weblogic/..2021_10_20_20_29_37.256759996/createSOADomain.py\u0026quot;, line 588, in configureJDBCTemplates File \u0026quot;/tmp/WLSTOfflineIni956349269221112379.py\u0026quot;, line 267, in getDatabaseDefaults File \u0026quot;/tmp/WLSTOfflineIni956349269221112379.py\u0026quot;, line 19, in command Failed to build JDBC Connection object: at com.oracle.cie.domain.script.jython.CommandExceptionHandler.handleException(CommandExceptionHandler.java:69) at com.oracle.cie.domain.script.jython.WLScriptContext.handleException(WLScriptContext.java:3085) at com.oracle.cie.domain.script.jython.WLScriptContext.runCmd(WLScriptContext.java:738) at sun.reflect.GeneratedMethodAccessor152.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) com.oracle.cie.domain.script.jython.WLSTException: com.oracle.cie.domain.script.jython.WLSTException: Got exception when auto configuring the schema component(s) with data obtained from shadow table: Failed to build JDBC Connection object: ERROR: /u01/weblogic/create-domain-script.sh failed. This error is reported when there is an issue with database schema access during domain creation. The possible causes are:\n Incorrect schema name specified in create-domain-inputs.yaml. RCU schema credentials specified in the secret soainfra-rcu-credentials are different from the credentials specified while creating the RCU schema using create-rcu-schema.sh. To resolve these possible causes, check that the schema name and credentials used during the domain creation are the same as when the RCU schema was created.\nServer pods not started after applying domain configuration file When a domain configuration file (YAML) is deployed and no introspector or server pods are initiated, as well as there is no mention of the domain in the operator log, ensure that the domain\u0026rsquo;s namespace has been configured to be managed by WebLogic Kubernetes Operator.\nThe domainNamespaceSelectionStrategy configuration in the operator installation Helm chart determines the namespaces managed by operators. The default value of the domainNamespaceSelectionStrategy Helm chart value was altered between versions 3.4 and 4.0. In version 3.4, the default value was List and in version 4.0, the default value is LabelSelector. Therefore, instead of managing the set of namespaces listed in the domainNamespaces Helm chart value, the operator now searches for namespaces with the label specified in the domainNamespaceLabelSelector Helm chart value, which defaults to weblogic-operator=enabled.\nFor operator versions 3.4 and lower, you can verify the configuration by running the command helm get values \u0026lt;operator-release\u0026gt; -n \u0026lt;operator-namespace\u0026gt; and checking the values under the domainNamespaces section.\nFor example:\n$ helm get values weblogic-kubernetes-operator -n opns USER-SUPPLIED VALUES: domainNamespaces: - soans image: ghcr.io/oracle/weblogic-kubernetes-operator:3.4.4 javaLoggingLevel: FINE serviceAccount: op-sa $ If you don\u0026rsquo;t see the domain namespace value under the domainNamespaces section, run the helm upgrade command in the operator namespace with appropriate values to configure the operator to manage the domain namespace.\n$ helm upgrade --reuse-values --namespace opns --set \u0026quot;domainNamespaces={soans}\u0026quot; --wait weblogic-kubernetes-operator charts/weblogic-operator For operator versions 4.0 and higher, verify if the label weblogic-operator=enabled is specified for domain namespace that is to be managed by the operator, by running the following command:\n$ kubectl get ns --selector=\u0026quot;weblogic-operator=enabled\u0026quot; For example, if your domain namespace is soans and the preceding command did not list the soans namespace, then execute the following command for operator to manage the domain namespace:\n$ kubectl label namespace soans weblogic-operator=enabled Ingress controller not serving the domain URLs To diagnose this issue:\n Verify that the Ingress controller is installed successfully.\nFor example, to verify the Traefik Ingress controller status, run the following command: $ helm list -n traefik NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION traefik traefik 2 2022-11-30 11:31:18.599876918 +0000 UTC deployed traefik-20.5.3 v2.9.5 $ Verify that the Ingress controller is setup to monitor the domain namespace.\nFor example, to verify the Traefik Ingress controller manages the soans domain namespace, run the following command and check the values under namespaces section. $ helm get values traefik-operator -n traefik USER-SUPPLIED VALUES: kubernetes: namespaces: - traefik - soans $ Verify that the Ingress chart is installed correctly in domain namespace. For example, run the following command: $ helm list -n soans NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION soainfra-traefik soans 1 2021-10-27 11:24:31.7572791 +0000 UTC deployed ingress-per-domain-0.1.0 1.0 $ Verify that the Ingress URL paths and hostnames are configured correctly by running the following commands: Click here to see the sample commands and output $ kubectl get ingress soainfra-traefik -n soans NAME CLASS HOSTS ADDRESS PORTS AGE soainfra-traefik \u0026lt;none\u0026gt; \u0026lt;Hostname\u0026gt; 80 20h $ $ kubectl describe ingress soainfra-traefik -n soans Name: soainfra-traefik Namespace: soans Address: Default backend: default-http-backend:80 (\u0026lt;error: endpoints \u0026quot;default-http-backend\u0026quot; not found\u0026gt;) Rules: Host Path Backends ---- ---- -------- \u0026lt;Hostname\u0026gt; /console soainfra-adminserver:7011 (10.244.0.123:7011) /em soainfra-adminserver:7011 (10.244.0.123:7011) /weblogic/ready soainfra-adminserver:7011 (10.244.0.123:7011) /soa-infra soainfra-cluster-soa-cluster:8011 (10.244.0.126:8011,10.244.0.127:8011) /soa/composer soainfra-cluster-soa-cluster:8011 (10.244.0.126:8011,10.244.0.127:8011) /integration/worklistapp soainfra-cluster-soa-cluster:8011 (10.244.0.126:8011,10.244.0.127:8011) /EssHealthCheck soainfra-cluster-soa-cluster:8011 (10.244.0.126:8011,10.244.0.127:8011) Annotations: kubernetes.io/ingress.class: traefik meta.helm.sh/release-name: soainfra-traefik meta.helm.sh/release-namespace: soans Events: \u0026lt;none\u0026gt; $ Security warnings reported in WebLogic Administration console With the July 2021 PSU applied, WebLogic Server regularly validates your domain configuration settings against a set of security configuration guidelines to determine whether the domain meets key security guidelines recommended by Oracle. If your domain does not meet a recommendation for a security configuration setting, a warning is logged in the Security Warnings Report in the WebLogic Administration Console.\nSee Review Potential Security Issues in Securing a Production Environment for Oracle WebLogic Server for more information.\nDisable Remote Anonymous RMI T3 and IIOP Requests If you see security warning message that Remote Anonymous RMI T3 or IIOP requests are enabled, resolve this warning by setting RemoteAnonymousRMIT3Enabled and RemoteAnonymousRMIIIOPEnabled attributes to false in domain.yaml with JAVA_OPTIONS before starting the domain as shown below:\nserverPod: # an (optional) list of environment variable to be set on the servers env: - name: JAVA_OPTIONS value: \u0026quot;-Dweblogic.StdoutDebugEnabled=false -Dweblogic.ssl.Enabled=true -Dweblogic.security.SSL.ignoreHostnameVerification=true -Dweblogic.security.remoteAnonymousRMIT3Enabled=false -Dweblogic.security.remoteAnonymousRMIIIOPEnabled=false\u0026quot; See link for more details.\nOracle Service Bus OWSM policy error If you see error messages like CannotCommit [OSB-387177]OWSM Policy oracle/xxxxxx is not supported on Oracle Service Bus console and exceptions like oracle.wsm.policymanager.PolicyManagerException: WSM-02141 : Unable to connect to the policy access service due to Oracle WSM policy manager host server being down in Administration server logs, resolve this error by targeting the wsm-pm application to Administration server. See link for details.\n"
+},
+{
+ "uri": "/fmw-kubernetes/24.2.2/categories/",
+ "title": "Categories",
+ "tags": [],
+ "description": "",
+ "content": ""
+},
+{
+ "uri": "/fmw-kubernetes/24.2.2/tags/",
+ "title": "Tags",
+ "tags": [],
+ "description": "",
+ "content": ""
+}]
\ No newline at end of file
diff --git a/24.2.2/index.xml b/24.2.2/index.xml
new file mode 100644
index 000000000..d45eb6cc5
--- /dev/null
+++ b/24.2.2/index.xml
@@ -0,0 +1,257 @@
+
+
+
+ Oracle Fusion Middleware on Kubernetes
+ /fmw-kubernetes/24.2.2/
+ Recent content on Oracle Fusion Middleware on Kubernetes
+ Hugo -- gohugo.io
+ en-us
+ Thu, 18 Apr 2019 06:46:23 -0500
+
+
+
+
+
+ Topology
+ /fmw-kubernetes/24.2.2/soa-domains/edg-guide/topology/
+ Wed, 22 Jun 2022 15:44:42 -0500
+
+ /fmw-kubernetes/24.2.2/soa-domains/edg-guide/topology/
+ Assumptions The most relevant assumptions for the Oracle SOA Suite Kubernetes Enterprise Deployment Guide (EDG) topology are related to the database and web tiers. Typical on-premises production systems keep their high end database (such as RAC, RAC+DG, Exadata, Autonomous Database) out of the Kubernetes cluster and manage that tier separately. This implies that the database runs separately from the Kubernetes cluster hosting the application tier. The database provisioning and configuration process is out of the scope of the Oracle SOA Suite Kubernetes setup.
+
+
+
+ Release Notes
+ /fmw-kubernetes/24.2.2/soa-domains/release-notes/
+ Fri, 15 Mar 2019 11:25:28 -0400
+
+ /fmw-kubernetes/24.2.2/soa-domains/release-notes/
+ Review the latest changes and known issues for Oracle SOA Suite on Kubernetes.
+Recent changes Date Version Change May 31, 2024 24.2.2 Supports Oracle SOA Suite 12.2.1.4 domains deployment using April 2024 PSU and known bug fixes. Support for WebLogic Kubernetes Operator 4.2.2. Oracle SOA Suite 12.2.1.4 Docker image for this release can be downloaded from My Oracle Support (MOS patch 36568531 for Oracle Linux 7 and MOS patch 36568606 for Oracle Linux 8) and container-registry.
+
+
+
+ Deploy using JDeveloper
+ /fmw-kubernetes/24.2.2/soa-domains/adminguide/deploying-composites/supportjdev/
+ Fri, 22 Feb 2019 15:44:42 -0500
+
+ /fmw-kubernetes/24.2.2/soa-domains/adminguide/deploying-composites/supportjdev/
+ Learn how to deploy Oracle SOA Suite and Oracle Service Bus composite applications from Oracle JDeveloper (running outside the Kubernetes network) to an Oracle SOA Suite instance in the WebLogic Kubernetes Operator environment.
+Use JDeveloper for development and test environments only. For a production environment, you should deploy using Application Control and WLST methods.
+ Deploy Oracle SOA Suite and Oracle Service Bus composite applications to Oracle SOA Suite from JDeveloper To deploy Oracle SOA Suite and Oracle Service Bus composite applications from Oracle JDeveloper, the Administration Server must be configured to expose a T3 channel.
+
+
+
+ Domain resource sizing
+ /fmw-kubernetes/24.2.2/soa-domains/appendix/soa-cluster-sizing-info/
+ Fri, 22 Feb 2019 15:44:42 -0500
+
+ /fmw-kubernetes/24.2.2/soa-domains/appendix/soa-cluster-sizing-info/
+ Oracle SOA cluster sizing minimum requirements Oracle SOA Normal Usage Moderate Usage High Usage Administration Server No of CPU core(s) : 1, Memory : 4GB No of CPU core(s) : 1, Memory : 4GB No of CPU core(s) : 1, Memory : 4GB Number of Managed Servers 2 2 4 Configurations per Managed Server No of CPU core(s) : 2, Memory : 16GB No of CPU core(s) : 4, Memory : 16GB No of CPU core(s) : 6, Memory : 16-32GB PV Storage Minimum 250GB Minimum 250GB Minimum 500GB
+
+
+
+ Patch an image
+ /fmw-kubernetes/24.2.2/soa-domains/patch_and_upgrade/patch-an-image/
+ Fri, 22 Feb 2019 15:44:42 -0500
+
+ /fmw-kubernetes/24.2.2/soa-domains/patch_and_upgrade/patch-an-image/
+ Oracle releases Oracle SOA Suite images regularly with the latest bundle and recommended interim patches in My Oracle Support (MOS). However, if you need to create images with new bundle and interim patches, you can build these images using the WebLogic Image Tool.
+If you have access to the Oracle SOA Suite patches, you can patch an existing Oracle SOA Suite image with a bundle patch and interim patches. Oracle recommends that you use the WebLogic Image Tool to patch the Oracle SOA Suite image.
+
+
+
+ Traefik
+ /fmw-kubernetes/24.2.2/soa-domains/adminguide/configure-load-balancer/traefik/
+ Fri, 22 Feb 2019 15:44:42 -0500
+
+ /fmw-kubernetes/24.2.2/soa-domains/adminguide/configure-load-balancer/traefik/
+ This section provides information about how to install and configure the ingress-based Traefik load balancer (version 2.2.1 or later for production deployments) to load balance Oracle SOA Suite domain clusters. You can configure Traefik for non-SSL, SSL termination, and end-to-end SSL access of the application URL.
+Follow these steps to set up Traefik as a load balancer for an Oracle SOA Suite domain in a Kubernetes cluster:
+ Install the Traefik (ingress-based) load balancer Create an Ingress for the domain Verify domain application URL access Uninstall the Traefik ingress Uninstall Traefik Install the Traefik (ingress-based) load balancer Use Helm to install the Traefik (ingress-based) load balancer.
+
+
+
+ Setup steps
+ /fmw-kubernetes/24.2.2/soa-domains/edg-guide/setup-edg/
+ Wed, 22 Jun 2022 15:44:42 -0500
+
+ /fmw-kubernetes/24.2.2/soa-domains/edg-guide/setup-edg/
+ This section provides recommended steps to set up Oracle SOA Suite enterprise deployment on Kubernetes to eliminate single points of failure and to provide high availability.
+ Set up your Kubernetes cluster Prepare the environment Configure firewalls and network Load Oracle SOA Suite images on all the worker nodes Enable a shared storage location for the persistent volume Create a database and the appropriate database services Install and configure Oracle HTTP Server in the DMZ Configure a front-end load balancer Create worker nodes Apply operating system changes for Coherence Deploy WebLogic Kubernetes Operator and Oracle SOA Suite Configure redundant persistent volume Configure the required priority for mounts Set front-end addresses Enable FAN for GridLink data sources Configure ASM Configure coredns allocation Adjust server’s pods Liveness Probe Set up your Kubernetes cluster Prepare the environment for the Kubernetes control plane (Master nodes) Create the L4/TCP listener for the load balancer (LBR).
+
+
+
+ Quick start deployment on-premise
+ /fmw-kubernetes/24.2.2/soa-domains/appendix/quickstart-deployment-on-prem/
+ Thu, 18 Jun 2020 15:27:38 -0500
+
+ /fmw-kubernetes/24.2.2/soa-domains/appendix/quickstart-deployment-on-prem/
+ Use this Quick Start to create an Oracle SOA Suite domain deployment in a Kubernetes cluster (on-premise environments) with the WebLogic Kubernetes Operator. Note that this walkthrough is for demonstration purposes only, not for use in production. These instructions assume that you are already familiar with Kubernetes. If you need more detailed instructions, refer to the Install Guide.
+Hardware requirements The Linux kernel supported for deploying and running Oracle SOA Suite domains with the operator is Oracle Linux 8 and Red Hat Enterprise Linux 8.
+
+
+
+ Deploy using Maven and Ant
+ /fmw-kubernetes/24.2.2/soa-domains/adminguide/deploying-composites/deploy-using-maven-ant/
+ Fri, 22 Feb 2019 15:44:42 -0500
+
+ /fmw-kubernetes/24.2.2/soa-domains/adminguide/deploying-composites/deploy-using-maven-ant/
+ Learn how to deploy Oracle SOA Suite and Oracle Service Bus composite applications using the Maven and Ant based approach in an Oracle SOA Suite in WebLogic Kubernetes Operator environment.
+Before deploying composite applications, we need to create a Kubernetes pod in the same cluster where the Oracle SOA Suite domain is running, so that composite applications can be deployed using the internal Kubernetes Service for the Administration Server URL.
+
+
+
+ Enable additional URL access
+ /fmw-kubernetes/24.2.2/soa-domains/adminguide/enable-additional-url-access/
+ Fri, 22 Feb 2019 15:44:42 -0500
+
+ /fmw-kubernetes/24.2.2/soa-domains/adminguide/enable-additional-url-access/
+ This section provides information about how to extend an existing ingress (Non-SSL and SSL termination) to enable additional application URL access for Oracle SOA Suite domains.
+The ingress per domain created in the steps in Set up a load balancer exposes the application paths defined in template YAML files present at ${WORKDIR}/charts/ingress-per-domain/templates/.
+To extend an existing ingress with additional application URL access:
+ Update the template YAML file at ${WORKDIR}/charts/ingress-per-domain/templates/ to define additional path rules.
+
+
+
+ NGINX
+ /fmw-kubernetes/24.2.2/soa-domains/adminguide/configure-load-balancer/nginx/
+ Fri, 22 Feb 2019 15:44:42 -0500
+
+ /fmw-kubernetes/24.2.2/soa-domains/adminguide/configure-load-balancer/nginx/
+ This section provides information about how to install and configure the ingress-based NGINX load balancer to load balance Oracle SOA Suite domain clusters. You can configure NGINX for non-SSL, SSL termination, and end-to-end SSL access of the application URL.
+Follow these steps to set up NGINX as a load balancer for an Oracle SOA Suite domain in a Kubernetes cluster:
+See the official installation document for prerequisites.
+ Install the NGINX load balancer for non-SSL and SSL termination configuration Generate secret for SSL access Install NGINX load balancer for end-to-end SSL configuration Configure NGINX to manage ingresses Verify domain application URL access Uninstall NGINX ingress Uninstall NGINX To get repository information, enter the following Helm commands:
+
+
+
+ Upgrade an operator release
+ /fmw-kubernetes/24.2.2/soa-domains/patch_and_upgrade/upgrade-operator-release/
+ Fri, 22 Feb 2019 15:44:42 -0500
+
+ /fmw-kubernetes/24.2.2/soa-domains/patch_and_upgrade/upgrade-operator-release/
+ To upgrade the WebLogic Kubernetes operator, use the helm upgrade command with new Helm chart and operator image. See the steps here to pull the operator image and set up the Oracle SOA Suite repository that contains the operator chart. To upgrade the operator run the following command:
+$ cd ${WORKDIR} $ helm upgrade \ --reuse-values \ --set image=ghcr.io/oracle/weblogic-kubernetes-operator:4.1.7 \ --namespace weblogic-operator-namespace \ --wait \ weblogic-kubernetes-operator \ charts/weblogic-operator Note: When the WebLogic Kubernetes Operator is upgraded from release version 3.
+
+
+
+ Deploy using composites in a persistent volume or image
+ /fmw-kubernetes/24.2.2/soa-domains/adminguide/deploying-composites/deploy-artifacts/
+ Tue, 19 Oct 2021 12:04:42 -0500
+
+ /fmw-kubernetes/24.2.2/soa-domains/adminguide/deploying-composites/deploy-artifacts/
+ Learn how to deploy Oracle SOA Suite and Oracle Service Bus composite applications artifacts in a Kubernetes persistent volume or in an image to an Oracle SOA Suite environment deployed using a WebLogic Kubernetes Operator.
+The deployment methods described in Deploy using JDeveloper and Deploy using Maven and Ant are manual processes. If you have the deployment artifacts (archives) already built, then you can package them either into a Kubernetes persistent volume or in an image and use this automated process to deploy the artifacts to an Oracle SOA Suite domain.
+
+
+
+ Apache web tier
+ /fmw-kubernetes/24.2.2/soa-domains/adminguide/configure-load-balancer/apache/
+ Fri, 22 Feb 2019 15:44:42 -0500
+
+ /fmw-kubernetes/24.2.2/soa-domains/adminguide/configure-load-balancer/apache/
+ This section provides information about how to install and configure the Apache web tier to load balance Oracle SOA Suite domain clusters. You can configure Apache web tier for non-SSL and SSL termination access of the application URL.
+Follow these steps to set up the Apache web tier as a load balancer for an Oracle SOA Suite domain in a Kubernetes cluster:
+ Build the Apache web tier image Create the Apache plugin configuration file Prepare the certificate and private key Install the Apache web tier Helm chart Verify domain application URL access Uninstall Apache web tier Build the Apache web tier image Refer to the sample, to build the Apache web tier Docker image.
+
+
+
+ Configure SSL certificates
+ /fmw-kubernetes/24.2.2/soa-domains/adminguide/configuring-custom-ssl-certificates/
+ Fri, 22 Feb 2019 15:44:42 -0500
+
+ /fmw-kubernetes/24.2.2/soa-domains/adminguide/configuring-custom-ssl-certificates/
+ Secure Socket Layer (SSL) provides a secured communication for data sent over unsecured networks. In an SSL termination scenario, you can configure SSL between the client browser and the load balancer in your Oracle SOA Suite instance to ensure that applications are accessed securely. In an SSL end-to-end scenario, an Oracle SOA Suite domain is configured to use a self-signed SSL certificate that was generated during domain creation. Clients will typically receive a message indicating that the signing CA for the certificate is unknown and not trusted.
+
+
+
+ Security hardening
+ /fmw-kubernetes/24.2.2/soa-domains/appendix/docker-k8s-hardening/
+ Fri, 22 Feb 2019 15:44:42 -0500
+
+ /fmw-kubernetes/24.2.2/soa-domains/appendix/docker-k8s-hardening/
+ Securing a Kubernetes cluster involves hardening on multiple fronts - securing the API servers, etcd, nodes, container images, container run-time, and the cluster network. Apply principles of defense in depth, principle of least privilege, and minimize the attack surface. Use security tools such as Kube-Bench to verify the cluster’s security posture. Since Kubernetes is evolving rapidly refer to Kubernetes Security Overview for the latest information on securing a Kubernetes cluster. Also ensure the deployed Docker containers follow the Docker Security guidance.
+
+
+
+ Upgrade a Kubernetes cluster
+ /fmw-kubernetes/24.2.2/soa-domains/patch_and_upgrade/upgrade-k8s-cluster/
+ Fri, 22 Feb 2019 15:44:42 -0500
+
+ /fmw-kubernetes/24.2.2/soa-domains/patch_and_upgrade/upgrade-k8s-cluster/
+ These instructions describe how to upgrade a Kubernetes cluster created using kubeadm on which an Oracle SOA Suite domain is deployed. A rolling upgrade approach is used to upgrade nodes (master and worker) of the Kubernetes cluster.
+It is expected that there will be a down time during the upgrade of the Kubernetes cluster as the nodes need to be drained as part of the upgrade process.
+ Prerequisites Review Prerequisites and ensure that your Kubernetes cluster is ready for upgrade.
+
+
+
+ Monitor a domain and publish logs
+ /fmw-kubernetes/24.2.2/soa-domains/adminguide/monitoring-soa-domains/
+ Fri, 22 Feb 2019 15:44:42 -0500
+
+ /fmw-kubernetes/24.2.2/soa-domains/adminguide/monitoring-soa-domains/
+ After the Oracle SOA Suite domain is set up, you can:
+ Monitor the Oracle SOA Suite instance using Prometheus and Grafana Publish WebLogic Server logs into Elasticsearch Publish SOA server diagnostics logs into Elasticsearch Monitor the Oracle SOA Suite instance using Prometheus and Grafana Using the WebLogic Monitoring Exporter you can scrape runtime information from a running Oracle SOA Suite instance and monitor them using Prometheus and Grafana.
+
+
+
+ Expose the T3/T3S protocol
+ /fmw-kubernetes/24.2.2/soa-domains/adminguide/enablingt3/
+ Fri, 22 Feb 2019 15:44:42 -0500
+
+ /fmw-kubernetes/24.2.2/soa-domains/adminguide/enablingt3/
+ Oracle strongly recommends that you do not expose non-HTTPS traffic (T3/T3s/LDAP/IIOP/IIOPs) outside of the external firewall. You can control this access using a combination of network channels and firewalls.
+ You can create T3/T3S channels and the corresponding Kubernetes service to expose the T3/T3S protocol for the Administration Server and Managed Servers in an Oracle SOA Suite domain.
+The WebLogic Kubernetes Operator provides an option to expose a T3 channel for the Administration Server using the exposeAdminT3Channel setting during domain creation, then the matching T3 service can be used to connect.
+
+
+
+ Uninstall
+ /fmw-kubernetes/24.2.2/soa-domains/cleanup-domain-setup/
+ Fri, 22 Feb 2019 15:44:42 -0500
+
+ /fmw-kubernetes/24.2.2/soa-domains/cleanup-domain-setup/
+ Learn how to clean up the Oracle SOA Suite domain setup.
+Remove the domain Remove the domain’s ingress (for example, Traefik ingress) using Helm:
+$ helm uninstall soa-domain-ingress -n sample-domain1-ns For example:
+$ helm uninstall soainfra-traefik -n soans Remove the domain resources by using the sample delete-weblogic-domain-resources.sh script present at ${WORKDIR}/delete-domain:
+$ cd ${WORKDIR}/delete-domain $ ./delete-weblogic-domain-resources.sh -d sample-domain1 For example:
+$ cd ${WORKDIR}/delete-domain $ ./delete-weblogic-domain-resources.sh -d soainfra Use kubectl to confirm that the server pods and domain resource are deleted:
+
+
+
+ Persist adapter customizations
+ /fmw-kubernetes/24.2.2/soa-domains/adminguide/persisting-soa-adapters-customizations/
+ Fri, 22 Feb 2019 15:44:42 -0500
+
+ /fmw-kubernetes/24.2.2/soa-domains/adminguide/persisting-soa-adapters-customizations/
+ The lifetime for any customization done in a file on a server pod is up to the lifetime of that pod. The changes are not persisted once the pod goes down or is restarted.
+For example, the following configuration updates DbAdapter.rar to create a new connection instance and creates data source CoffeeShop on the Administration Console for the same with jdbc/CoffeeShopDS.
+File location: /u01/oracle/soa/soa/connectors/DbAdapter.rar
+<connection-instance> <jndi-name>eis/DB/CoffeeShop</jndi-name> <connection-properties> <properties> <property> <name>XADataSourceName</name> <value>jdbc/CoffeeShopDS</value> </property> <property> <name>DataSourceName</name> <value></value> </property> <property> <name>PlatformClassName</name> <value>org.
+
+
+
+ Frequently Asked Questions
+ /fmw-kubernetes/24.2.2/soa-domains/faq/
+ Fri, 22 Feb 2019 15:44:42 -0500
+
+ /fmw-kubernetes/24.2.2/soa-domains/faq/
+ Overriding tuning parameters is not supported using configuration overrides The WebLogic Kubernetes Operator enables you to override some of the domain configuration using configuration overrides (also called situational configuration). See supported overrides. Overriding the tuning parameters such as MaxMessageSize and PAYLOAD, for Oracle SOA Suite domains is not supported using the configuration overrides feature. However, you can override them using the following steps:
+ Specify the new value using the environment variable K8S_REFCONF_OVERRIDES in serverPod.
+
+
+
+ Perform WLST operations
+ /fmw-kubernetes/24.2.2/soa-domains/adminguide/performing-wlst-operations/
+ Fri, 22 Feb 2019 15:44:42 -0500
+
+ /fmw-kubernetes/24.2.2/soa-domains/adminguide/performing-wlst-operations/
+ You can use the WebLogic Scripting Tool (WLST) to manage a domain running in a Kubernetes cluster. Some of the many ways to do this are provided here.
+If the Administration Server was configured to expose a T3 channel using exposeAdminT3Channel when creating the domain, refer to Use WLST.
+If you do not want to expose additional ports and perform WLST administration operations using the existing Kubernetes services created by the WebLogic Server Kubernetes operator, then follow this documentation.
+
+
+
+
\ No newline at end of file
diff --git a/24.2.2/js/auto-complete.js b/24.2.2/js/auto-complete.js
new file mode 100644
index 000000000..7fbde995e
--- /dev/null
+++ b/24.2.2/js/auto-complete.js
@@ -0,0 +1,223 @@
+/*
+ JavaScript autoComplete v1.0.4
+ Copyright (c) 2014 Simon Steinberger / Pixabay
+ GitHub: https://github.com/Pixabay/JavaScript-autoComplete
+ License: http://www.opensource.org/licenses/mit-license.php
+*/
+
+var autoComplete = (function(){
+ // "use strict";
+ function autoComplete(options){
+ if (!document.querySelector) return;
+
+ // helpers
+ function hasClass(el, className){ return el.classList ? el.classList.contains(className) : new RegExp('\\b'+ className+'\\b').test(el.className); }
+
+ function addEvent(el, type, handler){
+ if (el.attachEvent) el.attachEvent('on'+type, handler); else el.addEventListener(type, handler);
+ }
+ function removeEvent(el, type, handler){
+ // if (el.removeEventListener) not working in IE11
+ if (el.detachEvent) el.detachEvent('on'+type, handler); else el.removeEventListener(type, handler);
+ }
+ function live(elClass, event, cb, context){
+ addEvent(context || document, event, function(e){
+ var found, el = e.target || e.srcElement;
+ while (el && !(found = hasClass(el, elClass))) el = el.parentElement;
+ if (found) cb.call(el, e);
+ });
+ }
+
+ var o = {
+ selector: 0,
+ source: 0,
+ minChars: 3,
+ delay: 150,
+ offsetLeft: 0,
+ offsetTop: 1,
+ cache: 1,
+ menuClass: '',
+ renderItem: function (item, search){
+ // escape special characters
+ search = search.replace(/[-\/\\^$*+?.()|[\]{}]/g, '\\$&');
+ var re = new RegExp("(" + search.split(' ').join('|') + ")", "gi");
+ return '
' + item.replace(re, "$1") + '
';
+ },
+ onSelect: function(e, term, item){}
+ };
+ for (var k in options) { if (options.hasOwnProperty(k)) o[k] = options[k]; }
+
+ // init
+ var elems = typeof o.selector == 'object' ? [o.selector] : document.querySelectorAll(o.selector);
+ for (var i=0; i 0)
+ that.sc.scrollTop = selTop + that.sc.suggestionHeight + scrTop - that.sc.maxHeight;
+ else if (selTop < 0)
+ that.sc.scrollTop = selTop + scrTop;
+ }
+ }
+ }
+ addEvent(window, 'resize', that.updateSC);
+ document.body.appendChild(that.sc);
+
+ live('autocomplete-suggestion', 'mouseleave', function(e){
+ var sel = that.sc.querySelector('.autocomplete-suggestion.selected');
+ if (sel) setTimeout(function(){ sel.className = sel.className.replace('selected', ''); }, 20);
+ }, that.sc);
+
+ live('autocomplete-suggestion', 'mouseover', function(e){
+ var sel = that.sc.querySelector('.autocomplete-suggestion.selected');
+ if (sel) sel.className = sel.className.replace('selected', '');
+ this.className += ' selected';
+ }, that.sc);
+
+ live('autocomplete-suggestion', 'mousedown', function(e){
+ if (hasClass(this, 'autocomplete-suggestion')) { // else outside click
+ var v = this.getAttribute('data-val');
+ that.value = v;
+ o.onSelect(e, v, this);
+ that.sc.style.display = 'none';
+ }
+ }, that.sc);
+
+ that.blurHandler = function(){
+ try { var over_sb = document.querySelector('.autocomplete-suggestions:hover'); } catch(e){ var over_sb = 0; }
+ if (!over_sb) {
+ that.last_val = that.value;
+ that.sc.style.display = 'none';
+ setTimeout(function(){ that.sc.style.display = 'none'; }, 350); // hide suggestions on fast input
+ } else if (that !== document.activeElement) setTimeout(function(){ that.focus(); }, 20);
+ };
+ addEvent(that, 'blur', that.blurHandler);
+
+ var suggest = function(data){
+ var val = that.value;
+ that.cache[val] = data;
+ if (data.length && val.length >= o.minChars) {
+ var s = '';
+ for (var i=0;i 40) && key != 13 && key != 27) {
+ var val = that.value;
+ if (val.length >= o.minChars) {
+ if (val != that.last_val) {
+ that.last_val = val;
+ clearTimeout(that.timer);
+ if (o.cache) {
+ if (val in that.cache) { suggest(that.cache[val]); return; }
+ // no requests if previous suggestions were empty
+ for (var i=1; i https://github.com/noelboss/featherlight/issues/317
+!function(u){"use strict";if(void 0!==u)if(u.fn.jquery.match(/-ajax/))"console"in window&&window.console.info("Featherlight needs regular jQuery, not the slim version.");else{var r=[],i=function(t){return r=u.grep(r,function(e){return e!==t&&0','
','",'
'+n.loading+"
","
",""].join("")),o="."+n.namespace+"-close"+(n.otherClose?","+n.otherClose:"");return n.$instance=i.clone().addClass(n.variant),n.$instance.on(n.closeTrigger+"."+n.namespace,function(e){if(!e.isDefaultPrevented()){var t=u(e.target);("background"===n.closeOnClick&&t.is("."+n.namespace)||"anywhere"===n.closeOnClick||t.closest(o).length)&&(n.close(e),e.preventDefault())}}),this},getContent:function(){if(!1!==this.persist&&this.$content)return this.$content;var t=this,e=this.constructor.contentFilters,n=function(e){return t.$currentTarget&&t.$currentTarget.attr(e)},r=n(t.targetAttr),i=t.target||r||"",o=e[t.type];if(!o&&i in e&&(o=e[i],i=t.target&&r),i=i||n("href")||"",!o)for(var a in e)t[a]&&(o=e[a],i=t[a]);if(!o){var s=i;if(i=null,u.each(t.contentFilters,function(){return(o=e[this]).test&&(i=o.test(s)),!i&&o.regex&&s.match&&s.match(o.regex)&&(i=s),!i}),!i)return"console"in window&&window.console.error("Featherlight: no content filter found "+(s?' for "'+s+'"':" (no target specified)")),!1}return o.process.call(t,i)},setContent:function(e){return this.$instance.removeClass(this.namespace+"-loading"),this.$instance.toggleClass(this.namespace+"-iframe",e.is("iframe")),this.$instance.find("."+this.namespace+"-inner").not(e).slice(1).remove().end().replaceWith(u.contains(this.$instance[0],e[0])?"":e),this.$content=e.addClass(this.namespace+"-inner"),this},open:function(t){var n=this;if(n.$instance.hide().appendTo(n.root),!(t&&t.isDefaultPrevented()||!1===n.beforeOpen(t))){t&&t.preventDefault();var e=n.getContent();if(e)return r.push(n),s(!0),n.$instance.fadeIn(n.openSpeed),n.beforeContent(t),u.when(e).always(function(e){n.setContent(e),n.afterContent(t)}).then(n.$instance.promise()).done(function(){n.afterOpen(t)})}return n.$instance.detach(),u.Deferred().reject().promise()},close:function(e){var t=this,n=u.Deferred();return!1===t.beforeClose(e)?n.reject():(0===i(t).length&&s(!1),t.$instance.fadeOut(t.closeSpeed,function(){t.$instance.detach(),t.afterClose(e),n.resolve()})),n.promise()},resize:function(e,t){if(e&&t&&(this.$content.css("width","").css("height",""),this.$content.parent().width()');return n.onload=function(){r.naturalWidth=n.width,r.naturalHeight=n.height,t.resolve(r)},n.onerror=function(){t.reject(r)},n.src=e,t.promise()}},html:{regex:/^\s*<[\w!][^<]*>/,process:function(e){return u(e)}},ajax:{regex:/./,process:function(e){var n=u.Deferred(),r=u("").load(e,function(e,t){"error"!==t&&n.resolve(r.contents()),n.fail()});return n.promise()}},iframe:{process:function(e){var t=new u.Deferred,n=u(""),r=function(e,t){var n={},r=new RegExp("^"+t+"([A-Z])(.*)");for(var i in e){var o=i.match(r);o&&(n[(o[1]+o[2].replace(/([A-Z])/g,"-$1")).toLowerCase()]=e[i])}return n}(this,"iframe"),i=function(e,t){var n={};for(var r in e)r in t&&(n[r]=e[r],delete e[r]);return n}(r,o);return n.hide().attr("src",e).attr(i).css(r).on("load",function(){t.resolve(n.show())}).appendTo(this.$instance.find("."+this.namespace+"-content")),t.promise()}},text:{process:function(e){return u("
