Administration Best Practices

Follow these best practices to ensure that your Oracle Java Cloud Service instances work as expected and remain manageable.

Caution:

Oracle supports customizing the default configuration of the operating system, WebLogic Server, Coherence, Database, and Traffic Director in an Oracle Java Cloud Service instance. While most modifications to these components are acceptable, some changes may cause certain management features to fail or not operate properly, such as backups, patching, or scaling. Use caution, especially when performing root-level or system-level changes on the nodes in your service instance.
Best Practice More Information

Do not create additional product installations.

Use only the default Oracle WebLogic Server product installation that is provisioned when a service instance is created. If you manually create other installations in your service instance Oracle Java Cloud Service will not be aware of them. Consequently, you will not be able to use Oracle Java Cloud Service to manage, scale, backup or patch these product installations.

Similarly, do not manually install Oracle Traffic Director or Oracle Coherence.

Do not create additional WebLogic Server domains.

Use only the default Oracle WebLogic Server domain that is provisioned when a service instance is created. If you manually add domains to the service instance Oracle Java Cloud Service will not be aware of them. Consequently, you will not be able to use Oracle Java Cloud Service to manage, scale, backup or patch these domains.

Ensure unique WebLogic Server domain names.

If you plan to configure cross-domain communication between multiple Oracle Java Cloud Service instances, the Oracle WebLogic Server domains and their associated resources must have unique names. To accomplish this, be sure that the first eight characters of your Oracle Java Cloud Service instance names are unique.

By default, the names of the domain and cluster in the Oracle Java Cloud Service instance are generated from the first eight characters of the service instance name and use the following formats, respectively:

  • first8charsOfServiceInstanceName_domain

  • first8charsOfServiceInstanceName_cluster

  • first8charsOfServiceInstanceName_DGCluster (when Oracle Coherence is enabled for a service instance)

Do not modify or delete the default resources and applications in the WebLogic Server domain.

All service instances are configured with several data sources, libraries, applications and other domain resources. Do not modify or delete these default domain resources. Any modifications might cause your servers to fail upon restart.

By default, a sample application is deployed to a service instance. You can delete this sample application from the domain.

Do not modify the default administration ports.

Do not change the default ports that Oracle Java Cloud Service configures for the Oracle WebLogic Server administration server and the Oracle Traffic Director administration server.

You can open new ports, but closing or modifying existing ports may impair the functionality of the service instance. See About the Default Access Ports.

Restrict external access.

Oracle recommends you restrict Internet access to the WebLogic administration port and Oracle Traffic Director WebLogic administration port by configuring security ingress rules using a fixed set of IPs or a CIDR matching your organization's network addresses. See the My Oracle Support Document ID 2664435.1.

Do not enable T3 or tunneling.

Oracle does not recommend enabling the T3 and T3 over SSL (T3S) protocols or tunneling on network channels that are accessible from outside of Oracle Cloud.

Use Oracle VPN.

If you continue to use T3, block the ports from external access and make sure the ports are accessible via Oracle VPN only using T3S. See VPN Connect Overview in the Oracle Cloud Infrastructure documentation.

Apply only approved patches.

Apply only patches that are provided through the Oracle Java Cloud Service patching feature. Do not apply patches from any other source. See View Patch Details.

Apply patches promptly.

Apply the most recent patches as soon as they’re available in Oracle Java Cloud Service. Delaying the application of patches might cause your service instance to be unsupported for future patches.

Apply Oracle Linux OS patches.

Oracle Java Cloud Service does not provide cloud tooling to patch the Oracle Linux operating system on the nodes in your service instances. You are responsible for installing Oracle Linux OS patches. See About Patching and Rollback.

Do not install OS patches for other Linux distributions. Also, if you plan to use your service instance for production applications, Oracle recommends that you avoid installing any test, development, or preview OS packages that might be available in the repository.

Follow the approved SSL configuration procedure.

If you want to use custom SSL certificates in your service instance, see Configure SSL for a Service Instance. This procedure ensures that management operations like restarting, backing up, scaling, and patching continue to function properly.

Use Oracle Java Cloud Service to perform scaling operations.

Scale out an Oracle WebLogic Server cluster within a service instance only by using the scaling capabilities of Oracle Java Cloud Service. Do not use the WebLogic Server administrative interfaces to directly add Managed Servers to a cluster. See About Scaling an Oracle Java Cloud Service Cluster.

Use the REST API to add a cluster to an existing service instance.

By default, Oracle Java Cloud Service creates a single Oracle WebLogic Server cluster within your service instance, and optionally a second cluster if Oracle Coherence is enabled. However, you can create additional clusters in the service instance if necessary.

Add clusters to a service instance only by using the Oracle Java Cloud Service REST API. Do not use the WebLogic Server administrative interfaces to directly add clusters to your domain. See Scale Out a Service Instance in REST API for Oracle Java Cloud Service.

Oracle Java Cloud Service does not support service instances with multiple Coherence (storage-enabled) clusters.

