Resource Orchestration Service (ROS) provides managed Terraform execution. This topic covers development methods and best practices for writing Terraform code in ROS, and is intended for users already familiar with Terraform concepts in ROS.
Development methods
Choose the development method that best fits your workflow:
Use an on-premises environment.
Use the Terraform online debugging tool. This option supports Alibaba Cloud resources only.
Create a Terraform stack in the ROS console, then create or update the stack as needed. For more information, see Create a Terraform stack, Continue to create a stack, and Update a stack.
Development suggestions
-
Do not declare the alicloud provider in the .tf file.
ROS provides a default alicloud provider that uses a temporary AccessKey pair or Security Token Service (STS) credential and the stack region of the current Alibaba Cloud account. Using the default provider:
Simplifies development, improves security, and reduces the risk of AccessKey pair leaks.
Keeps resources and stacks in the same account and region for centralized management and integration.
-
Enhances features that require resources and stacks to share the same account and region, such as price inquiries, system tags, propagation of custom stack tags, propagation of stack resource groups, and risk detection.
NoteIf stacks and stack groups belong to different accounts and regions, price inquiries, system tags, propagation of custom stack tags, and risk detection are supported in specific scenarios.
If stacks and stack groups belong to different regions, propagation of stack resource groups is supported in specific scenarios.
-
Save on-premises code to the files whose names end with .debug.tf.
When Terraform code runs in ROS, ROS ignores .debug.tf files and excludes them from orchestration. In an on-premises environment, Terraform processes these files normally. For example, create a provider.debug.tf file to configure the alicloud provider. When you use the file to develop code in an on-premises environment, this configuration takes effect and creates resources in the China (Hong Kong) region. When you create a stack in ROS, the file is ignored and resources are created in the stack's region. Sample content for provider.debug.tf:
variable "region" { type = string default = "cn-hongkong" } provider "alicloud" { region ="${var.region}" } -
Pin the provider version.
ROS-managed Terraform supports multiple provider versions after the release of Aliyun::Terraform-v1.0. Pin the provider version to prevent breaking changes from upstream updates and maintain stability. Sample code:
terraform { required_providers { alicloud = { source = "aliyun/alicloud" version = "1.140.0" } } }For available provider versions, see the Provider version column in ROS version support.
-
Use Aliyun::Terraform-v1.0 or later.
Aliyun::Terraform-v0.12 and Aliyun::Terraform-v0.15 are maintained for compatibility only. Provider versions and features for these releases are no longer updated.
-
Use ROS parameters instead of .tfvars files to pass variable values.
ROS parameters offer the following advantages over .tfvars files:
Fewer template modifications — in most cases, updating parameter values is sufficient.
A one-to-one mapping with variables, visible in the ROS console. With .tfvars files, variable values may be overwritten silently, causing discrepancies between actual values and what the console displays.
For more information, see (Optional) Parameters.
-
Use pseudo parameters to get stack information.
For more information, see (Optional) Parameters. For example, define the ALIYUN__Region variable in your .tf file and reference it with var.ALIYUN__Region to get the stack's region. Sample code:
variable "ALIYUN__Region" { type = string default = "cn-hongkong" } -
Define variables precisely.
ROS automatically converts Terraform variables into ROS parameters. Well-defined variables produce accurate conversion results. For more information, see (Optional) Parameters.
Always specify the type parameter for each variable. Without a type, ROS may treat the variable as a string and pass it as such to Terraform, which can cause a type error during orchestration.
-
For variables containing sensitive data such as passwords, set
sensitive = true.variable "password" { type = string sensitive = true }
-
Use Metadata to control how parameters appear in the console.
Group parameters: For more information, see Metadata and Use Metadata to group parameters.
-
Hide parameters: Use Metadata.ALIYUN::ROS::Interface.Hidden to specify parameters to hide from the console.
ROSTemplateFormatVersion: '2015-09-01' Description: Creates a simple oss bucket Parameters: BucketName: Type: String Label: Bucket Name Description: en: Bucket name Default: bucketName1 Metadata: ALIYUN::ROS::Interface: Hidden: - BucketName Workspace: ... Query parameter constraints: Use ResourcesForParameterConstraints of ALIYUN::ROS::Interface in the .metadata file to configure constraints for parameters. For more information, see Manually configure parameter constraint query for a Terraform template.
-
Control parameter input mode in the console.
ROS parameters: Use AssociationProperty and AssociationPropertyMetadata to validate values automatically and specify valid options. For more information, see AssociationProperty and AssociationPropertyMetadata and Dynamically select parameter settings in the Resource Orchestration Service console.
-
Terraform variables: Use the description parameter to set AssociationProperty and AssociationPropertyMetadata for Terraform variables. For more information, see (Optional) Parameters. Sample code:
variable "vpc_id" { type = string description = <<EOT { "AssociationProperty": "ALIYUN::ECS::VPC::VPCId", "Description": { "en": "Please search the ID starts with (vpc-xxx)from console-Virtual Private Cloud", }, "Label": { "en": "Existing VPC ID", } } EOT }