Prácticas recomendadas para Workflows

Puedes consultar las prácticas recomendadas que se mencionan aquí cuando organices tus servicios con flujos de trabajo.

Esta no es una lista exhaustiva de recomendaciones y no te enseña los aspectos básicos del uso de Workflows. En este documento, se supone que ya tienes una comprensión general del panorama general de Google Cloud Workflows. Para obtener más información, consulta el marco de trabajo de la arquitectura deGoogle Cloud y la descripción general de los flujos de trabajo.

Selecciona un patrón de comunicación óptimo

Cuando diseñes una arquitectura de microservicios para implementar varios servicios, puedes elegir entre los siguientes patrones de comunicación:

  • Comunicación directa de servicio a servicio

  • Comunicación indirecta basada en eventos (también conocida como coreografía)

  • Configuración, coordinación y administración automatizadas (también conocidas como organización)

Asegúrate de considerar los beneficios y las desventajas de cada una de las opciones anteriores y selecciona un patrón óptimo para tu caso de uso. Por ejemplo, la comunicación directa de servicio a servicio puede ser más fácil de implementar que otras opciones, pero une estrechamente tus servicios. Por el contrario, una arquitectura basada en eventos te permite acoplar tus servicios de forma flexible. Sin embargo, la supervisión y la depuración pueden ser más complicadas. Por último, un orquestador central, como Workflows, aunque es menos flexible, te permite coordinar la comunicación entre servicios sin la vinculación estrecha de la comunicación directa entre servicios ni la complejidad de los eventos coreografiados.

También puedes combinar patrones de comunicación. Por ejemplo, en la orquestación basada en eventos, los servicios estrechamente relacionados se administran en una orquestación que activa un evento. Del mismo modo, podrías diseñar un sistema en el que una orquestación genere un mensaje de Pub/Sub para otro sistema orquestado.

Sugerencias generales

Una vez que hayas decidido usar Workflows como orquestador de servicios, ten en cuenta las siguientes sugerencias útiles.

Evita codificar las URLs

Puedes admitir flujos de trabajo que sean portátiles en varios entornos y más fáciles de mantener si evitas las URLs codificadas. Puedes lograr esto de las siguientes maneras:

  • Define las URLs como argumentos del entorno de ejecución.

    Esto puede ser útil cuando se invoca tu flujo de trabajo a través de una biblioteca cliente o la API. (Sin embargo, esto no funcionará si un evento de Eventarc activa tu flujo de trabajo y el único argumento que se puede pasar es la carga útil del evento).

    Ejemplo

    main:
  params: [args]
  steps:
    - init:
        assign:
          - url1: ${args.urls.url1}
          - url2: ${args.urls.url2}

    Cuando ejecutes el flujo de trabajo, podrás especificar las URLs. Por ejemplo:

    gcloud workflows run multi-env --data='{"urls":{"url1": "URL_ONE", "url2": "URL_TWO"}}'

  • Usa variables de entorno y crea un flujo de trabajo que se configure de forma dinámica según el entorno en el que se implemente. También puedes crear un flujo de trabajo que se pueda reutilizar como una plantilla y configurar según las variables de entorno que se mantienen por separado.

  • Usa una técnica de sustitución que te permita crear un solo archivo de definición de flujo de trabajo, pero implementa variantes con una herramienta que reemplace los marcadores de posición en tu flujo de trabajo. Por ejemplo, puedes usar Cloud Build para implementar un flujo de trabajo y, en el archivo de configuración de Cloud Build, agregar un paso para reemplazar las URLs de marcador de posición en el flujo de trabajo.

    Ejemplo

    steps:
‐ id: 'replace-urls'
  name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: bash
  args:
    - -c
    - |
      sed -i -e "s~REPLACE_url1~$_URL1~" workflow.yaml
      sed -i -e "s~REPLACE_url2~$_URL2~" workflow.yaml
