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: site/creating-domain.md
+46-45Lines changed: 46 additions & 45 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,13 +8,13 @@ Note that there is a short video demonstration of the domain creation process av
8
8
9
9
When running a WebLogic domain in Kubernetes, there are some additional considerations that must be taken into account to ensure correct functioning:
10
10
11
-
* Multicast is not well supported in Kubernetes at the time of writing. Some networking providers have some support for multicast, but it is generally considered of “beta” quality. Oracle recommends configuring WebLogic clusters to use unicast.
11
+
* Multicast is not currently well supported in Kubernetes. Some networking providers have some support for multicast, but it is generally considered of “beta” quality. Oracle recommends configuring WebLogic clusters to use unicast.
12
12
* The `ListenAddress` for all servers must be set to the correct DNS name; it should not be set to `0.0.0.0` or left blank. This is required for cluster discovery of servers to work correctly.
13
13
* If there is a desire to expose a T3 channel outside of the Kubernetes cluster -- for example, to allow WLST or RMI connections from clients outside Kubernetes -- then the recommended approach is to define a dedicated channel (per server) and to expose that channel using a `NodePort` service. It is required that the channel’s internal and external ports be set to the same value as the chosen `NodePort`; for example, they could all be `32000`. If all three are not the same, WebLogic Server will reject T3 connection requests.
14
14
15
15
## Creating a domain namespace
16
16
17
-
Oracle recommends creating namespaces to host WebLogic domains. It is not required to maintain a one-to-one relationship between WebLogic domains and Kubernetes namespaces, but this may be done if desired. More than one WebLogic domain may be run in a single namespace if desired.
17
+
Oracle recommends creating namespaces to host WebLogic domains. It is not required to maintain a one-to-one relationship between WebLogic domains and Kubernetes namespaces, but this may be done if desired. More than one WebLogic domain may be run in a single namespace, if desired.
18
18
19
19
Any namespaces that were listed in the `targetNamespaces` parameter in the operator parameters file when deploying the operator would have been created by the script.
20
20
@@ -45,11 +45,11 @@ In this command, replace the uppercase items with the appropriate values. The `S
45
45
46
46
## Go to the Docker Store and accept the license agreement for the WebLogic Server image
47
47
48
-
If you have never used the WebLogic Server image before, you will need to go to the [Docker Store web interface](https://store.docker.com/images/oracle-weblogic-server-12c) and accept the license agreement before Docker Store will allow you to pull this image. This is a one-time requirement, you do not have to repeat it for each machine you want to use the image on.
48
+
If you have never used the WebLogic Server image before, you will need to go to the [Docker Store web interface](https://store.docker.com/images/oracle-weblogic-server-12c) and accept the license agreement before Docker Store will allow you to pull this image. This is a one-time requirement, you do not have to repeat it for each machine you want to use the image on.
49
49
50
50
## Pull the WebLogic Server image
51
51
52
-
You can let Kubernetes pull the Docker image for you the first time you try to create a pod that uses the image, but we have found that you can generally avoid various common issues like putting the secret in the wrong namespace or getting the credentials wrong by just manually pulling the image by running these commands *on the Kubernetes nodes*:
52
+
You can let Kubernetes pull the Docker image for you the first time you try to create a pod that uses the image, but we have found that you can generally avoid various common issues, like putting the secret in the wrong namespace or getting the credentials wrong, by just manually pulling the image by running these commands *on the Kubernetes nodes*:
53
53
54
54
```
55
55
docker login
@@ -73,9 +73,9 @@ The `SECRET_NAME` value specified here must be in the format `DOMAINUID-weblogic
73
73
74
74
## Important considerations for persistent volumes
75
75
76
-
WebLogic domains that are managed by the operator are required to store their configuration and state on a persistent volume. This volume is mounted read/write on all containers that are running a server in the domain. There are many different persistent volume providers, but they do not all support multiple read/write mounts. It is required that the chosen provider supports multiple read/write mounts. Details of available providers are available at [https://kubernetes.io/docs/concepts/storage/persistent-volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes). Careful attention should be given to the table in the section titled “Access Modes”.
76
+
WebLogic domains that are managed by the operator are required to store their configuration and state on a persistent volume. This volume is mounted read/write on all containers that are running a server in the domain. There are many different persistent volume providers, but they do not all support multiple read/write mounts. It is required that the chosen provider supports multiple read/write mounts. Details of available providers are available at [https://kubernetes.io/docs/concepts/storage/persistent-volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes). Careful attention should be given to the information in the table in the section titled, “Access Modes”.
77
77
78
-
In a single-node Kubernetes cluster, such as may be used for testing or proof of concept activities, `HOST_PATH` provides the simplest configuration. In a multinode Kubernetes cluster a `HOST_PATH` that is located on shared storage mounted by all nodes in the Kubernetes cluster is the simplest configuration. If nodes do not have shared storage, then NFS is probably the most widely available option. There are other options listed in the referenced table.
78
+
In a single-node Kubernetes cluster, such as may be used for testing or proof of concept activities, `HOST_PATH` provides the simplest configuration. In a multinode Kubernetes cluster, a `HOST_PATH` that is located on shared storage mounted by all nodes in the Kubernetes cluster is the simplest configuration. If nodes do not have shared storage, then NFS is probably the most widely available option. There are other options listed in the referenced table.
79
79
80
80
## Creating a persistent volume for the domain
81
81
@@ -85,50 +85,50 @@ The persistent volume for the domain must be created using the appropriate tools
85
85
mkdir –m 777 –p /path/to/domain1PersistentVolume
86
86
```
87
87
88
-
For other providers, consult the documentation for the provider for instructions on how to create a persistent volume.
88
+
For other providers, consult the provider documentation for instructions on how to create a persistent volume.
89
89
90
90
## Customizing the domain parameters file
91
91
92
92
The domain is created with the provided installation script (`create-weblogic-domain.sh`). The input to this script is the file `create-weblogic-domain-inputs.yaml`, which must be copied and updated to reflect the target environment.
93
93
94
-
The following parameters must be provided in the input file:
94
+
The following parameters must be provided in the input file.
95
95
96
-
### CONFIGURATION PARAMETERS FOR THE CREATE DOMAIN JOB
96
+
### Configuration parameters for the create domain job
97
97
98
98
| Parameter | Definition | Default |
99
99
| --- | --- | --- |
100
-
| adminPort | Port number for the Administration Server inside the Kubernetes cluster. | 7001 |
101
-
| adminNodePort | Port number of the Administration Server outside the Kubernetes cluster. | 30701 |
102
-
| adminServerName |The name of the Administration Server. | admin-server |
103
-
| clusterName |The name of WebLogic Cluster instance to generate for the domain. | cluster-1 |
104
-
| configuredManagedServerCount | Number of Managed Server instances to generate for the domain. |2|
105
-
| domainName | Name of the WebLogic domain to create. | base_domain |
106
-
| domainUID | Unique ID that will be used to identify this particular domain. This ID must be unique across all domains in a Kubernetes cluster. | no default |
107
-
| exposeAdminNodePort | Boolean indicating if the the Administration Server is exposed outside of the Kubernetes cluster. | false |
108
-
| exposeAdminT3Channel | Boolean indicating if the T3 admin channel is exposed outside the Kubernetes cluster. | false |
109
-
| initialManagedServerReplicas |The number of managed servers to initially start for the domain |2|
110
-
| javaOptions | Java options for starting the Admin and Managed servers. | -Dweblogic.StdoutDebugEnabled=false |
111
-
| loadBalancer |The kind of load balancer to create. Legal values are 'NONE' and 'TRAEFIK'. | TRAEFIK |
112
-
| loadBalancerDashboardPort |The node port for the load balancer to accept dashboard traffic. | 30315 |
113
-
| loadBalancerWebPort |The node port for the load balancer to accept user traffic. | 30305 |
114
-
| managedServerNameBase | Base string used to generate Managed Server names. | managed-server |
115
-
| managedServerPort | Port number for each Managed Server. | 8001 |
116
-
| namespace |The Kubernetes namespace to create the domain in. | default |
117
-
| productionModeEnabled | Boolean indicating if production mode is enabled for the domain. | true |
118
-
| startupControl | Determines which WebLogic servers will be started up. Legal values are 'NONE', 'ALL', 'ADMIN', 'SPECIFIED', or 'AUTO'| AUTO |
119
-
| t3ChannelPort | Port for the T3Channel of the NetworkAccessPoint. | 30012 |
120
-
| t3PublicAddress | Public address for the t3 channel. | kubernetes |
121
-
| weblogicCredentialsSecretName | Name of the Kubernetes secret for the Administration Server's username and password. | domain1-weblogic-credentials |
122
-
| weblogicDomainStoragePath | Physical path of the storage for the domain. | no default |
123
-
| weblogicDomainStorageReclaimPolicy | Kubernetes persistent volume reclaim policy for the domain persistent storage | Retain |
124
-
| weblogicDomainStorageSize | Total storage allocated for the domain. | 10Gi |
125
-
| weblogicDomainStorageType | Type of storage for the domain. Legal values are 'NFS' and 'HOST_PATH". | HOST_PATH |
126
-
| weblogicDomainStorageNFSServer| The name of IP address of the NFS server for the domain's storage. | no default |
127
-
| weblogicImagePullSecretName | Name of the Kubernetes secret for the Docker Store, used to pull the WebLogic Server image. | docker-store-secret |
100
+
|`adminPort`| Port number for the Administration Server inside the Kubernetes cluster. |`7001`|
101
+
|`adminNodePort`| Port number of the Administration Server outside the Kubernetes cluster. |`30701`|
102
+
|`adminServerName`|Name of the Administration Server. |`admin-server`|
103
+
|`clusterName`|Name of the WebLogic cluster instance to generate for the domain. |`cluster-1`|
104
+
|`configuredManagedServerCount`| Number of Managed Server instances to generate for the domain. |`2`|
105
+
|`domainName`| Name of the WebLogic domain to create. |`base_domain`|
106
+
|`domainUID`| Unique ID that will be used to identify this particular domain. This ID must be unique across all domains in a Kubernetes cluster. | no default |
107
+
|`exposeAdminNodePort`| Boolean indicating if the Administration Server is exposed outside of the Kubernetes cluster. |`false`|
108
+
|`exposeAdminT3Channel`| Boolean indicating if the T3 administrative channel is exposed outside the Kubernetes cluster. |`false`|
109
+
|`initialManagedServerReplicas`|Number of Managed Servers to initially start for the domain.|`2`|
110
+
|`javaOptions`| Java options for starting the Administration and Managed Servers. |`-Dweblogic.StdoutDebugEnabled=false`|
111
+
|`loadBalancer`|Type of load balancer to create. Legal values are `NONE` and `TRAEFIK`. |`TRAEFIK`|
112
+
|`loadBalancerDashboardPort`|Node port for the load balancer to accept dashboard traffic. |`30315`|
113
+
|`loadBalancerWebPort`|Node port for the load balancer to accept user traffic. |`30305`|
114
+
|`managedServerNameBase`| Base string used to generate Managed Server names. |`managed-server`|
115
+
|`managedServerPort`| Port number for each Managed Server. |`8001`|
116
+
|`namespace`| Kubernetes namespace to create the domain in. |`default`|
117
+
|`productionModeEnabled`| Boolean indicating if production mode is enabled for the domain. |`true`|
118
+
|`startupControl`| Determines which WebLogic servers will be started up. Legal values are `NONE`, `ALL`, `ADMIN`, `SPECIFIED`, or `AUTO`|`AUTO`|
119
+
|`t3ChannelPort`| Port for the T3 channel of the NetworkAccessPoint. |`30012`|
120
+
|`t3PublicAddress`| Public address for the T3 channel. |`kubernetes`|
121
+
|`weblogicCredentialsSecretName`| Name of the Kubernetes secret for the Administration Server's username and password. |`domain1-weblogic-credentials`|
122
+
|`weblogicDomainStoragePath`| Physical path of the storage for the domain. | no default |
123
+
|`weblogicDomainStorageReclaimPolicy`| Kubernetes persistent volume reclaim policy for the domain persistent storage |`Retain`|
124
+
|`weblogicDomainStorageSize`| Total storage allocated for the domain. |`10Gi`|
125
+
|`weblogicDomainStorageType`| Type of storage for the domain. Legal values are `NFS` and `HOST_PATH`. |`HOST_PATH`|
126
+
|`weblogicDomainStorageNFSServer`| Name of the IP address of the NFS server for the domain's storage. | no default |
127
+
|`weblogicImagePullSecretName`| Name of the Kubernetes secret for the Docker Store, used to pull the WebLogic Server image. |`docker-store-secret`|
128
128
129
129
## Limitations of the create domain script
130
130
131
-
This technology preview release has some limitations in the create domain script that users should be aware of.
131
+
This release has some limitations in the create domain script that users should be aware of.
132
132
133
133
* The script creates the specified number of Managed Servers and places them all in one cluster.
134
134
* The script always creates one cluster.
@@ -139,11 +139,12 @@ Oracle intends to remove these limitations in a future release.
139
139
140
140
At this point, you've created a customized copy of the inputs file.
141
141
142
-
Next, choose and create a directory that generated operator related files will be stored in, e.g. /path/to/weblogic-operator-output-directory.
142
+
Next, choose and create a directory in which generated operator related files will be stored, for example, `/path/to/weblogic-operator-output-directory`.
143
143
144
144
Finally, run the create script, pointing it at your inputs file and output directory:
145
145
146
-
./create-weblogic-domain.sh \
146
+
```
147
+
./create-weblogic-domain.sh \
147
148
–i create-domain-job-inputs.yaml \
148
149
-o /path/to/weblogic-operator-output-directory
149
150
```
@@ -152,19 +153,19 @@ Finally, run the create script, pointing it at your inputs file and output direc
152
153
153
154
The script will perform the following steps:
154
155
155
-
* Create a directory for the generated Kubernetes YAML files for this domain. The pathname is /path/to/weblogic-operator-output-directory/weblogic-domains/<domainUID>.
156
+
* Create a directory for the generated Kubernetes YAML files for this domain. The pathname is `/path/to/weblogic-operator-output-directory/weblogic-domains/<domainUID>`.
156
157
* Create Kubernetes YAML files based on the provided inputs.
157
158
* Create a persistent volume for the shared state.
158
159
* Create a persistent volume claim for that volume.
159
160
* Create a Kubernetes job that will start up a utility WebLogic Server container and run WLST to create the domain on the shared storage.
160
161
* Wait for the job to finish and then create a domain custom resource for the new domain.
161
162
162
-
The default domain created the script has the following characteristics:
163
+
The default domain created by the script has the following characteristics:
163
164
164
165
* An Administration Server named `admin-server` listening on port `7001`.
165
166
* A single cluster named `cluster-1` containing the specified number of Managed Servers.
166
167
* A Managed Server named `managed-server1` listening on port `8001` (and so on up to the requested number of Managed Servers).
167
-
* Log files are located in `/shared/logs`.
168
+
* Log files that are located in `/shared/logs`.
168
169
* No applications deployed.
169
170
* No data sources.
170
171
* No JMS resources.
@@ -313,7 +314,7 @@ Status:
313
314
Events: <none>
314
315
```
315
316
316
-
In the "Status" section of the output, the available servers and clusters are listed. Note that if this command is issued very soon after the script finishes, there may be no servers available yet, or perhaps only the Administration Server but no Managed Servers. The operator will start up the Administration Server first and wait for it to become ready before starting Managed Servers.
317
+
In the `Status` section of the output, the available servers and clusters are listed. Note that if this command is issued very soon after the script finishes, there may be no servers available yet, or perhaps only the Administration Server but no Managed Servers. The operator will start up the Administration Server first and wait for it to become ready before starting Managed Servers.
317
318
318
319
### Verify pods
319
320
@@ -381,6 +382,6 @@ Events: <none>
381
382
382
383
## Configuring the domain readiness
383
384
384
-
Kubernetes has a concept of “readiness” that is used to determine when external requests should be routed to a particular pod. The domain creation job provided with the operator configures the readiness probe to use the WebLogic Server ReadyApp, which provides a mechanism to check when the server is actually ready to process work, as opposed to simply being in the RUNNING state. Often applications have some work to do after the server is RUNNING but before they are ready to process new requests.
385
+
Kubernetes has a concept of “readiness” that is used to determine when external requests should be routed to a particular pod. The domain creation job provided with the operator configures the readiness probe to use the WebLogic Server ReadyApp, which provides a mechanism to check when the server is actually ready to process work, as opposed to simply being in the `RUNNING` state. Often applications have some work to do after the server is `RUNNING` but before they are ready to process new requests.
385
386
386
387
ReadyApp provides an API that allows an application to register itself, so that its state will be taken into consideration when determining if the server is “ready”, and an API that allows the application to inform ReadyApp when it considers itself to be ready.
0 commit comments