Version 1.0.1 of the opc Terraform provider for Oracle Cloud Infrastructure Classic, and Oracle Cloud at Customer, introduces initial support for provisioning instances using the Compute Classic native Orchestration capabilities.

In this article we’ll look at how to provision instances using Orchestrations as part of the Terraform configuration and explore some of the differences between the ‘orchestrated’ instances and instances natively created by Terraform.

Oracle Compute Cloud Classic Orchestrations

Orchestrations are a Oracle Compute Classic native resource provisioning and orchestration feature, to some extent Orchestrations could be considered an alternative to Terraform.

An orchestration defines the attributes and interdependencies of a collection of compute, networking, and storage resources in Compute Classic. You can use orchestrations to automate the provisioning and lifecycle operations of an entire virtual compute topology.

Most users first experience with the Oracle Compute service is launching an instance using the Console UI. When using the UI, instances are always created using Orchestrations. Orchestration plans can also be defined directly in a JSON format and provisioned using the APIs, CLI, or uploaded in the UI.

An example native orchestration template for creating and instance is shown below:

This example assumes that the referenced security lists, ip reservations, ssh keys, etc. are already created, but they could also be defined as additional objects within the same Orchestration plan, in much the same way that a Terraform configuration can define multiple resources. When the orchestration plan is created in Oracle Compute Classic, the internal orchestration framework to manages the object (resource) creation and life cycle.

Terraform vs Orchestrations

Terraform is also manage infrastructure orchestration and provisioning, taking the above instance example, the same configuration can be defined in Terraform HCL

Again the referenced security lists, ip reservations, ssh keys, etc. are assumed to be already created, but they could also be defined as additional resources within the same Terraform configuration.

When this configuration is applied using Terraform the opc provider creates the opc_compute_instance resource using an Oracle Compute Classic Launch Plan. The Launch Plan creates instance directly within Compute and does use the Orchestration.

One of the key differences between instances created from an Orchestration plan vs instances created using a Launch Plan is the Orchestration objects are actively managed, so in the event of an instance failure the Compute Classic orchestration framework automatically detects the errored instance state and will attempt to recreate the instance, supporting outage recovery without the need to introduce an external monitoring tool.

Creating an ‘Orchestrated’ Instance using Terraform

To support creation of actively managed instances, the opc Terraform provider version 1.0.1 introduces a opc_compute_orchestrated_instance resource specifically for creating instances within an Orchestration plan.

Terraform is effectively delegating the actual instance creation and management to the native orchestration framework there are some key points to be aware of:

The orchestration plan created by the opc_compute_orchestrated_instance resource only contains the instance object definition, all other dependent resources such as the instance block storage volume continue to be managed directly by Terraform, so are not part of the orchestration definition.

resource only contains the instance object definition, all other dependent resources such as the instance block storage volume continue to be managed directly by Terraform, so are not part of the orchestration definition. Setting the orchestration desired_state to inactive (or suspend if the instance persistent option is not set) will result in the instance being destroyed. A new instance with a new instance UUID is created when the orchestration is set back to active

to (or if the instance option is not set) will result in the instance being A new instance with a new instance UUID is created when the orchestration is set back to If an instance get automatically recreated by an orchestration due to a instance failure the UUID of the recreated instance will be different from the instance ID of the original instance. The Terraform state file will be out of sync with the instance details until the next Terraform refresh , plan , or apply updates the state.

With that out of the way, lets look at simple example for defining an opc_compute_orchestrated_instance resource.

resource "opc_compute_orchestrated_instance" "my-instance" {

name = "my-instance-orchestration"

description = "my-instance-orchestration"

desired_state = "active"



instance {

persistent = true

name = "my-orchestrated-instance"

shape = "oc3"

image_list = "/oracle/public/OL_7.2_UEKR4_x86_64"

}

}

The name , description , and desired_state attributes apply to the Orchestration resource that gets created by Terraform.

The instance block within the resource definition defines the instance orchestration object template within the orchestration definition. The instance block has the same same general attributes and structure as regular opc_compute_instance resource, with the addition of the persistent option to set if the instance object should persist if the orchestration is suspended.

As with the regular opc_compute_instance , any dependencies for persistent boot storage, networking, security etc. can be declared as separate resrouces in the Terraform configuration and referenced using the standard Terraform interpolation syntax. These additional resources continue to be managed directly by Terraform and are not part of the Orchestration.

Beware of unintended consequences