Saturday, April 12, 2025

 

OCI Resource Manager

OCI Resource manager is an automation tool for infrastructure. It can be considered as Infrastructure as a code tool. It executes the terraform code and provisions the resource. It’s a managed service for Terraform in OCI.

We would have provisioned resources using OCI market place image. Basically, terraform code was written behind for provisioning market place image in OCI and that terraform code will be executed via Resource manager. So knowingly or unknowingly we use Resource manager for provisioning resources in OCI.

Stacks

OCI resource manager bundles the terraform code and required attributes/variable in a package called Stacks. The stacks will be validated through plan and apply phase which is similar to terraform plan and apply. The variables can have default value or it can collected dynamically during execution.

Resource manager can be invoked in OCI console through  Developer Services -> Resource Manager.

 

Lets see how to execute a terraform code using Resource manager.

In the Resource manager window choose Stacks -> Create stack.

 

Stack can be created in 4 ways.

My configuration: Stack creation with our own terraform code.
Template: A set of defined templates available like market place images and stack can be created using that.
Source code control system: Terraform code stored at Bitbucket Cloud, Bitbucket Server, DevOps, GitHub, or GitLab can be used to create stack. Based on chosen repository platform, details will be collected to create stack.
Existing compartment: This is very useful and unique feature of Resource manager. It can read the existing resources and generate terraform code of that. It will be useful to redeploy the resources in other region or other tenancy.

In this article lets examine first option – My configuration.

My configuration – We need to provide terraform code to create stack. The terraform code can be uploaded as folder or object storage bucket URL or Zip file.

It has option to choose custom terraform provides, but that would require the provider to be stored in the object storage bucket. Hashicorp is used here.

Stack name and description fields are optional and stack creation requires compartment to create. Also, it has option to specify the preferred terraform versions to execute the stack.

In this article we use terraform code of vcn creation and it has been uploaded as zip file.

The next page will have details of variables needed to execute the stack.  In case variables are specified with default value in the code, that will be displayed here. It can be modified and also values can be specified to other variables.

 

After confirming values, click next.

The next page will display all the variable and its value.

It has option to execute this stack along with creation. In case we want to perform terraform plan to preview the changes, not to choose the ratio button Run apply.

The stack has option to perform Plan and Apply.

Edit option will allow to recreate the stack with same name. We can upload new terraform code if required. Plan will perform terraform plan with a task name.

Logs column will show if any warnings or errors are observed.

If the plan succeeded, we could see the banner in green color with the status.

Logs can be downloaded for future reference. Also Terraform configuration and Terraform plan (as binary or json file) can be downloaded.

When plan is succeeded, we can proceed with apply.

 

 

Apply can proceed with automatic approval or specify the plan which had success.

Apply with automatic approval will perform terraform plan and also execute the code. Logs will show the details of execution. Also Terraform configuration and Terraform state file can be downloaded.

 

 

 Advantage of Resource manager:

1)     Its serverless, we don’t need resource to execute terraform code.

2)     It has native terraform integration using Hashicorp.

3)     State files are maintained internally and has provision to download.

4)     GUI based execution.

5)     All stack executions are recorded and it can be referred at any point of time.

Friday, March 14, 2025

 

OCI - Shielded compute instance creation through Terraform


We all know about the features of Oracle cloud infrastructure (OCI). It has big portfolio to manage any real time environments. One the common requirement is making automation of infrastructure provisioning. At real time environments it’s not easy to perform the provisioning of each resource by clicks via GUI. It will take lot of time. To solve that “Infrastructure as a code” has been innovated. Most commonly used automation tool is Terraform.

In this article we are going to discuss how terraform can be used to create an instance in OCI.  This terraform code uses terraform module approach. In module approach we segregate the business logic from required instance specific variables. Business logic is called as module here. The module will have the code to create instance and it will accept the instance specifications as variables. By doing this way we can reuse the module for instance creations. 

 

Module for Instance

-----------------------------------

resource "oci_core_instance" "this" {

  availability_domain = var.availability_domain

  compartment_id      = var.compartment_id

  display_name        = var.display_name

  shape               = var.shape

  is_pv_encryption_in_transit_enabled = true

  create_vnic_details {

  subnet_id           = var.subnet_id

 nsg_ids =  var.nsg_ids != null ? var.nsg_ids : []

  }

 

  shape_config {

    memory_in_gbs = 4

    ocpus = 1

  }

 

  source_details{

  source_id            = var.image_id

  source_type =   "image"

  boot_volume_size_in_gbs = 50

  kms_key_id = "<kms_id>"

}

  # Shielded instance-specific setting

 # shielded = true

platform_config {

    type = "AMD_VM"

    is_measured_boot_enabled = true

    is_secure_boot_enabled = true

    is_symmetric_multi_threading_enabled = true

    is_trusted_platform_module_enabled  = true

}

  metadata = {

    ssh_authorized_keys = var.ssh_public_key

  }

 extended_metadata = var.extended_metadata

}

 