‐ id: 'deploy-workflow'
  name: 'gcr.io/cloud-builders/gcloud'
  args: ['workflows', 'deploy', 'multi-env-$_ENV', '--source', 'workflow.yaml']

    Luego, puedes substituir valores de variables en el momento de la compilación. Por ejemplo:

    gcloud builds submit --config cloudbuild.yaml \
    --substitutions=_ENV=staging,_URL1="URL_ONE",_URL2="URL_TWO"

    Para obtener más información, consulta Cómo enviar una compilación a través de la CLI y la API.

    También puedes usar Terraform para aprovisionar tu infraestructura y definir un archivo de configuración que cree flujos de trabajo para cada entorno con variables de entrada.

    Ejemplo

    variable "project_id" {
  type = string
}

variable "url1" {
  type = string
}

variable "url2" {
  type = string
}

locals {
  env = ["staging", "prod"]
}

# Define and deploy staging and production workflows
resource "google_workflows_workflow" "multi-env-workflows" {
  for_each = toset(local.env)

  name            = "multi-env-${each.key}"
  project         = var.project_id
  region          = "us-central1"
  source_contents = templatefile("${path.module}/workflow.yaml", { url1 : "${var.url1}-${each.key}", url2 : "${var.url2}-${each.key}" })
}

    Cuando se declaran variables en el módulo raíz de tu configuración, se les pueden asignar valores de varias maneras. Por ejemplo:

    terraform apply -var="project_id=PROJECT_ID" -var="url1=URL_ONE" -var="url2=URL_TWO"

  • Usa el conector de Secret Manager para almacenar y recuperar URLs de forma segura en Secret Manager.

Usa pasos anidados

Cada flujo de trabajo debe tener al menos un paso. De forma predeterminada, Workflows considera que los pasos están en una lista ordenada y los ejecuta uno a la vez hasta que se ejecutan todos. Lógicamente, algunos pasos deben agruparse, y puedes usar un bloque steps para anidar una serie de pasos. Esto es conveniente, ya que te permite apuntar al paso atómico correcto para procesar un conjunto de pasos.

Ejemplo

main:
    params: [input]
    steps:
    - callWikipedia:
        steps:
        - checkSearchTermInInput:
            switch:
                - condition: ${"searchTerm" in input}
                  assign:
                    - searchTerm: ${input.searchTerm}
                  next: readWikipedia
        - getCurrentDate:
            call: http.get
            args:
                url: https://timeapi.io/api/Time/current/zone?timeZone=Europe/Amsterdam
            result: currentDate
        - setFromCallResult:
            assign:
                - searchTerm: ${currentDate.body.dayOfWeek}
        - readWikipedia:
            call: http.get
            args:
                url: https://en.wikipedia.org/w/api.php
                query:
                    action: opensearch
                    search: ${searchTerm}
            result: wikiResult
    - returnOutput:
            return: ${wikiResult.body[1]}

Une expresiones

Todas las expresiones deben comenzar con una $ y estar entre llaves:

${EXPRESSION}

Para evitar problemas de análisis de YAML, puedes unir las expresiones con comillas. Por ejemplo, las expresiones que contienen dos puntos pueden causar un comportamiento inesperado cuando el dos puntos se interpreta como la definición de un mapa. Para resolver este problema, une la expresión YAML con comillas simples:

'${"Name: " + myVar}'

También puedes usar expresiones que abarcan varias líneas. Por ejemplo, es posible que necesites encerrar una consulta en SQL entre comillas cuando uses el conector de BigQuery de Workflows.

Ejemplo

- runQuery:
    call: googleapis.bigquery.v2.jobs.query
    args:
        projectId: ${sys.get_env("GOOGLE_CLOUD_PROJECT_ID")}
        body:
            useLegacySql: false
            useQueryCache: false
            timeoutMs: 30000
            # Find top 100 titles with most views on Wikipedia
            query: ${
                "SELECT TITLE, SUM(views)
                FROM `bigquery-samples.wikipedia_pageviews." + table + "`
                WHERE LENGTH(TITLE) > 10
                GROUP BY TITLE
                ORDER BY SUM(VIEWS) DESC
                LIMIT 100"
                }
    result: queryResult

