Oracle is finding ways for organizations using WebLogic Server to run important workloads, to move those workloads into the cloud. By certifying on industry standards, such as Docker and Kubernetes, WebLogic now runs in a cloud neutral infrastructure. In addition, we’ve provided an open source Oracle WebLogic Server Kubernetes Operator (the “operator”) which has several key features to assist you with deploying and managing WebLogic domains in a Kubernetes environment. You can:
The current release of the operator is 2.5.0. This release was published on February 26, 2020.
Please review the prerequisites and supported environments here.
Starting from the 2.0.1 release, operator releases are backward compatible with respect to the domain resource schema, operator Helm chart input values, configuration overrides template, Kubernetes resources created by the operator Helm chart, Kubernetes resources created by the operator, and the operator REST interface. We intend to maintain compatibility for three releases, except in the case of a clearly communicated deprecated feature, which will be maintained for one release after a replacement is available.
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:
The User guide provides detailed information about all aspects of using the operator including:
Please refer to our samples for information about the available sample code.
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. We would love to hear from you. 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!”
See the Release Notes for recent changes to the operator and known issues.
Developers interested in this project are encouraged to read the Developer guide to learn how to build the project, run tests, and so on. The Developer guide also provides details about the structure of the code, coding standards, and the Asynchronous Call facility used in the code to manage calls to the Kubernetes API.
Please take a look at our wish list to get an idea of the kind of features we would like to add to the operator. Maybe you will see something to which you would like to contribute!
Documentation for APIs:
The operator provides a REST API that you can use to obtain configuration information and to initiate scaling actions. For details about how to use the REST APIs, see Use the operator’s REST services.
See the Swagger documentation for the operator’s REST interface.
Oracle welcomes contributions to this project from anyone. Contributions may be reporting an issue with the operator or submitting a pull request. Before embarking on significant development that may result in a large pull request, it is recommended that you create an issue and discuss the proposed changes with the existing developers first.
If you want to submit a pull request to fix a bug or enhance an existing feature, please first open an issue and link to that issue when you submit your pull request.
If you have any questions about a possible submission, feel free to open an issue too.
Pull requests can be made under The Oracle Contributor Agreement (OCA), which is available at https://www.oracle.com/technetwork/community/oca-486395.html.
For pull requests to be accepted, the bottom of the commit message must have the following line, using the contributor’s name and e-mail address as it appears in the OCA Signatories list.
Signed-off-by: Your Name <email@example.com>
This can be automatically added to pull requests by committing with:
git commit --signoff
Only pull requests from committers that can be verified as having signed the OCA can be accepted.
Please be aware that pull requests that seek to introduce a new dependency will be subject to additional review. In general, contributors should avoid dependencies with incompatible licenses, and should try to use recent versions of dependencies. Standard security vulnerability checklists will be consulted before accepting a new dependency. Dependencies on closed-source code, including WebLogic Server, will most likely be rejected.