3.4 Supported Architectures for Oracle HTTP Server

Oracle HTTP Server (OHS) can be deployed in the following Kubernetes scenarios:
  • Oracle HTTP Server deployed on a shared Kubernetes cluster with other applications.
  • Oracle HTTP Server deployed on an independent Kubernetes cluster.

Before deploying OHS you must consider what architecture to deploy and then plan accordingly.

Oracle HTTP Server on a Shared Kubernetes Cluster

This deployment is recommended for sandbox and intranet environments only.

In this deployment OHS is installed on the same Kubernetes cluster as other Kubernetes deployed applications. For example, you may want to deploy OHS on the same Kubernetes cluster as other Oracle products such as Oracle WebLogic Server, or Oracle Access Management (OAM).

If OHS needs to communicate with other applications on the same Kubernetes cluster, for example using mod_wls_ohs to communicate with Oracle WebLogic Server, then the OHS communicates to the internal port of that Kubernetes service.

An example architecture is as follows:

Figure 3-2 OHS on a Shared Kubernetes Cluster


OHS on a Shared Kubernetes Cluster

In this example:
  • OHS is deployed in the same Kubernetes cluster as Oracle WebLogic Server.
  • SSL is terminated at the load balancer.
  • The load balancer communicates with OHS via the OHS nodeport using HTTP.
  • OHS communicates with the WebLogic Administration and WebLogic Managed Servers via HTTP, using the internal port of the associated Kubernetes service: <service_name>.<namespace>.svc.cluster.local:<port>. The <service_name> and <port> can be found by running kubectl get svc -n <namespace> on your Kubernetes cluster.

Note:

The load balancer is optional and you can connect direct to the OHS nodeport if required, either from workstations outside the firewall, or internally from other applications.

Oracle HTTP Server on an Independent Kubernetes Cluster

This deployment is recommended for internet facing, production environments.

In this deployment OHS is installed on it’s own Kubernetes cluster inside a demilitarized zone.

If OHS needs to communicate with other applications deployed on a different Kubernetes cluster, for example using mod_wl_ohs to communicate with Oracle WebLogic Server, then the OHS communicates via HTTP to the Ingress controller port used by the application on that Kubernetes cluster, or to the appropriate NodePort Kubernetes service you wish to connect to.

An example architecture is as follows:

Figure 3-3 OHS on an Independent Kubernetes Cluster


OHS on an Independent Kubernetes Cluster

In this example:
  • SSL is terminated at the load balancer.
  • The load balancer communicates with OHS via the OHS nodeport using HTTP.
  • WebLogic Server is deployed on it’s own Kubernetes cluster.
  • OHS communicates with the WebLogic Administration and WebLogic Managed Servers using the HTTP port of the Ingress controller configured for WebLogic Server.

Note:

The load balancer is optional and you can connect direct to the OHS nodeport if required, either from workstations outside the firewall, or internally from other applications.