Los componentes de la nube son útiles y poderosos. Sin embargo, todos están desconectados de los demás y cuando desee implementar una tubería completa, debe pegarlos . Puede lograr esto con PubSub y Cloud Functions.
Sin embargo, rápidamente se convierte en un diseño de espagueti con muchos temas y funciones. Tener un lugar centralizado para ver, administrar y configurar el flujo de trabajo de su canalización podría ser excelente.
Flujos de trabajo de Google
Los flujos de trabajo de Google se llevan a cabo aquí. Se anunció desde el verano de 2020 en Cloud Next on Air y ahora está disponible en general (GA) desde enero de 2021. Es una solución totalmente administrada con un modelo de pago por uso . Es una solución más liviana (y muy menos costosa) para Cloud Composer, basada en Apache Airflow. Y lo suficientemente lejos para muchos casos de uso y muy prometedor para el futuro .
Guillaume Laforge (promotor de desarrolladores de Google Cloud) ya ha compartido su viaje sobre los flujos de trabajo . Y con Mete Atamel (también Google Cloud Developer Advocate), han lanzado una excelente publicación de blog .
Así que el tema ya ha sido bien cubierto y documentado .
Sin embargo, falta una pieza: la capacidad de paralelizar los pasos en un flujo de trabajo.
Paralelización experimental
Estuve involucrado en el programa Alpha y una de las principales solicitudes de los evaluadores fue la paralelización de llamadas. Se ha colocado entre las principales prioridades del equipo de desarrollo. Sin embargo, a día de hoy aún no está completamente implementado y solo tenemos una característica experimental que podemos usar: el mapa de ejecución .
En este componente, debe hacer referencia
- Un ID de flujo de trabajo al que desea llamar. Lo llamaré "flujo de trabajo invocable".
- Una serie de argumentos . Cada entrada en la matriz es una invocación del "flujo de trabajo invocable" , en paralelo
- Opcionalmente, puede especificar la ubicación y el ID del proyecto si el "flujo de trabajo invocable" no está en la misma región y / o el proyecto.
Como puedes imaginar, por diseño, hay 2 "limitaciones"
- Debe crear otro flujo de trabajo invocable para utilizar el mapa de ejecución. No puede llamar directamente a la API que desea.
- Debe utilizar el mismo flujo de trabajo invocable , solo los parámetros son diferentes para cada llamada en paralelo. No puede paralelizar diferentes flujos de trabajo invocables , siempre es lo mismo con los parámetros personalizados.
En realidad, ya no es una limitación, consulte la sección Flujos de trabajo avanzados para ver las soluciones.
De todos modos, probémoslo por primera vez.
Primera ejecución paralela
Para probar la paralelización de las ejecuciones, necesitamos realizar una llamada que lleve más o menos tiempo . En el caso de uso del mundo real, puede imaginar varias consultas de BigQuery en paralelo , cada una con un tiempo de ejecución diferente.
Entonces necesitamos crear un flujo de trabajo invocable para usar esta aplicación.
Y finalmente para crear un flujo de trabajo con la función experimental del mapa de ejecución.
Implementar la aplicación Go Sleepy
Para esperar más o menos tiempo, creé una aplicación Go simple que duerme de acuerdo con el parámetro de consulta proporcionado aw (en segundos).
Puedes encontrarlo en el repositorio de Github. Clonarlo y ejecutar este comando
gcloud beta ejecutar deploy --source =. --region = us-central1 \
--platform = managed --allow-unuthenticated sleepy-app
Obtenga la URL del servicio Cloud Run proporcionada al final de la implementación.
Crea el flujo de trabajo invocable
Este flujo de trabajo invocable es muy simple. Llama al servicio Cloud Run con el parámetro proporcionado en el argumento (nombre, espere aquí) e imprime el resultado.
principal:
params: [args]
pasos:
- callSleepyApp:
llamar: http.get
argumentos:
url:
consulta:
w: $ {args.wait}
resultado: resultado
- returnOutput:
retorno: $ {resultado}
Reemplazar
Y despliegue el flujo de trabajo
gcloud workflows deploy --source = workflow / run-long-process.yaml \
--location = us-central1 run-long-process
En el repositorio de GitHub, los archivos de flujo de trabajo están en el directorio de flujo de trabajo . Adapte el comando según la estructura de su proyecto
Ejecute flujos de trabajo en paralelo
Finalmente, el mapa de ejecución. Como se describe, necesita el ID de flujo de trabajo invocable (en este caso, run-long-process) y proporcionar el argumento correcto.
principal:
pasos:
- ejecutor paralelo:
llamar: experimental.executions.map
argumentos:
workflow_id: ejecutar-proceso largo
argumentos: [{"espera": 5}, {"espera": 10}, {"espera": 15}]
resultado: resultado
- returnOutput:
retorno: $ {resultado}
Y despliegue el flujo de trabajo
Implementación de flujos de trabajo de gcloud --source = workflow / paralelo-ejecutor.yaml \
--location = us-central1 paralelo-ejecutor
Ahora puede probarlo, a través de la interfaz de usuario o por CLI
Los flujos de trabajo de gcloud ejecutan el ejecutor paralelo
Al final, puede ver que obtiene una matriz de resultados de cada una de las llamadas en el orden en que las definió en el parámetro . No importa cuál haya terminado primero, el orden de los argumentos se respeta en el resultado
Flujos de trabajo avanzados
En realidad, es bastante simple de usar, pero no perfecto. Como se mencionó anteriormente, puede tener algunas limitaciones para casos de uso avanzados y propongo soluciones .
Llamar a una URL diferente en paralelo
Un caso de uso es la capacidad de llamar a diferentes URL en paralelo . Para esto, una de las soluciones es envolver la llamada a la API en un " flujo de trabajo invocable" con parámetros apropiados como este
principal:
params: [args]
pasos:
- prepareQuery:
cambiar:
- condición: $ {"consulta" en argumentos}
asignar:
- consulta: $ {args.query}
- condición: verdadera
asignar:
- consulta: nulo
- callCustomUrl:
llamar: http.get
argumentos:
url: $ {args.url}
consulta: $ {consulta}
resultado: resultado
- returnOutput:
retorno: $ {resultado}
Puede observar el paso prepareQuery que permite a las personas que llaman no pasar algunos parámetros (aquí el parámetro de consulta).
Este flujo de trabajo es un ejemplo que puede adaptar a su caso de uso. El valor de la llamada puede ser diferente, se puede pasar un cuerpo al paso callCustomUrl,…
Luego, tienes el mapa de ejecución que puede ser similar a este, con o sin el parámetro de consulta
principal:
pasos:
- ejecutor paralelo:
llamar: experimental.executions.map
argumentos:
workflow_id: custom-api-call
argumentos: [{"url": ""," consulta ": {" w ": 5}}, {" url ":" https://www.google.com "}]
resultado: resultado
- logStep:
llamar: sys.log
argumentos:
texto: $ {resultado}
severidad: INFO
- returnOutput:
retorno: $ {resultado}
Llame a diferentes flujos de trabajo invocables en paralelo
En otro caso de uso, desea llamar a diferentes "flujos de trabajo invocables" con diferentes argumentos . Aquí nuevamente, la idea es ajustar la llamada a un "flujo de trabajo invocable" específico en un " flujo de trabajo invocable".
Ok, suena como muñecas rusas pero es una solución alternativa a una función experimental, que usa otra opción experimental: execution.run
principal:
params: [args]
pasos:
- callCustomWorkflow:
llamar: experimental.executions.run
argumentos:
workflow_id: $ {args.workflow}
argumento: $ {args.argument}
resultado: resultado
- returnOutput:
retorno: $ {resultado}
Luego, puede llamar a este contenedor desde un mapa de ejecución, combinado con los flujos de trabajo existentes anteriores.
principal:
pasos:
- ejecutor paralelo:
llamar: experimental.executions.map
argumentos:
workflow_id: flujo de trabajo personalizado
argumentos: [{"workflow": "run-long-process", "argument": {"wait": 5}}, {"workflow": "custom-api-call", "argument": {"url" : ""," consulta ": {" w ": 5}}}]
resultado: resultado
- returnOutput:
retorno: $ {resultado}
Puede encontrar las instrucciones para implementar y probar este archivo README.ms ubicado en el repositorio de GitHub.
Solo el comienzo
Como se dijo en la introducción, el producto es muy nuevo pero ya en GA y muy prometedor.
Algunas soluciones no están perfectamente incluidas ni integradas, pero puede lograr una gran cantidad de casos de uso sin demasiadas limitaciones y restricciones .
Sin embargo, en estas características experimentales específicas, tenga en cuenta que son experimentales y pueden romperse o eliminarse en el futuro. ¡Pero para una mejor solución, estoy seguro!
Las ejecuciones paralelas con Google Workflows se publicaron originalmente en Google Cloud - Community on Medium, donde las personas continúan la conversación destacando y respondiendo a esta historia.