Comment déployer Cloud SQL HA Terraform 2026

Introduction

Cloud SQL est le service managé de bases de données relationnelles de Google Cloud, supportant PostgreSQL, MySQL et SQL Server. En 2026, avec l'essor des applications cloud-native, déployer une instance en haute disponibilité (HA) est essentiel pour garantir une résilience >99,99% et une scalabilité automatique. Ce tutoriel expert vous guide pas à pas pour créer une instance PostgreSQL HA avec Terraform, incluant un VPC privé, des backups automatisés, le monitoring via Cloud Monitoring, et une connexion sécurisée sans proxy public.

Pourquoi c'est crucial ? Une mauvaise configuration expose à des downtimes coûteux (jusqu'à 5 minutes en failover sans HA) et des vulnérabilités réseau. Nous utilisons Terraform pour l'infrastructure as code (IaC), rendant les déploiements reproductibles et auditables. À la fin, vous aurez une stack production-ready, avec des exemples de code complets pour migration et queries. Idéal pour les architectes DevOps gérant des workloads critiques.

Prérequis

Compte Google Cloud Platform (GCP) activé avec facturation.
gcloud CLI installée (version 2026+).
Terraform 1.9+ installé.
Connaissances avancées en IaC, networking VPC et PostgreSQL.
Projet GCP dédié avec APIs activées : Cloud SQL Admin, Compute Engine, Cloud Monitoring.
Éditeur comme VS Code avec extension HashiCorp Terraform.

Initialiser l'environnement GCP et Terraform

init.sh

#!/bin/bash

gcloud auth login
gcloud config set project YOUR_PROJECT_ID
gcloud services enable sqladmin.googleapis.com compute.googleapis.com monitoring.googleapis.com

mkdir cloudsql-ha-terraform && cd cloudsql-ha-terraform

cat > versions.tf << EOF
terraform {
  required_version = ">= 1.9.0"
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 6.0"
    }
  }
}
EOF

terraform init

Ce script authentifie gcloud, active les APIs nécessaires et initialise Terraform avec le provider Google récent. Remplacez YOUR_PROJECT_ID par votre ID de projet. Les pièges : oublier d'activer les APIs bloque les ressources ; utilisez gcloud projects describe pour vérifier le projet.

Configurer le VPC et le réseau privé

Avant Cloud SQL, créez un VPC avec sous-réseaux privés pour isoler la DB. Cela active les IP privées et Serverless VPC Access pour connexions sans IP publique, réduisant la surface d'attaque de 90%.

Définir le VPC et sous-réseaux

vpc.tf

provider "google" {
  project = var.project_id
  region  = var.region
}

resource "google_compute_network" "vpc" {
  name                    = "cloudsql-vpc"
  auto_create_subnetworks = false
  mtu                     = 1460
}

resource "google_compute_subnetwork" "private" {
  name                     = "cloudsql-subnet"
  ip_cidr_range            = "10.0.0.0/20"
  region                   = var.region
  network                  = google_compute_network.vpc.id
  private_ip_google_access = true
  description              = "Sous-réseau privé pour Cloud SQL"
}

variable "project_id" {
  description = "GCP Project ID"
  type        = string
}

variable "region" {
  description = "Region GCP"
  type        = string
  default     = "europe-west1"
}

output "vpc_id" {
  value = google_compute_network.vpc.id
}

Ce module crée un VPC custom avec sous-réseau privé activant l'accès Google privé. MTU 1460 optimise TCP pour Cloud SQL. Piège : sans private_ip_google_access, les métadonnées GCP échouent ; appliquez avec terraform apply -var='project_id=your-id' -var='region=europe-west1'.

Déployer l'instance Cloud SQL HA

cloudsql.tf

resource "google_sql_database_instance" "ha_postgres" {
  name             = "ha-postgres"
  database_version = "POSTGRES_16"
  region           = var.region

  settings {
    tier              = "db-custom-4-15360"  # 4 vCPU, 15GB RAM pour prod
    availability_type = "REGIONAL"           # HA avec failover auto
    disk_autoresize   = true
    disk_size         = "100"
    disk_type         = "PD_SSD"

    ip_configuration {
      ipv4_enabled    = false               # Pas d'IP publique
      private_network = google_compute_network.vpc.id
      require_ssl     = true
    }

    backup_configuration {
      enabled                        = true
      start_time                     = "02:00"
      location                       = "EU"
      point_in_time_recovery_enabled = true
      retention_period_days          = 7
    }

    maintenance_window {
      day  = 7  # Dimanche
      hour = 3
    }

    database_flags {
      name  = "cloudsql.iam_authentication"
      value = "on"
    }
  }

  deletion_protection = true
}

resource "google_sql_database" "app_db" {
  name     = "appdb"
  instance = google_sql_database_instance.ha_postgres.name
}

resource "google_sql_user" "app_user" {
  name     = "appuser"
  instance = google_sql_database_instance.ha_postgres.name
  password = "SecurePass123!"  # Utilisez secrets manager en prod
}

Déployez une instance PostgreSQL 16 HA régionale avec IP privée, backups PITR (Point-In-Time Recovery) et IAM auth. Tier custom scale selon charge. Piège : deletion_protection=true empêche les suppressions accidentelles ; flags IAM pour auth sans mot de passe.