Para obtener la definición completa del flujo de trabajo, consulta Ejecuta varios trabajos de BigQuery en paralelo.

Usa llamadas declarativas

Usa Workflows para llamar a servicios desde el flujo de trabajo en sí y controlar los resultados, y para ejecutar tareas simples, como hacer una llamada HTTP. Los flujos de trabajo pueden invocar servicios, analizar respuestas y construir entradas para otros servicios conectados. Llamar a un servicio te permite evitar las complicaciones de invocaciones adicionales, dependencias adicionales y servicios que llaman a servicios. Considera reemplazar los servicios que no tienen lógica empresarial con llamadas a la API declarativas y usa flujos de trabajo para abstraer la complejidad.

Sin embargo, debes crear servicios para realizar cualquier tarea que sea demasiado compleja para Workflows, por ejemplo, implementar una lógica empresarial reutilizable, cálculos complejos o transformaciones que no sean compatibles con las expresiones de Workflows y su biblioteca estándar. Por lo general, un caso complicado es más fácil de implementar en código, en lugar de usar YAML o JSON y la sintaxis de Workflows.

Almacena solo lo que necesitas

Mantén el consumo de memoria bajo control para no encontrar límites de recursos ni un error que lo indique, como ResourceLimitError, MemoryLimitExceededError o ResultSizeLimitExceededError.

Sé selectivo con lo que almacenas en las variables. Filtra y almacena solo lo que necesitas. Si un servicio muestra una carga útil demasiado grande, usa una función independiente para realizar la llamada por ti y mostrar solo lo que se requiere.

Para liberar memoria, borra las variables. Por ejemplo, es posible que desees liberar la memoria necesaria para los pasos posteriores. O bien, es posible que tengas llamadas con resultados que no te interesan, y puedes omitir esos resultados por completo.

Para borrar una variable, asigna null. En YAML, también puedes asignar un valor vacío o ~ a una variable. Esto identifica la memoria que se puede recuperar de forma segura.

Ejemplo

  - step:
      assign:
        - bigVar:

Usa subflujos de trabajo y flujos de trabajo externos

Puedes usar subflujos de trabajo para definir una lógica o un conjunto de pasos a los que deseas llamar varias veces, lo que simplifica la definición del flujo de trabajo. Los subflujos de trabajo son similares a una función o una rutina en un lenguaje de programación. Pueden aceptar parámetros y mostrar valores, lo que te permite crear flujos de trabajo más complejos con un rango más amplio de aplicaciones.

Ten en cuenta que los subflujos de trabajo son locales para la definición de tu flujo de trabajo y no se pueden reutilizar en otros flujos de trabajo. Sin embargo, puedes llamar a flujos de trabajo desde otros flujos de trabajo. Los conectores de flujos de trabajo pueden ayudarte con esto. Para obtener más información, consulta las descripciones generales de los conectores de la API de Workflow Executions y la API de Workflows.

Usa conectores de flujos de trabajo

Los flujos de trabajo proporcionan una serie de conectores que facilitan el acceso a otros productos Google Cloud dentro de un flujo de trabajo. Los conectores simplifican los servicios de llamadas porque manejan el formato de las solicitudes por ti y proporcionan métodos y argumentos para que no necesites conocer los detalles de una API deGoogle Cloud . Los conectores también tienen un comportamiento integrado para controlar los reintentos y las operaciones de larga duración, de modo que puedas evitar iterar y esperar a que se completen las llamadas. Los conectores se encargan de esto por ti.

Si necesitas llamar a una API de Google Cloud , primero verifica si existe un conector de Workflows para ella. Si no ves un conector para un producto Google Cloud , puedes solicitar uno.

