
Y continuamos hablando sobre Dapr. En este caso, sobre la extensión para Azure Functions que permite que una función interactúe con Dapr para crear aplicaciones nativas en Cloud. Con esta extensión, es posible unir ambos mundos: Serverless y Event-Driven que pueden usar las capacidades de Dapr.
En particular, construiremos dos funciones «QueueReader» y «EmailSender» para probar las distintas posiblidades que nos brinda Dapr: Read from a queue, State Store, Pub/Sub, Binding, Secrets and Service Invocation, hosteadas sobre AKS.
Nota: Actualmente, esta extensión está disponible para Kubernetes o IoT Edge sin embargo, no lo está para ser hosteada Azure Functions.
Como simpre, el código completo puedes encontrarlo aquí, en mi github y recuerda que en la Introducción a Dapr .NET SDK, ya vimos muchos de los puntos que trataremos en este post.
Este artículo se compone de dos posts. El primero es el que nos ocupa y el segundo aborda el despliegue de la solución a Kuberneetes/AKS:
- [ -> ] Dapr en Azure Functions (1/N)
- Dapr en Azure Functions (2/N): Deploy a Kubernetes/AKS.
Comenzaremos en este primero, ejecutando las siguientes instrucciones desde línea de comandos. ¡Tendremos que tener instalado dotnet y Azure Functions Core Tools!
mkdir hello-functions
cd hello-functions
func init hello-functions // select dotnet as worker runtime
dotnet add package Microsoft.Azure.WebJobs.Extensions.Storage
dotnet add package Dapr.AzureFunctions.Extension
func new QueueReader # QueueTrigger
func new EmailSender # ServiceBusTopicTrigger
A continuación, actualizamos el código de las funciones QueReader y EmailSender:
public static class QueueReader
{
[FunctionName("QueueReader")]
public static async Task Run(
[DaprBindingTrigger(BindingName = "queuebinding")] Data data,
[DaprState("statestore", Key = "{data.Id}")] IAsyncCollector<string> state,
[DaprPublish(PubSubName = "pubsub", Topic = "greatings")] IAsyncCollector<string> pubsub,
ILogger log)
{
log.LogInformation($"C# Queue trigger function initiated");
await state.AddAsync(data.Name);
await pubsub.AddAsync(data.Name);
log.LogInformation($"C# Queue trigger function processed: {data.Name}");
}
}
public static class EmailSender
{
[FunctionName("EmailSender")]
public static async Task<IActionResult> Run(
[DaprTopicTrigger("pubsub", Topic = "greatings")] CloudEvent @event,
[DaprSecret("secretstore", "sampleKey")] IDictionary<string, string> secret,
[DaprBinding(BindingName = "mail", Operation = "create")] IAsyncCollector<DaprBindingMessage> mailer,
ILogger log)
{
log.LogInformation($"C# ServiceBus topic trigger function initiated");
var msg = $"Just a sample: User '{@event.Data}' are using '{secret["sampleKey"]}' key.";
var content = new InvokeMethodParameters()
{
Body = msg
};
await invoke.AddAsync(content);
await mailer.AddAsync(new DaprBindingMessage(msg);
log.LogInformation($"Email Sender end !");
return new OkResult();
}
}
En cuanto a los componentes dapr, básicamente se trata de los mismos que ya vimos en la introducción a Dapr, a excepción del envío de email con Twilio – SendGrid, que pasa a ser el siguiente:
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
name: mail
spec:
type: bindings.twilio.sendgrid
metadata:
- name: emailFrom
value: "<TU-EMAIL-FROM>"
- name: emailTo
value: "<TU-EMAIL-TO>"
- name: subject
value: "Dapr using azure functions"
- name: apiKey
secretKeyRef:
name: sendgridKey
auth:
secretStore: secretstore
Twilio SendGrid
Para configurar el envío de emails usando SendGrid seguimos estos pasos:
- Desde el Portal de Azure creamos un nuevo recurso Twilio – SendGrid y completamos el progreso al igual que para crear cualquier otro recurso de Azure. ¡Eso si, e trata de un proveedor externo por lo que al final saldrás del Portal de Azure para su configuración!
- Seleccionamos el plan gratuito
- Completado el proceso, accedemos a esta url : https://app.sendgrid.com/ y,
- Creamos y configuramos un Sender Identity y,
- Un nuevo APIKey tal y como se muestra en la siguiente imagen.

- En nuestro Key Vault intoducimos un nuevo secret «sendGrindKey» con el valor del APIKey obtenido en el paso anterior.
- Adicionalmetne, introducimos un nuevo secret «sampleyKey» con un valor cualquiera. ¡Se trata simplemente de conocer el acceso y uso de este secret de manera explicita desde nuestra azure function.!
En lo que respecta a la configuración del componente de Key Vault (secrets.yaml), necesitamos el spnClientId, para lo que tenemos que ejecutar desde linea de comandos la siguiente instrucción.
az ad sp list --display-name ServicePrincipal
Asi como esta otra para descargar el certificado (.pfx). El path donde lo descarguemos debe coincidir con el valor/ruta que demos a la propiedad spnCertificateFile, en el fichero «secrets.yaml«.
az keyvault secret download --vault-name <KEY-VAULT-NAME> --name CertName --encoding base64 --file c:\users\<USER-NAME>\<FILE-NAME>.pfx
Una vez completado estos puntos, ya tenemos listo todos los componentes Dapr. ¡ De los que no hemos hablado, recueda que tienes todo su detalle en github y ya lo comentamos en posts antriores!:

Ejecutando la aplicación
Ahora que ya tenemos todo configurado y tenemos todas las piezas, veamos como es el flujo y como funciona nuestra aplicación según la arquitectura planteada:
- En primer lugar, DaprBindingTrigger, permanece escuchando en la cola para leer cualquier mensaje que depositemos en la misma.
- DaprState permite almacenar el mensaje obtenido de la cola en el Table Storage de Azure.
- DaprPublish, publica un mensaje en el Azure Service Bus, para poder comunicarse así, con la siguiente función EmailSender.
- DaprTopicTrigger. Recoge el mensaje enviado por la función QueueReader, en concreto en «name».
- DaprSecret. Obtiene del Key Vault la clave sampleKey para usarla en el mensaje a envíar.
- DaprBinding. Utiliza el componente Dapr mail (mail.yaml), que a su vez hace uso del secreto sendgridKey (de Key Vault), para obtener el ApiKey de SendGrid y hacer el envío del email, a la dirección de email configurada también en dicho componente.
Finalmente, para ponerlo to en marcha:
- Introducimos el siguiente mensaje en la cola de Azure Storage, vía «Microsoft Azure Storage Explorer» (versión web) o bien desde la sección «Data Storage – Queues», ambas opciones en el Portal de Azure.
{
"id": 1,
"name" : "Juanlu"
}
- Y nos aseguramos de desmarcar la casilla «Encode the message body in Base64«.

- Ejecutamos el siguiente comando para poner en ejecución ambas funciones y comienza «el juego».
dapr run --app-id hello-functions --dapr-http-port 3501 -p 3001 --components-path .\dapr\components -- func host start
Todas la piezas se ponen en marcha y finalmente el email es enviado.



No dejes de probar esta arquitectura, creo que es un buen ejemplo para probar la mayoria de los binding/trigger de Dapr en Azure Functions y entender todo su funcionamiento.
Happy #Dapr coding !!
Reblogueó esto en El Bruno.
Me gustaMe gusta