-
Notifications
You must be signed in to change notification settings - Fork 213
FAQ
What is the WebLogic Kubernetes Operator, how can I get started with it, where is its documentation?
See https://github.com/oracle/weblogic-kubernetes-operator/wiki
The WebLogic Kubernetes Operator is free and open sourced.
WebLogic Server itself is not open source. Licensing is required for each running WebLogic Server instance, just as with any deployment of WebLogic Server. Licensing is free for a single developer desktop development environment.
We have a public Slack channel where you can get in touch with us to ask questions about using the operator or give us feedback or suggestions about what features and improvements you would like to see. To join our channel, please visit this site to get an invitation. The invitation email will include details of how to access our Slack workspace. After you are logged in, please come to #operator and say, "hello!"
Q: Which Java EE profiles are supported/certified on Kubernetes, only Web Profile or WLS Java EE full blown?
A: We support the full Java EE Profile.
Q: Are XA transactions and recovery also supported?
A: Yes, XA transactions are supported. We are expanding our certification to include more complex cross domain XA transaction use cases.
Q: How is the WebLogic Server domain configured in a Docker container (e.g. databases, JMS, etc.) that is potentially shared by many domains?
A: In a Kubernetes & Docker environment, the WebLogic domain home can be externalized to a persistent volume, or supplied in an image (via a layer on top of a WebLogic Server image). For WebLogic domains that are supplied via an image, the domain's logs and store locations can optionally be located on a persistent volume. See the samples that come with this project.
When using the WebLogic Kubernetes Operator, each deployed domain is specified by a domain resource that you define which describes important aspects of the domain. These include the location of the WebLogic image you wish to use, a unique identifier for the domain called the domain-uid, any PVs or PVC the domain's pods will need to mount, the WebLogic clusters and servers which you want to be running, and the location of its domain home.
Multiple deployments of the same domain are supported by specifying a unique domain-uid string for each deployed domain and specifying a different domain resource. The domain-uid is in turn used by the Operator as the name-prefix and/or label for the domain's Kubernetes resources that the Operator deploys for you. The WebLogic configuration of a domain's deployments can optionally by customized by specifying configuration overrides in the domain resource -- which, for example, is useful for overriding the configuration of a data source URL, user name, or password.
The WebLogic Kubernetes Operator does not specify how a WebLogic domain home configuration is created. You can use WLST, REST, or a very convenient new tool called the WebLogic Deploy Tool (WDT). WDT allows you to compactly specify WebLogic configuration and deployments (including JMS, data sources, applications, authenticators, etc.) via a YAML file and a ZIP file (which include the binaries). The Operator samples show how to create domains via WLST and via WDT.
Q: Is the Administration Server required? Node Manager?
A: Certification of both WebLogic on Docker and WebLogic in Kubernetes consists of a WebLogic domain with the Administration Server. The Operator configures and runs Node Managers for you within a domain's pods - you don't need to configure them yourself - so their presence is largely transparent.
Q: How is Location Transparency achieved and the communication between WLS instances handled? T3s?
A: Inside the Kubernetes cluster, we use the Cluster IP (acts as a DNS name) and Ingress controller which allows for the pods with WebLogic Servers to move to different nodes in the Kubernetes cluster and continue communicating with other servers.
For T3 communication outside the Kubernetes cluster, we use NodePort and configure a WebLogic channel for T3 RMI. Please read the blog https://blogs.oracle.com/weblogicserver/t3-rmi-communication-for-weblogic-server-running-on-kubernetes which explains in detail RMI T3 communication. All QOS are supported for T3 and HTTP communication (SSL, Admin).
Q: Are clusters supported on Kubernetes using both multicast and unicast?
A: Only unicast is supported. Most Kubernetes network fabrics do not support multicast communication. Weave claims to support multicast but it is a commercial network fabric. We have only certified on Flannel which supports unicast only.
Q: Docker resources: we use an SSL listener, SSL port, and an Admin port on each instance. How do we map these resources?
A: Yes, you can use an SSL listener, SSL port, and an Admin port in both Docker and Kubernetes. Please refer to the blog https://blogs.oracle.com/weblogicserver/t3-rmi-communication-for-weblogic-server-running-on-kubernetes which describes how to map these ports in Kubernetes.
Q: Load Balancing and Failover inside a DataCenter (HTTPS and T3s)
A: We originally certified with Traefik with the Kubernetes cluster; this is a very basic load balancer. We have also certified other more sophisticated load balancers.
Q: How to deal with grow and shrink? Cluster and non-cluster mode.
A: You can scale and shrink a configured WebLogic cluster (a set of pre-configured Managed Servers) or a dynamic WebLogic cluster (a cluster that uses a templated Managed Server) using different methods. Please see the blog https://blogs.oracle.com/weblogicserver/automatic-scaling-of-weblogic-clusters-on-kubernetes-v2
- Manually using Kubernetes command-line interface, kubectl
- WLDF rules and policies, when the rule is met the Administration Server sends a REST call to the Operator which calls the Kubernetes API to start a new pod/container/server.
- We have developed and open sourced the WebLogic Monitoring Exporter which exports WebLogic metrics to Prometheus and Grafana. In Prometheus you can set rules similar to WLDF and when these rules are met, a REST call is made to the Operator which invokes a Kubernetes API to start a new pod. Please refer to blog https://blogs.oracle.com/weblogicserver/announcing-the-new-weblogic-monitoring-exporter-v2
Q: Container-life cycle: How to properly spin-up and gracefully shutdown WLS in a container?
A: The Operator manages container/pod/WebLogic Server life cycle automatically; it uses the Node Manager (internally) and additional approaches to do the following operations:
- ENTRYPOINT - start WebLogic Server
- Liveliness probe – check if the the WebLogic Server is alive
- Readiness probe – query if the WebLogic Server is ready to receive requests
- Shutdown Hook – gracefully shutdown the WebLogic Server
These operations can also be done manually using the Kubernetes command-line interface, kubectl.
Q: For binding EJB’s (presentation-/business-tier) are unique and/or dynamic domain-names used?
A: We do not enforce unique domain names. If you deploy two domains that must interoperate via RMI/EJB/JMS/JTA/etc, or that share RMI/EJB/JMS/JTA/etc clients which concurrently communicate with both domains, then, as usual, the domain names must be configured to be different (even if they have different domain-uids).
Q: Patching: rolling upgrades, handling of one-off-patches and overlays, CPUs, etc.
A: Patches are applied using OPatch and rolled out in the following fashion:
- Upgrade or patch WebLogic cluster in a Docker environment.
- Apply PSUs important security upgrades.
- In Dockerfile, extend image and apply patch using OPatch.
- Operator starts rolling upgrade calling Kubernetes API. Starting the pods/containers/servers in a rolling fashion can be invoked manually calling the Kubernetes API directly. Please refer to blog https://blogs.oracle.com/weblogicserver/patching-weblogic-server-in-a-kubernetes-environment.
Q: Certificates and CA provisioning and Containers
A: The WebLogic Kubernetes Operator will generate self-signed certificates based on the subject alternative names that you provide and we will automatically configure the key stores, etc. for SSL. The alternative is you can provide your own certificates that you get from a CA or that you create.
Q: Integration with Ecosystems: logging, monitoring (OS, JVM and Application level), etc.
A: WebLogic logs are persisted to an external volume. We are working on a project to integrate WebLogic Server logs with the Elastic Stack.
With regards to monitoring, all the tools that are traditionally used to monitor WebLogic can still be used in Docker and Kubernetes. In addition, as mentioned above, we have developed the WebLogic Monitoring Exporter which exports WebLogic metrics in a format that can be read and displayed in dashboards like Prometheus and Grafana.