Automation practices - Top developer examples

更新时间:
复制 MD 格式

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:

  1. Service activation — Automatically enable required Alibaba Cloud services when provisioning new accounts

  2. Infrastructure lifecycle management — Spin up a complete environment on demand and tear it down when done

  3. 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:

  1. Clone the module from the GitHub repository

  2. Configure outputs.tf — comment out services you don't need; leave required services set to "on"

  3. Set credentials — use environment variables or a credentials manager (not plaintext AccessKey pairs in files)

  4. Initialize — run terraform init to install the Alibaba Cloud provider

  5. Plan — run terraform plan to preview which services will be activated

  6. Apply — run terraform apply to 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:

  1. Identify the resource type and resource ID for each existing resource (from the Alibaba Cloud console)

  2. Define a corresponding resource block in your .tf configuration

  3. Import the resource into state:

   terraform import <resource_type>.<resource_name> <resource_id>
  1. Reconcile any mismatches between the imported state and your configuration (for example, if a scaling group has min_size=0 in state but your config specifies a range of 20–60, adjust to match the actual environment)

  2. 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

init, plan, apply

Consistent service baseline for every new account

Infrastructure lifecycle

init, plan, apply, destroy

On-demand environments with clean teardown

Brownfield import

import, plan, apply

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.