Avoid Disaster with Terraform: Safe Blue‑Green Deployments on UCloud

Recently I experimented with the new UCloud Terraform Provider and built a custom Terraform module, sharing the process and insights.

Terraform Is Powerful Yet Dangerous

Terraform's strength lies in its state‑based approach, which can also be hazardous; a tiny mistake in parameters may cause catastrophic failures.

The following example is inspired by Nicki Watt’s video "Evolving your Infrastructure with Terraform" which highlights anti‑patterns.

Let’s See a Real Example

We started with a simple Terraform script for a test environment. When the product manager requested a production release, we duplicated the code:

This week go live

We split the configuration by environment, creating terraform-prod.tf for production and terraform-test.tf for testing.

Later, to avoid accidentally modifying production, we renamed the production file:

terraform apply --auto-approve

Unfortunately, this command deleted the production system because the state file no longer described it, and the --auto-approve flag skipped the plan review.

Human Plan Checks Are Unreliable

Terraform calculates an execution plan by comparing the desired configuration with the current tfstate. The plan step is a crucial safety net, allowing operators to verify changes before applying them.

Terraform has a "planning" step where it generates an execution plan. This lets you avoid any surprises when Terraform manipulates infrastructure.

The plan feature is a major advantage over tools like AWS CloudFormation, which combine planning and execution.

Terraform also separates the planning phase from the execution phase, by using the concept of an execution plan. By running terraform plan , the current state is refreshed and the configuration is consulted to generate an action plan. The plan includes all actions to be taken: which resources will be created, destroyed or modified. It can be inspected by operators to ensure it is exactly what is expected.

Enforcing manual plan review is essential, but operators may still bypass it with --auto-approve or a rushed check.

Safe Release Strategy

Rejecting Terraform outright is a mistake; instead, adopt a disciplined release process. The video by Nicki Watt outlines a safe architecture that isolates test, staging, and production environments, with a classic blue‑green deployment pattern.

Blue‑Green Deployment

Blue‑green deployment tags servers as "blue" or "green" behind a load balancer. New versions are deployed to the idle group, tested, then traffic is switched. In cloud environments, the idle group can be torn down after the switch.

To prevent accidental direct switches, an arbitration module enforces a staging state between blue and green.

Arbitration Module

The module receives the following variables:

variable "operation" {}
variable "desired_blue_count" {}
variable "desired_green_count" {}
variable "current_blue_count" {}
variable "current_green_count" {}

Supported operations include:

"i2b"
"i2g"
"b2s"
"g2s"
"s2b"
"s2g"
"b2b"
"g2g"
"destroy"

The state machine ensures transitions go through a staging state, preventing direct blue‑to‑green switches and allowing safe rollbacks.

The module validates constraints such as zero counts for init operations, non‑zero counts for blue/green operations, and matching desired counts for staging.

i2* commands require both blue and green counts to be 0.

b2* commands require current_blue_count > 0.

g2* commands require current_green_count > 0.

s2* commands require both current counts > 0.

*2b commands require desired_blue_count > 0 and desired_green_count = 0.

*2g commands require desired_green_count > 0 and desired_blue_count = 0.

*2s commands require both desired counts > 0.

b2s and g2s require desired counts to match current counts.

Implementation uses Terraform’s external data source to run a Go program that performs the checks.

data "external" "arbiter" {
  program = [
    "go",
    "run",
    "${path.module}/main.go",
    "-operation=${var.operation}",
    "-currentBlue=${var.current_blue_count}",
    "-currentGreen=${var.current_green_count}",
    "-desiredBlue=${var.desired_blue_count}",
    "-desiredGreen=${var.desired_green_count}"
  ]
}

The external data source acts as an escape hatch, allowing arbitrary logic and error handling via the Go program.

UCloud Terraform Provider Review

The provider works well overall; I would rate it 7/10. It has a reasonable resource model and stable API, but there are several shortcomings:

Limited resource types – only basic network, compute, and database resources are available.

Few data sources – mainly images, elastic IPs, and instances.

Tags are called "business groups" in the console, which is confusing.

Only a single tag per resource is supported, restricting categorization.

Documentation lags behind implementation, with some parameters marked deprecated.

Despite these issues, the blue‑green module can be reused across clouds (Azure, AWS, GCP) and even on‑prem OpenStack, demonstrating the power of Terraform code reuse.

Future improvements could include more resource types, richer tagging, and better documentation, as well as a Packer builder for UCloud to automate image creation.