If a WebLogic EJB or JMS resource is located in the same Kubernetes namespace as an application that calls the resource, then:
No additional configuration steps are needed.
The URL that the application specifies depends on both the location of the application and the location of its target resource.
If the application is running in a WebLogic Server JVM, and the JVM hosts the target resource or the JVM is located within the same WebLogic cluster as the target resource, then the application can simply specify the JNDI name of the resource and it should not specify a URL.
If the application is running outside of one of the previously listed locations,
but is still in the same Kubernetes namespace as the target resource,
then, in addition to a JNDI name, the application must also specify a t3
or t3s URL that includes the DNS name of the target
resource’s Kubernetes ClusterIP service. To see the service DNS names
for a deployed domain, run kubectl -n MYNS get services.
Example URLs:
For a target resource that’s hosted anywhere
in WebLogic cluster mycluster
with domain UID myuid where the cluster is listening
on port 7001:
t3://myuid-cluster-mycluster:7001
For a target resource that’s hosted in a non-clustered
WebLogic Server myserver that is part
of a domain with a domain UID myuid where the server
is listening on port 7001:
t3://myuid-myserver:7001
If a WebLogic EJB or JMS resource is located in the same Kubernetes cluster as an application that calls the resource, but the application and resource are in different Kubernetes namespaces, then:
The URL used by the application can begin with t3 or t3s, and the
DNS address in the URL must be fully specified to differentiate the namespace.
For example:
mycluster with
domain UID myuid in namespace myns, and the cluster is
listening on port 8001, then the cluster service name
that is generated by the operator will
be myuid-cluster-mycluster and the full URL will be
t3://myuid-cluster-mycluster.myns:8001.myserver with
domain UID myuid in namespace myns, and the server is
listening on port 7001, then the server service name
that is generated by the operator will
be myuid-myserver and the full URL will be
t3://myuid-myserver.myns:7001.The applications should access their target WebLogic Server or cluster using a WebLogic custom T3 or T3S channel that is configured on the target with the following configuration:
mycluster that
is part of domain with a domain UID myuid running in domain
myns, then
the cluster service name will be myuid-cluster-mycluster
and the fully decorated name will be
myuid-cluster-mycluster.myns.myserver that
is part of domain with a domain UID myuid running in domain
myns, then
the server service name will be myuid-myserver
and the fully decorated name will be
myuid-myserver.myns.outbound enabled.t3 or t3s.
Application URLs must specify the channel’s port.If the applications run within a WebLogic Server JVM, then the WebLogic Server instances that host the target EJB or JMS resources may need to be configured to enable unknown host access. This should not be needed when the public address on the network channel is configured, as directed in the previous bulleted item.
If JTA transactions span between domains
in different namespaces, then additional configuration
is required to ensure that JTA transaction managers
can communicate with each-other between the domains:
configure each server’s default channel External Listen Address
to a service name that is decorated with the server’s namespace.
For more information, see Configuring external listen addresses for WebLogic default channels.
If a WebLogic EJB or JMS resource is hosted inside a Kubernetes cluster, but an application that calls the resource is hosted outside of the Kubernetes cluster, then:
There are two supported approaches for exposing an external address and port that the applications can use:
NodePortsThe applications must specify a URL that resolves to the external address.
If tunneling, then this
URL must begin with http or https instead of t3 or t3s.
For example, http://my-lb-address:my-lb-port.
You may need to enable unknown host access on the WebLogic Server instances that host the EJB or JMS resources.
If tunneling, then you may need to configure clusters that host EJB or JMS resources with a ‘server affinity’ default load balancer algorithm. This can significantly speedup connection creation for EJB and JMS clients. See Configuring WebLogic Server affinity load balancing algorithms.
You may need to use RMI forwarding to support JTA transactions that involve multiple WebLogic Server domains.
If a WebLogic EJB or JMS resource is hosted outside of a Kubernetes cluster, and the EJB or JMS applications that call the resource are located within the cluster, then:
You may need to enable unknown host access on the external WebLogic Server instance or instances.
Plus, if the target server or servers can be accessed only by tunneling through a load balancer using HTTP:
http instead of t3.You may need to use RMI forwarding to support JTA transactions that involve multiple WebLogic Server domains.
All DNS addresses must be ‘DNS-1123’ compliant;
this means that any DNS names created using the name of a service,
pod, WebLogic Server, WebLogic cluster, and such,
must be lowercase with underscores converted to dashes (hyphens).
For example, if a WebLogic Server instance is named My_Server
and the domain UID is MyUid, then its listen
address within the namespace will be myuid-my-server.
For more information on Kubernetes resource compliant naming,
please see Meet Kubernetes resource name restrictions.
Load balancer tunneling is the preferred approach for giving applications that are hosted outside of a Kubernetes cluster access to EJB and JMS resources that are hosted within the cluster. This approach involves configuring a network channel on the resource’s WebLogic cluster, ensuring the network channel accepts T3 protocol traffic that’s tunneled over HTTP, deploying a load balancer that redirects external HTTP network traffic to the network channel, and ensuring that the applications specify a URL that resolves the load balancer’s network address where the URL begins with http or https.
Here are the steps:
In WebLogic, configure a custom channel for the T3 protocol that enables HTTP tunneling, and specifies an external address and port that correspond to the address and port that remote applications will use to access the load balancer. See Adding a WebLogic custom channel for samples and details.
Set up a load balancer that redirects HTTP traffic to the custom channel. For more information on load balancers, see Ingress. If you’re using Oracle Container Engine for Kubernetes/Oracle Cloud Infrastructure to host your Kubernetes cluster, also see Using an Oracle Cloud Infrastructure Load Balancer.
Important: Ensure that the load balancer configures the HTTP flow to be ‘sticky’ - for example, a Traefik load balancer has a sticky sessions option. This ensures that all of the packets of a tunneling client connection flow to the same pod, otherwise the connection will stall when its packets are load balanced to a different pod.
Important: For EJB and JMS resources that are targeted to a cluster, we recommend that you configure a default load balancer algorithm that provides server affinity (round-robin-affinity, weight-based-affinity, random-affinity) to speedup connection creation for EJB and JMS clients. See Configuring WebLogic Server affinity load balancing algorithms.
If you are adding access for applications that are hosted on remote WebLogic Server instances, then the Kubernetes hosted servers may need to enable unknown host access.
Remote applications can then access the custom channel using an http:// URL instead of a t3:// URL.
Review the Security notes.
The following sections describe WebLogic custom channel considerations and configuration.
WebLogic implicitly creates a multi-protocol default channel that spans the Listen Address and Port fields specified on each server in the cluster, but this channel is usually unsuitable for external network traffic from EJB and JMS applications. Instead, you may need to configure an additional, dedicated WebLogic custom channel to handle remote EJB or JMS application network traffic.
A custom channel provides a way to configure an external listen address and port for use by external applications, unlike a default channel. External listen address or port configuration is needed when a channel’s configured listen address or port would not work if used to form a URL in the remote application. This is because remote EJB and JMS applications internally use their application’s channel’s configured network information to reconnect to WebLogic when needed. (The EJB and JMS applications do not always use the initial URL specified in the application’s JNDI context.)
A custom channel can be locked down using two-way SSL as a way to prevent access by unauthorized external JMS and EJB applications, only accepts protocols that are explicitly enabled for the channel, and can be configured to be the only channel that accepts EJB/JMS applications that tunnel over HTTP. A default channel may often be deliberately unencrypted for convenient internal use, or, if used externally, is used for web traffic (not tunneling traffic) only. In addition, a default channel supports several protocols but it’s a best practice to limit the protocols that can be accessed by external applications. Finally, external applications may require access using HTTP tunneling to make connections, but it’s often inadvisable to enable tunneling for an unsecured default channel that’s already servicing external HTTP traffic. This is because enabling HTTP tunneling would potentially allow unauthorized external JMS and EJB applications unsecured access to the WebLogic cluster through the same HTTP path.
The basic requirements for configuring a custom channel for remote EJB and JMS access are:
Configure a T3 protocol network access point (NAP) with the same name and port on each server (the operator will set the listen address for you).
Configure the external listen address and port on each NAP to match the address and port component of a URL your applications can use. For example, if you are providing access to remote applications using a load balancer, then these should match the address and port of the load balancer.
If you want WebLogic T3 applications to tunnel through HTTP, then enable HTTP tunneling on each NAP. This is often necessary for load balancers.
Do NOT set outbound-enabled to true on the network access point (the default is false), because this may cause internal network traffic to stall in an attempt to route through the network access point.
For operator controlled WebLogic clusters, ensure you haven’t enabled calculated-listen-ports for WebLogic dynamic cluster servers. The operator requires that a channel have the same port on each server in a cluster, but calculated-listen-ports causes the port to be different on each server.
For clusters that are not operator controlled, minimally ensure that the server’s default channel ListenAddress is configured. Oracle strongly recommends configuring a ListenAddress on all WebLogic Server instances. Note that if a NAP’s ListenAddress is left blank, then it will use the default channel’s ListenAddress. (This is not a concern for operator controlled clusters as the operator sets the listen addresses on every WebLogic Server instance.)
For example, here is a snippet of a WebLogic domain config.xml file for channel MyChannel defined for an operator controlled WebLogic dynamic cluster named cluster-1:
<server-template>
<name>cluster-1-template</name>
<listen-port>8001</listen-port>
<cluster>cluster-1</cluster>
<network-access-point>
<name>MyChannel</name>
<protocol>t3</protocol>
<public-address>some.public.address.com</public-address>
<listen-port>7999</listen-port>
<public-port>30999</public-port>
<http-enabled-for-this-protocol>true</http-enabled-for-this-protocol>
<tunneling-enabled>true</tunneling-enabled>
<outbound-enabled>false</outbound-enabled>
<enabled>true</enabled>
<two-way-ssl-enabled>false</two-way-ssl-enabled>
<client-certificate-enforced>false</client-certificate-enforced>
</network-access-point>
</server-template>
<cluster>
<name>cluster-1</name>
<cluster-messaging-mode>unicast</cluster-messaging-mode>
<dynamic-servers>
<name>cluster-1</name>
<server-template>cluster-1-template</server-template>
<maximum-dynamic-server-count>5</maximum-dynamic-server-count>
<calculated-listen-ports>false</calculated-listen-ports>
<server-name-prefix>managed-server</server-name-prefix>
<dynamic-cluster-size>5</dynamic-cluster-size>
<max-dynamic-cluster-size>5</max-dynamic-cluster-size>
</dynamic-servers>
</cluster>
Here is a snippet of offline WLST code that corresponds to the previous config.xml file snippet:
templateName = "cluster-1-template"
cd('/ServerTemplates/%s' % templateName)
templateChannelName = "MyChannel"
create(templateChannelName, 'NetworkAccessPoint')
cd('NetworkAccessPoints/%s' % templateChannelName)
set('Protocol', 't3')
set('ListenPort', 7999)
set('PublicPort', 30999)
set('PublicAddress', 'some.public.address.com')
set('HttpEnabledForThisProtocol', true)
set('TunnelingEnabled', true)
set('OutboundEnabled', false)
set('Enabled', true)
set('TwoWaySslEnabled', false)
set('ClientCertificateEnforced', false)
Here is a snippet of WDT model YAML file configuration that corresponds to the previous snippets:
topology:
Cluster:
'cluster-1':
DynamicServers:
ServerTemplate: 'cluster-1-template'
ServerNamePrefix: 'managed-server'
DynamicClusterSize: '5'
MaxDynamicClusterSize: '5'
MinDynamicClusterSize: '0'
CalculatedListenPorts: false
ServerTemplate:
'cluster-1-template':
Cluster: 'cluster-1'
ListenPort: 8001
NetworkAccessPoint:
MyT3Channel:
Protocol: 't3'
ListenPort: 7999
PublicPort: 30999
PublicAddress: 'some.public.address.com'
HttpEnabledForThisProtocol: true
TunnelingEnabled: true
OutboundEnabled: false
Enabled: true
TwoWaySSLEnabled: false
ClientCertificateEnforced: false
In this example:
WebLogic binds the custom network channel to port 7999 and the default network channel to 8001.
The operator will automatically create a Kubernetes Service named DOMAIN_UID-cluster-cluster-1 for both the custom and default channel.
The operator will automatically set the ListenAddress on each WebLogic Server instance for each of its channels.
Internal applications running in the same Kubernetes cluster as the channel can access the cluster using t3://DOMAIN_UID-cluster-cluster-1:8001.
External applications would be expected to access the cluster using the custom channel with URLs like t3://some.public.address.com:30999 or, if using tunneling, http://some.public.address.com:30999.
Channel configuration for a configured cluster requires configuring the same network access point on each server. The operator currently doesn’t test or support network channels that have a different configuration on each server in the cluster.
Additional steps are required for external applications beyond configuring the custom channel - see Overview.
NodePortsThe following sections provide detailed information about Kubernetes NodePorts.
NodePort overviewKubernetes NodePorts provide an alternative approach for giving external WebLogic EJB or JMS applications access to a Kubernetes hosted WebLogic cluster. This approach involves configuring a network channel on the desired WebLogic cluster that accepts T3 protocol traffic, and exposing a Kubernetes NodePort that redirects external network traffic on the Kubernetes Nodes to the network channel.
NodePort warningsAlthough Kubernetes NodePorts are good for use in demos and getting-started guides, they are usually not suited for production systems for multiple reasons, including:
NodePorts because their Kubernetes clusters run on a private network that cannot be reached by external clients.Load balancer tunneling is the preferred approach over Kubernetes NodePorts.
NodePort stepsHere are the high-level steps:
Review NodePort warnings.
In WebLogic, configure a custom channel for the T3 protocol that specifies an external address and port that are suitable for remote application use. See Adding a WebLogic custom channel.
Define a Kubernetes NodePort to publicly expose the WebLogic ports. See Setting up a NodePort.
If you are adding access for remote WebLogic Server instances, then the Kubernetes hosted servers may need to enable unknown host access.
Review the Security notes.
NodePortA Kubernetes NodePort exposes a port on each worker node in the Kubernetes cluster (they are not typically exposed on masters), where the port is accessible from outside of a Kubernetes cluster. This port redirects network traffic to pods within the Kubernetes cluster. Setting up a Kubernetes NodePort is one approach for giving external WebLogic applications access to JMS or EJBs.
If an EJB or JMS service is running on an Administration Server, then you can skip the rest of this section and use the spec.adminServer.adminService.channels Domain field to have the operator create a NodePort for you. See Reference - Domain. Otherwise, if the EJB or JMS service is running in a WebLogic cluster or standalone WebLogic Server Managed Server, and you desire to provide access to the service using a NodePort, then the NodePort must be exposed ‘manually’ - see the following sample and table.
Setting up a NodePort usually also requires setting up a custom network channel. See Adding a WebLogic custom channel.
NodePort resourceThe following NodePort YAML file exposes an external node port of 30999 and internal port 7999 for a domain UID of DOMAIN_UID, a domain name of DOMAIN_NAME, and a cluster name of CLUSTER_NAME. It assumes that 7999 corresponds to a T3 protocol port of a channel that’s configured on your WebLogic cluster.
apiVersion: v1
kind: Service
metadata:
namespace: default
name: DOMAIN_UID-cluster-CLUSTER_NAME-ext
labels:
weblogic.domainUID: DOMAIN_UID
spec:
type: NodePort
externalTrafficPolicy: Cluster
sessionAffinity: ClientIP
selector:
weblogic.domainUID: DOMAIN_UID
weblogic.clusterName: CLUSTER_NAME
ports:
- name: myclustert3channel
nodePort: 30999
port: 7999
protocol: TCP
targetPort: 7999
NodePort attributes| Attribute | Description |
|---|---|
metadata.name |
For this particular use case, the NodePort name can be arbitrary as long as it is DNS compatible. But, as a convention, it’s recommended to use DOMAIN_UID-cluster-CLUSTER_NAME-ext. To ensure the name is DNS compatible, use all lowercase and convert any underscores (_) to dashes (-). |
metadata.namespace |
Must match the namespace of your WebLogic cluster. |
metadata.labels |
Optional. It’s helpful to set a weblogic.domainUid label so that cleanup scripts can locate all Kubernetes resources associated with a particular domain UID. |
spec.type |
Must be NodePort. |
spec.externalTrafficPolicy |
Set to Cluster for most use cases. This may lower performance, but ensures that a client that attaches to a node without any pods that match the spec.selector will be rerouted to a node with pods that do match. If set to Local, then connections to a particular node will route only to that node’s pods and will fail if the node doesn’t host any pods with the given spec.selector. It’s recommended for applications of a spec.externalTrafficPolicy: Local NodePort to use a URL that resolves to a list of all nodes, such as t3://mynode1,mynode2:30999, so that a client connect attempt will implicitly try mynode2 if mynode1 fails (alternatively, use a round-robin DNS address in place of mynode1,mynode2). |
spec.sessionAffinity |
Set to ClientIP to ensure an HTTP tunneling connection always routes to the same pod, otherwise the connection may hang and fail. |
spec.selector |
Specifies a weblogic.domainUID and weblogic.clusterName to associate the NodePort resource with your cluster’s pods. The operator automatically sets these labels on the WebLogic cluster pods that it deploys for you. |
spec.ports.name |
This name is arbitrary. |
spec.ports.nodePort |
The external port that applications will use. This must match the external port that’s configured on the WebLogic configured channels/network access points. By default, Kubernetes requires that this value range from 30000 to 32767. |
spec.ports.port and spec.targetPort |
These must match the port that’s configured on the WebLogic configured channel/network access points. |
The following sections describe when and how to enable unknown host access.
If a source WebLogic Server attempts to initiate an EJB, JMS, or JTA connection with a target WebLogic Server, then the target WebLogic Server will reject the connection by default, if it cannot find the source server’s listen address in its DNS. Such a failed connection attempt can yield log messages or exceptions like "...RJVM has already been shutdown..." or "...address was valid earlier, but now we get...".
This means that it’s usually necessary to enable unknown host access on an external WebLogic Server instance so that it can support EJB, JMS, or JTA communication that is initiated by an operator hosted WebLogic Server. For example, if an operator hosted WebLogic Server with service address mydomainuid-myservername initiates a JMS connection to a remote WebLogic Server, then the remote server will implicitly attempt to look up mydomainuid-myservername in its DNS as part of the connection setup, and this lookup will typically fail.
Similarly, this also means that it’s necessary to enable unknown host access on an operator hosted WebLogic Server that accepts EJB or JMS connection requests from external WebLogic Server instances when the external WebLogic Server’s listen addresses cannot be resolved by the DNS running in the Kuberneters cluster.
To enable an ‘unknown host’ source WebLogic Server to initiate EJB, JMS, or JTA communication with a target WebLogic Server:
weblogic.rjvm.allowUnknownHost Java system property to true on each target WebLogic Server instance.
-Dweblogic.rjvm.allowUnknownHost=true in the JAVA_OPTIONS Domain environment variable defined in the domain resource’s spec.serverPod.env attribute.JTA transactions that span WebLogic Server domains are referred to as cross-domain transactions. The WebLogic Server Transaction Manager (TM) requires direct server-to-server communications with all other global transaction server participants. For a Kubernetes hosted WebLogic cluster, this requires each server in the cluster to be individually addressable. This conflicts with the current operator requirement that a network channel in a cluster have the same port across all servers in the cluster, and the fact that we use cluster service to load balance communication in the WebLogic Server cluster.
RMI forwarding makes cross-domain transactions possible without requiring each server in a cluster to be individually addressable.
It requires the use of a proxy, such as a load balancer or an Ingress, that is configured to route messages to servers in the target WebLogic Server domain.
When a T3 message, such as transaction coordination RMI calls issued by the WebLogic Server TM, is sent from a source WebLogic Server to a target WebLogic Server in a different WebLogic Server domain:
RMI forwarding may be needed when transaction server participants are not able to establish connection directly with one another.
For example, if a cross-domain transaction communication has failed, and messages such as the following can be found in the WebLogic server log files:
<BEA-111015> <The commit operation for transaction BEA1-0000993203DB6CDB7DE9 timed out after 30 seconds.>
With additional JTA debugging turned on using the Java system property -Dweblogic.debug.DebugJTA2PC=true,
messages, such as the following, confirm that the failed transaction is caused by transaction
participants not being able to reach the transaction coordinator:
...<startPrepare FAILED javax.transaction.SystemException: Could not obtain coordinator at managed-server1+domain1-managed-server1:8001+domain1+t3+...
Configure a proxy for each WebLogic Server domain that is a participant in global transactions but is not reachable by all other global transaction participants, because the listen addresses of the WebLogic Server instances in the domain cannot be resolved by the DNS from other participants. For example, if servers in domain1 cannot be reached from servers in domain2, configure a proxy for domain1 such that messages sent from servers in domain2 can be routed to servers in domain1 through the proxy.
In each source WebLogic Server domain, specify the URL for the proxy configured for each target WebLogic Server domain:
weblogic.rjvm.domain.proxy.<prefix> where <prefix> is the
domain UID of the target WebLogic Server domain.
Multiple Java system properties with different values of <prefix> can be specified.JAVA_OPTIONS
Domain environment variable defined in the domain resource’s spec.serverPod.env attribute.For example, if the URL of the proxy for domain1 is t3://proxy-host:31234, specify
Java system property -Dweblogic.rjvm.domain.proxy.domain1=t3://proxy-host:31234
in WebLogic Server domain2.
A message originating from WebLogic Server instances in domain2 that are addressed to the host name that starts
with domain1, such as t3://domain1-managed-server1:8001, will be sent to the proxy at
t3://proxy-host:31234. The proxy then routes the message to a WebLogic Server instance in domain2, and
RMI forwarding will ensure that the message will reach WebLogic Server managed-server1 in domain1.
Patch 32408938 is required in each WebLogic Server instance that participates in cross-domain transactions, or that is the routing destination of a proxy. The patch is available for WebLogic versions 12.2.1.4.0 (PS4), and 14.1.1.0.0, and is already included in the PSUs for these releases since July 2022.
When providing external clients access to EJB and JMS resources using load balancer tunneling, we recommend that you configure a server affinity load balancing algorithm for the cluster in which the resources are targeted. Using a server affinity based algorithm reduces the amount of time it takes for EJB and JMS standalone or server hosted clients to establish a connection through a tunneling port. It does this by ensuring that the clients prefer communicating with a target server instance which already has an established connection to the client, where this server instance is implicitly picked when such clients create their JNDI context. See Load Balancing for EJBs and RMI Objects in Load Balancing in a Cluster.
Here is a snippet of offline WLST code for enabling server affinity in a cluster ‘cluster-1’:
clusterName = "cluster-1"
cd('/Clusters/%s' % clusterName)
set('DefaultLoadAlgorithm', 'round-robin-affinity')
Here is a snippet of WDT model YAML file configuration for enabling server affinity in a cluster ‘cluster-1’:
topology:
Cluster:
'cluster-1':
DynamicServers:
ServerTemplate: 'cluster-1-template'
ServerNamePrefix: 'managed-server'
DynamicClusterSize: '5'
MaxDynamicClusterSize: '5'
MinDynamicClusterSize: '0'
CalculatedListenPorts: false
DefaultLoadAlgorithm: 'round-robin-affinity'
WebLogic Server provides an external listen address/DNS name feature to enable external JMS and EJB clients to properly reestablish and/or load balance connections to servers with listen addresses that aren’t directly available in the client’s DNS (such as through a firewall or a load balancer, or between different namespaces in Kubernetes). For more information on external listen addresses, see the ExternalDNSName attribute in the ServerMBean reference.
Here is a snippet of offline WLST code for setting the external listen address for a standalone server named AdminServer in namespace weblogic-domain for domain-uid domain1:
serverName = "AdminServer"
domainUid = "domain1"
nameSpace = "weblogic-domain"
address = domainUid + '_' + serverName + '_' + nameSpace
externalDNSName = address.lower().replace('_','-') # DNS names must be DNS-1123 compliant
cd('/Servers/%s' % serverName)
set('ExternalDNSName', externalDNSName)
Here is a snippet of offline WLST code for setting the external listen address for a server template named cluster-1-template in namespace weblogic-domain for domain-uid domain1:
templateName = "cluster-1-template"
serverName = "managed-server${id}"
domainUid = "domain1"
nameSpace = "weblogic-domain"
address = domainUid + '_' + serverName + '_' + nameSpace
externalDNSName = address.lower().replace('_','-') # DNS names must be DNS-1123 compliant
cd('/ServerTemplates/%s' % templateName)
set('ExternalDNSName', externalDNSName)
The server name contains the server template macro “${id}” in which the correct instance ID will be substituted by the WebLogic Server runtime. See Using Macros in Server Templates.
Here is a snippet of WDT model YAML file configuration to set the ExternalDNSName attribute for both a standalone server and for a server template:
topology:
Cluster:
"cluster-1":
DynamicServers:
ServerTemplate: "cluster-1-template"
ServerNamePrefix: "managed-server"
DynamicClusterSize: 5
MaxDynamicClusterSize: 5
CalculatedListenPorts: false
Server:
"admin-server":
ListenPort: 7001
ExternalDNSName: '@@ENV:DOMAIN_UID@@-admin-server.@@ENV:NAMESPACE@@'
ServerTemplate:
"cluster-1-template":
Cluster: "cluster-1"
ListenPort : 8001
ExternalDNSName: '@@ENV:DOMAIN_UID@@-managed-server${id}.@@ENV:NAMESPACE@@'
In the previous example, DOMAIN_UID and NAMESPACE are assumed to already be ‘DNS-1123’ compliant.
Alternatively, you can substitute the macros with DNS-1123 acceptable values
(changed to lowercase and underscores converted to dashes).
For more information on Kubernetes resource compliant naming,
please see Meet Kubernetes resource name restrictions.
With some cloud providers, a load balancer or NodePort may implicitly expose a port to the public Internet. See also NodePort warnings.
If an externally available port supports a protocol suitable for WebLogic applications, note that WebLogic allows access to JNDI entries, EJB/RMI applications, and JMS by anonymous users by default.
You can configure a custom channel with a secure protocol and two-way SSL to help prevent external access by unwanted applications. See When is a WebLogic custom channel needed?.
For a detailed description of external network access security, see External network access security.
For a description of the WebLogic URL syntax for JMS, EJB, and JNDI applications see Understanding WebLogic URLs.
If JMS applications need to specify a URL and the applications are hosted on a WebLogic Server or cluster, then, as a best practice, the application should simply be coded to use local JNDI names for its JMS Connection Factories and JMS Destinations, and these local JNDI names should be configured in WebLogic to map to the remote location using a Foreign JMS Server. A Foreign JMS Server maps the local JNDI name of a JMS Connection Factory or JMS Destination to a remote JNDI name located at a different URL, where the local JNDI name, remote JNDI name, remote user name, remote password, and remote URL are all configurable. See Integrating Remote JMS Destinations.
For a detailed description of using T3 in combination with port mapping, see T3 RMI Communication for WebLogic Server Running on Kubernetes.