Prácticas recomendadas para flujos de trabajo

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 básicos sobre cómo usar Workflows. En este documento, se supone que ya tienes una comprensión general del panorama general de Google Cloud y de Workflows. Para obtener más información, consulta la Framework de la arquitectura de Google Cloud y Descripción general de los flujos de trabajo.

Selecciona un patrón de comunicación óptimo

Cuando diseñas una arquitectura de microservicios para implementar varios servicios, puedes seleccionar 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 las ventajas y desventajas de cada una de las opciones anteriores. y selecciona un patrón óptimo para tu caso de uso. Por ejemplo, la comunicación servicio a servicio podría ser más fácil de implementar que otras opciones, pero acopla estrechamente tus servicios. Por el contrario, una arquitectura controlada por 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 organizador central como Workflows, mientras menos flexible, te permite coordinar la comunicación entre servicios sin la acoplamiento alto de la comunicación directa de servicio a servicio o la complejidad de eventos coreografiados.

También puedes combinar patrones de comunicación. Por ejemplo, en los controles de eventos los servicios estrechamente relacionados se gestionan en una organización que se activa con un evento. De forma similar, podrías diseñar un sistema donde una organización dé como resultado un mensaje de Pub/Sub a otro un sistema organizado.

Sugerencias generales

Una vez que hayas decidido usar Workflows como tu organizador de servicios, ten en cuenta los siguientes consejos útiles.

Evita codificar las URLs

Puedes admitir flujos de trabajo que son portátiles en varios entornos y y más fáciles de mantener, ya que evita las URLs codificadas. Puedes lograr esto de la siguiente manera:

  • Definir 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 flujo de trabajo único archivo de definición, pero puedes implementar variantes con una herramienta que reemplace 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 una 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.

    O bien, puedes usar Terraform aprovisionar tu infraestructura y definir un archivo de configuración que crea flujos de trabajo para cada entorno mediante 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

Usar Workflows para llamar a servicios desde el flujo de trabajo mismo y manejar los resultados y ejecutar tareas simples, como realizar 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 las invocaciones adicionales, dependencias adicionales y servicios de llamadas a servicios. Considera reemplazar servicios libres de lógica empresarial mediante llamadas a la API y usos declarativos Workflows para abstraer la complejidad

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

Guarda solo lo que necesitas

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

Sé selectivo sobre lo que almacenas en variables, filtrar y almacenando 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:

Usar 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 rutinaria 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 flujos de trabajo de llamada 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

Workflows ofrece varios conectores para facilitar para acceder a otros productos de Google Cloud en un flujo de trabajo. Conectores simplifican los servicios de llamadas, ya que administran el formato de las solicitudes por ti. proporcionar métodos y argumentos para que no necesites conocer los detalles de un API de Google Cloud. Los conectores también tienen un comportamiento integrado para controlar reintentos y operaciones de larga duración para evitar Iterar y esperar a que se completen las llamadas conectores se encargarán de esto por ti.

Si necesitas llamar a una API de Google Cloud, primero verifica si Existe un conector de Workflows para esto. Y si no ves un para un producto de Google Cloud, puedes solicitarlo.

Más información para usar un conector y, para obtener una referencia detallada de los conectores disponibles, consulta la Referencia de los 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 los pasos del flujo de trabajo en paralelo.

Aplica reintentos y el patrón de saga

Diseñar flujos de trabajo que sean resilientes y que puedan manejar tanto flujos de trabajo transitorios como permanentes fallas del servicio. 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 se necesita un mecanismo para implementar transacciones que abarcan servicios. El patrón de diseño de la saga permite administrar la coherencia de los datos entre 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 la Instructivo de reintentos y patrón de Saga en Workflows 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 indicar al flujo de trabajo que un evento específico tiene y espera ese evento sin sondear. Por ejemplo, puedes crear un flujo de trabajo que te notifique cuando un producto vuelva a estar disponible. en stock o cuando se envía un artículo o que espera para permitir la interacción humana como revisar un pedido o validar una traducción. También puedes Esperar eventos mediante 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áquina virtual (VM). 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.

Crea contenedores para tareas de larga duración

Puedes automatizar la ejecución de un contenedor de larga duración usando Workflows 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, el la ejecución del contenedor en la VM y su eliminación. Esto te permite un servidor y ejecutar un contenedor, pero simplifica la complejidad administra ambos y puede ser útil si tienes limitaciones de tiempo al usar un servicio como Cloud Run Functions o Cloud Run. Prueba la 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 uno se ejecuta contenedor de Docker. La ejecución de pasos de compilación es similar a la ejecución de comandos en un 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 Cloud Build y puedes crearlo en Workflows con el comando 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 utilizar el 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, Los archivos YAML importados a través del archivo de configuración de Terraform se combinan implementarse como un flujo de trabajo único.

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 y configurar activadores para detectar eventos entrantes, como cuando se inicia 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 una compilación de forma automática e 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, puede implementar cambios en un flujo de trabajo en un entorno de etapa de pruebas, ejecutar pruebas ese entorno y, luego, implementar de forma incremental estos cambios 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 altos el uso del volumen, aplica los siguientes lineamientos para optimizar el uso y reducir los costos:

  • En lugar de usar dominios personalizados, asegúrate de que cualquier llamada a Google Cloud servicios usan *.appspot.com, *.cloud.goog, *.cloudfunctions.net o *.run.app para que se te facture por los pasos internos y no por los externos.

  • Aplica una política de reintento personalizada que equilibre tus necesidades de latencia y confiabilidad con los costos. Más frecuente reducen la latencia y aumentan la confiabilidad, pero también pueden aumentar los costos.

  • Cuando uses conectores que esperan operaciones de larga duración, establece un política de sondeo personalizada que optimiza la latencia según el costo. Por ejemplo, si esperas que una operación tome más de una hora, tal vez quieras una política que, inicialmente, sondea después de un minuto de un error inmediato y cada 15 minutos después de eso.

  • Combina las tareas en un solo paso.

  • Evita el uso excesivo de pasos de sys.log. Considera usar registro de llamadas.

Resumen de prácticas recomendadas

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

Sugerencias generales
Prácticas recomendadas

¿Qué sigue?