Déployez sans effort votre application GCP Cloud Run à l'aide de Terraform

Terraform gagne en popularité pour une raison car il offre un haut niveau de flexibilité de contrôle comme IaC (Infrastructure as Code) 

Prend en charge les modules, assure le suivi de l'état de votre infrastructure et est utile si votre projet est un environnement complexe, multi-cloud ou hybride.

Conditions préalables

Pour commencer, assurez-vous de suivre ce guide pour l'installation de Terraform si vous ne l'avez pas fait et assurez-vous d'avoir déjà configuré un compte GCP.

Vous devez déjà avoir déployé l'application par d'autres moyens comme la CLI pour comprendre le processus de déploiement, la configuration de base, la transition incrémentielle, etc.

Blog associé avec déploiement manuel que j'ai ajouté ci-dessous ??

https://blog.stackademic.com/how-to-deploy-a-go-service-to-gcp-cloud-run-694d01cab5b5

Structure du projet

Pour la structure de mon projet, j'ai ces fichiers et cette structure de répertoires.

terraform/
  ├── modules/
  │   ├── docker/
  │   │   ├── docker-artifact.tf
  │   │   └── variables.tf
  │   ├── gcp/
  │   │   ├── cloud-run.tf
  │   │   └── variables.tf
  ├── main.tf
  ├── set-prod.env.sh
  ├── terraform.tfvars
  ├── variables.tf
  └── account_key.json

• main.tf : y compris les fournisseurs requis et la configuration du fournisseur Google.
• variables.tf : Décrivez comment définir des variables pour votre projet.
• terraform.tfvars : Expliquez comment définir des valeurs de variables spécifiques à votre * environnement.
• set-prod.env.sh : définit les variables d'environnement pour Terraform avec l'indicateur de préfixe TF_VAR.
• Modules : détaillez les modules Docker et Cloud-Run, en expliquant leurs rôles et comment ils interagissent.

Scripts IaC

Je présenterai les scripts des modules parent à enfant pour un guide d'ordre supérieur.
Très probablement, vous aurez des variables d'environnement. Le moyen le plus pratique pour moi est de créer un script shell avec le préfixe TF_VAR_ que Terraform reconnaîtra et utilisera ceux initialisés (mais pour cela plus tard).

#!/bin/bash

#server 
export TF_VAR_redis_url="redis_url"
export TF_VAR_firebase_account_key="your_account_key.json"
export TF_VAR_client_url="client_url"
export TF_VAR_gcp_account_key="client_url"

echo "Environment variables for Terraform GCP set."

Variables que j'ai également définies au niveau du module, mais le parent les contiendra généralement toutes, mais au niveau du module, je viens de passer les bonnes.

variable "project_id" {
  description = "The ID of the Google Cloud project."
  type        = string
}

variable "project_name" {
  description = "The project name of the Google Cloud Run project."
  type        = string
}

variable "region" {
  description = "The Google Cloud region."
  type        = string
}

variable "redis_url" {
  description = "The URL for the Redis instance."
  type        = string
}

variable "client_url" {
  description = "The URL for the client application."
  type        = string
}

variable "gcp_account_key" {
  description = "Path to the Google Cloud service account key file."
  type        = string
}

variable "firebase_account_key_location" {
  description = "Firebase account key location in Docker container."
  type        = string
}

Il existe également un autre fichier de script que j'ai créé qui ne contient PAS de valeurs de clé privée ou secrète qui peuvent être facilement modifiées et qui sont pratiques pour les valeurs par défaut qui sont votre terraform.tfvars

project_id = "recepies-6e7c0"
project_name = "recipe-service"
region     = "europe-north1"
gcp_account_key = "./account_key.json"
firebase_account_key_location = "/app/config/account_key.json"

Parlons de ? dans la salle notre script main.tf.

terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = ">= 4.0.0"
    }
  }
  required_version = ">= 0.12"
}

provider "google" {
  credentials = file(var.gcp_account_key)
  project     = var.project_id
  region      = var.region
}

# Get project information
data "google_project" "project" {
  project_id = var.project_id
}

module "docker" {
  source      = "./modules/docker"
  project_id  = var.project_id
}

module "cloud_run" {
  source      = "./modules/gcp"
  project_id  = var.project_id
  region      = var.region
  redis_url   = var.redis_url
  client_url  = var.client_url
  firebase_account_key_location = var.firebase_account_key_location
  cloudrun_image = "gcr.io/${var.project_id}/recipe-server:latest"

  depends_on = [
    module.docker
  ]
}

Au début, je définis le fournisseur PaaS au fur et à mesure que j'utilise GCP, Google est ajouté, vous pouvez ajouter AWS, Azure ou d'autres fournisseurs. Les informations d'identification sont essentielles pour approuver votre demande auprès de n'importe quel fournisseur de cloud, le gcp_account_key que vous transmettez en tant que fichier json que j'ai dans le répertoire parent Terraform.

Dans la capture d'écran ci-dessus, vous pouvez voir que j'ai créé une clé de compte de service dans GCP et transmis les droits d'accès IAM appropriés.

Il est crucial d'attribuer les droits d'accès IAM (Identity and Access Management) corrects au account_key.json, sinon vous rencontrerez différents problèmes d'autorisation lorsque vous tenterez d'exécuter Terraform. Visionneuse de rôles, éditeur, storage.admin, cloudrun.admin, artefacts Docker.

