Implementa en Compute Engine

---

En esta guía, se explica cómo realizar implementaciones azul-verde sin tiempo de inactividad en Grupos de instancias administrados de Compute Engine (MIG) que usan Cloud Build y en Terraform.

Cloud Build te permite automatizar varios procesos de desarrollador, incluida la compilación y la implementación de aplicaciones en varios entornos de ejecución de Google Cloud, como Compute Engine, Google Kubernetes Engine, GKE Enterprise, y Cloud Functions.

Los MIG de Compute Engine te permiten operar aplicaciones en varias máquinas virtuales (VMs) idénticas. Puedes hacer que tu cargas de trabajo escalables y con alta disponibilidad aprovechando los MIG servicios, incluidos los de ajuste de escala automático, reparación automática y regionales (en varias zonas) la implementación y la actualización automática. Usa la implementación continua azul-verde aprenderás a transferir de forma gradual el tráfico de usuarios desde un MIG (azul) a otro MIG (verde), que se ejecutan en producción.

Descripción general del diseño

En el siguiente diagrama, se muestra el modelo de implementación azul-verde que usa el código ejemplo descritos en este documento:

En un nivel alto, este modelo incluye los siguientes componentes:

• Dos grupos de VM de Compute Engine: azul y verde.
• Tres balanceadores de cargas HTTP(S) externos:
  • Un balanceador de cargas Azul-verde, que enruta el tráfico de los usuarios finales a el grupo azul o verde de las instancias de VM.
  • Un balanceador de cargas Blue que enruta el tráfico de los ingenieros de QA y desarrolladores al grupo de instancias de VM azul.
  • Un balanceador de cargas Green que enruta el tráfico de los ingenieros de QA y desarrolladores al grupo de instancias Green.
• Dos conjuntos de usuarios:
  • Los usuarios finales que tienen acceso al balanceador de cargas Azul-verde, que señala al grupo de instancias Azul o Verde.
  • Ingenieros y desarrolladores de QA que requieren acceso a ambos conjuntos de grupos para para el desarrollo y las pruebas. Pueden acceder tanto a la red móvil como a la Balanceadores de cargas verdes, que los enrutan al grupo de instancias azul y al Grupo de instancias verde, respectivamente.

Los grupos de VMs azul y verde se implementan como MIG de Compute Engine. Las direcciones IP externas se enrutan a las VMs del MIG con HTTP(S) externo de cargas HTTP(S) externos regionales. En la muestra de código descrita en este documento, se usa Terraform para configurar esta infraestructura.

En el siguiente diagrama, se ilustran las operaciones de desarrollador que ocurren en el Deployment:

En el diagrama anterior, las flechas rojas representan el flujo de arranque que se produce cuando se configura la infraestructura de implementación por primera vez Las flechas azules representan el flujo de GitOps que ocurre durante cada implementación.

Para configurar esta infraestructura, ejecuta una secuencia de comandos de configuración que inicie el arranque y configura los componentes para el flujo de GitOps.

La secuencia de comandos de configuración ejecuta una canalización de Cloud Build que ejecuta siguientes operaciones:

• Crea un repositorio en Cloud Source Repositories. con el nombre copy-of-gcp-mig-simple y copia el código fuente de GitHub al repositorio de Cloud Source Repositories.
• Crea dos activadores de Cloud Build llamados apply y destroy.

Nota: Cloud Build admite integración de primera clase con GitHub, GitLab y Bitbucket. Cloud Source Repositories se usa en esta muestra para con fines de demostración.

Precaución: A partir del 17 de junio de 2024, Cloud Source Repositories no estará disponible para clientes nuevos. Si tu organización no usó anteriormente Cloud Source Repositories, no puedes habilitar la API ni usar Cloud Source Repositories Los proyectos nuevos que no estén conectados a una organización no podrán habilitar la API de Cloud Source Repositories. Las organizaciones que usaron Cloud Source Repositories antes del 17 de junio de 2024 no se verán afectadas por este cambio.

El activador apply se adjunta a un archivo de Terraform llamado main.tfvars en el Cloud Source Repositories. Este archivo contiene las variables de Terraform que representan los balanceadores de cargas azul y verde.

Para configurar la implementación, actualiza las variables en el archivo main.tfvars. El activador apply ejecuta una canalización de Cloud Build que se ejecuta tf_apply y realiza las siguientes operaciones:

