8i | 9i | 10g | 11g | 12c | 13c | 18c | 19c | 21c | 23c | Misc | PL/SQL | SQL | RAC | WebLogic | Linux

Home » Articles » Misc » Here

Terraform : Oracle Cloud Infrastructure (OCI) Provider

This article describes how to configure an Oracle Cloud Infrastructure (OCI) provider for Terraform.

Related articles.

Add Public Key to Oracle Cloud Account

Generate a key pair as described here. You will need to upload the public key to your Oracle Cloud account to allow Terraform to authenticate to your Oracle Cloud account.

Gather Information From the Oracle Cloud Account

The provider needs several bits of information from the Oracle Cloud account.

tenancy_ocid:

user_ocid:

private_key_path : The path we used to create the keys.

fingerprint:

region:

root_compartment_id:

Create Working Directory

Create a new working directory and switch to that directory.

mkdir \git\oraclebase\terraform\oci\oci_provider
cd \git\oraclebase\terraform\oci\oci_provider

oci_provider.tf

Every time Terraform interacts with Oracle Cloud it will need a provider.

Create a file called "oci_provider.tf" with the following contents.

# Variables.
variable "tenancy_ocid"         { type = string }
variable "user_ocid"            { type = string }
variable "private_key_path"     { type = string }
variable "fingerprint"          { type = string }
variable "region"               { type = string }
variable "root_compartment_id"  { type = string }


# Resources
provider "oci" {
  tenancy_ocid     = var.tenancy_ocid
  user_ocid        = var.user_ocid
  private_key_path = var.private_key_path
  fingerprint      = var.fingerprint
  region           = var.region
}

The file begins with variable definitions. We could set default values for these variables, or use literal values directly in the provider definition, but we don't want sensitive information checked into version control, so it makes sense to separate out variable values from the script. The resources section defines the provider using the input variables.

The variables and resources sections can be split into separate files if you find that organisation easier. It may help for more complex definitions.

You'll notice the root_container_id variable isn't used in the script. We could just remove it altogether, but it is used by many of the OCI resources, so we've included it in our provider variable file below. If we don't include it here we will get a warning.

oci_provider_variables.auto.tfvars

There are a number of ways to supply values for input variables (see here). In this example we'll use a ".auto.tfvars" file. We won't check this script into version control as it contains sensitive information.

Create a file called "oci_provider_variables.auto.tfvars" with the following contents. Adjust the values to match the information you gathered from the Oracle Cloud account.

tenancy_ocid        = "ocid1.tenancy.oc1..aaaaaaaa..."
user_ocid           = "ocid1.user.oc1..aaaaaaaa..."
private_key_path    = "/Users/my_user/.oci/my-oci-key.pem"
fingerprint         = "a5:68:0f:46:6d:06:43:5a:38:98:74:09:??:??:??:??"
region              = "uk-london-1"
root_compartment_id = "ocid1.tenancy.oc1..aaaaaaaa..."

Test the OCI Provider

Initialize the working directory using the terraform init command.

terraform init

Initializing the backend...

Initializing provider plugins...
- Finding latest version of hashicorp/oci...
- Installing hashicorp/oci v4.13.0...
- Installed hashicorp/oci v4.13.0 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Use the terraform plan command to test the execution plan.

terraform plan

No changes. Infrastructure is up-to-date.

This means that Terraform did not detect any differences between your
configuration and real physical resources that exist. As a result, no
actions need to be performed.

Since there are no changes to apply, there's no point running the terraform apply command, but we'll do it anyway.

terraform apply

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

For more information see:

Hope this helps. Regards Tim...

Back to the Top.