DEV Community

quixoticmonk
quixoticmonk

Posted on

Terratags v0.6.0: Remote Configuration and Google Cloud Support

#gcp #hashicorp #tags #terratags

Terratags continues to evolve, and v0.6.0 brings two significant features: remote configuration support and Google Cloud Provider support. These additions make Terratags extend its reach beyond AWS and Azure to cover the major cloud providers.

What's New in v0.6.0

Remote Configuration Support

One of the requested features was the ability to centralize configuration management. This allows team to avoid duplicating tag requirements across multiple repositories and maintain consistency across their infrastructure.

v0.6.0 introduces remote configuration support, allowing you to load your Terratags configuration from:

HTTP/HTTPS URLs 

terratags -config https://example.com/configs/terratags.yaml -dir ./infra
Enter fullscreen mode Exit fullscreen mode

Git Repositories 

# HTTPS with branch/tag specification
terratags -config https://github.com/org/configs.git//terratags.yaml?ref=main -dir ./infra

# SSH support for private repositories
terratags -config git@github.com:org/configs.git//path/to/config.yaml?ref=v1.0.0 -dir ./infra
Enter fullscreen mode Exit fullscreen mode

This is particularly powerful for organizations that want to:

  • Version their tagging policies alongside their infrastructure code
  • Use different configurations for different environments (dev, staging, prod)
  • Maintain audit trails of configuration changes
  • Leverage Git's branching and tagging for configuration management

Version Pinning and Environment-Specific Configs

The Git integration supports referencing specific branches, tags, or commits:

# Production uses stable tagged version
terratags -config https://github.com/org/configs.git//prod-config.yaml?ref=v2.1.0

# Development uses latest from main branch
terratags -config https://github.com/org/configs.git//dev-config.yaml?ref=main

# Specific commit for reproducible builds
terratags -config https://github.com/org/configs.git//config.yaml?ref=abc123def
Enter fullscreen mode Exit fullscreen mode

Google Cloud Provider Support

The second major addition is full support for Google Cloud Platform. GCP uses 'labels' instead of 'tags' for resource metadata.

Basic GCP Label Validation 

resource "google_compute_instance" "web_server" {
  name         = "web-server-01"
  machine_type = "e2-medium"
  zone         = "us-central1-a"

  labels = {
    environment = "production"
    project     = "web-app"
    owner       = "devops@example.com"
    name        = "web-server-01"
  }
}
Enter fullscreen mode Exit fullscreen mode

Google Provider default_labels Support

Just like AWS and Azapi provider's default_tags , Google provider's default_labels are fully supported:

provider "google" {
  project = "my-project-id"
  region  = "us-central1"

  default_labels = {
    environment = "production"
    owner       = "team-platform"
    managed_by  = "terraform"
  }
}

resource "google_storage_bucket" "data_bucket" {
  name     = "company-data-bucket"
  location = "US"

  # Only need to specify labels not covered by default_labels
  labels = {
    name    = "data-bucket"
    project = "analytics"
  }
}
Enter fullscreen mode Exit fullscreen mode

In this example, the bucket will have all required labels: name and project from the resource-level labels, and environment, owner, and managed_by from the provider's default_labels.

Multi-Cloud Tagging Consistency

With v0.6.0, Terratags now supports all three major cloud providers with their respective tagging mechanisms:

  • AWS: tags with default_tags support
  • Azure: tags with azapi default_tags support
  • Google Cloud: labels with default_labels support

This means you can maintain consistent tagging policies across your entire multi-cloud infrastructure using a single tool and configuration format.

Validation in CI/CD 

# GitHub Actions example
- name: Validate AWS Resources
  run: terratags -config https://example.com/aws-tags.yaml -dir ./aws-infra

- name: Validate GCP Resources  
  run: terratags -config https://example.com/gcp-labels.yaml -dir ./gcp-infra

- name: Validate Azure Resources
  run: terratags -config https://example.com/azure-tags.yaml -dir ./azure-infra
Enter fullscreen mode Exit fullscreen mode

Pattern Validation

The advanced pattern validation introduced in earlier versions works consistently across all providers:

# Works for AWS tags, Azure tags, and GCP labels
required_tags:
  environment:
    pattern: "^(dev|test|staging|prod)$"

  owner:
    pattern: "^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$"

  cost_center:
    pattern: "^CC-[0-9]{4}$"
Enter fullscreen mode Exit fullscreen mode

Getting Started with v0.6.0

Installation 

# Using Homebrew (recommended)
brew install terratags/tap/terratags

# Or download from GitHub releases
# https://github.com/terratags/terratags/releases/tag/v0.6.0
Enter fullscreen mode Exit fullscreen mode

Quick Start with Remote Config

  1. Set up a remote configuration: 
# https://example.com/terratags.yaml
required_tags:
  environment:
    pattern: "^(dev|test|staging|prod)$"
  owner:
    pattern: "^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$"
  project: {}
  name: {}
Enter fullscreen mode Exit fullscreen mode
  1. Run validation: 
terratags -config https://example.com/terratags.yaml -dir ./infra -report report.html
Enter fullscreen mode Exit fullscreen mode
  1. Set up pre-commit hooks: 
repos:
  - repo: https://github.com/terratags/terratags
    rev: v0.6.0
    hooks:
      - id: terratags
        args: [--config=https://example.com/terratags.yaml]
Enter fullscreen mode Exit fullscreen mode

Looking Ahead

There are a few items in the report generation which I want to look to implement, without breaking existing structure and including all the metadata.

Resources

If you're using Terratags and have been waiting for centralized configuration management, v0.6.0 is definitely worth the upgrade. As always, I'd love to hear about your experience and any feedback you have!

Top comments (0)