This above module code expects variables availability domain name, compartment OCID, Instance display name, Instance shape, Instance image id, SSH key, subnet ocid, nsg ocids.

Few parameters are mandatory to create the instance and few are optional. Environments might require different parameters based on their requirement. For example, instance might or might not require NSG (Network security group). Instance might not require to be shielded. In such cases modules should written to handle all such requirements. It needs to check the parameter values and based on that it should perform the provisioning. The unneeded feature can be set to null. For example in the below terraform,tfvars file we pass values for 2 instances. All 2 instance values will go through module for creation. Unneeded parameters can be set to null as we see nsg_ids below.

Terraform.tfvars

Terraform.tfvars carries the variables and values to pass to the module.

For example, for the above module we could design terraform.tfvars as below.

instance_var = {

    "MyShieldedInstance1" = {

availability_domain = "MvNG:PHX-AD-2"

compartment_id      = "ocid1.compartment.oc1..aaaaaaaamgamfabcedgwu42gozmpp4snfgzfzmqb4equ5yq"

display_name        = "MyShieldedInstance1"

shape               = "VM.Standard.E3.Flex"

image_id            = "ocid1.image.oc1.phx.aaaaaaaahgrs3zcwrvutjtni557ttrt62uggseijsmqxacr7dym423uaokcq"

ssh_public_key      = "ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAhqXpiwufmWCWjfP3r44hKOXeQut7sj7yRDbJW+ /6eJqtk6qWhHHj == rsa-key-20170125."

subnet_id           = "ocid1.subnet.oc1.phx.aaaaaaaabyfqmurw7q46ox4s6fx64far4a"

nsg_ids = ["ocid1.networksecuritygroup.oc1.phx.aaaaaaaaafp2n2gkhb77ohyyvzssat2hjkbfa","ocid1.networksecuritygroup.oc1.phx.aaaaaaaa7i5ybjbbx3l2nv2ie4yynq"]

extended_metadata   = {

  project = "ShieldedInstanceProject"

}

},

    "MyShieldedInstance2" = {

availability_domain = "MvNG:PHX-AD-3"

compartment_id      = "ocid1.compartment.oc1..aaaaaaaamgamf64s7adosddcdfdfdpp4snfgzfzmqb4equ5yq"

display_name        = "MyShieldedInstance2"

shape               = "VM.Standard.E3.Flex"

image_id            = "ocid1.image.oc1.phx.aaaaaaaahgrs3zcwrvutjtni557ttrt62uggseijsmqxacr7dym423uaokcq"

ssh_public_key      = "ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAhqXpiwufmWCWjfP3r44hKOXeQut7sj7yRDbJW+ /6eJqtk6qWhHHj3yZVUv/jKtfs2eTU+HsgsxBGKhiebzo598T8w== rsa-key-20170125."

subnet_id           = "ocid1.subnet.oc1.phx.aaaaaaadb4zlyx7q46ox4s6fx64far4a"

nsg_ids             = null

extended_metadata   = {

  project = "ShieldedInstanceProject"

}

},

}

 

In the above terraform.tfvars, we could see two instances with required specifications are passed. First instance MyShieldedInstance1 requires NSG to be set and MyShieldedInstance2 doesn’t require NSG settings. We can keep adding the instances as required in the terraform.tfvars. Modules need not to be modified at any point of time unless instance provisioning comes up with new features.

 The main.tf will be very simple. It just need to call the module and pass the terraform.tfvars to the module.

 module "shielded_instance" {

  source = "./modules/instance"  ===รจ Module location

 

  for_each          = var.instance_var

  availability_domain = each.value.availability_domain

  compartment_id      = each.value.compartment_id

  display_name        = each.value.display_name

  shape               = each.value.shape

  image_id            = each.value.image_id

  ssh_public_key      = each.value.ssh_public_key

  extended_metadata   = each.value.extended_metadata

  subnet_id           = each.value.subnet_id

  nsg_ids             = each.value.nsg_ids

}

 for_each sets the for loop and calls each instance values in terraform.tfvars.

We need to define variables in variable.tf for module and main file.

You can find more terraform codes in my github page.

https://github.com/kmkittu/Terraform


  Oracle AI Database@Azure: Why It Matters and When to Use It Oracle Database@Azure was announced by Oracle and Microsoft in September 202...