Oracle Rest Data Services (ORDS) Operator for Kubernetes

This is a Proof-of-Concept Oracle Rest Data Services Operator (ORDS Operator) and is currently not supported by Oracle.

Your evaluation and Feedback is appreciated.

Description

The ORDS Operator extends the Kubernetes API with a Custom Resource (CR) and Controller for automating Oracle Rest Data Services (ORDS) lifecycle management. Using the ORDS Operator, you can easily migrate existing, or create new, ORDS implementations into an existing Kubernetes cluster.

This Operator allows you to run what would otherwise be an On-Premises ORDS middle-tier, configured as you require, inside Kubernetes with the additional ability of the controller to perform automatic ORDS/APEX install/upgrades inside the database.

Features Summary

The custom RestDataServices resource supports the following configurations as a Deployment, StatefulSet, or DaemonSet:

• Single RestDataServices resource with one database pool
• Single RestDataServices resource with multiple database pools^*
• Multiple RestDataServices resources, each with one database pool
• Multiple RestDataServices resources, each with multiple database pools^*

^{*See Limitations}

It supports the majority of ORDS configuration settings as per the API Documentation.

The ORDS and APEX schemas can be automatically installed/upgraded into the Oracle Database by the ORDS Operator.

ORDS Version support:

• v22.1+

Oracle Database Version:

• 19c
• 23ai (incl. 23ai Free)

Quick Installation

To install the ORDS Operator, run:

kubectl apply -f https://github.com/gotsysdba/oracle-ords-operator/releases/latest/download/oracle-ords-operator.yaml

This will create a new namespace, oracle-ords-operator-system, in which the Controller will run.

Common Configurations

A few common configuration examples can be used to quickly familiarise yourself with the ORDS Custom Resource Definition. The "Conclusion" section of each example highlights specific settings to enable functionality that maybe of interest.

• Containerised Single Instance Database using the OraOperator
• Multipool, Multidatabase using a TNS Names file
• Autonomous Database using the OraOperator - (Customer Managed ORDS) ^{*See Limitations}
• Autonomous Database without the OraOperator - (Customer Managed ORDS)
• Oracle API for MongoDB Support

Running through all examples in the same Kubernetes cluster illustrates the ability to run multiple ORDS instances with a variety of different configurations.

If you have a specific use-case that is not covered and would like it to be, please open an Enhancement Request or feel free to contribute it via a Pull Request.

Limitations

When connecting to a mTLS enabled ADB and using the OraOperator to retreive the Wallet, it is currently not supported to have multiple, different databases supported by the single RestDataServices resource. This is due to a requirement to set the TNS_ADMIN parameter at the Pod level (#97).

Contributing

See Contributing to this Repository

Reporting a Security Issue

See Reporting security vulnerabilities

License

Copyright (c) 2024 Oracle and/or its affiliates. Released under the Universal Permissive License v1.0 as shown at https://oss.oracle.com/licenses/upl/