Post Top Ad

Your Ad Spot

sábado, 1 de agosto de 2020

AWS Lambda Destination Support

¿Qué son los destinos Lambda?

Primero escribimos sobre Lambda Destinations cuando AWS anunció soporte para ellos justo antes de re: Invent 2019.
Esencialmente, los destinos son la capacidad de las invocaciones asincrónicas de Lambda para enviar sus resultados de ejecución a otros servicios de AWS sin necesidad de esperar a que finalice la ejecución de Lambda. Anteriormente, tendría que esperar el éxito o el fracaso de Lambda o debería aprovechar algo como las funciones de paso. Ahora, puede invocar funciones de forma asincrónica y enviar los resultados de las invocaciones a diferentes lugares según el éxito o el fracaso.
¡Hoy, nos complace anunciar la compatibilidad con los destinos de Lambda en el marco sin servidor! Asegúrese de haber actualizado v1.66.0 o superior y veamos cómo agregarlos.
¡Puede ver el video a continuación para obtener una versión abreviada o leer toda la guía!

Agregar destinos Lambda

El primer paso para agregar destinos Lambda es decidir qué recursos le gustaría utilizar como destino en caso de éxito o fracaso. Actualmente, los destinos de eventos se pueden configurar como otra función de Lambda, un tema de SNS, una cola de SQS o Amazon EventBridge. Puede crear estos recursos en su serverless.ymlarchivo o puede hacer referencia a los ARN de recursos ya existentes.
Dentro de serverless.yml, agregará una destinationssección a una función con la que desea configurar destinos de eventos con:
1functions:
2  helloStarting:
3    handler: handler.starting
4    destinations:
5      onSuccess: someOtherFunction
6      onFailure: arn:of:some:existing:resource
Dentro de la destinationsconfiguración se puede añadir ya sea un onSuccessonFailureo ambos. El valor para esos bits de configuración puede ser otra función definida en el mismo serverless.ymlarchivo o un ARN del recurso de destino.
Ahora veamos algunos ejemplos de configuración. Puede encontrar servicios de ejemplo completos de los fragmentos a continuación en GitHub aquí .

Destinos de eventos de función del mismo servicio

Una de las formas más fáciles de configurar destinos de eventos con sus funciones de Lambda es consultar otras funciones de Lambda que ya está creando en su servicio en el mismo serverless.ymlarchivo. Por ejemplo, en el fragmento de abajo, la sección de funciones crea una helloStartingfunción que luego usa las funciones helloSuccesshelloFailurecomo destinos:
1functions:
2  helloStarting:
3    handler: handler.starting
4    destinations:
5      onSuccess: helloSuccess
6      onFailure: helloFailure
7  helloSuccess:
8    handler: success.handler
9  helloFailure:
10    handler: failure.handler
Esta configuración tiene la ventaja de crear un destino por etapa automáticamente a medida que implementa su servicio en etapas como devprod.

Destinos basados ​​en ARN

Si ya tiene recursos existentes para los destinos de su evento, también puede hacer referencia a ellos utilizando el valor ARN de esos destinos. Por ejemplo:
1functions:
2  helloStarting:
3    handler: handler.starting
4    destinations:
5      onSuccess: arn:aws:sqs:us-east-1:444455556666:successQueue
6      onFailure: arn:aws:lambda:us-east-1:444455556666:function:failureFunction
En el ejemplo anterior, ya hemos creado una cola SQS llamada successQueuey una función Lambda llamada failureFunctiony hemos configurado nuestra función para entregar eventos de éxito y falla a cada uno de ellos, respectivamente.
Sin embargo, hay un problema potencial con este tipo de configuración. Es posible que no desee enviar notificaciones de éxito y error para cada etapa de la aplicación al mismo lugar. Echemos un vistazo a al menos una forma de solucionar esto.

Destinos basados ​​en etapas

Si desea destinos separados según la etapa de su servicio, puede utilizar algunos métodos diferentes para lograrlo.

