You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,7 +11,7 @@ You can:
11
11
* Supply WebLogic domain configuration using:
12
12
*_Model in Image_: Includes [WebLogic Deploy Tooling](https://github.com/oracle/weblogic-deploy-tooling) models and archives in a container image.
13
13
*_Domain in Image_: Includes a WebLogic domain home in a container image.
14
-
*_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.
14
+
*_Domain on PV_: Locates WebLogic domain homes in a Kubernetes PersistentVolume (PV). This PV can reside in an NFS file system or other Kubernetes volume types.
15
15
* Configure deployment of WebLogic domains as Kubernetes resources (using Kubernetes custom resource definitions).
16
16
* Override certain aspects of the WebLogic domain configuration; for example, use a different database password for different deployments.
17
17
* Start and stop servers and clusters in the domain based on declarative startup parameters and desired states.
Copy file name to clipboardExpand all lines: documentation/site/content/managing-domains/choosing-a-model/_index.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,7 +13,7 @@ This document describes the domain home source types for deploying a domain, and
13
13
14
14
When using the operator to start WebLogic Server instances from a domain, you have the choice of the following WebLogic domain home source types:
15
15
16
-
{{% notice note %}}The **Domain in Image** domain home source type is deprecated in WebLogic Kubernetes Operator version 4.0. Oracle recommends that you choose either Domain in PV or Model in Image, depending on your needs.
16
+
{{% notice note %}}The **Domain in Image** domain home source type is deprecated in WebLogic Kubernetes Operator version 4.0. Oracle recommends that you choose either Domain on PV or Model in Image, depending on your needs.
17
17
{{% /notice %}}
18
18
19
19
-**[Model in Image]({{< relref "/samples/domains/model-in-image/_index.md" >}})**:
@@ -56,10 +56,10 @@ There are advantages for each domain home source type where Model in Image is th
56
56
| Lets you use the same standard WebLogic Server image for every server in every domain. | Requires a different image for each domain, but all servers in that domain use the same image. | Different domains can use the same image, but require different domainUID and may have different configuration. |
57
57
| No state is kept in images making the containers created from these images completely throw away (cattle not pets). | Runtime state should not be kept in the images, but applications and configuration are. | Runtime state should not be kept in the images. Application and configuration may be. |
58
58
| You can deploy new applications using the Administration Console or WLST. | If you want to deploy application updates, then you must create a new image. | If you want to deploy application updates, then you must create a new image, which optionally can be an [auxiliary image]({{< relref "/managing-domains/model-in-image/auxiliary-images.md" >}}) that doesn't include a WebLogic installation. |
59
-
| You can use configuration overrides to mutate the domain configuration before it is deployed, but there are [limitations]({{< relref "/managing-domains/configoverrides/_index.md#unsupported-overrides" >}}). | Same as Domain in PV. | You can deploy model files to a ConfigMap to mutate the domain before it is deployed. The model file syntax is far simpler and less error prone than the configuration override syntax, and, unlike configuration overrides, allows you to directly add data sources and JMS modules. |
59
+
| You can use configuration overrides to mutate the domain configuration before it is deployed, but there are [limitations]({{< relref "/managing-domains/configoverrides/_index.md#unsupported-overrides" >}}). | Same as Domain on PV. | You can deploy model files to a ConfigMap to mutate the domain before it is deployed. The model file syntax is far simpler and less error prone than the configuration override syntax, and, unlike configuration overrides, allows you to directly add data sources and JMS modules. |
60
60
| You can change WebLogic domain configuration at runtime using the Administration Console or WLST. You can also change configuration overrides and [distribute the new overrides]({{< relref "/managing-domains/domain-lifecycle/introspection.md#distributing-changes-to-configuration-overrides" >}}) to running servers; however, non-dynamic configuration attributes can be changed only when servers are starting and some changes may require a full domain restart. | You also can change configuration overrides and [distribute the new overrides]({{< relref "/managing-domains/domain-lifecycle/introspection.md#distributing-changes-to-configuration-overrides" >}}) to running servers; however, non-dynamic configuration attributes can be changed only when servers are starting and some changes may require a full domain restart. You should not use the Administration Console or WLST for these domains as changes are ephemeral and will be lost when servers restart. | You can change configuration at runtime using model YAML file snippets supplied in [runtime updates]({{< relref "/managing-domains/model-in-image/runtime-updates.md" >}}) (which are substantially easier to specify than configuration overrides); however, non-dynamic configuration attributes will change only when servers are restarted (rolled) and some changes may require a full domain restart. You should not use the Administration Console or WLST for these domains as changes are ephemeral and will be lost when servers restart. |
61
61
| Logs are automatically placed on persistent storage and sent to the pod's stdout. | Logs are kept in the containers and sent to the pod's log (`stdout`) by default. To change the log location, you can set the Domain `logHomeEnabled` to true and configure the desired directory using `logHome`. | Same as Domain in Image. |
62
-
| Patches can be applied by simply changing the image and rolling the domain. | To apply patches, you must update the domain-specific image and then restart or roll the domain depending on the nature of the patch. | Same as Domain in PV when using dedicated [auxiliary images]({{< relref "/managing-domains/model-in-image/auxiliary-images.md" >}}) to supply model artifacts; same as Domain in Image otherwise. |
62
+
| Patches can be applied by simply changing the image and rolling the domain. | To apply patches, you must update the domain-specific image and then restart or roll the domain depending on the nature of the patch. | Same as Domain on PV when using dedicated [auxiliary images]({{< relref "/managing-domains/model-in-image/auxiliary-images.md" >}}) to supply model artifacts; same as Domain in Image otherwise. |
63
63
| Many cloud providers do not provide persistent volumes that are shared across availability zones, so you may not be able to use a single persistent volume. You may need to use some kind of volume replication technology or a clustered file system. | Provided you do not store and state in containers, you do not have to worry about volume replication across availability zones because each pod has its own copy of the domain. WebLogic replication will handle propagation of any online configuration changes. | Same as Domain in Image. |
64
64
| CI/CD pipelines may be more complicated because you would need to run WLST against the live domain directory to effect changes. | CI/CD pipelines are simpler because you can create the whole domain in the image and don't have to worry about a persistent copy of the domain. | CI/CD pipelines are even simpler because you don't need to generate a domain home. The operator will create a domain home for you based on the model that you supply. |
65
65
| There are fewer images to manage and store, which could provide significant storage and network savings. | There are more images to manage and store in this approach. | Same as Domain in Image unless you use the [auxiliary images]({{< relref "/managing-domains/model-in-image/auxiliary-images.md" >}}) approach. With auxiliary images, you can use a single image to distribute your WebLogic installation (similar to Domain on PV), plus one or more specific dedicated images that contain your WebLogic configuration and applications.|
@@ -82,4 +82,4 @@ There are advantages for each domain home source type where Model in Image is th
82
82
*[Create a custom image with patches applied]({{< relref "/base-images/custom-images#create-a-custom-image-with-patches-applied" >}})
83
83
*[Create a domain creation images]({{< relref "/managing-domains/model-in-image/auxiliary-images.md" >}})
Configuration overrides can only be used in combination with Domain in Image and Domain in PV domains. For Model in Image domains, use [Model in Image Runtime Updates]({{< relref "/managing-domains/model-in-image/runtime-updates.md" >}}) instead.
14
+
Configuration overrides can only be used in combination with Domain in Image and Domain on PV domains. For Model in Image domains, use [Model in Image Runtime Updates]({{< relref "/managing-domains/model-in-image/runtime-updates.md" >}}) instead.
15
15
{{% /notice %}}
16
16
17
-
Use configuration overrides (also called _situational configuration_) to customize a Domain in Image or Domain in PV domain's WebLogic domain configuration without modifying the domain's actual `config.xml` or system resource files. For example, you may want to override a JDBC data source XML module user name, password, and URL so that it references a local database.
17
+
Use configuration overrides (also called _situational configuration_) to customize a Domain in Image or Domain on PV domain's WebLogic domain configuration without modifying the domain's actual `config.xml` or system resource files. For example, you may want to override a JDBC data source XML module user name, password, and URL so that it references a local database.
18
18
19
-
**NOTE**: The Domain in Image [domain home source type]({{< relref "/managing-domains/choosing-a-model/_index.md" >}}) is deprecated in WebLogic Kubernetes Operator version 4.0. Oracle recommends that you choose either Domain in PV or Model in Image, depending on your needs.
19
+
**NOTE**: The Domain in Image [domain home source type]({{< relref "/managing-domains/choosing-a-model/_index.md" >}}) is deprecated in WebLogic Kubernetes Operator version 4.0. Oracle recommends that you choose either Domain on PV or Model in Image, depending on your needs.
20
20
21
21
You can use overrides to customize domains as they are moved from QA to production, are deployed to different sites, or are even deployed multiple times at the same site. Beginning with operator version 3.0.0, you can now modify configuration overrides for running WebLogic Server instances and have these new overrides take effect dynamically. There are [limitations](#unsupported-overrides) to the WebLogic configuration attributes that can be modified by overrides and only changes to dynamic configuration MBean attributes may be changed while a server is running. Other changes, specifically overrides to non-dynamic MBeans, must be applied when servers are starting or restarting.
22
22
@@ -59,7 +59,7 @@ For a detailed walk-through of the runtime flow, see the [Internal design flow](
59
59
---
60
60
### Prerequisites
61
61
62
-
* Configuration overrides can be used in combination with Domain in Image and Domain in PV domains.
62
+
* Configuration overrides can be used in combination with Domain in Image and Domain on PV domains.
63
63
For Model in Image domains (introduced in 3.0.0), use [Model in Image Runtime Updates]({{< relref "/managing-domains/model-in-image/runtime-updates.md" >}}) instead.
64
64
65
65
* A WebLogic domain home must not contain any configuration overrides XML file in its `optconfig` directory that was not placed there by the operator. Any existing configuration overrides XML files in this directory will be deleted and replaced by your operator override templates, if any.
@@ -121,7 +121,7 @@ The behavior when using an unsupported override is undefined.
121
121
122
122
The operator generates the final configuration overrides, combining customer-provided configuration overrides and operator-generated overrides, during the operator's introspection phase. These overrides are then used when starting or restarting WebLogic Server instances. Starting with operator version 3.0.0, these [overrides can also be distributed]({{< relref "/managing-domains/domain-lifecycle/introspection/_index.md#distributing-changes-to-configuration-overrides" >}}) and applied to already running WebLogic Server instances.
123
123
124
-
For [Domain in PV]({{< relref "/managing-domains/domain-lifecycle/restarting/_index.md#domain-in-pv" >}}), the ability to change WebLogic domain configuration using traditional management transactions involving the Administration Console or WLST can be combined with the ability to initiate a repeat introspection and distribute updated configuration overrides. This combination supports use cases such as defining a new WebLogic cluster and then immediately starting Managed Server cluster members.
124
+
For [Domain on PV]({{< relref "/managing-domains/domain-lifecycle/restarting/_index.md#domain-on-pv" >}}), the ability to change WebLogic domain configuration using traditional management transactions involving the Administration Console or WLST can be combined with the ability to initiate a repeat introspection and distribute updated configuration overrides. This combination supports use cases such as defining a new WebLogic cluster and then immediately starting Managed Server cluster members.
0 commit comments