• Crea dos MIG de Compute Engine (uno para el verde y otro para el azul), cuatro Instancias de VM de Compute Engine (dos para el MIG verde y dos para el azul) MIG), los tres balanceadores de cargas (azul, verde y el divisor) y tres direcciones IP públicas.
• Imprime las direcciones IP que puedes usar para ver las direcciones IP en las instancias azul y verde.

El activador de destrucción se activa de forma manual para borrar todos los recursos que creó con el activador de aplicación.

Objetivos

• Usar Cloud Build y Terraform para configurar la carga de HTTP(S) externa balanceadores de cargas con backends de grupos de instancias de VM de Compute Engine.

• Realizar implementaciones azul-verde en las instancias de VM

Costos

En este documento, usarás los siguientes componentes facturables de Google Cloud:

• Compute Engine
• Cloud Build
• Cloud Source Repositories
• Cloud Load Balancing

Para generar una estimación de costos en función del uso previsto, usa la calculadora de precios. Es posible que los usuarios nuevos de Google Cloud califiquen para obtener una prueba gratuita.

Cuando finalices las tareas que se describen en este documento, puedes borrar los recursos que creaste para evitar que continúe la facturación. Para obtener más información, consulta Cómo realizar una limpieza.

Antes de comenzar

1. Accede a tu cuenta de Google Cloud. Si eres nuevo en Google Cloud, crea una cuenta para evaluar el rendimiento de nuestros productos en situaciones reales. Los clientes nuevos también obtienen $300 en créditos gratuitos para ejecutar, probar y, además, implementar cargas de trabajo.
2. Instala Google Cloud CLI.

3. Para inicializar la CLI de gcloud, ejecuta el siguiente comando:

   gcloud init

4. Create or select a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   • Create a Google Cloud project:

     gcloud projects create PROJECT_ID

     Replace PROJECT_ID with a name for the Google Cloud project you are creating.

   • Select the Google Cloud project that you created:

     gcloud config set project PROJECT_ID

     Replace PROJECT_ID with your Google Cloud project name.

5. Asegúrate de que la facturación esté habilitada para tu proyecto de Google Cloud.

6. Instala Google Cloud CLI.

7. Para inicializar la CLI de gcloud, ejecuta el siguiente comando:

   gcloud init

8. Create or select a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   • Create a Google Cloud project:

     gcloud projects create PROJECT_ID

     Replace PROJECT_ID with a name for the Google Cloud project you are creating.

   • Select the Google Cloud project that you created:

     gcloud config set project PROJECT_ID

     Replace PROJECT_ID with your Google Cloud project name.

9. Asegúrate de que la facturación esté habilitada para tu proyecto de Google Cloud.

Haz una prueba