Obtén información para usar un conector y, para obtener una referencia detallada de los conectores disponibles, consulta la referencia de conectores.

Ejecuta pasos de flujo de trabajo en paralelo

Si bien Workflows puede ejecutar pasos de forma secuencial, también puedes ejecutar pasos independientes en paralelo. En algunos casos, esto puede acelerar significativamente la ejecución de tu flujo de trabajo. Para obtener más información, consulta Ejecuta pasos de flujo de trabajo en paralelo.

Aplica reintentos y el patrón de saga

Diseña flujos de trabajo que sean resilientes y puedan controlar fallas de servicio transitorias y permanentes. Los errores de Workflows pueden producirse, por ejemplo, por solicitudes HTTP, funciones o conectores fallidos, o bien generados por tu propio código de flujo de trabajo. Agrega control de errores y reintentos para que una falla en un paso no haga que falle todo el flujo de trabajo.

Algunas transacciones comerciales abarcan varios servicios, por lo que necesitas un mecanismo para implementar transacciones que abarquen varios servicios. El patrón de diseño de saga es una forma de gestionar la coherencia de los datos entre los microservicios en situaciones de transacciones distribuidas. Una saga es una secuencia de transacciones que publica un evento para cada transacción y que activa la siguiente. Si una transacción falla, la saga ejecuta transacciones de compensación que contrarrestan las fallas anteriores en la secuencia. Prueba el instructivo de reintentos y patrones de saga en flujos de trabajo en GitHub.

Usa devoluciones de llamada para esperar

Las funciones de devolución de llamada permiten que las ejecuciones de flujo de trabajo esperen a que otro servicio realice una solicitud al extremo de devolución de llamada. Esa solicitud reanuda la ejecución del flujo de trabajo.

Con las devoluciones de llamada, puedes indicarle a tu flujo de trabajo que se produjo un evento especificado y esperar a ese evento sin sondear. Por ejemplo, puedes crear un flujo de trabajo que te notifique cuando un producto vuelva a estar en stock o cuando se haya enviado un artículo, o que espere para permitir la interacción humana, como revisar un pedido o validar una traducción. También puedes esperar eventos con devoluciones de llamada y activadores de Eventarc.

Organiza trabajos de larga duración

Si necesitas ejecutar cargas de trabajo de procesamiento por lotes de larga duración, puedes usar Batch o trabajos de Cloud Run, y puedes usar flujos de trabajo para administrar los servicios. Esto te permite combinar las ventajas y aprovisionar y orquestar todo el proceso de manera eficiente.

Batch es un servicio completamente administrado que te permite programar, poner en cola y ejecutar cargas de trabajo por lotes en instancias de máquinas virtuales (VM) de Compute Engine. Puedes usar el conector de flujos de trabajo para por lotes para programar y ejecutar un trabajo por lotes. Para obtener más información, prueba el instructivo.

Los trabajos de Cloud Run se usan para ejecutar código que realiza trabajo (un trabajo) y se cierra cuando el trabajo finaliza. Los flujos de trabajo te permiten ejecutar trabajos de Cloud Run como parte de un flujo de trabajo para realizar procesamientos de datos más complejos o organizar un sistema de trabajos existentes. Prueba el instructivo en el que se muestra cómo usar Workflows para ejecutar un trabajo de Cloud Run.

Cómo crear contenedores para tareas de larga duración

Puedes automatizar la ejecución de un contenedor de larga duración con flujos de trabajo y Compute Engine. Por ejemplo, puedes contenedorizar una tarea de larga duración para que se ejecute en cualquier lugar y, luego, ejecutar el contenedor en una VM de Compute Engine durante la duración máxima de una ejecución de flujo de trabajo (un año).

Con Workflows, puedes automatizar la creación de la VM, la ejecución del contenedor en la VM y la eliminación de la VM. Esto te permite usar un servidor y ejecutar un contenedor, pero abstrae la complejidad de administrar ambos, y puede ser útil si tienes limitaciones de tiempo cuando usas un servicio como las funciones de Cloud Run o Cloud Run. Prueba el instructivo sobre contenedores de larga duración con Workflows y Compute Engine en GitHub.

