En este nuevo post sobre Dapr vamos a ver como integrarnos con Azure API Management (APIM).
Para ello y, como viene siendo habitual, usaremos uno de los ejemplos ya conocidos (de acuerdo a posts anteriores), y, en concreto, el ya publicado en github (AllTogether).
Antes de comenzar, es conveniente recordar que Azue API Mangement dispone de la opción «Self-hosted gateway«, lo que permite ampliar la compatibilidad con entornos Híbridos y MultiCloud. Permite administrar el hosting de APIs en entornos on-premisse, por lo que es posible contar con este «Selft-hosted gateway» en el mismo entorno (o cluster kubernetes/AKS) donde se encuentren desplegadas nuestras APIs. Esto es posible gracias a la existencia de una versión containerizada de API Management Gateway.
Por tanto, cuando hablamos de Azure API Management, hablamos de estos tres componentes (no sólo de los dos primeros que quizás son los mas conocidos):
- Management plane. Permite para exponer y configurar APIs tanto propias como de terceros. Su configuración se lleva a cabo mediante Azure Portal, PowerShell, AZ-CLI entre otros mecanismos.
- Developer Portal. Permite a los desarrolladores descubrir, conocer y usar las APIs expuestas.
- Gateway. Responsable de redirigir mediante proxy las solicitudes de API y también de la aplicación de directivas/politicas (o policies) y la recopilación de datos de telemetría
Configurando Self-hosted gateway
Veamos a continuación como configurar y desplegar el «Self-hosted gateway» en nuestro Cluster de Kubernetes (AKS).
- Comenzaremos siguiendo algunos sencillos pasos indicados en este post (Deploy to Kubernetes Service). Entre los cuales, destacamos este primero:
- Importante y, para evitar algún que otro inconveniente, asegurar que el nombre que indicamos al crear un nuevo gateway es en minusculas.
- Incluir/seleccionar las APIs a usar por el Gateway.
- Finalmente, tenemos estos dos últimos pasos indicados en la siguiente imagen:
Donde disponemos de dos comandos «kubectl».
- El primero de ellos para genera un secret y,
- el segundo para realizar el deploy de nuevos componentes en el Cluster: ConfigMap, Deployment y Service.
Completados estos pasos podemos decir que nuestro cluster está integrado con los dos servicios/apis que necesita la aplicación, si bien, antes de ejecutar los dos comandos anteriores y, para la integración con Dapr, necesitamos hacer algun ajuste y, en concreto, como ya vimos en este post, añadir las «annotations» pertinentes.
annotations:
dapr.io/enabled: "true"
dapr.io/app-id: "alltogether"
dapr.io/config: "tracing"
dapr.io/log-as-json: "true"
dapr.io/log-level: "debug" Para más detalle, en github, tenemos el fichero «APIM-alltogether.yaml» completo.
Finalmente comprobamos que todo está configurado correctametne echando un vistado al estado estado del gateway en la pestaña «Overview»:
Configuración de APIs y Directivas/Policies
Ahora que ya tenemos todo configuración, procederemos a configurar nuestro APIM de manera habitual.
En primer lugar creamos las APIs mediante cualquiera de las opciones. Para nuestro caso, navegamos a la ruta «/swagger» para cada servicios CounterService y WeatherService, (https://localhost:5004/swagger y https://localhost:5005/swagger respectivamente) y descargamos los «.json», que luego importamos como podemos ver en la siguiente imagen.
Nota: Recordemos que puedemos usar «Swagger Editor» para el diseño/documentación de cada una de las apis e incluso autogenerar el código. Así mismo, también podemos convertir a «.yaml» nuestros .json a la vez que realizamos algunas comprobaciones.
Si quieres profundizar un poco mas sobre la implementación de OpenAPI/Swagger en tus apis, no olvides echar un ojo a este otro post (OpenAPI en mi API Rest .NET)
El siguiente paso es crear las policies en APIM, que nos van a permitir el sidecar del gateway con el resto de sidecars.
CounterService:
<policies>
<inbound>
<base />
<publish-to-dapr pubsub-name="pubsub"
topic="CounterIncremented"
response-variable-name="pubsub-response">
@(context.Request.Body.As<string>())
</publish-to-dapr>
</inbound>
<backend>
<base />
</backend>
<outbound>
<base />
</outbound>
<on-error>
<base />
<return-response
response-variable-name="pubsub-response" />
</on-error>
</policies>WeatherService:
<policies>
<inbound>
<base />
<set-backend-service backend-id="dapr"
dapr-app-id="weatherservice"
dapr-method="weatherforecast" />
</inbound>
<backend>
<base />
</backend>
<outbound>
<base />
</outbound>
<on-error>
<base />
</on-error>
</policies>Ni que decir tiene que, que esta integración con Darp es solo una operación más dentro de las las policies de APIM, por loq ue podremos incluir tantas otras operaciones como consideremos.
Ejecutando la aplicación
Con la siguiente instrucción lanzamos localmente la aplicación web (website).
kubectl port-forward service/website 5000:80Navegamos a la url (http://localhost:5000), donde podemos comprobar que todo funciona como esperamos y así, también aseguramos que las policies de APIM se encuentran en ejecución.
Podría ocurrir, que los sidecar de los servicios funcionen y nos de la sensación de que el gateway esta funcionado, pero depués de hacer varias pruebas podremos corroborar, en el pestaña «Overview» una vez más, que gateway entra en el juego.
Adicionalmene, al igual que para el website, también podemos ejecutar el siguiente comando y lanzar el gateway localmente.
kubectl port-forward service/alltogether 6001:80De esta manera, podemos usar Posman para lanzar varias peticiones post a los servicios usando el gateway:
Por supuesto, si habilitamos Application Insight en APIM, tendremos mucho mas detalle e incluso una mejor depuración/diagnostico de lo que está pasando. En la siguiente imagen podemos ver, a modo de ejemplo varias peticiones, entre las cuales, aquellas con error previa configuración de Dapr.
Y, hasta aquí con este post. Espero que, una vez más hayas sido de utilidad.
Un saludo y happy #Dapr coding
Juanlu, ElGuerre 
Reblogueó esto en El Bruno.
Me gustaMe gusta