Automation practices - Top developer examples
Three practical Terraform scenarios for individual SREs and ops engineers: automating service activation for new accounts, spinning up and tearing down cloud infrastructure on demand, and importing existing console resources into Infrastructure as Code (IaC) management.
What this video covers
IaC transforms repetitive operational tasks into version-controlled code that machines execute consistently. Tools like Terraform, APIs, SDKs, and Resource Orchestration Service (ROS) all serve this goal — the right choice depends on your organization's stack and requirements.
This episode focuses on the individual engineer's perspective: how one SRE or ops engineer can use Terraform to solve concrete daily challenges without waiting for full organizational IaC adoption.
The video covers five scenarios in total. This article focuses on three that are most relevant to individual ops engineers:
Service activation — Automatically enable required Alibaba Cloud services when provisioning new accounts
Infrastructure lifecycle management — Spin up a complete environment on demand and tear it down when done
Brownfield resource import — Bring existing console-created resources under Terraform management
The video also covers access control (automated permission assignment for onboarding and role changes) and DevOps integration (end-to-end automation from infrastructure to application deployment), which are addressed in separate episodes.
---
Scenario 1: automate service activation for new accounts
The problem
New account provisioning requires activating services before they can be purchased or used. In practice, this means manually clicking through the Alibaba Cloud console for each account — a process that is slow, error-prone, and hard to audit.
Common failure modes without automation:
Over-privileged accounts (excessive service activation)
Under-provisioned accounts (missing required services)
Wrong services activated, requiring rework
For recurring events like employee onboarding, new business line launches, or department expansions, these manual steps compound quickly.
The solution
Alibaba Cloud provides a pre-built Terraform module for batch service activation. Pull it from the GitHub repository and adapt it to your environment with minimal changes.
Workflow:
Clone the module from the GitHub repository
Configure
outputs.tf— comment out services you don't need; leave required services set to"on"Set credentials — use environment variables or a credentials manager (not plaintext AccessKey pairs in files)
Initialize — run
terraform initto install the Alibaba Cloud providerPlan — run
terraform planto preview which services will be activatedApply — run
terraform applyto activate the services
Warning: Never store AccessKey pairs in plaintext configuration files. Use environment variables, local credential caching, or an AccessKey pair management service to protect credentials and enable regular key rotation.
After terraform apply completes, the configured services are active on the target account. Run this script for every new account to maintain a consistent activation baseline — no manual console clicks required.
---
Scenario 2: spin up and tear down cloud infrastructure on demand
The problem
Business teams often need ephemeral environments: create one for a two-week testing cycle, release it, then recreate it for the next cycle. Without automation, ops teams face:
Manual recreation of identical environments multiple times
Configuration drift between cycles
Delays when multiple teams request environments simultaneously
The solution
Define the full environment as Terraform code once, then use terraform apply and terraform destroy to manage its entire lifecycle.
Example environment in this demo:
Virtual Private Cloud (VPC) and vSwitch
Security group with an inbound rule opening port 8080
Internet-facing SLB instance with a public IP address
Auto Scaling group with scaling rules
A "hello world" application deployed on the Auto Scaling group
Create the environment:
terraform init # Install the Alibaba Cloud provider
terraform plan # Preview: 9 resources will be created
terraform apply # Create all 9 resources in dependency order
Terraform creates resources in dependency order: VPC first, then security group, then SLB, then Auto Scaling group and rules, then the application. Once complete, the output includes the public IP address where the application is reachable.
Verify the deployment:
Open the public IP address in a browser and confirm the "hello world" application is live.
Destroy the environment:
When the business team finishes testing, release all resources in a single command:
terraform destroy # Destroy all 9 resources based on predefined deletion logic
Verify the teardown by confirming the public IP and services no longer appear in the Alibaba Cloud console.
Infrastructure metadata and CMDB integration
After terraform apply, Terraform writes resource metadata to a state file (terraform.tfstate). This metadata — resource IDs, IP addresses, dependency graph — is the foundation for building a Configuration Management Database (CMDB) or multi-cloud management platform. Treat the state file as a first-class operational artifact.
---
Scenario 3: import existing resources into Terraform management
The problem
Most teams adopt IaC after infrastructure already exists. Resources created through the console, CLI, or earlier automation scripts sit outside Terraform's state, which means:
No drift detection — Terraform can't flag manual changes
No auditability — no record of who changed what and when
No reproducibility — you can't recreate the environment reliably from code
Until every resource is codified and tracked in state, you lose the core benefits of IaC.
The solution
Use terraform import to pull existing resources into local Terraform state and generate the corresponding IaC code. Once imported, they enter the same management lifecycle as resources created directly by Terraform.
Workflow:
Identify the resource type and resource ID for each existing resource (from the Alibaba Cloud console)
Define a corresponding resource block in your
.tfconfigurationImport the resource into state:
terraform import <resource_type>.<resource_name> <resource_id>
Reconcile any mismatches between the imported state and your configuration (for example, if a scaling group has
min_size=0in state but your config specifies a range of 20–60, adjust to match the actual environment)Apply to align the live configuration with your baseline:
terraform apply
After a successful import and apply, the tfstate file reflects the live environment. From this point, all changes go through Terraform — giving you drift detection, auditability, and consistent reproducibility.
Tip: Import one resource at a time and run terraform plan after each import to catch mismatches early. Reconciling nine resources at once is harder to debug than reconciling one.
---
Summary
|
Scenario |
Terraform commands |
Outcome |
|
Service activation |
|
Consistent service baseline for every new account |
|
Infrastructure lifecycle |
|
On-demand environments with clean teardown |
|
Brownfield import |
|
Existing resources under full IaC management |
These three scenarios address the most common friction points for individual ops engineers. Once your infrastructure is codified and in state, you gain accuracy, repeatability, and time to work on higher-value problems.
For questions or ideas about cloud automation, join the DingTalk group by scanning the QR code shown in the video.