Configurer le monitoring et alertes

Intégrez Cloud Monitoring pour tracker CPU >80%, connexions et latence. Les alertes Slack/Email préviennent les incidents proactivement.

Activer monitoring et dashboards

monitoring.tf

resource "google_monitoring_dashboard" "cloudsql_dashboard" {
  dashboard_json = jsonencode({
    displayName = "Cloud SQL HA Dashboard"
    row = [{
      title = "Métriques Clés"
      charts = [{
        displayName = "CPU Utilisation"
        metricType = "cloudsql.googleapis.com/database/cpu/utilization"
        resourceType = "cloud_sql_database"
      }, {
        displayName = "Connexions Actives"
        metricType = "cloudsql.googleapis.com/database/postgresql/connections"
        resourceType = "cloud_sql_database"
      }]
    }]
  })
}

resource "google_monitoring_alert_policy" "high_cpu" {
  display_name = "Alerte CPU Cloud SQL >80%"
  combiner     = "OR"

  conditions {
    display_name = "cpu_high"
    condition_threshold {
      filter     = "resource.type=\"cloud_sql_database\" AND metric.type=\"cloudsql.googleapis.com/database/cpu/utilization\" AND resource.label.\"database_id\"=\"${google_sql_database_instance.ha_postgres.name}\""
      threshold_value = 0.8
      duration   = "60s"
      comparison = "COMPARISON_GT"
    }
  }

  notification_channels = []  # Ajoutez vos channels
}

Crée un dashboard et alerte CPU haute. JSONencode pour dashboard dynamique. Piège : Filtre exact sur database_id ; testez avec terraform apply et vérifiez dans GCP Console > Monitoring.

Créer une table et insérer des données d'exemple

init.sql

-- Connexion via gcloud sql connect ha-postgres --user=postgres --database=appdb

CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  email VARCHAR(255) UNIQUE NOT NULL,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

INSERT INTO users (email) VALUES 
  ('user1@example.com'),
  ('user2@example.com');

-- Vérifier
SELECT * FROM users;

-- Index pour perf
CREATE INDEX idx_users_email ON users(email);

Initialisez la DB avec table users, données et index. Exécutez via gcloud sql connect. Piège : Sans index, queries scalent mal ; SERIAL pour auto-incrément Postgres.

Se connecter depuis une app Python avec Private IP

connect.py

import os
import pymysql  # pip install pymysql

from google.cloud.sql.connector import Connector, IPTypes
import sqlalchemy

# Instance connexion ID: projects/PROJECT/locations/REGION/instances/INSTANCE
INSTANCE_CONNECTION_NAME = "YOUR_PROJECT:REGION:ha-postgres"

connector = Connector(ip_type=IPTypes.PRIVATE)

def getconn() -> sqlalchemy.engine.base.Connection:
    conn = connector.connect(
        INSTANCE_CONNECTION_NAME,
        "tcp:5432",
        user="appuser",
        password="SecurePass123!",
        db="appdb"
    )
    return conn

engine = sqlalchemy.create_engine(
    "postgresql://",
    creator=getconn,
)

with engine.connect() as conn:
    result = conn.execute(sqlalchemy.text("SELECT * FROM users"))
    print([dict(row._mapping) for row in result])

connector.close()

Utilise Cloud SQL Python Connector pour IP privée sans proxy. Remplacez INSTANCE_CONNECTION_NAME. Piège : IPTypes.PRIVATE requiert VPC ; installez pip install cloud-sql-python-connector sqlalchemy psycopg2.

Appliquer Terraform et nettoyer

apply.sh

#!/bin/bash

terraform validate
terraform plan -var="project_id=YOUR_PROJECT_ID" -var="region=europe-west1"
terraform apply -auto-approve -var="project_id=YOUR_PROJECT_ID" -var="region=europe-west1"

# Outputs
terraform output

# Cleanup
# terraform destroy -auto-approve

Valide, planifie et applique la stack. Outputs montrent IDs. Piège : Toujours plan avant apply ; destroy pour lab, mais deletion_protection protège en prod.

Bonnes pratiques

Secrets Manager : Stockez passwords dans Secret Manager, référencez via google_secret_manager_secret_version.
HA + Multi-Zone : Utilisez availability_type=REGIONAL et failover_replica pour RTO <60s.
Audits Logs : Activez database_flags { name="log_min_duration_statement" value="1000" } pour tracer queries lentes.
Scaling Auto : Monitorez et upscale tier via Terraform variables.
CI/CD : Intégrez dans GitHub Actions avec terraform-cloud pour approbations.

Erreurs courantes à éviter

IP publique oubliée : ipv4_enabled=true expose à Internet ; forcez private_network.
Backups non-EUR : Choisissez location=EU pour conformité RGPD.
IAM non activé : Sans cloudsql.iam_authentication=on, auth SQL vulnérable.
VPC peering manquant : Pour apps externes, ajoutez Serverless VPC Access Connector.

Pour aller plus loin

Approfondissez avec nos formations DevOps GCP avancées. Ressources : Docs Cloud SQL HA, Terraform GCP Registry, Cloud SQL Proxy vs Connector.

Comment déployer Cloud SQL en haute disponibilité avec Terraform en 2026