Ejecuta herramientas de línea de comandos desde Workflows

Cloud Build es un servicio que ejecuta tus compilaciones en Google Cloud como una serie de pasos de compilación, en los que cada paso de compilación se ejecuta en un contenedor de Docker. La ejecución de pasos de compilación es similar a la ejecución de comandos en una secuencia de comandos.

Google Cloud CLI incluye las herramientas de línea de comandos de gcloud, bq y kubectl, pero no hay una forma directa de ejecutar comandos de gcloud CLI desde Workflows. Sin embargo, Cloud Build proporciona imágenes de contenedor que incluyen la CLI de gcloud. Puedes ejecutar comandos de gcloud CLI en esos contenedores desde un paso de Cloud Build, y puedes crear ese paso en Workflows con el conector de Cloud Build.

Ejemplo

Ejecuta gcloud en un flujo de trabajo:

# This example shows how to execute gcloud commands from Workflows
# using Cloud Build and returns the output

main:
  steps:
  - execute_command:
      call: gcloud
      args:
          args: "workflows list"
      result: result
  - return_result:
      return: ${result}

gcloud:
  params: [args]
  steps:
  - create_build:
      call: googleapis.cloudbuild.v1.projects.builds.create
      args:
        projectId: ${sys.get_env("GOOGLE_CLOUD_PROJECT_ID")}
        parent: ${"projects/" + sys.get_env("GOOGLE_CLOUD_PROJECT_ID") + "/locations/global"}
        body:
          serviceAccount: ${sys.get_env("GOOGLE_CLOUD_SERVICE_ACCOUNT_NAME")}
          options:
            logging: CLOUD_LOGGING_ONLY
          steps:
          - name: gcr.io/google.com/cloudsdktool/cloud-sdk
            entrypoint: /bin/bash
            args: ${["-c", "gcloud " + args + " > $$BUILDER_OUTPUT/output"]}
      result: result_builds_create
  - return_build_result:
      return: ${text.split(text.decode(base64.decode(result_builds_create.metadata.build.results.buildStepOutputs[0])), "\n")}

Run kubectl in a workflow:

# This example shows how to execute kubectl commands from Workflows
# using Cloud Build and returns the output

main:
  steps:
  - execute_command:
      call: kubectl
      args:
          args: "--help"
      result: result
  - return_result:
      return: ${result}

kubectl:
  params: [args]
  steps:
  - create_build:
      call: googleapis.cloudbuild.v1.projects.builds.create
      args:
        projectId: ${sys.get_env("GOOGLE_CLOUD_PROJECT_ID")}
        parent: ${"projects/" + sys.get_env("GOOGLE_CLOUD_PROJECT_ID") + "/locations/global"}
        body:
          serviceAccount: ${sys.get_env("GOOGLE_CLOUD_SERVICE_ACCOUNT_NAME")}
          options:
            logging: CLOUD_LOGGING_ONLY
          steps:
          - name: gcr.io/cloud-builders/kubectl
            entrypoint: /bin/bash
            args: ${["-c", "kubectl " + args + " > $$BUILDER_OUTPUT/output"]}
      result: result_builds_create
  - return_build_result:
      return: ${text.split(text.decode(base64.decode(result_builds_create.metadata.build.results.buildStepOutputs[0])), "\n")}

Usa Terraform para crear tu flujo de trabajo

Terraform es una herramienta de infraestructura como código que te permite crear, cambiar y mejorar de forma predecible tu infraestructura de nube mediante código.

Puedes definir e implementar un flujo de trabajo con el recurso google_workflows_workflow de Terraform. Para obtener más información, consulta Crea un flujo de trabajo con Terraform.

