Terraform with Azure and GCP

# CHAPTER 10

Terraform with Azure and GCP #

1. Introduction #

2. Learning Objectives #

• Authenticate the Azure (azurerm) and Google Cloud (google) providers.

• Understand the hierarchical differences between AWS, Azure, and GCP resources.

• Provision a Virtual Machine in Microsoft Azure.

• Provision a Compute Engine instance in Google Cloud.

• Grasp the concept of Multi-Cloud provisioning within a single Terraform workspace.

3. Beginner-Friendly Explanation #

• The Workflow (Terraform): No matter which company you go to, the process is exactly the same. You show your ID, sign a contract, and get the keys. (This is terraform plan and terraform apply).

• The Product (The Cloud): However, Hertz might give you a "Ford Focus," while Avis gives you a "Toyota Corolla." The steering wheel and buttons are in slightly different places.

You cannot use a Ford key to start a Toyota. In Terraform, you cannot use an awsinstance block to build a server in Azure; you must use the azurermlinuxvirtualmachine block. The workflow is identical, but the vocabulary changes.

4. Terraform with Microsoft Azure (azurerm) #

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 3.0"
    }
  }
}

provider "azurerm" {
  features {} # Required block for Azure provider
}

# 1. The mandatory Resource Group
resource "azurerm_resource_group" "my_rg" {
  name     = "production-resources"
  location = "West Europe"
}

# 2. The Virtual Network
resource "azurerm_virtual_network" "my_vnet" {
  name                = "production-network"
  address_space       = ["10.0.0.0/16"]
  # Implicit dependency on the Resource Group!
  location            = azurerm_resource_group.my_rg.location
  resource_group_name = azurerm_resource_group.my_rg.name
}

5. Terraform with Google Cloud (GCP) #

terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 5.0"
    }
  }
}

provider "google" {
  # Authentication is usually done via a Service Account JSON key
  # credentials = file("path/to/gcp-key.json") 
  project     = "my-gcp-project-id" # The overarching container
  region      = "us-central1"
}

resource "google_compute_instance" "default" {
  name         = "gcp-web-server"
  machine_type = "e2-micro"
  zone         = "us-central1-a"

  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-11"
    }
  }

  network_interface {
    network = "default"
    # An empty block assigns a random public IP
    access_config {} 
  }
}

6. Mini Project: Multi-Cloud Deployment Concept #

Step-by-Step Architecture Concept: Let's build a highly resilient architecture: A primary web server on AWS, and a backup server on Google Cloud.

# Configure AWS
provider "aws" {
  region = "us-east-1"
}

# Configure Google
provider "google" {
  project = "my-gcp-project"
  region  = "us-central1"
}

# Build on AWS
resource "aws_instance" "primary_server" {
  ami           = "ami-12345"
  instance_type = "t2.micro"
}

# Build on Google Cloud simultaneously!
resource "google_compute_instance" "backup_server" {
  name         = "backup-server"
  machine_type = "e2-micro"
  zone         = "us-central1-a"
  # ... configuration details
}

*When you run terraform apply, Terraform talks to both Amazon and Google at the exact same time, building infrastructure on both clouds simultaneously.*

7. Real-World Scenarios #

8. Best Practices #

• Authentication Methods: Avoid using credentials = file("key.json") in your GCP provider block if possible. Hardcoding paths to secret files is dangerous. Instead, rely on standard cloud CLI tools. Run gcloud auth application-default login in your terminal. Terraform will automatically detect the secure Google token on your machine, just as it does with AWS environment variables.

9. Security Recommendations #

• Azure Service Principals: When automating Azure via CI/CD (like GitHub Actions), you must create a "Service Principal" (a robotic user). Never give this Service Principal "Contributor" access to the entire Azure Subscription. Use strict Role-Based Access Control (RBAC) to ensure Terraform can only modify resources within its specifically assigned Resource Group.

10. Troubleshooting Tips #

• Azure Provider Features Block: In the azurerm provider, the features {} block is mandatory, even if it is completely empty. If you omit this block, Terraform will fail to initialize. It is a quirk specific to the Azure provider's design.

11. Exercises #

1. 1. What is the fundamental organizational container required in Azure before you can provision any other resource (like a Virtual Network or Virtual Machine)?

1. 2. How does Terraform achieve "Cloud Agnosticism"? Does it mean you write one block of code that works on all clouds?

12. FAQs #

13. Interview Questions #

• Q: Explain the paradigm of Multi-Cloud provisioning using Terraform. How would you architect a single Terraform workspace to manage an AWS EC2 instance that communicates with an Azure SQL Database?

• Q: Contrast the foundational organizational hierarchies of AWS, Azure, and Google Cloud Platform as they relate to Terraform resource provisioning (e.g., Accounts vs. Resource Groups vs. Projects).

14. Summary #

15. Next Chapter Recommendation #