Kubernetes has become the most popular and ubiquitous open-source framework for automating Continuous Integration and Continuous Delivery (CI/CD) pipelines. Its core functionality coupled with Helm Charts (i.e., a package manager for template YAML files and other capabilities) manages the lifecycle of simple and stateless applications (i.e., define, install, deploy, and delete). Operators, on the other hand, extend Kubernetes’s core functionality with custom resources definitions (i.e., complex and stateful applications such as databases) and controllers that encapsulate the knowledge or business logic involved in managing the lifecycle of those custom resources.
Oracle is releasing the Oracle Database Operator for Kubernetes (a.k.a. OraOperator) which extends the Kubernetes API with custom resources definitions and controllers for automating Oracle Databases operations.
What’s in OraOperator for Developers, DBAs, DevOps, and GitOps Teams?
By making Oracle Databases operatable by Kubernetes similarly to its native objects, OraOperator helps developers, DBAs, DevOps and GitOps teams reduce the time and complexity of deploying and managing Oracle Databases. It eliminates the dependency on a human operator or administrator for the majority of database operations.
This first release supports Oracle Database deployed in and off Kubernetes clusters, more specifically: the Autonomous Databases in OCI (Shared infrastructure), these do not run in Kubernetes; containerized Single Instance Databases in the OCI Kubernetes Engine (OKE), and the Oracle Linux Cloud Native Environment (OLCNE); finally, containerized Oracle Sharded Databases in OKE and OLCNE.
Here is a brief description of the lifecycle operations supported by each controller.
Managing Autonomous Databases with OraOperator
Oracle Autonomous Databases (ADB) are currently deployed in the Oracle Cloud Infrastructure (OCI), not in a Kubernetes cluster.
In this release, the Autonomous Database controller supports all current workloads on shared OCI infrastructure (as opposed to dedicated infrastructure). The workloads include the Autonomous Transaction Processing (ATP), the Autonomous Data Warehouse (ADW), the Autonomous JSON Database (AJD), and Oracle APEX Application Development (APEX Service).
The ADB controller allows provisioning a new instance or binding the operator to an existing one, then the following operation can be performed: start, stop, terminate, delete, rename, scale-up/down (CPU, storage), enable/disable auto-scaling, download the wallet associated with the database instance (a regional wallet is an alternative choice), and manage the password of the database ADMIN user.
Managing Containerized Single Instance Databases with OraOperator
Oracle Database Single Instance (SIDB) are instances of either Standard Edition (SE), or Enterprise Edition (EE) databases. These can be containerized and deployed over a Kubernetes cluster (OKE and OLCNE as of this release) and managed by the operator.
The SIDB controller furnishes the following lifecycle operations: provision a new database instance, clone an existing instance, in-place or out-of-place patching to a higher release update, or rolling back to a lower release update.
Managing Containerized Oracle Database Sharding with OraOperator
Oracle Database Sharding (SDB) is made of a Catalog database, Global Data Services, and Shards (i.e., databases). All these (a.k.a. the Sharding Database topology) can be containerized and deployed as a Statefulset in a Kubernetes cluster (OKE and OLCNS as of this release) and managed by the Operator.
The SDB controller furnishes the following lifecycle operations: provision a Sharding Database topology, Shard scale up/down, Sharding Database topology cleanup.
Kubernetes Secrets are the usual means for storing credentials or passwords. The operator reads the Secrets programmatically, which limits the exposure of sensitive data. However, Oracle strongly recommends that you set and get sensitive data from Oracle Cloud Infrastructure Vault, or from third-party Vaults.
The following YAML file fragment specifies Oracle Cloud Infrastructure Vault as the repository for the admin password.
Members of the Oracle database community who were briefed about this product are very excited about it. We are eager to incorporate suggestions and contributions.
See Contributing to this Repository
Looking Forward …
In upcoming releases, OraOperator will extend the capabilities of existing controllers, add support for more deployments in-and-off Kubernetes clusters, support for more Kubernetes clusters or equivalent platforms, and additional services.
@kmensah and #OraOperator for notifications, questions, and discussions.
Thanks for reading.