Para ayudarte a administrar y mantener flujos de trabajo grandes, puedes crear tu flujo de trabajo en un archivo YAML independiente y, luego, importarlo a Terraform con la función templatefile, que lee un archivo en una ruta de acceso determinada y renderiza su contenido como una plantilla.

Ejemplo

  # Define a workflow
  resource "google_workflows_workflow" "workflows_example" {
    name            = "sample-workflow"
    region          = var.region
    description     = "A sample workflow"
    service_account = google_service_account.workflows_service_account.id
    # Import main workflow YAML file
    source_contents = templatefile("${path.module}/workflow.yaml",{})
  }

Del mismo modo, si tienes un flujo de trabajo principal que llama a varios subflujos de trabajo, puedes definir el flujo de trabajo principal y los subflujos de trabajo en archivos separados y usar la función templatefile para importarlos.

Ejemplo

  # Define a workflow
  resource "google_workflows_workflow" "workflows_example" {
    name            = "sample-workflow"
    region          = var.region
    description     = "A sample workflow"
    service_account = google_service_account.workflows_service_account.id
    # Import main workflow and subworkflow YAML files
    source_contents = join("", [
      templatefile(
        "${path.module}/workflow.yaml",{}
      ),

      templatefile(
        "${path.module}/subworkflow.yaml",{}
      )])
  }

Ten en cuenta que, si te refieres a números de línea cuando depuras un flujo de trabajo, todos los archivos YAML importados a través del archivo de configuración de Terraform se combinan y se implementan como un solo flujo de trabajo.

Implementa un flujo de trabajo desde un repositorio de Git

Cloud Build usa activadores de compilación para habilitar la automatización de CI/CD. Puedes configurar activadores para detectar eventos entrantes, como cuando se empuja una confirmación nueva a un repositorio o cuando se inicia una solicitud de extracción y, luego, ejecutar automáticamente una compilación cuando lleguen eventos nuevos.

Puedes usar un activador de Cloud Build para iniciar automáticamente una compilación y, también, implementar un flujo de trabajo desde un repositorio de Git. Puedes configurar el activador para que implemente tu flujo de trabajo ante cualquier cambio en el repositorio de código fuente o solo cuando el cambio coincida con criterios específicos.

Este enfoque puede ayudarte a administrar el ciclo de vida de tu implementación. Por ejemplo, puedes implementar cambios en un flujo de trabajo en un entorno de etapa de pruebas, ejecutar pruebas en ese entorno y, luego, lanzar estos cambios de forma incremental en el entorno de producción. Para obtener más información, consulta Cómo implementar un flujo de trabajo desde un repositorio de Git con Cloud Build.

Optimiza el uso

El costo de ejecutar un flujo de trabajo es mínimo. Sin embargo, para el uso de alto volumen, aplica los siguientes lineamientos para optimizar el uso y disminuir el costo:

  • En lugar de usar dominios personalizados, asegúrate de que las llamadas a los servicios de Google Cloudusen *.appspot.com, *.cloud.goog, *.cloudfunctions.net o *.run.app para que se te facturen los pasos internos y no los externos.

  • Aplica una política de reintento personalizada que equilibre tus necesidades de latencia y confiabilidad con los costos. Los reintentos más frecuentes disminuyen la latencia y aumentan la confiabilidad, pero también pueden aumentar los costos.

  • Cuando uses conectores que esperan operaciones de larga duración, configura una política de sondeo personalizada que optimice la latencia en función del costo. Por ejemplo, si esperas que una operación demore más de una hora, te recomendamos que crees una política que, en un principio, sondee después de un minuto en caso de una falla inmediata y, luego, cada 15 minutos.

  • Combina las tareas en un solo paso.

  • Evita el uso excesivo de pasos sys.log. En su lugar, considera usar el registro de llamadas.

Resumen de prácticas recomendadas

En la siguiente tabla, se resumen las sugerencias generales y las prácticas recomendadas de este documento.

Sugerencias generales
Prácticas recomendadas

¿Qué sigue?