Il existe également une alternative pour simplement attribuer des rôles et des autorisations via IaC, mais pour moi, c'est plus compliqué, du moins jusqu'à ce que je me familiarise avec cela.

terraform/
  ├── modules/
  │   ├── docker/
  │   │   ├── docker-artifact.tf
  │   │   └── variables.tf
  │   ├── gcp/
  │   │   ├── cloud-run.tf
  │   │   └── variables.tf
  ├── main.tf
  ├── set-prod.env.sh
  ├── terraform.tfvars
  ├── variables.tf
  └── account_key.json

Ci-dessus illustre comment cela pourrait être fait.

Ensuite, les prochaines étapes consistent à exécuter vos modules. Je commence avec Docker car j'ai besoin de créer Docker Artifact dans GCP et une fois cela terminé, je fais de même avec Cloud Run. Gardez à l'esprit que j'accède au répertoire avec "./modules/docker" et que je transmets les variables nécessaires du parent à l'enfant modules/docker/variables.tf.

#!/bin/bash

#server 
export TF_VAR_redis_url="redis_url"
export TF_VAR_firebase_account_key="your_account_key.json"
export TF_VAR_client_url="client_url"
export TF_VAR_gcp_account_key="client_url"

echo "Environment variables for Terraform GCP set."

Le docker-artifact.tf est assez court car il suffit de définir les ressources utilisées en commençant par container_registry_api et d'autre part docker_build_push ajouter le provisionnement pour exécution locale et terminez-la par la création et le déploiement de l'image docker grc avec transmise var.project_id ajoutez que cela dépend de container_registry_api selon les besoins.

Enfin dans notre IaC nous le déployons en exécutant notre dernier module avec "./modules/gcp"

variable "project_id" {
  description = "The ID of the Google Cloud project."
  type        = string
}

variable "project_name" {
  description = "The project name of the Google Cloud Run project."
  type        = string
}

variable "region" {
  description = "The Google Cloud region."
  type        = string
}

variable "redis_url" {
  description = "The URL for the Redis instance."
  type        = string
}

variable "client_url" {
  description = "The URL for the client application."
  type        = string
}

variable "gcp_account_key" {
  description = "Path to the Google Cloud service account key file."
  type        = string
}

variable "firebase_account_key_location" {
  description = "Firebase account key location in Docker container."
  type        = string
}

Comme pour le module Docker, nous définissons les ressources requises pour "google_cloud_run_service", nous sélectionnons le nom, la région, le project_id puis sélectionnons l'image qui a été transmise depuis main.
Si vous avez requis des variables d'environnement, transmettez-les également. 
La ressource membre IAM est ajoutée pour autoriser le déploiement sur Cloud Run.

Déploiement de votre application

Maintenant, lorsque l'architecture est définie et terminée, nous procédons comme suit.

1.Initialiser Terraform

project_id = "recepies-6e7c0"
project_name = "recipe-service"
region     = "europe-north1"
gcp_account_key = "./account_key.json"
firebase_account_key_location = "/app/config/account_key.json"

1. Exécutez le script Shell ou définissez manuellement vos variables d'environnement

terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = ">= 4.0.0"
    }
  }
  required_version = ">= 0.12"
}

provider "google" {
  credentials = file(var.gcp_account_key)
  project     = var.project_id
  region      = var.region
}

# Get project information
data "google_project" "project" {
  project_id = var.project_id
}

module "docker" {
  source      = "./modules/docker"
  project_id  = var.project_id
}

module "cloud_run" {
  source      = "./modules/gcp"
  project_id  = var.project_id
  region      = var.region
  redis_url   = var.redis_url
  client_url  = var.client_url
  firebase_account_key_location = var.firebase_account_key_location
  cloudrun_image = "gcr.io/${var.project_id}/recipe-server:latest"

  depends_on = [
    module.docker
  ]
}

Pour que Terraform accède aux variables .env.

1. Prévisualisez les modifications dans Terraform ou déployez-le directement.

gcloud projects add-iam-policy-binding YOUR_PROJECT_ID \
  --member="serviceAccount:YOUR_SERVICE_ACCOUNT_EMAIL" \
  --role="roles/editor"

Si tout va bien, vous vous retrouverez avec quelque chose comme ça.

Si vous vous engagez sur GitHub, n'oubliez pas d'ajouter quelques fichiers dans .gitignore car Terraform génère des artefacts et des sauvegardes, etc.

resource "google_project_service" "container_registry_api" {
  project = var.project_id
  service = "containerregistry.googleapis.com"
  disable_on_destroy = false
}

resource "null_resource" "docker_build_push" {
  triggers = {
    always_run = timestamp()
  }

  provisioner "local-exec" {
    command = <<-EOT
      # Build the Docker image
      docker build -t gcr.io/${var.project_id}/recipe-server:latest .

      # Configure docker to authenticate with GCP
      gcloud auth configure-docker --quiet

      # Push the image
      docker push gcr.io/${var.project_id}/recipe-server:latest
    EOT
  }

  depends_on = [
    google_project_service.container_registry_api
  ]
}

Conclusion

Bien que l'IaC ajoute une certaine complexité par rapport à la configuration manuelle, il ajoute également, comme mentionné précédemment, plus de maintenabilité et d'automatisation, en particulier l'interaction entre plusieurs fournisseurs de cloud, etc. De plus, pour moi personnellement, cela me donne plus de pouvoir en tant que développeur ! 
Repo que vous pouvez trouver ici.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!