Parámetros de Framework Pro

Una de las formas más simples de lograr esto sería aprovechar los parámetros de Framework Pro y cargarlos en el momento de la implementación:
1org: fernando
2app: destinations
3service: stage-based-destinations-framework-pro
4
5provider:
6  name: aws
7  runtime: python3.8
8
9functions:
10  helloStarting:
11    handler: handler.starting
12    destinations:
13      onSuccess: ${params:SUCCESS_ARN}
14      onFailure: ${params:FAILURE_ARN}
De esta manera, el marco cargará el parámetro relevante en el momento de la implementación desde Framework Pro .

Variables de etapa en destinos de eventos

También puede renunciar a Framework Pro y crear recursos de destinos con el escenario como parte de su nombre. Por ejemplo, una cola de destino para mensajes de éxito en la devetapa podría convertirse successQueue-devy en producción successQueue-prodLuego, puede crear el ARN final en el momento del despliegue según la etapa:
1provider:
2  name: aws
3  runtime: python3.8
4  stage: ${opt:stage, 'dev'}
5
6functions:
7  helloStarting:
8    handler: handler.starting
9    destinations:
10      onSuccess: arn:aws:sqs:us-east-1:444455556666:successQueue-${self:provider.stage}
11      onFailure: arn:aws:sns:us-east-1:444455556666:failureTopic-${self:provider.stage}
Este tipo de configuración supone que ya ha creado todos los recursos necesarios para configurar con los destinos.

Probar los destinos

