From 5db2fd2ad195e7a6e31369a5c84751d31b378954 Mon Sep 17 00:00:00 2001 From: Ryan Eberhard Date: Tue, 27 Apr 2021 13:44:47 -0400 Subject: [PATCH] Update documentation for 3.2.2 release --- documentation/3.2/content/_index.md | 115 ++------- .../3.2/content/developerguide/branching.md | 2 +- .../content/developerguide/contributing.md | 42 ++++ .../content/developerguide/documentation.md | 6 +- .../3.2/content/faq/external-clients.md | 198 ++++++++++++--- .../3.2/content/faq/namespace-management.md | 6 +- documentation/3.2/content/faq/newbie.md | 128 ++++++++++ .../3.2/content/quickstart/get-images.md | 4 +- .../3.2/content/quickstart/install.md | 2 +- .../3.2/content/quickstart/prerequisites.md | 2 +- documentation/3.2/content/release-notes.md | 12 + .../azure-kubernetes-service/domain-on-pv.md | 2 +- .../model-in-image.md | 2 +- .../domains/domain-home-in-image/_index.md | 4 +- .../domains/domain-home-on-pv/_index.md | 4 +- .../domains/model-in-image/prerequisites.md | 4 +- .../simple/tanzu-kubernetes-service/_index.md | 2 +- .../content/userguide/base-images/_index.md | 238 ++++++++++++++++++ .../userguide/cicd/choose-an-approach.md | 2 +- .../userguide/introduction/architecture.md | 2 +- .../userguide/introduction/introduction.md | 4 +- .../configoverrides/_index.md | 4 +- .../managing-domains/domain-events.md | 10 +- .../domain-in-image/_index.md | 11 +- .../domain-in-image/base-images/_index.md | 154 ------------ .../domain-in-image/patching/_index.md | 10 - .../domain-lifecycle/restarting.md | 2 +- .../domain-lifecycle/scaling.md | 6 +- .../managing-domains/model-in-image/usage.md | 4 +- .../managing-fmw-domains/fmw-infra/_index.md | 2 +- .../managing-operators/installation/_index.md | 2 +- .../using-the-operator/using-helm.md | 2 +- 32 files changed, 656 insertions(+), 332 deletions(-) create mode 100644 documentation/3.2/content/developerguide/contributing.md create mode 100644 documentation/3.2/content/faq/newbie.md create mode 100644 documentation/3.2/content/userguide/base-images/_index.md delete mode 100644 documentation/3.2/content/userguide/managing-domains/domain-in-image/base-images/_index.md delete mode 100644 documentation/3.2/content/userguide/managing-domains/domain-in-image/patching/_index.md diff --git a/documentation/3.2/content/_index.md b/documentation/3.2/content/_index.md index 0fb4bcddb2f..807d9e8dd6d 100644 --- a/documentation/3.2/content/_index.md +++ b/documentation/3.2/content/_index.md @@ -1,30 +1,37 @@ ### Oracle WebLogic Server Kubernetes Operator -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: - -* Create WebLogic domains in a Kubernetes PersistentVolume. This PersistentVolume can reside in an NFS file system or other Kubernetes volume types. -* Create a WebLogic domain in a container image. -* Override certain aspects of the WebLogic domain configuration. -* Define WebLogic domains as a Kubernetes resource (using a Kubernetes custom resource definition). -* Start servers based on declarative startup parameters and desired states. -* Manage WebLogic configured or dynamic clusters. +The WebLogic Server Kubernetes Operator (the “operator”) supports running your WebLogic Server and Fusion Middleware Infrastructure domains on Kubernetes, an industry standard, cloud neutral deployment platform. It lets you encapsulate your entire WebLogic Server installation and layered applications into a portable set of cloud neutral images and simple resource description files. You can run them on any on-premises or public cloud that supports Kubernetes where you've deployed the operator. + +Furthermore, the operator is well suited to CI/CD processes. You can easily inject changes when moving between environments, such as from test to production. For example, you can externally inject database URLs and credentials during deployment or you can inject arbitrary changes to most WebLogic configurations. + +The operator takes advantage of the [Kubernetes operator pattern](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/), which means that it uses Kubernetes APIs to provide support for operations, such as: provisioning, lifecycle management, application versioning, product patching, scaling, and security. The operator also enables the use of tooling that is native to this infrastructure for monitoring, logging, tracing, and security. + +You can: +* Deploy an operator that manages all WebLogic domains in all namespaces in a Kubernetes cluster, or that only manages domains in a specific subset of the namespaces, or that manages only domains that are located in the same namespace as the operator. At most, a namespace can be managed by one operator. +* Supply WebLogic domain configuration using: + * _Domain in PV_: Locates WebLogic domain homes in a Kubernetes PersistentVolume (PV). This PV can reside in an NFS file system or other Kubernetes volume types. + * _Domain in Image_: Includes a WebLogic domain home in a container image. + * _Model in Image_: Includes [WebLogic Server Deploy Tooling](https://github.com/oracle/weblogic-deploy-tooling) models and archives in a container image. +* Configure deployment of WebLogic domains as a Kubernetes resource (using a Kubernetes custom resource definition). +* Override certain aspects of the WebLogic domain configuration; for example, use a different database password for different deployments. +* Start and stop servers and clusters in the domain based on declarative startup parameters and desired states. +* Scale WebLogic domains by starting and stopping Managed Servers on demand, or by integrating with a REST API to initiate scaling based on the WebLogic Diagnostics Framework (WLDF), Prometheus, Grafana, or other rules. * Expose the WebLogic Server Administration Console outside the Kubernetes cluster, if desired. * Expose T3 channels outside the Kubernetes domain, if desired. -* Expose HTTP paths on a WebLogic domain outside the Kubernetes domain with load balancing and update the load balancer when Managed Servers in the WebLogic domain are started or stopped. -* Scale WebLogic domains by starting and stopping Managed Servers on demand, or by integrating with a REST API to initiate scaling based on WLDF, Prometheus, Grafana, or other rules. +* Expose HTTP paths on a WebLogic domain outside the Kubernetes domain with load balancing, and automatically update the load balancer when Managed Servers in the WebLogic domain are started or stopped. * Publish operator and WebLogic Server logs into Elasticsearch and interact with them in Kibana. -The fastest way to experience the operator is to follow the [Quick Start guide]({{< relref "/quickstart/_index.md" >}}), or you can peruse our [documentation]({{< relref "/userguide/_index.md" >}}), read our [blogs](https://blogs.oracle.com/weblogicserver/how-to-weblogic-server-on-kubernetes), or try out the [samples]({{< relref "/samples/_index.md" >}}). - -{{% notice tip %}} Step through the [Tutorial](https://github.com/oracle/weblogic-kubernetes-operator/blob/main/kubernetes/hands-on-lab/README.md) +{{% notice tip %}} +The fastest way to experience the operator is to follow the [Quick Start guide]({{< relref "/quickstart/_index.md" >}}), or you can peruse our [documentation]({{< relref "/userguide/_index.md" >}}), read our [blogs](https://blogs.oracle.com/weblogicserver/how-to-weblogic-server-on-kubernetes), or try out the [samples]({{< relref "/samples/simple/_index.md" >}}). +Also, you can step through the [Tutorial](https://github.com/oracle/weblogic-kubernetes-operator/blob/main/kubernetes/hands-on-lab/README.md) using the operator to deploy and run a WebLogic domain container-packaged web application on an Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE) cluster. {{% /notice %}} *** #### Current production release -The [current release of the operator](https://github.com/oracle/weblogic-kubernetes-operator/releases) is 3.2.1. -This release was published on April 5, 2021. See the operator prerequisites and supported environments [here]({{< relref "/userguide/introduction/introduction#operator-prerequisites" >}}). +The [current release of the operator](https://github.com/oracle/weblogic-kubernetes-operator/releases) is 3.2.2. +This release was published on April 27, 2021. See the operator prerequisites and supported environments [here]({{< relref "/userguide/introduction/introduction#operator-prerequisites" >}}). *** @@ -52,42 +59,12 @@ please consult this table of contents: * The [Quick Start guide]({{< relref "/quickstart/_index.md" >}}) explains how to quickly get the operator running, using the defaults, nothing special. * The [User guide]({{< relref "/userguide/_index.md" >}}) contains detailed usage information, including how to install and configure the operator, and how to use it to create and manage WebLogic domains. -* The [Samples]({{< relref "/samples/_index.md" >}}) provide detailed example code and instructions that show you how to perform +* The [Samples]({{< relref "/samples/simple/_index.md" >}}) provide detailed example code and instructions that show you how to perform various tasks related to the operator. -* The [Developer guide]({{< relref "/developerguide/_index.md" >}}) provides details for people who want to understand how the operator is built, tested, and so on. Those who wish to contribute to the operator code will find useful information here. This section also includes - the Swagger/OpenAPI documentation for the REST APIs. -* The [Contributing](#contributing-to-the-operator) section provides information about contribution requirements. - - -### User guide - -The [User guide]({{< relref "/userguide/_index.md" >}}) provides detailed information about all aspects of using the operator including: - -* Installing and configuring the operator. -* Using the operator to create and manage WebLogic domains. -* Manually creating WebLogic domains to be managed by the operator. -* Scaling WebLogic clusters. -* Configuring Kubernetes load balancers. -* Configuring Elasticsearch and Kibana to access the operator's log files. -* Shutting down domains. -* Removing/deleting domains. -* And much more! - -### Samples - -Please refer to our [samples]({{< relref "/samples/_index.md" >}}) for information about the available sample code. - -### Developer guide - -Developers interested in this project are encouraged to read the [Developer guide]({{< relref "/developerguide/_index.md" >}}) 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. - -### API documentation - -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]({{< relref "/userguide/managing-operators/using-the-operator/the-rest-api#use-the-operators-rest-services" >}}). - -* See the [Swagger](https://oracle.github.io/weblogic-kubernetes-operator/swagger/index.html) documentation for the operator's REST interface. +* The [Developer guide]({{< relref "/developerguide/_index.md" >}}) provides details for people who want to understand how the operator is built, tested, and so on. Those who wish to [contribute]({{< relref "/developerguide/contributing.md" >}}) to the operator code will find useful information here. +* [Reference]({{< relref "/reference/_index.md" >}}) describes domain resource attributes and the operator REST API. +* [Security]({{< relref "/security/_index.md" >}}) describes Kubernetes, WebLogic, and OpenShift security requirements. +* [Frequently asked questions]({{< relref "/faq/_index.md" >}}) provides answers to common questions. ### Oracle support @@ -99,41 +76,3 @@ We have a **public Slack channel** where you can get in touch with us to ask que 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](https://weblogic-slack-inviter.herokuapp.com/). 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!" - -### Contributing to the operator - -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. - -#### Contributing to the Oracle WebLogic Server Kubernetes Operator repository - -Pull requests can be made under The Oracle Contributor Agreement (OCA), which is available at [https://www.oracle.com/technetwork/community/oca-486395.html](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 -``` - -This can be automatically added to pull requests by committing with: - -```shell -$ git commit --signoff -``` - -Only pull requests from committers that can be verified as having signed the OCA can be accepted. - -#### Pull request process - -* Fork the repository. -* Create a branch in your fork to implement the changes. We recommend using the issue number as part of your branch name, for example, `1234-fixes`. -* Ensure that any documentation is updated with the changes that are required by your fix. -* Ensure that any samples are updated if the base image has been changed. -* Submit the pull request. Do not leave the pull request blank. Explain exactly what your changes are meant to do and provide simple steps on how to validate your changes. Ensure that you reference the issue you created as well. We will assign the pull request to 2-3 people for review before it is merged. - -#### Introducing a new dependency - -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. diff --git a/documentation/3.2/content/developerguide/branching.md b/documentation/3.2/content/developerguide/branching.md index 724ea87f012..dd1fc7121b4 100644 --- a/documentation/3.2/content/developerguide/branching.md +++ b/documentation/3.2/content/developerguide/branching.md @@ -11,6 +11,6 @@ Because we want to balance separating destabilizing work into feature branches a All commits to `main` must pass the [integration test suite]({{< relref "/developerguide/integration-tests.md" >}}). Please run these tests locally before submitting a pull request. Additionally, each push to a branch in our GitHub repository triggers a run of a subset of the integration tests with the results visible [here](http://build.weblogick8s.org:8080/job/weblogic-kubernetes-operator-quicktest/). -Please submit pull requests to the `main` branch unless you are collaborating on a feature and have another target branch. Please see details on the Oracle Contributor Agreement (OCA) and guidelines for pull requests on the [README]({{< relref "/_index.md#contributing-to-the-oracle-weblogic-server-kubernetes-operator-repository" >}}). +Please submit pull requests to the `main` branch unless you are collaborating on a feature and have another target branch. Please see details on the Oracle Contributor Agreement (OCA) and guidelines for pull requests in [Contribute to the operator]({{< relref "/developerguide/contributing#contributing-to-the-oracle-weblogic-server-kubernetes-operator-repository" >}}). We will create git tags for each release candidate and generally available (GA) release of the operator. diff --git a/documentation/3.2/content/developerguide/contributing.md b/documentation/3.2/content/developerguide/contributing.md new file mode 100644 index 00000000000..6c00b96d5ee --- /dev/null +++ b/documentation/3.2/content/developerguide/contributing.md @@ -0,0 +1,42 @@ +--- +title: "Contribute to the operator" +date: 2019-02-23T17:19:19-05:00 +draft: false +weight: 1 +--- + +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. + +#### Contributing to the Oracle WebLogic Server Kubernetes Operator repository + +Pull requests can be made under The Oracle Contributor Agreement (OCA), which is available at [https://www.oracle.com/technetwork/community/oca-486395.html](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 +``` + +This can be automatically added to pull requests by committing with: + +```shell +$ git commit --signoff +``` + +Only pull requests from committers that can be verified as having signed the OCA can be accepted. + +#### Pull request process + +* Fork the repository. +* Create a branch in your fork to implement the changes. We recommend using the issue number as part of your branch name, for example, `1234-fixes`. +* Ensure that any documentation is updated with the changes that are required by your fix. +* Ensure that any samples are updated if the base image has been changed. +* Submit the pull request. Do not leave the pull request blank. Explain exactly what your changes are meant to do and provide simple steps on how to validate your changes. Ensure that you reference the issue you created as well. We will assign the pull request to 2-3 people for review before it is merged. + +#### Introducing a new dependency + +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. diff --git a/documentation/3.2/content/developerguide/documentation.md b/documentation/3.2/content/developerguide/documentation.md index 49b3d5cba55..e453b8f2346 100644 --- a/documentation/3.2/content/developerguide/documentation.md +++ b/documentation/3.2/content/developerguide/documentation.md @@ -9,13 +9,13 @@ This documentation is produced using [Hugo](http://gohugo.io). To make an update to the documentation, follow this process: 1. If you have not already done so, clone the repository. - + ```shell $ git clone https://github.com/oracle/weblogic-kubernetes-operator ``` 2. Create a new branch. - + ```shell $ git checkout -b your-branch ``` @@ -37,5 +37,5 @@ these commands. The site will be available on the URL shown here: 5. When you are ready to submit your changes, push your branch to `origin` and submit a pull request. Remember to follow the guidelines in the -[CONTRIBUTING](https://github.com/oracle/weblogic-kubernetes-operator/blob/main/CONTRIBUTING.md) +[Contribute to the operator]({{< relref "/developerguide/contributing.md" >}}) document. diff --git a/documentation/3.2/content/faq/external-clients.md b/documentation/3.2/content/faq/external-clients.md index 5c3f1d80930..4b32b9f942b 100644 --- a/documentation/3.2/content/faq/external-clients.md +++ b/documentation/3.2/content/faq/external-clients.md @@ -3,7 +3,7 @@ title: "External WebLogic clients" date: 2019-11-21T21:23:03Z draft: false weight: 11 -description: "This FAQ describes approaches for giving external WebLogic clients or servers access to a Kubernetes hosted WebLogic cluster JMS or EJBs, and for giving Kubernetes hosted clients or servers access to remotely hosted WebLogic JMS or EJBs." +description: "This FAQ describes approaches for giving WebLogic applications access to WebLogic JMS or EJB resources when either the applications or their resources are located in Kubernetes. This includes between different Kubernetes namespaces within the same Kubernentes cluster, between different Kubernetes clusters, and between a non-Kubernetes location and Kubernetes." --- #### Contents @@ -27,15 +27,100 @@ description: "This FAQ describes approaches for giving external WebLogic clients #### Overview -When WebLogic clients and servers are external to Kubernetes, and you want to give them access to Kubernetes hosted WebLogic cluster EJBs and JMS, there are two supported approaches: - - * [Load balancer tunneling](#load-balancer-tunneling) (preferred) - * [Kubernetes `NodePorts`](#kubernetes-nodeports) - -Conversely, if giving a Kubernetes hosted WebLogic Server access to external WebLogic Server EJBs, JMS, or JTA, then consider the following: - - * You may need to [enable unknown host access](#enabling-unknown-host-access) on the external WebLogic Servers. - * Plus, if the target server can be accessed only through a load balancer using HTTP: +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 above 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 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, + if the target resource is in WebLogic cluster `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.service.cluster.local:8001`. + +- The applications should access their target WebLogic Server or cluster + using [a WebLogic custom T3 or T3S channel](#adding-a-weblogic-custom-channel) + that is configured on the target with the following configuration: + - Specify a public address that matches the same fully decorated + DNS address that the applications will use. + - For example, + if the target resource is in WebLogic cluster `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.service.cluster.local`. + - Do not specify a public port. It should be the same as the + the channel's listen port, which is the default. This is because + there is no port mapping between namespaces. + - Do not enable `outbound enabled`. + - There is no need to enable tunneling, and you can continue + to use URLs that begin with `t3` or `t3s`. + Application URLs must specify the channel's port. + +- If the applications run within a WebLogic + Server JVM, then the WebLogic Servers that host the target + EJB or JMS resources may need to be configured to + [enable unknown host access](#enabling-unknown-host-access). + This should not be needed when the public address on the + network channel is configured as directed in the previous bullet. + +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: + - [Load balancer tunneling](#load-balancer-tunneling) (preferred) + - [Kubernetes `NodePorts`](#kubernetes-nodeports) + +- The 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](#enabling-unknown-host-access) + on the WebLogic Servers that host the EJB or JMS resources. + +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](#enabling-unknown-host-access) + on the external WebLogic Server(s). + * Plus, if the target server(s) can be accessed only through a load balancer using HTTP: * [Set up an HTTP tunneling-enabled custom channel](#adding-a-weblogic-custom-channel) on the external WebLogic Servers. * Specify URLs on the source server that resolve to the load balancer's address and that start with `http` instead of `t3`. * Ensure the load balancer configures the HTTP flow to be 'sticky'. @@ -46,33 +131,32 @@ The operator does not currently support external WebLogic JTA access to a Kubern #### Load balancer tunneling -Load balancer tunneling is the preferred approach for giving external clients and servers access to a Kubernetes hosted WebLogic cluster EJB and JMS. This approach involves configuring a network channel on the desired WebLogic cluster that accepts T3 protocol traffic that's tunneled over HTTP, deploying a load balancer that redirects external HTTP network traffic to the desired WebLogic network channel, and ensuring that EJB and JMS clients specify a URL that resolves the load balancer's network address. +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 remote clients will use to access the load balancer. See [Adding a WebLogic custom channel](#adding-a-weblogic-custom-channel) for samples and details. +- 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](#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 OKE/OCI to host your Kubernetes cluster, also see [Using an OCI 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. -- If you are adding access for remote WebLogic Servers, then the Kubernetes hosted servers may need to [enable unknown host access](#enabling-unknown-host-access). +- If you are adding access for applications that are hosted on remote WebLogic Servers, then the Kubernetes hosted servers may need to [enable unknown host access](#enabling-unknown-host-access). -- Remote clients and servers can then access the custom channel using an `http://` URL instead of a `t3://` URL. +- Remote applications can then access the custom channel using an `http://` URL instead of a `t3://` URL. - Review the [Security notes](#security-notes). #### Kubernetes `NodePorts` -Kubernetes `NodePorts` provide an alternative approach for giving external WebLogic EJB or JMS clients 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. - +Kubernetes `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. -{{% notice note %}} The `NodePort` approach is available only when worker nodes are accessible by the clients, for example, when they have public IP addresses. If private worker nodes are used and access to them is possible only through a load balancer or bastion, then the `NodePort` approach is not a valid option to provide access to external clients. +{{% notice note %}} The `NodePort` approach is available only when worker nodes are accessible by the applications, for example, when they have public IP addresses. If private worker nodes are used and access to them is possible only through a load balancer or bastion, then the `NodePort` approach is not a valid option to provide access to external applications. {{% /notice %}} Here are the steps: -- In WebLogic, configure a custom channel for the T3 protocol that specifies an external address and port that are suitable for remote client use. See [Adding a WebLogic custom channel](#adding-a-weblogic-custom-channel). +- 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](#adding-a-weblogic-custom-channel). - Define a Kubernetes `NodePort` to publicly expose the WebLogic ports. See [Setting up a `NodePort`](#setting-up-a-nodeport). @@ -84,11 +168,11 @@ Here are the steps: ##### When is a WebLogic custom channel needed? -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 clients. Instead, you may need to configure an additional dedicated WebLogic custom channel to handle remote EJB or JMS client network traffic. +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 clients, 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 client. This is because remote EJB and JMS clients internally use their client's channel's configured network information to reconnect to WebLogic when needed. (The EJB and JMS clients do not always use the initial URL specified in the client's JNDI context.) +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 clients, only accepts protocols that are explicitly enabled for the channel, and can be configured to be the only channel that accepts EJB/JMS clients 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 clients. Finally, external clients may require access using HTTP tunneling in order 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 clients unsecured access to the WebLogic cluster through the same HTTP path. +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 in order 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. ##### Configuring a WebLogic custom channel @@ -96,9 +180,9 @@ The basic requirements for configuring a custom channel for remote EJB and JMS a - 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 clients can use. For example, if you are providing access to remote clients using a load balancer, then these should match the address and port of the load balancer. +- 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 clients to tunnel through HTTP, then enable HTTP tunneling on each NAP. This is often necessary for load balancers. +- 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. @@ -142,7 +226,7 @@ For example, here is a snippet of a WebLogic domain `config.xml` file for channe ``` -And, here is a snippet of offline WLST code that corresponds to the above `config.xml` file snippet: +Here is a snippet of offline WLST code that corresponds to the above `config.xml` file snippet: ```javascript templateName = "cluster-1-template" @@ -162,6 +246,37 @@ And, here is a snippet of offline WLST code that corresponds to the above `confi set('ClientCertificateEnforced', false) ``` +Here is a snippet of WDT model YAML file configuration that corresponds to the above snippets: + +```yaml +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`. @@ -170,21 +285,21 @@ In this example: - The operator will automatically set the `ListenAddress` on each WebLogic Server for each of its channels. -- Internal clients running in the same Kubernetes cluster as the channel can access the cluster using `t3://DOMAIN_UID-cluster-cluster-1:8001`. +- Internal applications running in the same Kubernetes cluster as the channel can access the cluster using `t3://DOMAIN_UID-cluster-cluster-1:8001`. -- External clients 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`. +- 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`. ##### WebLogic custom channel notes - 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 clients beyond configuring the custom channel - see [Overview](#overview). +- Additional steps are required for external applications beyond configuring the custom channel - see [Overview](#overview). #### Setting up a `NodePort` ##### Getting started -A 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 clients access to JMS or EJBs. +A 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. @@ -227,11 +342,11 @@ spec: |`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 clients 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.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 clients 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.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.| #### Enabling unknown host access @@ -255,12 +370,25 @@ To enable an 'unknown host' source WebLogic Server to initiate EJB, JMS, or JTA - With some cloud providers, a load balancer or `NodePort` may implicitly expose a port to the public Internet. -- If such a port supports a protocol suitable for WebLogic clients, note that WebLogic allows access to JNDI entries, EJB/RMI applications, and JMS by anonymous users by default. +- If such a 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 clients. See [When is a WebLogic custom channel needed?](#when-is-a-weblogic-custom-channel-needed). +- 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?](#when-is-a-weblogic-custom-channel-needed). #### Optional reading -- For sample JMS client code and JMS configuration, see [Run Standalone WebLogic JMS Clients on Kubernetes](https://blogs.oracle.com/weblogicserver/run-standalone-weblogic-jms-clients-on-kubernetes). - -- For a detailed discussion of using T3 in combination with port mapping, see [T3 RMI Communication for WebLogic Server Running on Kubernetes](https://blogs.oracle.com/weblogicserver/t3-rmi-communication-for-weblogic-server-running-on-kubernetes). +- For a description of the WebLogic URL syntax for JMS, EJB, and JNDI applications + see [Understanding WebLogic URLs](https://docs.oracle.com/en/middleware/fusion-middleware/weblogic-server/12.2.1.4/jmsad/best_practice.html#GUID-CFA6D7B9-6059-4098-801C-30F0EE31C1AA). + +- 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 username, + remote password, and remote URL are all configurable. + See [Integrating Remote JMS Destinations](https://docs.oracle.com/en/middleware/fusion-middleware/weblogic-server/12.2.1.4/jmsad/best_practice.html#GUID-9F7CF546-2649-4E5E-B117-ABBB445EA7C1). + +- For a detailed description of using T3 in combination with port mapping, see [T3 RMI Communication for WebLogic Server Running on Kubernetes](https://blogs.oracle.com/weblogicserver/t3-rmi-communication-for-weblogic-server-running-on-kubernetes). diff --git a/documentation/3.2/content/faq/namespace-management.md b/documentation/3.2/content/faq/namespace-management.md index 513017c8cc7..3c709de3c36 100644 --- a/documentation/3.2/content/faq/namespace-management.md +++ b/documentation/3.2/content/faq/namespace-management.md @@ -2,7 +2,7 @@ title: "Managing domain namespaces" date: 2019-09-19T10:41:32-05:00 draft: false -weight: 1 +weight: 2 description: "Considerations for managing namespaces while the operator is running." --- @@ -45,7 +45,7 @@ elkIntegrationEnabled: false externalDebugHttpPort: 30999 externalRestEnabled: false externalRestHttpsPort: 31001 -image: ghcr.io/oracle/weblogic-kubernetes-operator:3.2.1 +image: ghcr.io/oracle/weblogic-kubernetes-operator:3.2.2 imagePullPolicy: IfNotPresent internalDebugHttpPort: 30999 istioEnabled: false @@ -118,7 +118,7 @@ For operators configured to select managed namespaces through the use of a label you simply need to create a namespace with the appropriate labels or with a name that matches the expression, respectively. If you did not choose to enable the value, `enableClusterRoleBinding`, then the operator will not have the necessary -permissions to manage the namespace. You can do this by performing a `helm upgrade` with the values used when installing the +permissions to manage the namespace. You can do this by performing a `helm upgrade` with the values used when installing the Helm release: ```shell diff --git a/documentation/3.2/content/faq/newbie.md b/documentation/3.2/content/faq/newbie.md new file mode 100644 index 00000000000..cc3688db0a5 --- /dev/null +++ b/documentation/3.2/content/faq/newbie.md @@ -0,0 +1,128 @@ +--- +title: "Answers for newcomers" +date: 2019-09-19T10:41:32-05:00 +draft: false +weight: 1 +description: "Answers to commonly asked newcomer questions." +--- +#### What is the WebLogic Server Kubernetes Operator, how can I get started with it, where is its documentation? + +It's all [here]({{< relref "/_index.md" >}}). + +#### How much does it cost? + +The WebLogic Server Kubernetes Operator (the “operator”) is open source and free. + +WebLogic Server 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. + +#### How can I get help? + +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](https://weblogic-slack-inviter.herokuapp.com/). 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!" + +#### WebLogic Server Certification + +**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. + + +#### WebLogic Server Configuration + +**Q:** How is the WebLogic Server domain configured in a container (for example, databases, JMS, and such) that is potentially shared by many domains? + +**A:** In a Kubernetes and container environment, the WebLogic domain home can be externalized to a persistent volume, or supplied in an image (by using a layer on top of a WebLogic Server image). For WebLogic domains that are supplied using an image, the domain logs and store locations optionally can be located on a persistent volume. See the [samples]({{< relref "/samples/simple/_index.md" >}}) in this project. + +When using the 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 Server image you wish to use, a unique identifier for the domain called the `domain-uid`, any PVs or PVC the domain 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 optionally can 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 operator does not specify how a WebLogic domain home configuration is created. You can use WLST, REST, or a very convenient new tool called [WebLogic Server Deploy Tooling](https://github.com/oracle/weblogic-deploy-tooling) (WDT). WDT allows you to compactly specify WebLogic configuration and deployments (including JMS, data sources, applications, authenticators, and such) using a YAML file and a ZIP file (which include the binaries). The operator [samples]({{< relref "/samples/simple/_index.md" >}}) show how to create domains using WLST and using WDT. + + +**Q:** Is the Administration Server required? Node Manager? + +**A:** Certification of both WebLogic running in containers 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. + +*** + +#### Communications + +**Q:** How is location transparency achieved and the communication between WLS instances handled? + +**A:** Inside the Kubernetes cluster, the operator generates a Kubernetes ClusterIP service for each WebLogic Server pod called `DOMAINUID-WEBLOGICSERVERNAME` and for each WebLogic cluster called `DOMAINUID-cluster-CLUSTERNAME`. The operator also overrides your WebLogic network listen address configuration to reflect the service names so that you don't need to do this. The services act as DNS names, and allow the pods with WebLogic Servers to move to different nodes in the Kubernetes cluster and continue communicating with other servers. + +**Q:** How is communication from outside the Kubernetes cluster handled? + +**A:** + +* _HTTP communication to your applications from locations outside the cluster_: Typically, this is accomplished by deploying a load balancer that redirects traffic to your domain's Kubernetes services (the operator automatically deploys these services for you); see [Ingress]({{< relref "/userguide/managing-domains/ingress/_index.md" >}}). +For an example, see the Quick Start, [Install the operator and ingress controller]({{< relref "/quickstart/install.md" >}}). + +* _JMS, EJB, and other types of RMI communication with locations outside of the Kubernetes cluster_: This is typically accomplished by tunneling the RMI traffic over HTTP through a load balancer or, less commonly accomplished by using T3 or T3S directly with Kubernetes NodePorts; see [External WebLogic clients]({{< relref "/faq/external-clients.md" >}}). + +* _Access the WebLogic Server Administration Console_: This can be done through a load balancer; see the [Model in Image]({{< relref "/samples/simple/domains/model-in-image/_index.md" >}}) sample. Or, this can be done through a Kubernetes NodePort service; run `$ kubectl explain domain.spec.adminServer.adminService.channels`. + +* _Access the WebLogic Server Remote Console_: This can be done using a load balancer or Kubernetes NodePort service; see [Use the Remote Console]({{< relref "/userguide/managing-domains/accessing-the-domain/admin-console.md" >}}). + + +**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 certified on Flannel and Calico, which support unicast only. + +*** + +**Q:** For binding EJBs (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 using RMI/EJB/JMS/JTA/and such, or that share RMI/EJB/JMS/JTA/and such 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`). + +*** + +#### Load Balancers + +**Q:** Load balancing and failover inside a DataCenter (HTTPS and T3s)? + +**A:** We originally certified on Traefik with the Kubernetes cluster; this is a very basic load balancer. We have also certified other more sophisticated load balancers. See [Ingress]({{< relref "/userguide/managing-domains/ingress/_index.md" >}}). + +*** + +#### Life Cycle and Scaling + +**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 preconfigured Managed Servers) or a dynamic WebLogic cluster (a cluster that uses templated Managed Servers) using different methods. See [Scaling]({{< relref "/userguide/managing-domains/domain-lifecycle/scaling.md" >}}). +* 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 made open source the [WebLogic Monitoring Exporter](https://github.com/oracle/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. + + +**Q:** Container life cycle: How to properly spin up and gracefully shut down 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 WebLogic Server is alive. +* Readiness probe – query if the WebLogic Server is ready to receive requests. +* Shutdown hook – gracefully shut down WebLogic Server. + +These operations also can be done manually using the Kubernetes command-line interface, `kubectl`. + +For more information, see the [Domain life cycle]({{< relref "/userguide/managing-domains/domain-lifecycle/_index.md" >}}) documentation. + +*** + + +#### Patching and Upgrades + +**Q:** Patching: rolling upgrades, handling of one-off-patches and overlays, CPUs, and such. + +**A:** For relevant information, see [Apply patched images to a running domain]({{< relref "/userguide/base-images/#apply-patched-images-to-a-running-domain" >}}), [Rolling restarts]({{< relref "/userguide/managing-domains/domain-lifecycle/restarting#overview" >}}), and [CI/CD considerations]({{< relref "/userguide/cicd/_index.md" >}}). + +*** + + +#### Diagnostics and Logging + +**Q:** Integration with ecosystems: logging, monitoring (OS, JVM and application level), and such. + +**A:** WebLogic Server `stdout` logging is echoed to their pod logs by default, and WebLogic Server file logs are optionally persisted to an external volume. We are working on a project to integrate WebLogic Server logs with the Elastic Stack. See [Elastic Stack]({{< relref "/samples/simple/elastic-stack/_index.md" >}}). + +With regards to monitoring, all the tools that are traditionally used to monitor WebLogic Server can be used running in containers and Kubernetes. In addition, as mentioned previously, we have developed the [WebLogic Monitoring Exporter](https://github.com/oracle/weblogic-monitoring-exporter), which exports WebLogic metrics in a format that can be read and displayed in dashboards like Prometheus and Grafana. diff --git a/documentation/3.2/content/quickstart/get-images.md b/documentation/3.2/content/quickstart/get-images.md index a5c474bea89..b83ee96a9f4 100644 --- a/documentation/3.2/content/quickstart/get-images.md +++ b/documentation/3.2/content/quickstart/get-images.md @@ -10,7 +10,7 @@ weight: 3 1. Pull the operator image: ```shell - $ docker pull ghcr.io/oracle/weblogic-kubernetes-operator:3.2.1 + $ docker pull ghcr.io/oracle/weblogic-kubernetes-operator:3.2.2 ``` 1. Pull the Traefik ingress controller image: @@ -21,7 +21,7 @@ weight: 3 1. Obtain the WebLogic Server image from the [Oracle Container Registry](https://container-registry.oracle.com). - a. First time users, follow these [directions]({{< relref "/userguide/managing-domains/domain-in-image/base-images/_index.md#obtaining-standard-images-from-the-oracle-container-registry" >}}). + a. First time users, follow these [directions]({{< relref "/userguide/base-images/_index.md#obtain-standard-images-from-the-oracle-container-registry" >}}). b. Find and then pull the WebLogic 12.2.1.4 install image: diff --git a/documentation/3.2/content/quickstart/install.md b/documentation/3.2/content/quickstart/install.md index 9505dff64e4..89229346f94 100644 --- a/documentation/3.2/content/quickstart/install.md +++ b/documentation/3.2/content/quickstart/install.md @@ -50,7 +50,7 @@ $ helm install traefik-operator traefik/traefik \ ```shell $ helm install sample-weblogic-operator kubernetes/charts/weblogic-operator \ --namespace sample-weblogic-operator-ns \ - --set image=ghcr.io/oracle/weblogic-kubernetes-operator:3.2.1 \ + --set image=ghcr.io/oracle/weblogic-kubernetes-operator:3.2.2 \ --set serviceAccount=sample-weblogic-operator-sa \ --set "enableClusterRoleBinding=true" \ --set "domainNamespaceSelectionStrategy=LabelSelector" \ diff --git a/documentation/3.2/content/quickstart/prerequisites.md b/documentation/3.2/content/quickstart/prerequisites.md index 4729e5d819d..855258360a6 100644 --- a/documentation/3.2/content/quickstart/prerequisites.md +++ b/documentation/3.2/content/quickstart/prerequisites.md @@ -12,5 +12,5 @@ The operator uses Helm to create and deploy the necessary resources and then run You should clone this repository to your local machine so that you have access to the various sample files mentioned throughout this guide: ```shell -$ git clone --branch v3.2.1 https://github.com/oracle/weblogic-kubernetes-operator +$ git clone --branch v3.2.2 https://github.com/oracle/weblogic-kubernetes-operator ``` diff --git a/documentation/3.2/content/release-notes.md b/documentation/3.2/content/release-notes.md index 6144f134bd9..cdb91ad44a1 100644 --- a/documentation/3.2/content/release-notes.md +++ b/documentation/3.2/content/release-notes.md @@ -8,6 +8,7 @@ draft: false | Date | Version | Introduces backward incompatibilities? | Change | | --- | --- | --- | --- | +| April 27, 2021 | v3.2.2 | no | Resolved a set of issues with many related to reducing the operator's network utilization. | | April 5, 2021 | v3.2.1 | no | Updated several dependencies, including the Oracle Linux base for the container image. | | March 31, 2021 | v3.2.0 | no | Online updates for dynamic changes for Model in Image, injection of the WebLogic Monitoring Exporter, other features, and a significant number of additional fixes. | | March 1, 2021 | v3.1.4 | no | Resolved an issue where the operator would ignore live data that was older than cached data, such as following an etcd restore and updated Kubernetes Java Client and Bouncy Castle dependencies. | @@ -38,6 +39,17 @@ draft: false ### Change log +#### Operator 3.2.2 + +* Resolved an issue where the operator would retry Kubernetes API requests that timed out without a backoff causing increased network utilization ([#2300](https://github.com/oracle/weblogic-kubernetes-operator/pull/2300)). +* Resolved an issue where the operator would select the incorrect WebLogic Server port for administrative traffic ([#2301](https://github.com/oracle/weblogic-kubernetes-operator/pull/2301)). +* Resolved an issue where the operator, when running in a large and heavily loaded Kubernetes cluster, would not properly detect when a domain had been deleted and recreated ([#2305](https://github.com/oracle/weblogic-kubernetes-operator/pull/2305) and [#2314](https://github.com/oracle/weblogic-kubernetes-operator/pull/2314)). +* Resolved an issue where the operator would fail to recover and begin processing in a namespace if the operator did not immediately have privileges in that namespace when it was first detected ([#2315](https://github.com/oracle/weblogic-kubernetes-operator/pull/2315)). +* The operator logs a message when it cannot generate a `NamespaceWatchingStopped` Event in a namespace because the operator no longer has privileges in that namespace ([#2323](https://github.com/oracle/weblogic-kubernetes-operator/pull/2323)). +* Resolved an issue where the operator would repeatedly replace a ConfigMap causing increased network utilization ([#2321](https://github.com/oracle/weblogic-kubernetes-operator/pull/2321)). +* Resolved an issue where the operator would repeatedly read a Secret causing increased network utilization ([#2326](https://github.com/oracle/weblogic-kubernetes-operator/pull/2326)). +* Resolved an issue where the operator was not honoring `domain.spec.adminServer.serverService` ([#2334](https://github.com/oracle/weblogic-kubernetes-operator/pull/2334)). + #### Operator 3.2.1 Updated several dependencies, including the Oracle Linux base for the container image. diff --git a/documentation/3.2/content/samples/simple/azure-kubernetes-service/domain-on-pv.md b/documentation/3.2/content/samples/simple/azure-kubernetes-service/domain-on-pv.md index 326bcb36e01..518eac4a15f 100644 --- a/documentation/3.2/content/samples/simple/azure-kubernetes-service/domain-on-pv.md +++ b/documentation/3.2/content/samples/simple/azure-kubernetes-service/domain-on-pv.md @@ -29,7 +29,7 @@ This sample demonstrates how to use the [Oracle WebLogic Server Kubernetes Opera Clone the [Oracle WebLogic Server Kubernetes Operator repository](https://github.com/oracle/weblogic-kubernetes-operator) to your machine. We will use several scripts in this repository to create a WebLogic domain. This sample was tested with v3.1.1, but should work with the latest release. ```shell -$ git clone --branch v3.2.1 https://github.com/oracle/weblogic-kubernetes-operator.git +$ git clone --branch v3.2.2 https://github.com/oracle/weblogic-kubernetes-operator.git ``` {{% notice info %}} The following sections of the sample instructions will guide you, step-by-step, through the process of setting up a WebLogic cluster on AKS - remaining as close as possible to a native Kubernetes experience. This lets you understand and customize each step. If you wish to have a more automated experience that abstracts some lower level details, you can skip to the [Automation](#automation) section. diff --git a/documentation/3.2/content/samples/simple/azure-kubernetes-service/model-in-image.md b/documentation/3.2/content/samples/simple/azure-kubernetes-service/model-in-image.md index 70a460a3718..e3dd5ab9b30 100644 --- a/documentation/3.2/content/samples/simple/azure-kubernetes-service/model-in-image.md +++ b/documentation/3.2/content/samples/simple/azure-kubernetes-service/model-in-image.md @@ -30,7 +30,7 @@ This sample demonstrates how to use the [Oracle WebLogic Server Kubernetes Opera Clone the [Oracle WebLogic Server Kubernetes Operator repository](https://github.com/oracle/weblogic-kubernetes-operator) to your machine. We will use several scripts in this repository to create a WebLogic domain. This sample was tested with v3.1.1, but should work with the latest release. ```shell -$ git clone --branch v3.2.1 https://github.com/oracle/weblogic-kubernetes-operator.git +$ git clone --branch v3.2.2 https://github.com/oracle/weblogic-kubernetes-operator.git ``` ```shell $ cd weblogic-kubernetes-operator diff --git a/documentation/3.2/content/samples/simple/domains/domain-home-in-image/_index.md b/documentation/3.2/content/samples/simple/domains/domain-home-in-image/_index.md index af241554fd2..81c43b56157 100644 --- a/documentation/3.2/content/samples/simple/domains/domain-home-in-image/_index.md +++ b/documentation/3.2/content/samples/simple/domains/domain-home-in-image/_index.md @@ -14,7 +14,7 @@ Before you begin, read this document, [Domain resource]({{< relref "/userguide/m The following prerequisites must be met prior to running the create domain script: * The WebLogic Deploy Tooling (WDT) sample requires that `JAVA_HOME` is set to a Java JDK version 1.8 or later. -* The operator requires either Oracle WebLogic Server 12.2.1.3.0 with patch 29135930 applied, or Oracle WebLogic Server 12.2.1.4.0, or Oracle WebLogic Server 14.1.1.0.0. The existing WebLogic Server image, `container-registry.oracle.com/middleware/weblogic:12.2.1.3`, has all the necessary patches applied. For details on how to obtain or create the image, see [WebLogic Server images]({{< relref "/userguide/managing-domains/domain-in-image/base-images/_index.md#creating-or-obtaining-weblogic-server-images" >}}). +* The operator requires either Oracle WebLogic Server 12.2.1.3.0 with patch 29135930 applied, or Oracle WebLogic Server 12.2.1.4.0, or Oracle WebLogic Server 14.1.1.0.0. The existing WebLogic Server image, `container-registry.oracle.com/middleware/weblogic:12.2.1.3`, has all the necessary patches applied. For details on how to obtain or create the image, see [WebLogic Server images]({{< relref "/userguide/base-images/_index.md#create-or-obtain-weblogic-server-images" >}}). * Create a Kubernetes Namespace for the domain unless you intend to use the default namespace. * If `logHomeOnPV` is enabled, create the Kubernetes PersistentVolume where the log home will be hosted, and the Kubernetes PersistentVolumeClaim for the domain in the same Kubernetes Namespace. For samples to create a PV and PVC, see [Create sample PV and PVC]({{< relref "/samples/simple/storage/_index.md" >}}). * Create a Kubernetes Secret for the WebLogic administrator credentials that contains the fields `username` and `password`, and make sure that the secret name matches the value specified for `weblogicCredentialsSecretName`; see [Configuration parameters](#configuration-parameters) below. For example: @@ -139,7 +139,7 @@ The following parameters can be provided in the inputs file. | `adminServerName` | Name of the Administration Server. | `admin-server` | | `clusterName` | Name of the WebLogic cluster instance to generate for the domain. | `cluster-1` | | `configuredManagedServerCount` | Number of Managed Server instances to generate for the domain. | `5` | -| `domainHomeImageBase` | Base WebLogic binary image used to build the WebLogic domain image. The operator requires either Oracle WebLogic Server 12.2.1.3.0 with patch 29135930 applied, or Oracle WebLogic Server 12.2.1.4.0, or Oracle WebLogic Server 14.1.1.0.0. The existing WebLogic Server image, `container-registry.oracle.com/middleware/weblogic:12.2.1.3`, has all the necessary patches applied. For details on how to obtain or create the image, see [WebLogic Server images]({{< relref "/userguide/managing-domains/domain-in-image/base-images/_index.md#creating-or-obtaining-weblogic-server-images" >}}). | `container-registry.oracle.com/middleware/weblogic:12.2.1.3` | +| `domainHomeImageBase` | Base WebLogic binary image used to build the WebLogic domain image. The operator requires either Oracle WebLogic Server 12.2.1.3.0 with patch 29135930 applied, or Oracle WebLogic Server 12.2.1.4.0, or Oracle WebLogic Server 14.1.1.0.0. The existing WebLogic Server image, `container-registry.oracle.com/middleware/weblogic:12.2.1.3`, has all the necessary patches applied. For details on how to obtain or create the image, see [WebLogic Server images]({{< relref "/userguide/base-images/_index.md#create-or-obtain-weblogic-server-images" >}}). | `container-registry.oracle.com/middleware/weblogic:12.2.1.3` | | `domainHomeImageBuildPath` | Location of the WebLogic "domain home in image" image in the `https://github.com/oracle/docker-images.git` project. If not specified, use `./docker-images/OracleWebLogic/samples/12213-domain-home-in-image`. Another possible value is `./docker-images/OracleWebLogic/samples/12213-domain-home-in-image-wdt` which uses WDT, instead of WLST, to generate the domain configuration. | `./docker-images/OracleWebLogic/samples/12213-domain-home-in-image` | | `domainPVMountPath` | Mount path of the domain persistent volume. This parameter is required if `logHomeOnPV` is true. Otherwise, it is ignored. | `/shared` | | `domainUID` | Unique ID that will be used to identify this particular domain. Used as the name of the generated WebLogic domain as well as the name of the Domain. 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. | `domain1` | diff --git a/documentation/3.2/content/samples/simple/domains/domain-home-on-pv/_index.md b/documentation/3.2/content/samples/simple/domains/domain-home-on-pv/_index.md index a1dc84f4ac0..16383530ace 100644 --- a/documentation/3.2/content/samples/simple/domains/domain-home-on-pv/_index.md +++ b/documentation/3.2/content/samples/simple/domains/domain-home-on-pv/_index.md @@ -15,7 +15,7 @@ Before you begin, read this document, [Domain resource]({{< relref "/userguide/m The following prerequisites must be met prior to running the create domain script: * Make sure the WebLogic Server Kubernetes Operator is running. -* The operator requires either Oracle WebLogic Server 12.2.1.3.0 with patch 29135930 applied, or Oracle WebLogic Server 12.2.1.4.0, or Oracle WebLogic Server 14.1.1.0.0. The existing WebLogic Server image, `container-registry.oracle.com/middleware/weblogic:12.2.1.3`, has all the necessary patches applied. For details on how to obtain or create the image, see [WebLogic Server images]({{< relref "/userguide/managing-domains/domain-in-image/base-images/_index.md#creating-or-obtaining-weblogic-server-images" >}}). +* The operator requires either Oracle WebLogic Server 12.2.1.3.0 with patch 29135930 applied, or Oracle WebLogic Server 12.2.1.4.0, or Oracle WebLogic Server 14.1.1.0.0. The existing WebLogic Server image, `container-registry.oracle.com/middleware/weblogic:12.2.1.3`, has all the necessary patches applied. For details on how to obtain or create the image, see [WebLogic Server images]({{< relref "/userguide/base-images/_index.md#create-or-obtain-weblogic-server-images" >}}). * Create a Kubernetes Namespace for the domain unless you intend to use the default namespace. * In the same Kubernetes Namespace, create the Kubernetes PersistentVolume (PV) where the domain home will be hosted, and the Kubernetes PersistentVolumeClaim (PVC) for the domain. For samples to create a PV and PVC, see [Create sample PV and PVC]({{< relref "/samples/simple/storage/_index.md" >}}). By default, the `create-domain.sh` script creates a domain with the `domainUID` set to `domain1` and expects the PVC `domain1-weblogic-sample-pvc` to be present. You can create `domain1-weblogic-sample-pvc` using [create-pv-pvc.sh](https://github.com/oracle/weblogic-kubernetes-operator/blob/main/kubernetes/samples/scripts/create-weblogic-domain-pv-pvc/create-pv-pvc.sh) with an inputs file that has the `domainUID` set to `domain1`. * Create the Kubernetes Secrets `username` and `password` of the administrative account in the same Kubernetes Namespace as the domain. @@ -113,7 +113,7 @@ The following parameters can be provided in the inputs file. | `exposeAdminNodePort` | Boolean indicating if the Administration Server is exposed outside of the Kubernetes cluster. | `false` | | `exposeAdminT3Channel` | Boolean indicating if the T3 administrative channel is exposed outside the Kubernetes cluster. | `false` | | `httpAccessLogInLogHome` | Boolean indicating if server HTTP access log files should be written to the same directory as `logHome`. Otherwise, server HTTP access log files will be written to the directory specified in the WebLogic domain home configuration. | `true` | -| `image` | WebLogic Server image. The operator requires either Oracle WebLogic Server 12.2.1.3.0 with patch 29135930 applied, or Oracle WebLogic Server 12.2.1.4.0, or Oracle WebLogic Server 14.1.1.0.0. The existing WebLogic Server image, `container-registry.oracle.com/middleware/weblogic:12.2.1.3`, has all the necessary patches applied. For details on how to obtain or create the image, see [WebLogic Server images]({{< relref "/userguide/managing-domains/domain-in-image/base-images/_index.md#creating-or-obtaining-weblogic-server-images" >}}). | `container-registry.oracle.com/middleware/weblogic:12.2.1.3` | +| `image` | WebLogic Server image. The operator requires either Oracle WebLogic Server 12.2.1.3.0 with patch 29135930 applied, or Oracle WebLogic Server 12.2.1.4.0, or Oracle WebLogic Server 14.1.1.0.0. The existing WebLogic Server image, `container-registry.oracle.com/middleware/weblogic:12.2.1.3`, has all the necessary patches applied. For details on how to obtain or create the image, see [WebLogic Server images]({{< relref "/userguide/base-images/_index.md#create-or-obtain-weblogic-server-images" >}}). | `container-registry.oracle.com/middleware/weblogic:12.2.1.3` | | `imagePullPolicy` | WebLogic Server image pull policy. Legal values are `IfNotPresent`, `Always`, or `Never` | `IfNotPresent` | | `imagePullSecretName` | Name of the Kubernetes Secret to access the container registry to pull the WebLogic Server image. The presence of the secret will be validated when this parameter is specified | | | `includeServerOutInPodLog` | Boolean indicating whether to include the server `.out` in the pod's `stdout`. | `true` | diff --git a/documentation/3.2/content/samples/simple/domains/model-in-image/prerequisites.md b/documentation/3.2/content/samples/simple/domains/model-in-image/prerequisites.md index 420cbcdf4f1..f07bb5aab8a 100644 --- a/documentation/3.2/content/samples/simple/domains/model-in-image/prerequisites.md +++ b/documentation/3.2/content/samples/simple/domains/model-in-image/prerequisites.md @@ -23,7 +23,7 @@ weight: 1 $ cd /tmp ``` ```shell - $ git clone --branch v3.2.1 https://github.com/oracle/weblogic-kubernetes-operator.git + $ git clone --branch v3.2.2 https://github.com/oracle/weblogic-kubernetes-operator.git ``` > **Note**: We will refer to the top directory of the operator source tree as `/tmp/weblogic-kubernetes-operator`; however, you can use a different location. @@ -138,7 +138,7 @@ weight: 1 e. Later in this sample, when you run WebLogic Image Tool commands, the tool will use the image as a base image for creating model images. Specifically, the tool will implicitly call `docker pull` for one of the above licensed images as specified in the tool's command line using the `--fromImage` parameter. For `JRF`, this sample specifies `container-registry.oracle.com/middleware/fmw-infrastructure:12.2.1.4`, and for `WLS`, the sample specifies `container-registry.oracle.com/middleware/weblogic:12.2.1.4`. {{% notice info %}} - If you prefer, you can create your own base image and then substitute this image name in the WebLogic Image Tool `--fromImage` parameter throughout this sample. For example, you may wish to start with a base image that has patches applied. See [Preparing a Base Image]({{< relref "/userguide/managing-domains/domain-in-image/base-images/_index.md" >}}). + If you prefer, you can create your own base image and then substitute this image name in the WebLogic Image Tool `--fromImage` parameter throughout this sample. For example, you may wish to start with a base image that has patches applied. See [Preparing a Base Image]({{< relref "/userguide/base-images/_index.md" >}}). {{% /notice %}} 1. Download the latest [WebLogic Deploy Tooling](https://github.com/oracle/weblogic-deploy-tooling) (WDT) and [WebLogic Image Tool](https://github.com/oracle/weblogic-image-tool) (WIT) installer ZIP files to your `/tmp/mii-sample/model-images` directory. Both WDT and WIT are required to create your Model in Image container images. diff --git a/documentation/3.2/content/samples/simple/tanzu-kubernetes-service/_index.md b/documentation/3.2/content/samples/simple/tanzu-kubernetes-service/_index.md index f2d450d0b16..776845dab0a 100644 --- a/documentation/3.2/content/samples/simple/tanzu-kubernetes-service/_index.md +++ b/documentation/3.2/content/samples/simple/tanzu-kubernetes-service/_index.md @@ -63,7 +63,7 @@ Kubernetes Operators use [Helm](https://helm.sh/) to manage Kubernetes applicati Clone the repository. ```shell -$ git clone --branch v3.2.1 https://github.com/oracle/weblogic-kubernetes-operator.git +$ git clone --branch v3.2.2 https://github.com/oracle/weblogic-kubernetes-operator.git ``` ```shell $ cd weblogic-kubernetes-operator diff --git a/documentation/3.2/content/userguide/base-images/_index.md b/documentation/3.2/content/userguide/base-images/_index.md new file mode 100644 index 00000000000..d6f11782cee --- /dev/null +++ b/documentation/3.2/content/userguide/base-images/_index.md @@ -0,0 +1,238 @@ +--- +title: "WebLogic Server images" +date: 2019-02-23T16:45:55-05:00 +weight: 4 +description: "Create or obtain WebLogic Server images." +--- + +#### Contents + +* [Create or obtain WebLogic Server images](#create-or-obtain-weblogic-server-images) +* [Set up secrets to access the Oracle Container Registry](#set-up-secrets-to-access-the-oracle-container-registry) +* [Obtain standard images from the Oracle Container Registry](#obtain-standard-images-from-the-oracle-container-registry) +* [Create a custom image with patches applied](#create-a-custom-image-with-patches-applied) +* [Create a custom image with your domain inside the image](#create-a-custom-image-with-your-domain-inside-the-image) +* [Patch WebLogic Server images](#patch-weblogic-server-images) +* [Apply patched images to a running domain](#apply-patched-images-to-a-running-domain) + + +#### Create or obtain WebLogic Server images + +You will need container images to run your WebLogic domains in Kubernetes. +There are two main options available: + +* Use an image which contains the WebLogic Server binaries but + not the domain, or +* Use an image which contains both the WebLogic Server binaries + and the domain directory. + +If you want to use the first option, then you will need to obtain the standard +WebLogic Server image from the Oracle Container Registry; see [Obtain standard images from the Oracle Container Registry](#obtain-standard-images-from-the-oracle-container-registry). +This image already contains the mandatory patches applied, as described in [Create a custom image with patches applied](#create-a-custom-image-with-patches-applied). +If you want to use additional patches, you can customize that process to include additional patches. + +If you want to use the second option, which includes the domain directory +inside the image, then you will need to build your own images, +as described in [Create a custom image with your domain inside the image](#create-a-custom-image-with-your-domain-inside-the-image). + +#### Set up secrets to access the Oracle Container Registry + +{{% notice note %}} +This version of the operator requires WebLogic Server 12.2.1.3.0 plus patch 29135930; the standard image, `container-registry.oracle.com/middleware/weblogic:12.2.1.3`, already includes this patch pre-applied. Images for WebLogic Server 12.2.1.4.0 do not require any patches. +{{% /notice %}} + +In order for Kubernetes to obtain the WebLogic Server image from the Oracle Container Registry (OCR), which requires authentication, a Kubernetes Secret containing the registry credentials must be created. To create a secret with the OCR credentials, issue the following command: + +```shell +$ kubectl create secret docker-registry SECRET_NAME \ + -n NAMESPACE \ + --docker-server=container-registry.oracle.com \ + --docker-username=YOUR_USERNAME \ + --docker-password=YOUR_PASSWORD \ + --docker-email=YOUR_EMAIL +``` + +In this command, replace the uppercase items with the appropriate values. The `SECRET_NAME` will be needed in later parameter files. The `NAMESPACE` must match the namespace where the first domain will be deployed, otherwise, Kubernetes will not be able to find it. + +It may be preferable to manually pull the image in advance, on each Kubernetes worker node, as described in the next section. +If you choose this approach, you do not require the Kubernetes Secret. + +#### Obtain standard images from the Oracle Container Registry + +The Oracle Container Registry contains images for licensed commercial Oracle software products that you may use in your enterprise. To access the Oracle Registry Server, you must have an Oracle Single Sign-On (SSO) account. The Oracle Container Registry provides a web interface that allows an administrator to authenticate and then to select the images for the software that your organization wishes to use. Oracle Standard Terms and Restrictions terms must be agreed to using the web interface. After the Oracle Standard Terms and Restrictions have been accepted, you can pull images of the software from the Oracle Container Registry using the standard `docker pull` command. + +To pull an image from the Oracle Container Registry, in a web browser, navigate to https://container-registry.oracle.com and log in +using the Oracle Single Sign-On authentication service. If you do not already have SSO credentials, at the top of the page, click the Sign In link to create them. + +Use 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 is stored in a database that links the software images to your Oracle Single Sign-On login credentials. + +The Oracle Container Registry provides a WebLogic Server 12.2.1.3.0 image, which already has the necessary patches applied, and the Oracle WebLogic Server 12.2.1.4.0 and 14.1.1.0.0 images, which do not require any patches. + +First, you will need to log in to the Oracle Container Registry: + +```shell +$ docker login container-registry.oracle.com +``` + +Then, you can pull the image with this command: + +```shell +$ docker pull container-registry.oracle.com/middleware/weblogic:12.2.1.4 +``` +If desired, you can: + +* Check the WLS version with `docker run container-registry.oracle.com/middleware/weblogic:12.2.1.4 sh -c` `'source $ORACLE_HOME/wlserver/server/bin/setWLSEnv.sh > /dev/null 2>&1 && java weblogic.version'` + +* Check the WLS patches with `docker run container-registry.oracle.com/middleware/weblogic:12.2.1.4 sh -c` `'$ORACLE_HOME/OPatch/opatch lspatches'` + +Additional information about using this image is available in the Oracle Container Registry. + +#### Create a custom image with patches applied + +The Oracle WebLogic Server Kubernetes Operator and WebLogic Server 12.2.1.3.0 image requires patch 29135930. +This patch has some prerequisite patches that will also need to be applied. The WebLogic Server 12.2.1.4.0 image does not require any patches. To create and customize the WebLogic Server image, +and apply the required patches, use the [WebLogic Image Tool](https://github.com/oracle/weblogic-image-tool). + +To use the Image Tool, follow the [Setup](https://github.com/oracle/weblogic-image-tool/blob/master/README.md#setup) instructions +and [Quick Start](https://github.com/oracle/weblogic-image-tool/blob/master/site/quickstart.md) Guide. + +To build the WebLogic Server image and apply the patches: + +1. Add the Server JRE and the WebLogic Server installer to the [`cache` command](https://github.com/oracle/weblogic-image-tool/blob/master/site/cache.md). + + ```shell + $ imagetool cache addInstaller \ + --type=jdk \ + --version=8u241 \ + --path=/home/acmeuser/wls-installers/jre-8u241-linux-x64.tar.gz + ``` + ```shell + $ imagetool cache addInstaller \ + --type=wls \ + --version=12.2.1.4.0 \ + --path=/home/acmeuser/wls-installers/fmw_12.2.1.4.0_wls_Disk1_1of1.zip + ``` +2. Use the [Create Tool](https://github.com/oracle/weblogic-image-tool/blob/master/site/create-image.md) +to build the image and apply the patches. + + For the Create Tool to download the patches, you must supply your My Oracle Support credentials. + ```shell + $ imagetool create \ + --tag=weblogic:12.2.1.3 \ + --type=wls \ + --version=12.2.1.3.0 \ + --jdkVersion=8u241 \ + -–patches=29135930_12.2.1.3.0,27117282_12.2.1.3.0 \ + --user=username.mycompany.com \ + --passwordEnv=MYPWD + ``` + +3. After the tool creates the image, verify that the image is in your local repository: + + ```shell + $ docker images + ``` +#### Create a custom image with your domain inside the image + +You can also create an image with the WebLogic domain inside the image. +[Samples]({{< relref "/samples/simple/domains/domain-home-in-image/_index.md" >}}) +are provided that demonstrate how to create the image using either: + +* WLST to define the domain, or +* [WebLogic Deploy Tooling](https://github.com/oracle/weblogic-deploy-tooling) to define the domain. + +In these samples, you will see a reference to a "base" or `FROM` image. You should use an image +with the mandatory patches installed as this base image. This image could be either +the standard `container-registry.oracle.com/middleware/weblogic:12.2.1.3` pre-patched image or an image you created using the instructions above. +WebLogic Server 12.2.1.4.0 images do not require patches. + +{{% notice warning %}} +Oracle strongly recommends storing a domain image as private in the registry. +A container image that contains a WebLogic domain home has sensitive information +including keys and credentials that are used to access external resources +(for example, the data source password). For more information, see +[WebLogic domain in container image protection]({{}}). +{{% /notice %}} + +#### Patch WebLogic Server images + +Use the [WebLogic Image Tool](https://github.com/oracle/weblogic-image-tool) (WIT) to patch +WebLogic Server images with quarterly Patch Set Updates (PSUs), which include security fixes, or with one-off patches. + +Use either the WIT [`create`](https://github.com/oracle/weblogic-image-tool/blob/master/site/create-image.md) or +[`update`](https://github.com/oracle/weblogic-image-tool/blob/master/site/update-image.md) command, however, +patching using the `create` command results in a smaller WebLogic Server image size. Note that you will need to +download the WebLogic Server 12.2.1.4.0 installer and JDK installer prior to running the `create` command. For details, see +the WIT [Quick Start](https://github.com/oracle/weblogic-image-tool/blob/master/site/quickstart.md) guide. + +Example: Create an image named `sample:wls` with the WebLogic Server 12.2.1.4.0 slim installer, JDK 8u291, a slim version of the Oracle Linux 7 container image, +and latest PSU and recommended CPU and SPU patches applied. + +```shell +$ imagetool create --tag sample:wls --type=wlsslim --recommendedPatches --pull --user testuser@xyz.com --password hello --version=12.2.1.4.0 --jdkVersion=8u291 +``` + +#### Apply patched images to a running domain + +When updating the WebLogic binaries of a running domain in Kubernetes with a patched container image, +the operator applies the update in a zero downtime fashion. The procedure for the operator +to update the running domain differs depending on the [domain home source type]({{< relref "/userguide/managing-domains/choosing-a-model/_index.md" >}}). One +difference between the domain home source types is the location of the domain home: + +* Domain in PV: The container image contains the JDK and WebLogic Server binaries. The domain home is located in a Persistent Volume (PV). +* Model in Image: The container image contains the JDK, WebLogic Server binaries, and a [WebLogic Deployment Tooling](https://github.com/oracle/weblogic-deploy-tooling) (WDT) installation, WDT model file, and application archive file. +* Domain in Image: The container image contains the JDK, WebLogic Server binaries, and domain home. + +For Domain in PV, the operator can apply the update to the running domain without modifying the patched container image. For Model in Image (MII) and Domain in Image, +before the operator can apply the update, the patched container images must be modified to add the domain home or a +WDT model and archive. You use WebLogic Image Tool (WIT) [Rebase Image](https://github.com/oracle/weblogic-image-tool/blob/master/site/rebase-image.md) +to update the Oracle Home of the original image using the patched Oracle Home from a patched container image. + +In all three domain home source types, you edit the [Domain Resource]({{< relref "/userguide/managing-domains/domain-resource#domain-resource-attribute-references" >}}) +to inform the operator of the name of the new patched image so that it can manage the update of the WebLogic domain. + +For a broader description of managing the evolution and mutation of container images to run WebLogic Server in Kubernetes, see [CI/CD]({{< relref "/userguide/cicd/_index.md" >}}). + +##### Domain in PV + +Edit the Domain Resource image reference with the new image name/tag (for example, `oracle/weblogic:12.2.1.4-patched`). +Then, the operator performs a [rolling restart]({{< relref "/userguide/managing-domains/domain-lifecycle/restarting#overview" >}}) +of the WebLogic domain to update the Oracle Home of the servers. +For information on server restarts, see [Restarting]({{< relref "/userguide/managing-domains/domain-lifecycle/restarting.md" >}}). + +##### Model in Image +Use the WIT [`rebase`](https://github.com/oracle/weblogic-image-tool/blob/master/site/rebase-image.md) command +to update the Oracle Home for an existing image with the model and archive files in the image using the patched Oracle Home from a +patched container image. Then, the operator performs a [rolling update]({{< relref "/userguide/managing-domains/domain-lifecycle/restarting#overview" >}}) +of the domain, updating the Oracle Home of each server pod. + + +Example: WIT copies a WDT model and WDT archive from the source image, `mydomain:v1`,  +to a new image, `mydomain:v2`, based on a target image named `oracle/weblogic:generic-12.2.1.4.0-patched`.  + +**Note**: Oracle Home and the JDK must be installed in the same directories on each image. + + +```shell +$ imagetool rebase --tag mydomain:v2 --sourceImage mydomain:v1 --targetImage oracle/weblogic:generic-12.2.1.4.0-patched --wdtModelOnly +``` + +Then, edit the Domain Resource image reference with the new image name/tag (`mydomain:2`). + +##### Domain in Image +Use the WIT [`rebase`](https://github.com/oracle/weblogic-image-tool/blob/master/site/rebase-image.md) command to update the Oracle Home +for an existing domain image using the patched Oracle Home from a patched container image. Then, the operator performs a +[rolling update]({{< relref "/userguide/managing-domains/domain-lifecycle/restarting#overview" >}}) of the domain, +updating the Oracle Home of each server pod. + +Example: WIT copies the domain from the source image, `mydomain:v1`, to a new image, `mydomain:v2`, based on a target +image named `oracle/weblogic:12.2.1.4-patched`. + +**Note**: Oracle Home and the JDK must be installed in the same directories on each image. + +```shell +$ imagetool rebase --tag mydomain:v2 --sourceImage mydomain:v1 --targetImage oracle/weblogic:12.2.1.4-patched +``` + +Then, edit the Domain Resource image reference with the new image name/tag (`mydomain:2`). diff --git a/documentation/3.2/content/userguide/cicd/choose-an-approach.md b/documentation/3.2/content/userguide/cicd/choose-an-approach.md index 1da98aee9bc..d84f33a92af 100644 --- a/documentation/3.2/content/userguide/cicd/choose-an-approach.md +++ b/documentation/3.2/content/userguide/cicd/choose-an-approach.md @@ -64,7 +64,7 @@ various approaches. We can start by asking ourselves questions like these: If you need to make an update in a lower layer, then you will need to rebuild that layer and all of the layers above it. This means that you will need to rebuild the - domain layer. In the case of Model in Image, you will need to determine if you need to + domain layer. In the case of Domain in Image, you will need to determine if you need to keep the same domain encryption keys. The diagram below summarizes these concerns in a decision tree for the “domain-in-image” case: diff --git a/documentation/3.2/content/userguide/introduction/architecture.md b/documentation/3.2/content/userguide/introduction/architecture.md index d280edf8270..4fd523741a6 100644 --- a/documentation/3.2/content/userguide/introduction/architecture.md +++ b/documentation/3.2/content/userguide/introduction/architecture.md @@ -17,7 +17,7 @@ The operator consists of the following parts: The operator is packaged in a [container image](https://github.com/orgs/oracle/packages/container/package/weblogic-kubernetes-operator) which you can access using the following `docker pull` commands: ```shell -$ docker pull ghcr.io/oracle/weblogic-kubernetes-operator:3.2.1 +$ docker pull ghcr.io/oracle/weblogic-kubernetes-operator:3.2.2 ``` For more details on acquiring the operator image and prerequisites for installing the operator, consult the [Quick Start guide]({{< relref "/quickstart/_index.md" >}}). diff --git a/documentation/3.2/content/userguide/introduction/introduction.md b/documentation/3.2/content/userguide/introduction/introduction.md index 71d631bb9fd..496a5dbc004 100644 --- a/documentation/3.2/content/userguide/introduction/introduction.md +++ b/documentation/3.2/content/userguide/introduction/introduction.md @@ -16,14 +16,14 @@ Detailed instructions are available [here]({{< relref "/userguide/managing-opera ### Operator prerequisites -For the current production release 3.2.1: +For the current production release 3.2.2: * Kubernetes 1.16.15+, 1.17.13+, 1.18.10+, and 1.19.7+ (check with `kubectl version`). * Flannel networking v0.9.1-amd64 or later (check with `docker images | grep flannel`), Calico networking v3.16.1 or later, *or* OpenShift SDN on OpenShift 4.3 systems. * Docker 18.9.1 or 19.03.1+ (check with `docker version`) *or* CRI-O 1.14.7+ (check with `crictl version | grep RuntimeVersion`). * Helm 3.3.4+ (check with `helm version --client --short`). -* For domain home source type `Model in Image`, WebLogic Deploy Tooling 1.9.10. +* For domain home source type `Model in Image`, WebLogic Deploy Tooling 1.9.11. * Either Oracle WebLogic Server 12.2.1.3.0 with patch 29135930, Oracle WebLogic Server 12.2.1.4.0, or Oracle WebLogic Server 14.1.1.0.0. * The existing WebLogic Server image, `container-registry.oracle.com/middleware/weblogic:12.2.1.3`, has all the necessary patches applied. diff --git a/documentation/3.2/content/userguide/managing-domains/configoverrides/_index.md b/documentation/3.2/content/userguide/managing-domains/configoverrides/_index.md index 3d6b4a51dd3..7a5f974066b 100644 --- a/documentation/3.2/content/userguide/managing-domains/configoverrides/_index.md +++ b/documentation/3.2/content/userguide/managing-domains/configoverrides/_index.md @@ -105,6 +105,7 @@ See [overrides distribution](#overrides-distribution) for a discussion of distri * Domain topology (cluster members) * Network channel listen address, port, and enabled configuration * Server and domain log locations +* Default or custom file store directories when `domain.spec.dataHome` is set * Node Manager related configuration * Changing any existing MBean name * Adding or removing a module (for example, a JDBC module) @@ -120,7 +121,8 @@ See [overrides distribution](#overrides-distribution) for a discussion of distri * Dynamic cluster size * Default, SSL, and Admin channel `Enabled`, listen address, and port * Network Access Point (custom channel), listen address, or port - * Server and domain log locations -- use the `logHome` domain setting instead + * Server and domain log locations -- use the `domain.spec.logHome` setting instead and ensure that `domain.spec.logHomeEnabled` is set to true + * Default or custom file store directories when `domain.spec.dataHome` is set * Node Manager access credentials * Any existing MBean name (for example, you cannot change the domain name) diff --git a/documentation/3.2/content/userguide/managing-domains/domain-events.md b/documentation/3.2/content/userguide/managing-domains/domain-events.md index 50c0ba53b8b..ec43e72b646 100644 --- a/documentation/3.2/content/userguide/managing-domains/domain-events.md +++ b/documentation/3.2/content/userguide/managing-domains/domain-events.md @@ -1,7 +1,7 @@ +++ title = "Domain events" date = 2020-11-30T16:43:45-05:00 -weight = 9 +weight = 10 pre = " " +++ @@ -38,12 +38,14 @@ The operator also generates these event types in the operator's namespace, which * `StartManagingNamespace`: The operator has started managing domains in a namespace. * `StopManagingNamespace`: The operator has stopped managing domains in a namespace. +* `StartManagingNamespaceFailed`: The operator failed to start managing domains in a namespace because it does not have the required privileges. + #### Operator-generated event details Each operator-generated event contains the following fields: * `metadata` - * `namespace`: Namespace in which the event is generated. + * `namespace`: Namespace in which the event is generated. * `labels`: `weblogic.createdByOperator=true` and, for a domain event, `weblogic.domainUID=`. * `type`: String that describes the type of the event. Possible values are `Normal` or `Warning`. * `count`: Integer that indicates the number of occurrences of the event. Note that the events are matched by the combination of the `reason`, `involvedObject`, and `message` fields. @@ -59,7 +61,7 @@ Each operator-generated event contains the following fields: * `kind`: String that describes the kind of resource this object represents. The value is `Domain` for a domain event, `Namespace` for a namespace event in the domain namespace, or `Pod` for the operator pod. * `apiVersion`: String that describes the `apiVersion` of the involved object, which is the `apiVersion` of the domain resource, for example, `weblogic.oracle/v8`, for a domain event or unset for a namespace event. * `UID`: String that describes the unique identifier of the object that is generated by the Kubernetes server. - + #### How to access the events To access the events that are associated with all resources in a particular namespace, run: @@ -213,7 +215,7 @@ LAST SEEN TYPE REASON OBJECT 5m43s Warning DomainProcessingFailed domain/sample-domain1 Failed to complete processing domain resource sample-domain1 due to: Job sample-domain1-introspector failed due to reason: DeadlineExceeded. ActiveDeadlineSeconds of the job is configured with 120 seconds. The job was started 120 seconds ago. Ensure all domain dependencies have been deployed (any secrets, config-maps, PVs, and PVCs that the domain resource references). Use kubectl describe for the job and its pod for more job failure information. The job may be retried by the operator up to 5 times with longer ActiveDeadlineSeconds value in each subsequent retry. Use tuning parameter domainPresenceFailureRetryMaxCount to configure max retries., the processing will be retried if needed 5m43s Normal SuccessfulDelete job/sample-domain1-introspector Deleted pod: sample-domain1-introspector-d42rf 5m32s Normal Scheduled pod/sample-domain1-introspector-cmxjs Successfully assigned sample-domain1-ns/sample-domain1-introspector-cmxjs to doxiao-1 -5m32s Normal SuccessfulCreate job/sample-domain1-introspector Created pod: sample-domain1-introspector-cmxjs +5m32s Normal SuccessfulCreate job/sample-domain1-introspector Created pod: sample-domain1-introspector-cmxjs 4m52s Normal Pulling pod/sample-domain1-introspector-cmxjs Pulling image "domain-home-in-image:12.2.1.4" 4m50s Warning Failed pod/sample-domain1-introspector-cmxjs Failed to pull image "domain-home-in-image:12.2.1.4": rpc error: code = Unknown desc = pull access denied for domain-home-in-image, repository does not exist or may require 'docker login' 4m50s Warning Failed pod/sample-domain1-introspector-cmxjs Error: ErrImagePull diff --git a/documentation/3.2/content/userguide/managing-domains/domain-in-image/_index.md b/documentation/3.2/content/userguide/managing-domains/domain-in-image/_index.md index db18f154a06..74c042f8d8d 100644 --- a/documentation/3.2/content/userguide/managing-domains/domain-in-image/_index.md +++ b/documentation/3.2/content/userguide/managing-domains/domain-in-image/_index.md @@ -2,15 +2,14 @@ title = "Domain in Image" date = 2019-02-23T16:45:16-05:00 weight = 4 +draft = true pre = " " +++ {{% children style="h4" description="true" %}} -{{% notice warning %}} -Oracle strongly recommends storing a domain image as private in the registry. -A container image that contains a WebLogic domain home has sensitive information -including keys and credentials that are used to access external resources -(for example, the data source password). For more information, see -[WebLogic domain in container image protection]({{}}). + +{{% notice note %}} +Oracle strongly recommends that images containing WebLogic domains +be kept in a private repository. {{% /notice %}} diff --git a/documentation/3.2/content/userguide/managing-domains/domain-in-image/base-images/_index.md b/documentation/3.2/content/userguide/managing-domains/domain-in-image/base-images/_index.md deleted file mode 100644 index c7e6dfc4e7d..00000000000 --- a/documentation/3.2/content/userguide/managing-domains/domain-in-image/base-images/_index.md +++ /dev/null @@ -1,154 +0,0 @@ ---- -title: "Base images" -date: 2019-02-23T16:45:55-05:00 -weight: 1 -description: "Creating or obtaining WebLogic Server images." ---- - -#### Contents - -* [Creating or obtaining WebLogic Server images](#creating-or-obtaining-weblogic-server-images) -* [Setting up secrets to access the Oracle Container Registry](#setting-up-secrets-to-access-the-oracle-container-registry) -* [Obtaining standard images from the Oracle Container Registry](#obtaining-standard-images-from-the-oracle-container-registry) -* [Creating a custom image with patches applied](#creating-a-custom-image-with-patches-applied) -* [Creating a custom image with your domain inside the image](#creating-a-custom-image-with-your-domain-inside-the-image) - -#### Creating or obtaining WebLogic Server images - -You will need container images to run your WebLogic domains in Kubernetes. -There are two main options available: - -* Use an image which contains the WebLogic Server binaries but - not the domain, or -* Use an image which contains both the WebLogic Server binaries - and the domain directory. - -If you want to use the first option, then you will need to obtain the standard -WebLogic Server image from the Oracle Container Registry; see [Obtaining standard images from the Oracle Container Registry](#obtaining-standard-images-from-the-oracle-container-registry). -This image already contains the mandatory patches applied, as described in [Creating a custom image with patches applied](#creating-a-custom-image-with-patches-applied). -If you want to use additional patches, you can customize that process to include additional patches. - -If you want to use the second option, which includes the domain directory -inside the image, then you will need to build your own images, -as described in [Creating a custom image with your domain inside the image](#creating-a-custom-image-with-your-domain-inside-the-image). - -#### Setting up secrets to access the Oracle Container Registry - -{{% notice note %}} -This version of the operator requires WebLogic Server 12.2.1.3.0 plus patch 29135930; the standard image, `container-registry.oracle.com/middleware/weblogic:12.2.1.3`, already includes this patch pre-applied. Images for WebLogic Server 12.2.1.4.0 do not require any patches. -{{% /notice %}} - -In order for Kubernetes to obtain the WebLogic Server image from the Oracle Container Registry (OCR), which requires authentication, a Kubernetes Secret containing the registry credentials must be created. To create a secret with the OCR credentials, issue the following command: - -```shell -$ kubectl create secret docker-registry SECRET_NAME \ - -n NAMESPACE \ - --docker-server=container-registry.oracle.com \ - --docker-username=YOUR_USERNAME \ - --docker-password=YOUR_PASSWORD \ - --docker-email=YOUR_EMAIL -``` - -In this command, replace the uppercase items with the appropriate values. The `SECRET_NAME` will be needed in later parameter files. The `NAMESPACE` must match the namespace where the first domain will be deployed, otherwise, Kubernetes will not be able to find it. - -It may be preferable to manually pull the image in advance, on each Kubernetes worker node, as described in the next section. -If you choose this approach, you do not require the Kubernetes Secret. - -#### Obtaining standard images from the Oracle Container Registry - -The Oracle Container Registry contains images for licensed commercial Oracle software products that you may use in your enterprise. To access the Oracle Registry Server, you must have an Oracle Single Sign-On (SSO) account. The Oracle Container Registry provides a web interface that allows an administrator to authenticate and then to select the images for the software that your organization wishes to use. Oracle Standard Terms and Restrictions terms must be agreed to using the web interface. After the Oracle Standard Terms and Restrictions have been accepted, you can pull images of the software from the Oracle Container Registry using the standard `docker pull` command. - -To pull an image from the Oracle Container Registry, in a web browser, navigate to https://container-registry.oracle.com and log in -using the Oracle Single Sign-On authentication service. If you do not already have SSO credentials, at the top of the page, click the Sign In link to create them. - -Use 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 is stored in a database that links the software images to your Oracle Single Sign-On login credentials. - -The Oracle Container Registry provides a WebLogic Server 12.2.1.3.0 image, which already has the necessary patches applied, and the Oracle WebLogic Server 12.2.1.4.0 and 14.1.1.0.0 images, which do not require any patches. - -First, you will need to log in to the Oracle Container Registry: - -```shell -$ docker login container-registry.oracle.com -``` - -Then, you can pull the image with this command: - -```shell -$ docker pull container-registry.oracle.com/middleware/weblogic:12.2.1.4 -``` -If desired, you can: - -* Check the WLS version with `docker run container-registry.oracle.com/middleware/weblogic:12.2.1.4 sh -c` `'source $ORACLE_HOME/wlserver/server/bin/setWLSEnv.sh > /dev/null 2>&1 && java weblogic.version'` - -* Check the WLS patches with `docker run container-registry.oracle.com/middleware/weblogic:12.2.1.4 sh -c` `'$ORACLE_HOME/OPatch/opatch lspatches'` - -Additional information about using this image is available on the -Oracle Container Registry. - -#### Creating a custom image with patches applied - -The Oracle WebLogic Server Kubernetes Operator and WebLogic Server 12.2.1.3.0 image requires patch 29135930. -This patch has some prerequisite patches that will also need to be applied. The WebLogic Server 12.2.1.4.0 image does not require any patches. To create and customize the WebLogic Server image, -and apply the required patches, use the [WebLogic Image Tool](https://github.com/oracle/weblogic-image-tool). - -To use the Image Tool, follow the [Setup](https://github.com/oracle/weblogic-image-tool/blob/master/README.md#setup) instructions -and [Quick Start](https://github.com/oracle/weblogic-image-tool/blob/master/site/quickstart.md) Guide. - -To build the WebLogic Server image and apply the patches: - -1. Add the Server JRE and the WebLogic Server installer to the [`cache` command](https://github.com/oracle/weblogic-image-tool/blob/master/site/cache.md). - - ```shell - $ imagetool cache addInstaller \ - --type=jdk \ - --version=8u241 \ - --path=/home/acmeuser/wls-installers/jre-8u241-linux-x64.tar.gz - ``` - ```shell - $ imagetool cache addInstaller \ - --type=wls \ - --version=12.2.1.4.0 \ - --path=/home/acmeuser/wls-installers/fmw_12.2.1.4.0_wls_Disk1_1of1.zip - ``` -2. Use the [Create Tool](https://github.com/oracle/weblogic-image-tool/blob/master/site/create-image.md) -to build the image and apply the patches. - - For the Create Tool to download the patches, you must supply your My Oracle Support credentials. - ```shell - $ imagetool create \ - --tag=weblogic:12.2.1.3 \ - --type=wls \ - --version=12.2.1.3.0 \ - --jdkVersion=8u241 \ - -–patches=29135930_12.2.1.3.0,27117282_12.2.1.3.0 \ - --user=username.mycompany.com \ - --passwordEnv=MYPWD - ``` - -3. After the tool creates the image, verify that the image is in your local repository: - - ```shell - $ docker images - ``` - - -#### Creating a custom image with your domain inside the image - -You can also create an image with the WebLogic domain inside the image. -[Samples]({{< relref "/samples/simple/domains/domain-home-in-image/_index.md" >}}) -are provided that demonstrate how to create the image using either: - -* WLST to define the domain, or -* [WebLogic Deploy Tooling](https://github.com/oracle/weblogic-deploy-tooling) - to define the domain. - -In these samples, you will see a reference to a "base" or `FROM` image. You should use an image -with the mandatory patches installed as this base image. This image could be either -the standard `container-registry.oracle.com/middleware/weblogic:12.2.1.3` pre-patched image or an image you created using the instructions above. -WebLogic Server 12.2.1.4.0 images do not require patches. - -{{% notice note %}} -Oracle recommends that images containing WebLogic domains -be kept in a private repository. -{{% /notice %}} diff --git a/documentation/3.2/content/userguide/managing-domains/domain-in-image/patching/_index.md b/documentation/3.2/content/userguide/managing-domains/domain-in-image/patching/_index.md deleted file mode 100644 index 40d352650ed..00000000000 --- a/documentation/3.2/content/userguide/managing-domains/domain-in-image/patching/_index.md +++ /dev/null @@ -1,10 +0,0 @@ -+++ -title = "Patching" -date = 2019-02-23T16:45:48-05:00 -weight = 2 -draft = true -pre = " " -+++ - - -Lorem Ipsum. diff --git a/documentation/3.2/content/userguide/managing-domains/domain-lifecycle/restarting.md b/documentation/3.2/content/userguide/managing-domains/domain-lifecycle/restarting.md index 06a2b10abe7..eccc2a96ce3 100644 --- a/documentation/3.2/content/userguide/managing-domains/domain-lifecycle/restarting.md +++ b/documentation/3.2/content/userguide/managing-domains/domain-lifecycle/restarting.md @@ -188,7 +188,7 @@ d. Update the `image` field of the Domain YAML file, specifying the new image na ```yaml domain: spec: - image: ghcr.io/oracle/weblogic-updated:3.2.1 + image: ghcr.io/oracle/weblogic-updated:3.2.2 ``` e. The operator will now initiate a rolling restart, which will apply the updated image, for all the servers in the domain. diff --git a/documentation/3.2/content/userguide/managing-domains/domain-lifecycle/scaling.md b/documentation/3.2/content/userguide/managing-domains/domain-lifecycle/scaling.md index b38592f74dd..174db828822 100644 --- a/documentation/3.2/content/userguide/managing-domains/domain-lifecycle/scaling.md +++ b/documentation/3.2/content/userguide/managing-domains/domain-lifecycle/scaling.md @@ -8,10 +8,7 @@ description: "The operator provides several ways to initiate scaling of WebLogic WebLogic Server supports two types of clustering configurations, configured and dynamic. Configured clusters are created by defining each individual Managed Server instance. In dynamic clusters, the Managed Server configurations are generated from a single, shared template.  With dynamic clusters, when additional server capacity is needed, new server instances can be added to the cluster without having to configure them individually. Also, unlike configured clusters, scaling up of dynamic clusters is not restricted to the set of servers defined in the cluster but can be increased based on runtime demands. For more information on how to create, configure, and use dynamic clusters in WebLogic Server, see [Dynamic Clusters](https://docs.oracle.com/en/middleware/standalone/weblogic-server/14.1.1.0/clust/dynamic_clusters.html#GUID-DA7F7FAD-49AA-4F3D-8A05-0D9921B96971). -The following blogs provide more in-depth information on support for scaling WebLogic clusters in Kubernetes: - -* [Automatic Scaling of WebLogic Clusters on Kubernetes](https://blogs.oracle.com/weblogicserver/automatic-scaling-of-weblogic-clusters-on-kubernetes-v2) -* [WebLogic Dynamic Clusters on Kubernetes](https://blogs.oracle.com/weblogicserver/weblogic-dynamic-clusters-on-kubernetes) +For more in-depth information on support for scaling WebLogic clusters in Kubernetes, see [WebLogic Dynamic Clusters on Kubernetes](https://blogs.oracle.com/weblogicserver/weblogic-dynamic-clusters-on-kubernetes). The operator provides several ways to initiate scaling of WebLogic clusters, including: @@ -42,6 +39,7 @@ spec: replicas: 1 ... ``` +In addition, see the helper scripts in the [Domain lifecycle sample scripts]({{< relref "/userguide/managing-domains/domain-lifecycle/startup#domain-lifecycle-sample-scripts" >}}) section. #### Calling the operator's REST scale API diff --git a/documentation/3.2/content/userguide/managing-domains/model-in-image/usage.md b/documentation/3.2/content/userguide/managing-domains/model-in-image/usage.md index 28c5029c497..00043d9328a 100644 --- a/documentation/3.2/content/userguide/managing-domains/model-in-image/usage.md +++ b/documentation/3.2/content/userguide/managing-domains/model-in-image/usage.md @@ -29,8 +29,8 @@ Model in Image requires creating an image that has WebLogic Server and WDT insta First, obtain a base image: -- You can start with a WebLogic Server 12.2.1.3 or later Oracle Container Registry pre-built base image such as `container-registry.oracle.com/middleware/weblogic:12.2.1.3` for WLS domains or `container-registry.oracle.com/middleware/fmw-infrastructure:12.2.1.3` for JRF domains. For an example of this approach for both WLS and JRF domains, see the [Model in Image]({{< relref "/samples/simple/domains/model-in-image/_index.md" >}}) sample. For detailed instructions on how to log in to the Oracle Container Registry and accept the license agreement for an image (required to allow pulling an Oracle Container Registry image), see this [document]({{< relref "/userguide/managing-domains/domain-in-image/base-images/_index.md#obtaining-standard-images-from-the-oracle-container-registry" >}}). -- Or you can manually build your own base image as per [Preparing a Base Image]({{< relref "/userguide/managing-domains/domain-in-image/base-images/_index.md#creating-a-custom-image-with-patches-applied" >}}). This is useful if you want your base images to include additional patches. Note that any 12.2.1.3 image must also include patch 29135930 (the pre-built images already contain this patch). +- You can start with a WebLogic Server 12.2.1.3 or later Oracle Container Registry pre-built base image such as `container-registry.oracle.com/middleware/weblogic:12.2.1.3` for WLS domains or `container-registry.oracle.com/middleware/fmw-infrastructure:12.2.1.3` for JRF domains. For an example of this approach for both WLS and JRF domains, see the [Model in Image]({{< relref "/samples/simple/domains/model-in-image/_index.md" >}}) sample. For detailed instructions on how to log in to the Oracle Container Registry and accept the license agreement for an image (required to allow pulling an Oracle Container Registry image), see this [document]({{< relref "/userguide/base-images/_index.md#obtain-standard-images-from-the-oracle-container-registry" >}}). +- Or you can manually build your own base image as per [Preparing a Base Image]({{< relref "/userguide/base-images/_index.md#create-a-custom-image-with-patches-applied" >}}). This is useful if you want your base images to include additional patches. Note that any 12.2.1.3 image must also include patch 29135930 (the pre-built images already contain this patch). After you have a base image, Model in Image requires the following directory structure for its (optional) WDT model artifacts and (required) WDT binaries: diff --git a/documentation/3.2/content/userguide/managing-fmw-domains/fmw-infra/_index.md b/documentation/3.2/content/userguide/managing-fmw-domains/fmw-infra/_index.md index beafc688589..528e4a15271 100644 --- a/documentation/3.2/content/userguide/managing-fmw-domains/fmw-infra/_index.md +++ b/documentation/3.2/content/userguide/managing-fmw-domains/fmw-infra/_index.md @@ -62,7 +62,7 @@ following limitations currently exist for FMW Infrastructure domains: #### Obtaining the FMW Infrastructure image The Oracle WebLogic Server Kubernetes Operator requires patch 29135930. -The standard pre-built FMW Infrastructure image, `container-registry.oracle.com/middleware/fmw-infrastrucutre:12.2.1.3`, already has this patch applied. For detailed instructions on how to log in to the Oracle Container Registry and accept license agreement, see this [document]({{< relref "/userguide/managing-domains/domain-in-image/base-images/_index.md#obtaining-standard-images-from-the-oracle-container-registry" >}}). +The standard pre-built FMW Infrastructure image, `container-registry.oracle.com/middleware/fmw-infrastrucutre:12.2.1.3`, already has this patch applied. For detailed instructions on how to log in to the Oracle Container Registry and accept license agreement, see this [document]({{< relref "/userguide/base-images/_index.md#obtain-standard-images-from-the-oracle-container-registry" >}}). The FMW Infrastructure 12.2.1.4.0 images do not require patches. To pull an image from the Oracle Container Registry, in a web browser, navigate to https://container-registry.oracle.com and log in diff --git a/documentation/3.2/content/userguide/managing-operators/installation/_index.md b/documentation/3.2/content/userguide/managing-operators/installation/_index.md index b4f471bb6ce..ef576108eca 100644 --- a/documentation/3.2/content/userguide/managing-operators/installation/_index.md +++ b/documentation/3.2/content/userguide/managing-operators/installation/_index.md @@ -113,7 +113,7 @@ the `helm upgrade` command requires that you supply a new Helm chart and image. ```shell $ helm upgrade \ --reuse-values \ - --set image=ghcr.io/oracle/weblogic-kubernetes-operator:3.2.1 \ + --set image=ghcr.io/oracle/weblogic-kubernetes-operator:3.2.2 \ --namespace weblogic-operator-namespace \ --wait \ weblogic-operator \ diff --git a/documentation/3.2/content/userguide/managing-operators/using-the-operator/using-helm.md b/documentation/3.2/content/userguide/managing-operators/using-the-operator/using-helm.md index 79d1076f9f7..4954a201cf0 100644 --- a/documentation/3.2/content/userguide/managing-operators/using-the-operator/using-helm.md +++ b/documentation/3.2/content/userguide/managing-operators/using-the-operator/using-helm.md @@ -102,7 +102,7 @@ javaLoggingLevel: "FINE" ##### `image` Specifies the container image containing the operator code. -Defaults to `ghcr.io/oracle/weblogic-kubernetes-operator:3.2.1`. +Defaults to `ghcr.io/oracle/weblogic-kubernetes-operator:3.2.2`. Example: ```yaml