OCI stack deployment
A manual deployment of OCI's diverse components could be error-prone and challenging. To simplify this, OCI provides a tool known as Resource Manager. This tool facilitates a user-friendly experience by allowing straightforward deployment directly from a UI, significantly reducing complexity and improving usability for customers.
Under the hood, the OCI Resource Manager uses configuration by Terraform, a very popular infrastructure-as-code tool to build, change, and version infrastructure safely and efficiently. The OCI Resource Manager lets you define, provision, and manage cloud infrastructure-as-code without having to install or manage Terraform yourself.
In OCI Resource Manager, a stack empowers users to automate the provisioning of OCI services as a single unit. It is essentially a Terraform configuration package (set of .tf files and variables) that defines a collection of OCI resources.
Hackolade has open-sourced the Terraform configuration needed to seamlessly create the OCI stack for the Model Hub in their own OCI accounts. The configuration can be scrutinized, if needed, so you can be confident of the security and reliability of the configuration. The configuration is accessible in this GitHub repository.
Our stack includes:
- creates and configures all necessary components.
- ensures compatibility and coordination between services.
- streamlines the setup process to avoid manual, error-prone procedures.
The configuration creates the following components:
- a dynamic group and a policy to manage permissions
- an always-free Autonomous JSON database (can be upgraded later to larger instance)
- both an admin username/password and a schema username and password
- a container registry including an image with the latest version of the Docker images of the Model Hub
- OCI functions, including models replication from the configured repositories
- a Queue and a service connector
- a key management store for secrets
- various network resources
- an API gateway
- a resource scheduler (checks for the availability of new Docker images, based on a schedule)
- a logging group
If you have not done so yet, make sure first that all documented prerequisites have been fulfilled.
Before we start, let's briefly discuss additional preparation steps, including sizing estimates and naming conventions for the different elements that will be created with this operation...
Installation variables
Naming guidelines
Having a clear naming convention in OCI is important because resources are the backbone of governance, access control, and cost tracking. Oracle doesn’t enforce a standard, but many organizations follow conventions that reflect organization, environment, and purpose. Choosing the right names is helpful for many different resources.
A compartment is a logical container location you use to organize and isolate OCI resources (like compute instances, VCNs, databases, buckets, etc.). Think of it like a folder in a file system, but instead of files, it holds cloud resources. Compartments allow fine-grained access control, so you can grant or restrict groups of users access to specific compartments. They allow to separate workloads (e.g., Prod, Dev, Test) or separate environments (e.g., HR apps vs. eCommerce apps). They allow to tag resources, for example for billing and cost tracking. They help enforce least-privilege access and let you keep unrelated workloads isolated to reduce risk.
Since compartments are long-lived and organizational, a clear naming strategy helps a lot. If you don't already have internal compartments naming conventions, we suggest to create one that is consistent across your organization. One that reflects your environment, function/team, organizational unit, shared services, or region/project, and one that keeps names human-readable (avoid cryptic codes only admins understand). For example: [Department] - [Application] - [Environment] For simplicity, the Model Hub can be placed in its own compartment. Then, if you need access its resources from other compartments, it will be possible to create a cross-compartment IAM policy to do so.
Stack names should reflect their purpose, environment, and scope. For example: [Project or App] - [Environment] - [Layer/Function] - [Region (if needed)]. You may want to align with compartment naming conventions (so it’s easy to map stacks to their resource location.)
OCI provides a tagging framework that lets you attach metadata to resources. Think of them as flexible labels that travel with your resources. They can be used for cost tracking, ownership and responsibility, automation, lifecycle management, governance, etc. Tags can be free-form (key-value pairs with no enforced schema), or organization-controlled key-value pairs with predefined namespaces.
Warning: the database name must begin with an alphabetic character and can contain a maximum of 30 alphanumeric characters. Special characters are not permitted. The database name must be unique in the tenancy.
Instance sizing
An OCI Elastic Compute Unit (ECPU) is an abstracted measure of compute resources for the Oracle Autonomous Database to provide a consistent price metric independent of the underlying hardware. ECPUs allow for elastic resource allocation, enabling dynamic adjustments based on workload and contributing to cost savings through features like elastic pools. An ECPU is based on the number of cores per hour elastically allocated from a pool of compute and storage servers. It is not to be confused with an OCPU which is defined as the equivalent of one physical core with hyper-threading enabled. In contrast, an ECPU is not explicitly defined in terms of an amount of physical hardware. By introducing ECPU’s, Oracle is providing a durable pricing metric which is not tied to the exact make, model, or clock speed of the underlying processor.
The OCI pricing information is provided for information purposes, and only to help with your sizing estimates. The information was taken at the time of writing this documentation from this Oracle ECPU FAQ document, and may change without notice. Hackolade is not responsible for OCI pricing. Prices listed here are as of the time of writing this article and are subject to change. Customers are billed directly by Oracle. Prices below are in US Dollars. Please refer to the pricing list at https://www.oracle.com/cloud/price-list/)
Unless you set the number of ECPU to 0 which sets your instance with always-free (but limited) capacity, ECPU databases need to be provisioned with a minimum of 2 ECPUs. At the time of writing this documentation, the prices for ECPU’s are (in US dollars):
- Autonomous JSON Database: $0.0807 per ECPU per hour (0 ECPUs for always-free tier, or minimum of 2 ECPUs)
- Autonomous Database Serverless storage for Autonomous Transaction Processing, Autonomous JSON Database, and APEX Service: 1 GB at $0.1156 with 1 GB increment (minimum of 20 GB)
- Autonomous Transaction Processing: $0.336 per ECPU per hour. Alternatively, Bring-You-Own-License pricing is available with Autonomous Transaction Processing: $0.0807 per ECPU per hour. (Up to 8 ECPU’s may be activated for each supported Processor license of Oracle Database Enterprise Edition and up to 16 ECPU’s for each supported Processor license of Oracle Database Standard Edition)
We suggest that you start small, then monitor usage, and adjust if necessary. Videos about OCI cost analysis and management are available here.
Instance storage
The initial creation of the dat base requires 6.5GB of the minimum 20GB of storage, meaning that more than 13GB remain available for the operations of the Model Hub. It is advised to consider alerts when reaching 75% utilization. Waiting until storage is nearly full (above 85%) can risk service interruption or failed writes, so timely scaling or expansion at 75-80% usage ensures database continuity and smooth operations. 75% of 20MB minus ~7GB, that leaves 8GB for Model Hub operation.
Deploying the Hackolade Model Hub stack on OCI
This infrastructure-as-code deployment is useful for the initial setup. It is run just once to set up a new stack. It cannot be used to update the infrastructure. For updates, an OCI administrator will need to update the stack configuration.
Log in to your OCI account, the follow these steps:
Create a compartment
Use the navigation menu to go to Identity & Security > Identity > Compartments and click the Create compartment button
Then provide a name and description, and choose the appropriate parent compartment, typically the root compartment.
Create a configuration source provider
Use the navigation menu to go to Developer Servcies > Resource Manager > Configuration source providers. Make sure to select the correct compartment in the dropdown list on the left:
Then click the button Create configuration source provider:
The server URL is https://github.com/hackolade-public/ and the Personal access token will have been given to you by the Hackolade Helpdesk at support@hackolade.com
Once created, it is useful to validate the connection before proceeding, to ensure that the setup is correct.
Click the link Validate connection and make sure to get the proper acknowledgment:
Create a stack
Use the navigation menu to go to Developer Services > Resource Manager > Stacks and make sure to select the appropriate region, typically the one closest to the majority of your Model Hub users. It is possible, but not covered here, to replicate regions for higher availability.
Make sure to select the proper compartment in the dropdown list on the left:
Click the button Create stack and select the radio button for Source code control system. Select Github, the source provider config created above in the selected compartment, then select the repository we provide and the main branch:
Optionally provide a name and decription, then ensure that the stack is created in the correct compartment, then click Next:
In the next scree, you must provide values for the stack variables. Be careful to enter the proper values according to guidelines below, and document them:
The deployed stack comes with the variables below. They are sorted in alphabetical order
- compartment_ocid: do not change this value. It is the OCID of the parent compartment
- hub_db_admin password: password of the admin user for the hub_db_name instance of the autonomous database
- hub_db_ecpu_count: number of ECPUs provisioned for this new database. If set to 0, it will create an always-free database
- hub_db_name: name of the Hub database to be created. The name must begin with an alphabetic character and can contain a maximum of 30 alphanumeric characters. Special characters are not permitted. The database name must be unique in the tenancy.
- hub_db_schema_password: password of the schema for the hub_db_name instance the autonomous database
- hub_db_schema_username: user that will be created in the database. It's in this user schema that the Hub database schema will be deployed. You must communicate this database schema username to Hackolade Helpdesk, as detailed in these instructions.
- hub_db_storage_count: specify the storage you wish to make available to your database in gigabytes. Minimum starts at 20GB
- hub_domain_name: the domain name used to serve the application. It is used to enable CORS in ORDS. OCI IAM also uses it to redirect the user to the correct application after a successful login. It is critical that:
-
- the domain remains .hackolade.com, and
- that you assign (and keep a record of) the subdomain.
For example <yourcompany-prod>.hackolade.com You must communicate this subdomain to Hackolade Helpdesk as detailed in these instructions.
- oci_username: this is the username of the user doing the installation. It's going to be used as a user to push Docker images in the internal Docker registry.
- region: you can leave this as is. It's the region where this compartment will be deployed, and it's going to be the same as the one you are in
- tenancy_ocid: do not change this value. It's the OCID of the tenancy
Troubleshooting
Go to Resources Manager > Stacks and click in the stack name. Then click on the job name for the job which was applied for your stack
The status of the job is provided in just a few minutes.
You can also verify the presence of the different resources created in the specified compartment, for example in Oracle Database > Autonomous Databases:
Troubleshooting
The status of the job is provided in just a few minutes.
The bottom of the log file should explain the reason for the failure, for example
In the above example, the message is clear and the corrective actions explained.
If necessary, you may open a ticket with our Helpdesk at support@hackolade.com and provide the downloaded log file.