Overview of Resource Manager
Resource Manager is an Oracle Cloud Infrastructure service that allows you to automate the process of provisioning your Oracle Cloud Infrastructure resources. Using Terraform, Resource Manager helps you install, configure, and manage resources through the "infrastructure-as-code" model.
Resource Manager is not available in US Government Cloud realms.
A Terraform configuration codifies your infrastructure in declarative configuration files. Resource Manager allows you to share and manage infrastructure configurations and state files across multiple teams and platforms. This infrastructure management can't be done with local Terraform installations and Oracle Terraform modules alone. For more information about the Oracle Cloud Infrastructure Terraform provider, see Terraform Provider. For a general introduction to Terraform and the "infrastructure-as-code" model, see https://www.terraform.io.
Following are brief descriptions of key concepts and the main components of Resource Manager.
- Information to codify your infrastructure. A Terraform configuration can be either a solution or a file that you write. You can either upload your written file directly or store it in a source code control system.
- Use your configuration to specify the Oracle Cloud
Infrastructure resources in a given stack. For example, specify resource metadata, data
source definitions, and variable declarations. Each Terraform configuration file
is either HashiCorp Configuration Language (HCL) format or JSON format, as
indicated by the file's extension (either
- For example configurations, see Terraform provider examples and Sample Solutions. For more information, see Terraform Configurations for Resource Manager and Writing Terraform Configurations; see also Hashicorp: Configuration.
- configuration source provider
- Connection information to a source code control system where your Terraform configuration files are stored. Use a configuration source provider to create a stack from a remote, versioned Terraform configuration file.
- A configuration source provider has the following types:
- GitLab: Supports the following products:
- GitLab Community Edition
- GitLab Enterprise Edition
- GitLab: Supports the following products:
- A configuration source provider has the following lifecycle states:
- Active: The configuration source provider is available for use.
- For more information, see Managing Configuration Source Providers (Console) and To create a stack.
- Difference between the actual, real-world state of your infrastructure, and the stack's last executed configuration. For example, drift occurs when a team member adds a production tag to your resources, or when a resource fails. You can run drift detection reports to determine if provisioned resources have different states than those resources defined in the stack's last executed configuration. You can also view detailed drift status for each resource.
- Instructions to perform the actions defined in your configuration. Only one job at a time can run on a given stack; further, you can have only one set of Oracle Cloud Infrastructure resources on a given stack. To provision a different set of resources, you must create a separate stack and use a different configuration.
- Resource Manager provides the following job types:
- Plan: Parses your Terraform configuration and creates an execution plan for the associated stack. The execution plan lists the sequence of specific actions planned to provision your Oracle Cloud Infrastructure resources. The execution plan is handed off to the apply job, which then executes the instructions.
- Apply. Applies the execution plan to the associated stack to create (or modify) your Oracle Cloud Infrastructure resources. Depending on the number and type of resources specified, a given apply job can take some time. You can check status while the job runs.
- Destroy. Releases resources associated with a stack. Released resources are not deleted. For example, terminates a Compute instance controlled by a stack. The stack's job history and state remain after running a destroy job. You can monitor the status and review the results of a destroy job by inspecting the stack's log files.
- Import State. Sets the provided Terraform state file as the current state of the stack. Use this job to migrate local Terraform environments to Resource Manager.
- Jobs store history about their associated stack. For example, plan jobs store generated execution plans and apply jobs store configurations (snapshots) and state files. Jobs reside in the same compartment as the stack they are associated with. An OCID is assigned to each job.
- A job has the following lifecycle states:
- Accepted: The job was accepted for processing.
- In Progress: The job is currently executing.
- Failed: The job did not complete execution.
- Succeeded: The job completed execution.
- Canceling: The job is being canceled.
- Canceled: The job was canceled.
- A group of related resources. Use modules to create lightweight and reusable abstractions, so that you can describe your infrastructure in terms of its architecture. For more information, see Creating Modules.
- A .zip file to a Terraform configuration that is stored in a supported provider, such as GitHub. For more information, see Constructing a URL for the Deploy Button.
- resource discovery
- A feature to capture deployed resources as Terraform configuration and state files. With this feature, you can:
- Move from manually managed infrastructure to Resource Manager-controlled infrastructure.
- Learn how Terraform uses HashiCorp Configuration Language (HCL) syntax to represent Oracle Cloud Infrastructure resources.
- Duplicate or rebuild existing infrastructure in another compartment.
- Resource discovery supports the following Oracle Cloud Infrastructure resources: https://www.terraform.io/docs/providers/oci/guides/resource_discovery.html#supported-resources.
- To discover resources, use Resource Manager to create a stack from your compartment. The created stack includes a generated Terraform configuration and state file corresponding to the supported resources in the source compartment.
Attributes are missing from some supported resources captured using resource discovery. For more information, see Missing attributes in some discovered resources.
Details about undiscoverable attributes
In some cases, a required or optional attribute may not be discoverable from the Oracle Cloud Infrastructure services and may be omitted from the generated Terraform configuration. This omission may be expected behavior from the service, which may prevent discovery of certain sensitive attributes or secrets. In such cases, a placeholder value is set along with a comment like this:
admin_password = "<placeholder for missing required attribute>" #Required attribute not found in discovery, placeholder value set to avoid plan failure
The missing required attributes are also added to lifecycle ignore_changes. This addition is done to avoid Terraform plan failure when moving manually managed infrastructure to Terraform-managed infrastructure. Any changes made to such fields are not reflected in the Terraform plan. If you want to update these fields, remove them from ignore_changes.
Resources that depend on availability domains are generated under availability_domain.tf file. These resources include
- Terraform versions supported: 0.12.x
- sample solution
- An Oracle-provided, pre-built Terraform configuration that provisions a set of resources used in a common scenario. For instructions, see To create a stack. For reference, see Sample Solutions.
- The collection of Oracle Cloud Infrastructure resources corresponding to a given Terraform configuration. Each stack resides in the compartment you specify, in a single region; however, resources on a given stack can be deployed across multiple regions. An OCID is assigned to each stack.
can create stacksfrom solutions, from Terraform configurations stored either remotely or
locally, or from existing compartments using resource discovery.
A stack created from a compartment represents all supported resources in the entire compartment, at the appropriate scope. If you select the root compartment for your tenancy, then the scope is the tenancy level, such as users and groups. If you select a non-root compartment, then the scope is compartment level, such as Compute instances.
Stack creation is supported from a single compartment only. Stacks cannot be created from nested compartments.
- A stack has the following lifecycle states:
- Creating: The stack is being created.
- Active: The stack is available for use.
- Deleting: The stack is being deleted.
- Deleted: The stack was deleted.
- Failed: The stack could not be created.
- The state of your resource configuration, stored in JSON format in a state file (.tfstate). The state file maps your stack's resources to your configuration and also maintains essential configuration metadata, such as resource dependencies. For instructions, see To view the state of a stack and To view the state of a job. Resource Manager generates and updates state files automatically. You cannot edit the file manually.
- Resource Manager supports state locking by allowing only one job at a time to run on a given stack. For more information about state files, see Hashicorp: State.
The following image represents a generalized view of the Resource Manager workflow.
You can store your Terraform configuration file locally or remotely, using a source code control system. With remote storage, any job running on the associated stack automatically uses the latest version of your configuration. For more information about remotely storing your file, see Managing Configuration Source Providers (Console). You can skip this step if you use a solution provided by Oracle or create a stack from a compartment.
- Create a stack.
- Run a plan job, which produces an execution plan.
- Review the execution plan.
- If changes are needed in the execution plan, update the configuration and run a plan job again.
- Run an apply job to provision resources.
- Review state file and log files, as needed.
- You can optionally reapply your configuration, with or without making changes, by running an apply job again.
- Optionally, to release the resources running on a stack, run a destroy job.
For a detailed walkthrough of the Resource Manager workflow, see Sample: Creating a Compute Instance Using Resource Manager.
Ways to Access Resource Manager
You can access the Resource Manager service using the Console (a browser-based interface) or the REST API. Instructions for the Console and API are included in topics throughout this guide. For a list of available SDKs, see Software Development Kits and Command Line Interface.
Console: To access Resource Manager using the Console, you must use a supported browser. You can use the Console link at the top of this page to go to the sign-in page. You will be prompted to enter your cloud tenant, your user name, and your password. Open the navigation menu. Under Solutions and Platform, go to Resource Manager and click Stacks.
API: To access Resource Manager through APIs, use Resource Manager API. To access this API using the Command Line Interface (CLI), use the
oci resource-manager designation.
In addition to
terraform-provider-oci (the Terraform provider for Oracle Cloud
Infrastructure), Resource Manager supports the following third-party Terraform providers.
|Third-party Terraform Provider||Supported Versions|
1.1.0, 1.2.2, 1.4.0
Authentication and Authorization
Each service in Oracle Cloud Infrastructure integrates with IAM for authentication and authorization, for all interfaces (the Console, SDK or CLI, and REST API).
An administrator in your organization needs to set up groups , compartments , and policies that control which users can access which services, which resources, and the type of access. For example, the policies control who can create new users, create and manage the cloud network, launch instances, create buckets, download objects, etc. For more information, see Getting Started with Policies. For specific details about writing policies for each of the different services, see Policy Reference.
If you’re a regular user (not an administrator) who needs to use the Oracle Cloud Infrastructure resources that your company owns, contact your administrator to set up a user ID for you. The administrator can confirm which compartment or compartments you should be using.
Administrators: For common policies that give groups access to stacks and jobs, see Policies for Managing Stacks and Jobs. For a complete list of Resource Manager permissions, see Details for Resource Manager. Policies for managing accessed resource types are also required.
Policies for managing Oracle Cloud Infrastructure resources are also required for Resource Manager operations that access resources. For example, running an apply job on a stack that includes Compute instances and subnets requires policies that grant you permissions for those resource types, in the compartments where you want to provision the resources. To see examples of policies for managing Oracle Cloud Infrastructure resources, see Common Policies.