1. Ejecuta la secuencia de comandos de configuración del repositorio de muestra de código de Google:

   bash <(curl https://raw.githubusercontent.com/GoogleCloudPlatform/cloud-build-samples/main/mig-blue-green/setup.sh)
   

2. Cuando la secuencia de comandos de configuración solicite el consentimiento del usuario, ingresa yes.

   La secuencia de comandos termina de ejecutarse en unos segundos.

3. En la consola de Google Cloud, abre Historial de compilaciones de Cloud Build. página:

   Abrir la página Historial de compilación

4. Haz clic en la compilación más reciente.

   Verás la página Detalles de compilación, que muestra un Cloud Build de compilación con tres pasos de compilación: el primero crea un repositorio en Cloud Source Repositories, el segundo paso clona el contenido de la muestra en GitHub a Cloud Source Repositories y, en el tercer paso, se agregan activadores de compilación.

5. Abre Cloud Source Repositories:

   Abrir Cloud Source Repositories

6. En la lista de repositorios, haz clic en copy-of-gcp-mig-simple.

   En la pestaña Historial, en la parte inferior de la página, verás una confirmación con la descripción A copy of https://github.com/GoogleCloudPlatform/cloud-build-samples.git de Cloud Build para crear un repositorio llamado copy-of-gcp-mig-simple

7. Abre la página Activadores de Cloud Build:

   Abrir la página Activadores

Verás dos activadores de compilación llamados apply y destroy. El activador apply Se adjunta al archivo infra/main.tfvars en la rama main. Este activador se ejecuta cada vez que se actualiza el archivo. El activador destroy es un activador un activador.

8. Para iniciar el proceso de implementación, actualiza el archivo infra/main.tfvars:

   1. En la ventana de la terminal, crea una carpeta llamada deploy-compute-engine:

      mkdir ~/deploy-compute-engine
      cd ~/deploy-compute-engine
      

   2. Clona el repositorio copy-of-gcp-mig-simple:

      gcloud source repos clone copy-of-mig-blue-green
      

   3. Navega al directorio clonado:

      cd ./copy-of-mig-blue-green
      

   4. Actualiza infra/main.tfvars para reemplazar azul por verde:

      sed -i'' -e 's/blue/green/g' infra/main.tfvars
      

   5. Agrega el archivo actualizado:

      git add .
      

   6. Confirma el archivo:

      git commit -m "Promote green"
      

   7. Envía el archivo:

      git push
      

      Realizar cambios en infra/main.tfvars activa la ejecución de apply activador, que inicia la implementación.

9. Abre Cloud Source Repositories:

   Abrir Cloud Source Repositories

10. En la lista de repositorios, haz clic en copy-of-gcp-mig-simple.

    Verás la confirmación con la descripción Promote green en el Historial en la parte inferior de la página.

11. Para ver la ejecución del activador apply, abre la página Historial de compilaciones en la consola de Google Cloud:

    Abrir la página Historial de compilación

12. Haz clic en la primera compilación para abrir la página Detalles de compilación.

    Verás la canalización del activador apply con dos pasos de compilación. La primera el paso de compilación ejecuta el Compute Engine terraform apply para crear la instancia el balanceo de recursos para la implementación. En el segundo paso de compilación, se imprime Es la dirección IP en la que se ejecuta la aplicación.

13. Abre la dirección IP correspondiente al MIG verde en un navegador. Verás lo siguiente: una captura de pantalla similar a la siguiente que muestra la implementación:

    

14. Dirígete a la página Grupo de instancias de Compute Engine para ver las métricas Grupos de instancias verdes:

    Abrir la página Grupo de instancias

15. Abre la página Instancias de VM para ver las cuatro instancias de VM:

    Abrir la página Instancia de VM

16. Abre la página Direcciones IP externas para ver los tres balanceadores de cargas:

    Abrir la página Direcciones IP externas

Comprende el código

El código fuente para esta muestra de código incluye lo siguiente:

• Código fuente relacionado con la secuencia de comandos de configuración
• Código fuente relacionado con las canalizaciones de Cloud Build
• Código fuente relacionado con las plantillas de Terraform

Guion de configuración

setup.sh es la secuencia de comandos de configuración que ejecuta el proceso de arranque y crea la para la implementación azul-verde. La secuencia de comandos realiza las siguientes acciones operaciones:

• Habilita Cloud Build, Resource Manager, Compute Engine y las APIs de Cloud Source Repositories.
• Otorga el rol de IAM roles/editor a la Cuenta de servicio de Cloud Build en tu proyecto. Este rol es necesarios para que Cloud Build cree y configure componentes de GitOps para la implementación.
• Otorga el rol de IAM roles/source.admin a la Cuenta de servicio de Cloud Build en tu proyecto. Este rol es necesario para que la cuenta de servicio de Cloud Build cree el Cloud Source Repositories en tu proyecto y clona el contenido de la muestra repositorio de GitHub a tus repositorios de Cloud Source Repositories.

• Genera una canalización de Cloud Build llamada bootstrap.cloudbuild.yaml intercalado, que:

  • Crea un repositorio nuevo en Cloud Source Repositories.
  • Copia el código fuente del repositorio de GitHub de muestra en el en un repositorio nuevo en Cloud Source Repositories.
  • Crea los activadores de compilación de aplicación y destrucción.

set -e

BLUE='\033[1;34m'
RED='\033[1;31m'
GREEN='\033[1;32m'
NC='\033[0m'

echo -e "\n${GREEN}######################################################"
echo -e "#                                                    #"
echo -e "#  Zero-Downtime Blue/Green VM Deployments Using     #"
echo -e "#  Managed Instance Groups, Cloud Build & Terraform  #"
echo -e "#                                                    #"
echo -e "######################################################${NC}\n"

echo -e "\nSTARTED ${GREEN}setup.sh:${NC}"

echo -e "\nIt's ${RED}safe to re-run${NC} this script to ${RED}recreate${NC} all resources.\n"
echo "> Checking GCP CLI tool is installed"
gcloud --version > /dev/null 2>&1

readonly EXPLICIT_PROJECT_ID="$1"
readonly EXPLICIT_CONSENT="$2"

if [ -z "$EXPLICIT_PROJECT_ID" ]; then
    echo "> No explicit project id provided, trying to infer"
    PROJECT_ID="$(gcloud config get-value project)"
else
    PROJECT_ID="$EXPLICIT_PROJECT_ID"
fi

if [ -z "$PROJECT_ID" ]; then
    echo "ERROR: GCP project id was not provided as parameter and could not be inferred"
    exit 1
else
    readonly PROJECT_NUM="$(gcloud projects describe $PROJECT_ID --format='value(projectNumber)')"
    if [ -z "$PROJECT_NUM" ]; then
        echo "ERROR: GCP project number could not be determined"
        exit 1
    fi
    echo -e "\nYou are about to:"
    echo -e "  * modify project ${RED}${PROJECT_ID}/${PROJECT_NUM}${NC}"
    echo -e "  * ${RED}enable${NC} various GCP APIs"
    echo -e "  * make Cloud Build ${RED}editor${NC} of your project"
    echo -e "  * ${RED}execute${NC} Cloud Builds and Terraform plans to create"
    echo -e "  * ${RED}4 VMs${NC}, ${RED}3 load balancers${NC}, ${RED}3 public IP addresses${NC}"
    echo -e "  * incur ${RED}charges${NC} in your billing account as a result\n"
fi

if [ "$EXPLICIT_CONSENT" == "yes" ]; then
  echo "Proceeding under explicit consent"
  readonly CONSENT="$EXPLICIT_CONSENT"
else
    echo -e "Enter ${BLUE}'yes'${NC} if you want to proceed:"
    read CONSENT
fi

if [ "$CONSENT" != "yes" ]; then
    echo -e "\nERROR: Aborted by user"
    exit 1
else
    echo -e "\n......................................................"
    echo -e "\n> Received user consent"
fi

#
# Executes action with one randomly delayed retry.
#
function do_with_retry {
    COMMAND="$@"
    echo "Trying $COMMAND"
    (eval $COMMAND && echo "Success on first try") || ( \
        echo "Waiting few seconds to retry" &&
        sleep 10 && \
        echo "Retrying $COMMAND" && \
        eval $COMMAND \
    )
}

echo "> Enabling required APIs"
# Some of these can be enabled later with Terraform, but I personally
# prefer to do all API enablement in one place with gcloud.
gcloud services enable \
    --project=$PROJECT_ID \
    cloudbuild.googleapis.com \
    cloudresourcemanager.googleapis.com \
    compute.googleapis.com \
    sourcerepo.googleapis.com \
    --no-user-output-enabled \
    --quiet

echo "> Adding Cloud Build to roles/editor"
gcloud projects add-iam-policy-binding \
    "$PROJECT_ID" \
    --member="serviceAccount:$[e-mail]" \
    --role='roles/editor' \
    --condition=None \
    --no-user-output-enabled \
    --quiet

echo "> Adding Cloud Build to roles/source.admin"
gcloud projects add-iam-policy-binding \
    "$PROJECT_ID" \
    --member="serviceAccount:$[e-mail]" \
    --condition=None \
    --role='roles/source.admin' \
    --no-user-output-enabled \
    --quiet

echo "> Configuring bootstrap job"
rm -rf "./bootstrap.cloudbuild.yaml"
cat <<'EOT_BOOT' > "./bootstrap.cloudbuild.yaml"
tags:
- "mig-blue-green-bootstrapping"
steps:
- id: create_new_cloud_source_repo
  name: "gcr.io/cloud-builders/gcloud"
  script: |
    #!/bin/bash
    set -e

    echo "(Re)Creating source code repository"

    gcloud source repos delete \
        "copy-of-mig-blue-green" \
        --quiet || true

    gcloud source repos create \
        "copy-of-mig-blue-green" \
        --quiet

- id: copy_demo_source_into_new_cloud_source_repo
  name: "gcr.io/cloud-builders/gcloud"
  env:
    - "PROJECT_ID=$PROJECT_ID"
    - "PROJECT_NUMBER=$PROJECT_NUMBER"
  script: |
    #!/bin/bash
    set -e

    readonly GIT_REPO="https://github.com/GoogleCloudPlatform/cloud-build-samples.git"

    echo "Cloning demo source repo"
    mkdir /workspace/from/
    cd /workspace/from/
    git clone $GIT_REPO ./original
    cd ./original

    echo "Cloning new empty repo"
    mkdir /workspace/to/
    cd /workspace/to/
    gcloud source repos clone \
        "copy-of-mig-blue-green"
    cd ./copy-of-mig-blue-green

    echo "Making a copy"
    cp -r /workspace/from/original/mig-blue-green/* ./

    echo "Setting git identity"
    git config user.email \
        "$[e-mail]"
    git config user.name \
        "Cloud Build"

    echo "Commit & push"
    git add .
    git commit \
        -m "A copy of $GIT_REPO"
    git push

- id: add_pipeline_triggers
  name: "gcr.io/cloud-builders/gcloud"
  env:
    - "PROJECT_ID=$PROJECT_ID"
  script: |
    #!/bin/bash
    set -e

    echo "(Re)Creating destroy trigger"
    gcloud builds triggers delete "destroy" --quiet || true
    gcloud builds triggers create manual \
        --name="destroy" \
        --repo="https://source.developers.google.com/p/$PROJECT_ID/r/copy-of-mig-blue-green" \
        --branch="master" \
        --build-config="pipelines/destroy.cloudbuild.yaml" \
        --repo-type=CLOUD_SOURCE_REPOSITORIES \
        --quiet

    echo "(Re)Creating apply trigger"
    gcloud builds triggers delete "apply" --quiet || true
    gcloud builds triggers create cloud-source-repositories \
        --name="apply" \
        --repo="copy-of-mig-blue-green" \
        --branch-pattern="master" \
        --build-config="pipelines/apply.cloudbuild.yaml" \
        --included-files="infra/main.tfvars" \
        --quiet

EOT_BOOT

echo "> Waiting API enablement propagation"
do_with_retry "(gcloud builds list --project "$PROJECT_ID" --quiet && gcloud compute instances list --project "$PROJECT_ID" --quiet && gcloud source repos list --project "$PROJECT_ID" --quiet) > /dev/null 2>&1" > /dev/null 2>&1

echo "> Executing bootstrap job"
gcloud beta builds submit \
    --project "$PROJECT_ID" \
    --config ./bootstrap.cloudbuild.yaml \
    --no-source \
    --no-user-output-enabled \
    --quiet
rm ./bootstrap.cloudbuild.yaml

echo -e "\n${GREEN}All done. Now you can:${NC}"
echo -e "  * manually run 'apply' and 'destroy' triggers to manage deployment lifecycle"
echo -e "  * commit change to 'infra/main.tfvars' and see 'apply' pipeline trigger automatically"

echo -e "\n${GREEN}Few key links:${NC}"
echo -e "  * Dashboard: https://console.cloud.google.com/home/dashboard?project=$PROJECT_ID"
echo -e "  * Repo: https://source.cloud.google.com/$PROJECT_ID/copy-of-mig-blue-green"
echo -e "  * Cloud Build Triggers: https://console.cloud.google.com/cloud-build/triggers;region=global?project=$PROJECT_ID"
echo -e "  * Cloud Build History: https://console.cloud.google.com/cloud-build/builds?project=$PROJECT_ID"

echo -e "\n............................."

echo -e "\n${GREEN}COMPLETED!${NC}"

Canalizaciones de Cloud Build

apply.cloudbuild.yaml y destroy.cloudbuild.yaml son las Archivos de configuración de Cloud Build que usa la secuencia de comandos de configuración para configurar para el flujo de GitOps. apply.cloudbuild.yaml contiene dos pasos de compilación:

• Paso de compilación de tf_apply build que llama a la función tf_install_in_cloud_build_step, que instala Terraform tf_apply que crea los recursos usados en el flujo de GitOps. Las funciones tf_install_in_cloud_build_step y tf_apply se definen en bash_utils.sh y el paso de compilación usa el comando source para llamar de ellos.
• Paso de compilación de describe_deployment que llama a la función describe_deployment que imprime las direcciones IP de la carga balanceadores de cargas.

destroy.cloudbuild.yaml llama a tf_destroy, que borra todos los recursos. creado por tf_apply.

Las funciones tf_install_in_cloud_build_step, tf_apply describe_deployment y tf_destroy se definen en el archivo bash_utils.sh. Los archivos de configuración de compilación usan el comando source para llamar a las funciones.

steps:
  - id: run-terraform-apply
    name: "gcr.io/cloud-builders/gcloud"
    env:
      - "PROJECT_ID=$PROJECT_ID"
    script: |
      #!/bin/bash
      set -e
      source /workspace/lib/bash_utils.sh
      tf_install_in_cloud_build_step
      tf_apply

  - id: describe-deployment
    name: "gcr.io/cloud-builders/gcloud"
    env:
      - "PROJECT_ID=$PROJECT_ID"
    script: |
      #!/bin/bash
      set -e
      source /workspace/lib/bash_utils.sh
      describe_deployment

tags:
  - "mig-blue-green-apply"

steps:
  - id: run-terraform-destroy
    name: "gcr.io/cloud-builders/gcloud"
    env:
      - "PROJECT_ID=$PROJECT_ID"
    script: |
      #!/bin/bash
      set -e
      source /workspace/lib/bash_utils.sh
      tf_install_in_cloud_build_step
      tf_destroy

tags:
  - "mig-blue-green-destroy"

El siguiente código muestra la función tf_install_in_cloud_build_step que se definido en bash_utils.sh. Los archivos de configuración de compilación llaman a esta función para instalar Terraform sobre la marcha. Crea un bucket de Cloud Storage para registrar el estado de Terraform.

function tf_install_in_cloud_build_step {
    echo "Installing deps"
    apt update
    apt install \
        unzip \
        wget \
        -y

    echo "Manually installing Terraform"
    wget https://releases.hashicorp.com/terraform/1.3.4/terraform_1.3.4_linux_386.zip
    unzip -q terraform_1.3.4_linux_386.zip
    mv ./terraform /usr/bin/
    rm -rf terraform_1.3.4_linux_386.zip

    echo "Verifying installation"
    terraform -v

    echo "Creating Terraform state storage bucket $BUCKET_NAME"
    gcloud storage buckets create \
        "gs://$BUCKET_NAME" || echo "Already exists..."

    echo "Configure Terraform provider and state bucket"
cat <<EOT_PROVIDER_TF > "/workspace/infra/provider.tf"
terraform {
  required_version = ">= 0.13"
  backend "gcs" {
    bucket = "$BUCKET_NAME"
  }
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = ">= 3.77, < 5.0"
    }
  }
}
EOT_PROVIDER_TF

    echo "$(cat /workspace/infra/provider.tf)"
}

En el siguiente fragmento de código, se muestra la función tf_apply que se define en bash_utils.sh Primero, llama a terraform init, que carga todos los módulos y bibliotecas personalizadas y, luego, ejecuta terraform apply para cargar las variables desde el archivo main.tfvars.

function tf_apply {
    echo "Running Terraform init"
    terraform \
        -chdir="$TF_CHDIR" \
        init

    echo "Running Terraform apply"
    terraform \
        -chdir="$TF_CHDIR" \
        apply \
        -auto-approve \
        -var project="$PROJECT_ID" \
        -var-file="main.tfvars"
}

En el siguiente fragmento de código, se muestra la función describe_deployment que se definido en bash_utils.sh. Usa gcloud compute addresses describe para recuperar las direcciones IP de los balanceadores de cargas con el nombre y las imprime.

function describe_deployment {
    NS="ns1-"
    echo -e "Deployment configuration:\n$(cat infra/main.tfvars)"
    echo -e \
      "Here is how to connect to:" \
      "\n\t* active color MIG: http://$(gcloud compute addresses describe ${NS}splitter-address-name --region=us-west1 --format='value(address)')/" \
      "\n\t* blue color MIG: http://$(gcloud compute addresses describe ${NS}blue-address-name --region=us-west1 --format='value(address)')/" \
      "\n\t* green color MIG: http://$(gcloud compute addresses describe ${NS}green-address-name --region=us-west1 --format='value(address)')/"
    echo "Good luck!"
}

En el siguiente fragmento de código, se muestra la función tf_destroy que se define en bash_utils.sh Llama a terraform init, que carga todos los módulos y datos y, luego, ejecuta terraform destroy que descarga las variables de Terraform.

function tf_destroy {
    echo "Running Terraform init"
    terraform \
        -chdir="$TF_CHDIR" \
        init

    echo "Running Terraform destroy"
    terraform \
        -chdir="$TF_CHDIR" \
        destroy \
        -auto-approve \
        -var project="$PROJECT_ID" \
        -var-file="main.tfvars"
}

Plantillas de Terraform

Encontrarás todos los archivos y variables de configuración de Terraform en la copy-of-gcp-mig-simple/infra/ carpeta.

• main.tf: Este es el archivo de configuración de Terraform.
• main.tfvars: Este archivo define las variables de Terraform.
• mig/ y splitter/: Estas carpetas contienen los módulos que definen la de cargas HTTP(S) externos regionales. La carpeta mig/ contiene el archivo de configuración de Terraform que define el MIG para los balanceadores de cargas azul y verde. El objetivo azul y los MIG verdes son idénticos, por lo que se definen una vez y se crearon instancias de los objetos azul y verde. La configuración de Terraform del balanceador de cargas del divisor está en la carpeta splitter/ .

En el siguiente fragmento de código, se muestra el contenido de infra/main.tfvars. Integra contiene tres variables, dos que determinan qué versión de la aplicación implementar a los grupos Azul y Verde, y una variable para el color activo: azul o Verde. Los cambios en este archivo activan la implementación.

MIG_VER_BLUE     = "v1"
MIG_VER_GREEN    = "v1"
MIG_ACTIVE_COLOR = "blue"

El siguiente es un fragmento de código de infra/main.tf. En este fragmento:

• Se define una variable para el proyecto de Google Cloud.
• Google está configurado como el proveedor de Terraform.
• Se define una variable para el espacio de nombres. Todos los objetos que crea Terraform se con el prefijo esta variable para que varias versiones de la aplicación puedan implementar en el mismo proyecto y los nombres de los objetos no colisionen entre sí.
• Las variables MIG_VER_BLUE, MIG_VER_BLUE y MIG_ACTIVE_COLOR son las vinculaciones para las variables en el archivo infra/main.tfvars.

variable "project" {
  type        = string
  description = "GCP project we are working in."
}

provider "google" {
  project = var.project
  region  = "us-west1"
  zone    = "us-west1-a"
}

variable "ns" {
  type        = string
  default     = "ns1-"
  description = "The namespace used for all resources in this plan."
}

variable "MIG_VER_BLUE" {
  type        = string
  description = "Version tag for 'blue' deployment."
}

variable "MIG_VER_GREEN" {
  type        = string
  description = "Version tag for 'green' deployment."
}

variable "MIG_ACTIVE_COLOR" {
  type        = string
  description = "Active color (blue | green)."
}

En el siguiente fragmento de código de infra/main.tf, se muestra la creación de una instancia de la divisor. Este módulo toma el color activo para que el divisor cargue de red sabe qué MIG implementar la aplicación.

module "splitter-lb" {
  source               = "./splitter"
  project              = var.project
  ns                   = "${var.ns}splitter-"
  active_color         = var.MIG_ACTIVE_COLOR
  instance_group_blue  = module.blue.google_compute_instance_group_manager_default.instance_group
  instance_group_green = module.green.google_compute_instance_group_manager_default.instance_group
}

En el siguiente fragmento de código de infra/main.tf, se definen dos módulos idénticos para MIG azul y verde. Toma el color, la red y la subred que se definen en el módulo divisor.

module "blue" {
  source                               = "./mig"
  project                              = var.project
  app_version                          = var.MIG_VER_BLUE
  ns                                   = var.ns
  color                                = "blue"
  google_compute_network               = module.splitter-lb.google_compute_network
  google_compute_subnetwork            = module.splitter-lb.google_compute_subnetwork_default
  google_compute_subnetwork_proxy_only = module.splitter-lb.google_compute_subnetwork_proxy_only
}

module "green" {
  source                               = "./mig"
  project                              = var.project
  app_version                          = var.MIG_VER_GREEN
  ns                                   = var.ns
  color                                = "green"
  google_compute_network               = module.splitter-lb.google_compute_network
  google_compute_subnetwork            = module.splitter-lb.google_compute_subnetwork_default
  google_compute_subnetwork_proxy_only = module.splitter-lb.google_compute_subnetwork_proxy_only
}

El archivo splitter/main.tf define los objetos que se crean para el o un MIG separador. El siguiente es un fragmento de código de splitter/main.tf que contiene la lógica para alternar entre el MIG verde y azul. Cuenta con el respaldo el servicio google_compute_region_backend_service, que puede dirigir el tráfico a dos regiones de backend: var.instance_group_blue o var.instance_group_green. capacity_scaler define la cantidad de tráfico que se debe enrutar.

El siguiente código enruta el 100% del tráfico al color especificado, pero puede actualizar este código para que la implementación de versiones canary enrute el tráfico a un subconjunto a los usuarios.

resource "google_compute_region_backend_service" "default" {
  name                  = local.l7-xlb-backend-service
  region                = "us-west1"
  load_balancing_scheme = "EXTERNAL_MANAGED"
  health_checks         = [google_compute_region_health_check.default.id]
  protocol              = "HTTP"
  session_affinity      = "NONE"
  timeout_sec           = 30
  backend {
    group           = var.instance_group_blue
    balancing_mode  = "UTILIZATION"
    capacity_scaler = var.active_color == "blue" ? 1 : 0
  }
  backend {
    group           = var.instance_group_green
    balancing_mode  = "UTILIZATION"
    capacity_scaler = var.active_color == "green" ? 1 : 0
  }
}

El archivo mig/main.tf define los objetos relacionados con el azul y el verde. MIG. El siguiente fragmento de código de este archivo define la Compute Engine de instancias administrados para crear los grupos de VM. Ten en cuenta que esta instancia tiene la propiedad del ciclo de vida de Terraform establecida en create_before_destroy. Esto se debe a que, cuando actualizas la versión del grupo, no puedes usar el plantilla para crear la versión nueva de los grupos cuando aún la están usando la versión anterior del grupo. Pero si la versión anterior del grupo es antes de crear la nueva plantilla, habrá un período en el que las piscinas están fuera de servicio. Para evitar esta situación, configuramos el ciclo de vida de Terraform para create_before_destroy para que primero se cree la versión más reciente de un grupo de VM antes de que se destruya la versión anterior.

resource "google_compute_instance_template" "default" {
  name = local.l7-xlb-backend-template
  disk {
    auto_delete  = true
    boot         = true
    device_name  = "persistent-disk-0"
    mode         = "READ_WRITE"
    source_image = "projects/debian-cloud/global/images/family/debian-10"
    type         = "PERSISTENT"
  }
  labels = {
    managed-by-cnrm = "true"
  }
  machine_type = "n1-standard-1"
  metadata = {
    startup-script = <<EOF
    #! /bin/bash
    sudo apt-get update
    sudo apt-get install apache2 -y
    sudo a2ensite default-ssl
    sudo a2enmod ssl
    vm_hostname="$(curl -H "Metadata-Flavor:Google" \
    http://169.254.169.254/computeMetadata/v1/instance/name)"
    sudo echo "<html><body style='font-family: Arial; margin: 64px; background-color: light${var.color};'><h3>Hello, World!<br><br>version: ${var.app_version}<br>ns: ${var.ns}<br>hostname: $vm_hostname</h3></body></html>" | \
    tee /var/www/html/index.html
    sudo systemctl restart apache2
    EOF
  }
  network_interface {
    access_config {
      network_tier = "PREMIUM"
    }
    network    = var.google_compute_network.id
    subnetwork = var.google_compute_subnetwork.id
  }
  region = "us-west1"
  scheduling {
    automatic_restart   = true
    on_host_maintenance = "MIGRATE"
    provisioning_model  = "STANDARD"
  }
  tags = ["load-balanced-backend"]

  # NOTE: the name of this resource must be unique for every update;
  #       this is wy we have a app_version in the name; this way
  #       new resource has a different name vs old one and both can
  #       exists at the same time
  lifecycle {
    create_before_destroy = true
  }
}

Limpia

Para evitar que se apliquen cargos a tu cuenta de Google Cloud por los recursos usados en este instructivo, borra el proyecto que contiene los recursos o conserva el proyecto y borra los recursos individuales.

Borra los recursos individuales

1. Borra los recursos de Compute Engine que creó el activador de aplicación:

   1. Abre la página Activadores de Cloud Build:

      Abrir la página Activadores

   2. En la tabla Activadores, localiza la fila correspondiente a destroy. y haz clic en Ejecutar. Cuando el activador completa la ejecución, el se borran los recursos creados por el activador apply.

2. Borra los recursos creados durante el inicio ejecutando el siguiente comando comando en la ventana de tu terminal:

   bash <(curl https://raw.githubusercontent.com/GoogleCloudPlatform/cloud-build-samples/main/mig-blue-green/teardown.sh)
   

Borra el proyecto

Precaución: Borrar un proyecto tiene estas consecuencias:

• Se borra todo en el proyecto. Si usaste un proyecto existente para las tareas de este documento, cuando lo borres, también se borrará cualquier otro trabajo que hayas realizado en el proyecto.
• Se pierden los ID personalizados de proyectos. Cuando creaste este proyecto, es posible que hayas creado un ID del proyecto personalizado que desees utilizar en el futuro. Para conservar las URL que utilizan el ID del proyecto, como una URL appspot.com, borra los recursos seleccionados dentro del proyecto en lugar de borrar todo el proyecto.

Si planeas explorar varias infraestructuras, instructivos y guías de inicio rápido la reutilización de proyectos puede ayudarte a evitar exceder los límites de las cuotas del proyecto.

Borra un proyecto de Google Cloud:

gcloud projects delete PROJECT_ID

¿Qué sigue?

• Obtén más información sobre los activadores de compilación.
• Aprende a ver la procedencia de la compilación.