Entonces, ¿cómo probaríamos uno de estos ejemplos?
Primero, clone el repositorio de ejemplos de GitHub aquí . Hay varios ejemplos en ese repositorio, pero cambie los directorios al arn-based-event-destinationse iremos desde allí.
Primero, podemos crear una sola cola SQS para que terminen los eventos de falla y éxito.
  1. Ejecutar aws sqs create-queue --queue-name destinationQueuepara crear una cola
  2. Luego, copie la URL de la cola de salida en el siguiente comando para obtener la QueueArn:
    aws sqs get-queue-attributes \
    --queue-url <the-queue-url> \
    --attribute-names QueueArn```
    
Ahora que tenemos el valor ARN, reemplace los ARN existentes onSuccessonFailuredentro del serverless.ymlarchivo. Deberías terminar con algo como esto:
1service: arn-based-destinations
2
3provider:
4  name: aws
5  runtime: python3.8
6
7functions:
8  helloStarting:
9    handler: handler.starting
10    destinations:
11      onSuccess: arn:aws:sqs:us-east-1:123456777888:successQueueDemo
12      onFailure: arn:aws:sqs:us-east-1:123456777888:successQueueDemo
Desde aquí, podemos correr serverless deploypara configurar todo. Cuando finaliza la implementación, podemos invocar nuestra función con eventos que harán que la función tenga éxito y falle y luego revisar los resultados en la cola SQS.
Ejecute esto varias veces para crear algunos eventos exitosos:
1aws lambda invoke --function-name arn-based-destinations-dev-helloStarting --invocation-type Event --payload '{ "Success": true }' response.json
Luego, puede ejecutar esto varias veces para causar algunas fallas:
1aws lambda invoke --function-name arn-based-destinations-dev-helloStarting --invocation-type Event --payload '{ "Success": false }' response.json
Si ha cambiado el servicio o el nombre de la función antes de implementar, deberá asegurarse de actualizar el --function-namevalor en los comandos.
Cuando haya terminado, puede revisar los resultados en la cola que creó. Deberá reemplazarlos <queueUrl>con su URL de cola en el siguiente comando:
1aws sqs receive-message --queue-url <queueUrl> --attribute-names All --message-attribute-names All --max-number-of-messages 10
Si necesita la url, siempre puede ejecutar el aws sqs list-queuescomando. Es posible que los mensajes tarden un momento en llegar a la cola SQS, pero cuando estén allí, debería ver algo como esto:
{
    "Messages": [
        {
            "MessageId": "169e1a5a-7200-4df9-9cf2-46fbde04af79",
            "ReceiptHandle": "AQEBFnz9cRqIrl2XGFilWVyBXSUlA3mHYvwzsk5Yi1781G9txOpxLTpadribqYKs3DBi0DBL3skv5wRfVJKCQxVCoZ6Lh7Bd/qBBjyg359qc5910HPy07wbWhAYbaE6S2ZhHAsIjmiBf9cfk7/yu8IhFvstVlycYCZ0BM7Ca6DN29O0mN5PHBSdEsA4dLZ172irtzAM9jOc8n9vS3lBfvfCbRjpMJylPTMoMdlE/uvB8RpJC4FkXtLwxHRP+d0WvbO0VsMt+z/dgJk5z0ORfmZlu94RpIHZ4+PoyLja35e43eAGGjHyqRQCpCIROrI2c3tvjRkUknFHTFtYqvGFs4Jj7OVHJ2D9riDHDLBhVjvGDCzMbSHWdnyOqVeojIyarh6nFKJb/iXE6hrTX3zNslE/kDQ==",
            "MD5OfBody": "332ed48526ab22a68a161b100f83a4bc",
            "Body": "{\"version\":\"1.0\",\"timestamp\":\"2020-03-09T22:01:53.075Z\",\"requestContext\":{\"requestId\":\"cabbfbd0-e266-42a9-a52e-6e96eb16c695\",\"functionArn\":\"arn:aws:lambda:us-east-1:757370802528:function:arn-based-destinations-dev-helloStarting:$LATEST\",\"condition\":\"RetriesExhausted\",\"approximateInvokeCount\":3},\"requestPayload\":{ \"Success\": true },\"responseContext\":{\"statusCode\":200,\"executedVersion\":\"$LATEST\",\"functionError\":\"Unhandled\"},\"responsePayload\":{\"errorMessage\": \"name 'body' is not defined\", \"errorType\": \"NameError\", \"stackTrace\": [\"  File \\\"/var/task/handler.py\\\", line 8, in starting\\n    \\\"body\\\": json.dumps(body)\\n\"]}}",
            "Attributes": {
                "SenderId": "AROA3AVWRKFQPTOBYHBI4:awslambda_212_20200309184354940",
                "ApproximateFirstReceiveTimestamp": "1583791332207",
                "ApproximateReceiveCount": "1",
                "SentTimestamp": "1583791313178"
            }
        }
    ]
}
¡Y eso es! Ha configurado y probado con éxito sus Destinos de eventos.

¿Ahora que?

Ahora que ha configurado su primer destino de eventos, puede usarlos para salvarse de las arquitecturas que tienen que esperar a que Lambda Functions finalice su invocación y luego devuelva una respuesta. Esto significa que puede evitar situaciones en las que una función no hace nada y espera que el servicio o la función a la que llamó responda. En su lugar, puede usar los Destinos de eventos para procesar cualquier éxito o fracaso una vez que la Función Lambda haya hecho su trabajo.
Si no tiene suficiente diversión con el ejemplo anterior, o los otros ejemplos en GitHub , también hay un montón de otras maneras de configurar Recursos de destino de eventos! Usted puede:
  1. Almacene los valores ARN en SSM y extráigalos con la sintaxis variable SSM: ${ssm:paramName}
  2. Haga referencia a las salidas ARN de otros servicios con Framework Pro Outputs y la sintaxis variable de salidas:${output:my-service.myOutputKey}
¡Esperamos que esto lo ayude a comenzar con los Destinos de eventos en el Marco sin servidor! ¿Tiene preguntas sobre los destinos de eventos? ¡Ponte en contacto o deja un comentario a continuación!

No hay comentarios.:

Publicar un comentario

Dejanos tu comentario para seguir mejorando!

outbrain

Páginas