Use the REST API to change the Node Manager password.

If you want to change the default Node Manager password, do not manually edit the nm_password.properties file on a node. This will cause lifecycle and other administrative operations to fail. Instead, you must use the Oracle Java Cloud Service REST API. See Change the Node Manager Credentials in REST API for Oracle Java Cloud Service.

Do not use the default Coherence cluster.

When Oracle Coherence is enabled for a service instance, Oracle Java Cloud Service creates a Coherence cluster in the domain named DataGridConfig. Both Oracle WebLogic Server clusters are members of this Coherence cluster. You can customize the configuration of the DataGridConfig Coherence cluster if necessary.

All Oracle Java Cloud Service domains also include a Coherence cluster named defaultCoherenceCluster, which has no members. Do not modify or use this Coherence cluster.

Use Oracle Java Cloud Service to add storage to a node.

If a node within a service instance requires additional storage, add storage by scaling up the node. See About Scaling an Oracle Java Cloud Service Node.

Do not attach custom storage volumes to a service instance's nodes. Any custom storage volumes that you attach will be detached if the service instance is restarted.

Do not share databases if backups are enabled.

To ensure that you can restore the database for an Oracle Java Cloud Service instance without risking data loss for other service instances, Oracle recommends that you do not associate the same infrastructure schema database (or the same pluggable database) with multiple service instances.

Backups of a database that is used with multiple Oracle Java Cloud Service instances contain data for all the instances. Therefore, if you restore the database from a backup, data for all the service instances is restored, which might not be the intended result.

Use a dedicated storage container for backups.

Do not use an object storage container that you use for backups of Oracle Java Cloud Service instances for any other purpose. Using the container for multiple purposes can result in billing errors.

For example, do not use the same object storage container to also back up the database.

Do not directly modify the MIDDLEWARE_HOME or JAVA_HOME volumes on any node.

All storage volumes mounted under /u01 should be treated as read-only by administrators, except for the contents of DOMAIN_HOME and APPLICATION_HOME. Any modifications you make to other volumes such as MIDDLEWARE_HOME may be lost when you perform management operations on your Oracle Java Cloud Service instance like applying a patch.

Do not modify a node’s file system configuration.

Do not detach, change file access permissions for, or change the mount point of any storage volume that Oracle Java Cloud Service creates and attaches to a service instance's nodes during the creation of the service instance. See About the Disk Volumes.

Do not directly modify a node’s user or SSH settings.

Oracle Java Cloud Service configures default OS users and Secure Shell (SSH) access settings during the creation of a service instance. Do not modify these default users and use only the features of Oracle Java Cloud Service to modify the SSH settings. See Add an SSH Public Key.

Avoid certain modifications to a node’s network configuration.

Do not close any ports that Oracle Java Cloud Service opened during the creation of your service instance. You can open new ports, but closing existing ports may impair the functionality of the service instance. See Understanding the Default Access Ports.

Also,

  • Do not change the default egress and ingress network and security settings of a service instance’s nodes.

  • Do not detach the public IP addresses from any of a service instance's nodes.

Do not modify the required database schemas.

Do not modify the Oracle Fusion Middleware component schemas that Oracle Java Cloud Service provisions within the selected infrastructure schema database during the creation of a service instance.

Do not modify any scripts in the /u01/app/oracle/tools directory. Any changes to the scripts in the /u01/app/oracle/tools directory can affect the manageability of your instance adversely.
Do not modify the /u01/app/oracle/tools/paas/state/logs directory or any files in it. If the log files in /u01/app/oracle/tools/paas/state/logs are lost, then information that’s important for diagnosing issues will be lost.
Do not modify the /u01/app/oracle/tools/paas/state/work directory or any files in it. If the files in /u01/app/oracle/tools/paas/state/work are lost or modified, failures can occur when performing operations like adding a second Oracle Traffic Director node or rotating the log file.
Use only the opc-config Oracle Traffic Director configuration, which is created automatically when the instance is created. If you replace opc-config with a configuration of a different name, then Oracle Cloud won't recognize the configuration. Oracle Traffic Director may not start when the node is rebooted, restarted, or restored.

If you create an additional Oracle Traffic Director configuration, then that configuration and its Oracle Traffic Director instance are not recognized by Oracle Cloud. So lifecycle operations for that Oracle Traffic Director instance are not managed by Oracle.

Use the ephemeral port range (1024 - 65535) for Oracle Traffic Director listener port. By default, Oracle Java Cloud Service instance provisioning always configures Oracle Traffic Director HTTPS listener on port 8081 and redirects the requests on port 443 to port 8081 using iptables.

If the listener is configured to use ports in the range 1 to 1024, Oracle Traffic Director fails to start as oracle user cannot open listen ports in the range 1 to 1024.

So, you must configure Oracle Traffic Director listener port in the ephemeral port range and use the iptables command to redirect requests from port 443 to the ephemeral port that you have configured.