Create and manage WebLogic domains
In this version of the operator, a WebLogic domain can be located either in a persistent volume (PV) or in a Docker image. There are advantages to both approaches, and there are sometimes technical limitations of various cloud providers that may make one approach better suited to your needs. You can also mix and match on a domain-by-domain basis.
|Domain on a persistent volume||Domain in a Docker image|
|Let's you use the same standard read-only Docker image for every server in every domain.||Requires a different image for each domain, but all servers in that domain use the same image.|
|No state is kept in Docker images making them completely throw away (cattle not pets).||Runtime state should not be kept in the images, but applications and configuration are.|
|The domain is long-lived, so you can mutate the configuration or deploy new applications using standard methods (Administration Console, WLST, and such).||If you want to mutate the domain configuration or deploy application updates, you must create a new image.|
|Logs are automatically placed on persistent storage.||Logs are kept in the images, and sent to the pod's log (stdout) unless you manually place them on persistent storage.|
|Patches can be applied by simply changing the image and rolling the domain.||To apply patches, you must create a new domain-specific image and then roll the domain.|
|Many cloud providers do not provide persistent volumes that are shared across availability zones, so you may not be able to use a single persistent volume. You may need to use some kind of volume replication technology or a clustered file system.||You do not have to worry about volume replication across availability zones since each pod has its own copy of the domain. WebLogic replication will handle propagation of any online configuration changes.|
|CI/CD pipelines may be more complicated because you would probably need to run WLST against the live domain directory to effect changes.||CI/CD pipelines are simpler because you can create the whole domain in the image and don't have to worry about a persistent copy of the domain.|
|There are less images to manage and store, which could provide significant storage and network savings.||There are more images to manage and store in this approach.|
|You may be able to use standard Oracle-provided images or, at least, a very small number of self-built images, for example, with patches installed.||You may need to do more work to set up processes to build and maintain your images.|
Preparing the Kubernetes cluster to run WebLogic domains
Perform these steps to prepare your Kubernetes cluster to run a WebLogic domain:
Create the domain namespace(s). One or more domains can share a namespace. A single instance of the operator can manage multiple namespaces.
$ kubectl create namespace domain-namespace-1
domain-namespace-1with name you want to use. The name must follow standard Kubernetes naming conventions, that is, lower case, numbers, and hyphens.
Create a Kubernetes secret containing the Administration Server boot credentials. You can do this manually or by using the provided sample. To create the secret manually, use this command:
$ kubectl -n domain-namespace-1 \ create secret generic domain1-weblogic-credentials \ --from-literal=username=weblogic \ --from-literal=password=welcome1
domain-namespace-1with the namespace that the domain will be in. Replace
domain1-weblogic-credentialswith the name of the secret. The operator expects the secret name to be the
domainUIDfollowed by the literal string
-weblogic-credentialsand many of the samples assume this name. Replace the string
weblogicin the third line with the user name for the administrative user. Replace the string
welcome1in the fourth line with the password.
Optionally, create a PV & persistent volume claim (PVC) which can hold the domain home, logs, and application binaries. Even if you put your domain in a Docker image, you may want to put the logs on a persistent volume so that they are available after the pods terminate. This may be instead of, or as well as, other approaches like streaming logs into Elasticsearch.
Configure load balancer(s) to manage access to any WebLogic clusters.
Important considerations for WebLogic domains in Kubernetes
Please be aware of the following important considerations for WebLogic domains running in Kubernetes.
Domain Home Location: The WebLogic domain home location is determined by the domain resource
domainHomeif set; otherwise, a default location is determined by the
domainHomeInImagesetting. If a domain resource
domainHomefield is not set and
true(the default), then the operator will assume that the domain home is a directory under
/u01/oracle/user_projects/domains/and report an error if no domain is found or more than one domain is found. If a domain resource
domainHomefield is not set and
false, then the operator will assume that the domain home is
Log File Locations: The operator can automatically override WebLogic domain and server log locations using situational configuration overrides. This occurs if the domain resource
logHomeEnabledfield is explicitly set to
true, or if
logHomeEnabledisn't set and
domainHomeInImageis explicitly set to
false. When overriding, the log location will be the location specified by the
Listen Address Overrides: The operator will automatically override all WebLogic domain default, SSL, admin, or custom channel listen addresses (using situational configuration overrides). These will become
domainUIDfollowed by a hyphen and then the server name, all lower case, and underscores converted to hyphens. For example, if
domainUID=domain1and the WebLogic server name is
Admin_Server, then its listen address becomes
Domain, Cluster, Server, and Network-Access-Point Names: WebLogic domain, cluster, server, and network-access-point (channel) names must contain only the characters
_. This ensures that they can be converted to meet Kubernetes resource and DNS1123 naming requirements. (When generating pod and service names, the operator will convert configured names to lower case and substitute a hyphen (
-) for each underscore (
Node Ports: If you choose to expose any WebLogic channels outside the Kubernetes cluster via a
NodePort, for example, the administration port or a T3 channel to allow WLST access, you need to ensure that you allocate each channel a unique port number across the entire Kubernetes cluster. If you expose the administration port in each WebLogic domain in the Kubernetes cluster, then each one must have a different port. This is required because
NodePortsare used to expose channels outside the Kubernetes cluster.
IMPORTANT: Exposing admin, RMI, or T3 capable channels via a node port can create an insecure configuration; in general only HTTP protocols should be made available externally and this exposure is usually accomplished by setting up an external load balancer that can access internal (non-NodePort) services.
Host Path Persistent Volumes: If using a
hostPathpersistent volume, then it must be available on all worker nodes in the cluster and have read/write/many permissions for all container/pods in the WebLogic Server deployment. Be aware that many cloud provider's volume providers may not support volumes across availability zones. You may want to use NFS or a clustered file system to work around this limitation.
The following features are not certified or supported in this release:
- Whole Server Migration
- Consensus Leasing
- Node Manager (although it is used internally for the liveness probe and to start WebLogic Server instances)
- Production redeployment
Please consult My Oracle Support Doc ID 2349228.1 for up-to-date information about the features of WebLogic Server that are supported in Kubernetes environments.
Creating and managing WebLogic domains
In this version of the operator, a WebLogic domain can be located either in a persistent volume (PV) or in a Docker image. For examples of each, see the WebLogic operator samples.
If you want to create your own Docker images, for example, to choose a specific set of patches or to create a domain with a specific configuration and/or applications deployed, then you can create the domain custom resource manually to deploy your domain. This process is documented in this sample.
Modifying domain configurations
You can modify the WebLogic domain configuration for both the "domain in persistent volume" and the "domain in image" options before deploying a domain resource:
- When the domain is in a persistent volume, you can use WLST or WDT to change the configuration.
- For either case, you can use configuration overrides.
Configuration overrides allow changing a configuration without modifying its original
config.xml or system resource XML files, and also support parameterizing overrides so that you can inject values into them from Kubernetes secrets. For example, you can inject database user names, passwords, and URLs that are stored in a secret.
About the domain resource
For information about the domain resource, see Domain resource.
Managing lifecycle operations
The operator let's you initiate scaling of clusters in various ways: