8.2 OCI Resource Manager: Stacks, Jobs, Drift Detection & Private Endpoints
Key Takeaways
A Resource Manager stack is the set of OCI resources that corresponds to one Terraform configuration, and it lives in one compartment in one region.
Only one job at a time can run on a stack, because Resource Manager locks the stack's state while a job runs.
Drift detection reports resources whose real configuration differs from the stack's last executed configuration, and it can be limited to specific resource addresses.
Resource discovery captures existing resources in a compartment as Terraform configuration and state files.
Resource Manager private endpoints let Terraform reach non-public resources, such as private instances for remote-exec or a private Git server.
What Resource Manager Adds to Terraform
Running Terraform on laptops creates problems at enterprise scale: state files get lost or copied, two people run apply at once, and credentials sit on personal machines. OCI Resource Manager solves these by running Terraform jobs inside OCI, storing the state, and controlling access with IAM.
Core Concepts
| Concept | Meaning |
|---|---|
| Stack | The collection of OCI resources for a Terraform configuration. A stack resides in one compartment and one region, although the configuration can create resources in other regions. |
| Configuration | Terraform files (HCL or JSON) that define the resources, data sources, and variables. |
| Job | An instruction to run a Terraform action on a stack. Jobs keep history: plan jobs store execution plans, and apply jobs store configuration snapshots and state. |
| State | The JSON state file that Resource Manager generates and stores for each stack. |
| Configuration source provider | Connection details for a source control system that holds the configuration. |
| Template | A prebuilt configuration, provided by Oracle or shared privately within your tenancy. |
| Private endpoint | Network information that lets Resource Manager reach non-public resources. |
Creating a Stack: Where the Configuration Comes From
| Source | Typical use |
|---|---|
| Local .zip file | Quick uploads of a configuration bundle |
| Object Storage bucket | Configurations produced by a build pipeline |
| Source code control (GitHub, GitLab, Bitbucket Cloud, Bitbucket Server, OCI DevOps code repositories) | CI/CD: the stack always uses a versioned branch |
| Oracle-provided or private templates | Standard architectures shared across teams |
| Existing compartment | Resource discovery turns deployed resources into a new stack |
| Resource creation page | Saving a Console form as a stack instead of creating the resource directly |
You can also add a Deploy to Oracle Cloud button to a Git repository's README so users launch the configuration as a stack with one click.
Variables and the Schema Document
Stack variables are passed to the Terraform job as environment variables. A schema document (schema.yaml) in the configuration describes the variables for the Console, so users see friendly fields, drop-down lists of compartments or VCNs, validation, and grouping instead of raw text boxes. Inside Resource Manager, the provider "oci" block only needs the region, because the service supplies authentication.
Jobs
Resource Manager supports these job types:
| Job | What it does |
|---|---|
| Plan | Generates and stores an execution plan |
| Apply | Creates or updates resources, optionally using an approved plan job |
| Destroy | Deletes the stack's resources |
| Import state | Imports an existing Terraform state file into the stack |
Job lifecycle states are Accepted, In Progress, Succeeded, Failed, Canceling, and Canceled. Only one job at a time can run on a stack, because Resource Manager locks the stack's state during a job. This replaces the manual locking discipline that local Terraform requires. If a job fails because of a temporary problem in a downstream service, it retries according to the Go SDK's default retry policy.
Drift Detection
Drift is the difference between the real state of the infrastructure and the stack's last executed configuration, for example when someone adds a tag or changes a security rule in the Console. A drift detection run reports the drift status of each resource. You can limit the run to specific resource addresses, such as oci_core_instance.test_instance[3], which combines the resource type, the resource name from the configuration, and an index.
Drift detection only reports. To fix drift, you either update the configuration to match the change or run an apply job to restore the configured values.
Resource Discovery: Importing Existing Infrastructure
Many organizations start with resources built by hand. Resource discovery captures deployed OCI resources as Terraform configuration and state files. With it you can:
- Move manually managed infrastructure under Resource Manager control.
- Learn how Terraform represents OCI resources in HCL.
- Duplicate or rebuild existing infrastructure in another compartment.
Private Endpoints and Remote-Exec
Terraform's remote-exec provisioner runs commands on an instance after it is created, for example to install software. If the instance has only a private IP, Resource Manager cannot reach it over the internet. A Resource Manager private endpoint gives jobs a network path into a VCN subnet so they can:
- Run remote-exec against private compute instances.
- Pull configurations from a private Git server in OCI or on-premises (over VPN or FastConnect); you import the server's SSL certificate into the Certificates service.
- Reach other private endpoints, such as a private OKE API endpoint.
Managing private endpoints requires permission to manage Resource Manager private endpoints and to use the related network resources.
Templates and Governance
Private templates let a platform team publish approved configurations, such as a hardened three-tier application or a standard network, to everyone in the tenancy. Combined with IAM (manage orm-stacks and manage orm-jobs for operators, read-only access for auditors), templates make the approved architecture the easiest one to deploy.
A security engineer changed a security list rule in the Console on resources that are managed by a Resource Manager stack. The architect wants to know which resources no longer match the stack's last executed configuration, without changing anything. What should the architect run?
An apply job with the latest configuration
A destroy job followed by an apply job
An import state job using a local state file
A drift detection report on the stack
A Terraform configuration in Resource Manager uses remote-exec to install an agent on new compute instances that have only private IP addresses. The apply job fails because it cannot connect to the instances. What should the architect add?
An internet gateway and public IP addresses on every target instance
A Resource Manager private endpoint in a subnet that can reach the instances
A larger shape for each instance so that the agent installs faster
A second stack in another region that runs the remote-exec provisioner for the first
A company built its production network by hand over two years and now wants to manage it with Resource Manager without rebuilding anything. Which capability should it use first?
Drift detection, which converts the existing resources into a stack
An Oracle-provided template that matches the existing network design
A destroy job followed by an apply job of a newly written configuration
Resource discovery, which creates a stack with configuration and state
Sections you finish are checked off in the contents.