WSO2 API Microgateways en cloud con Azure AKS

(1 votos, promedio: 5,00 de 5)

Cargando…

Hoy en día, cualquier departamento de IT es consciente del gran número de aplicaciones y servicios existente, tanto dentro de nuestra organización, como fuera en otras organizaciones con la cuales colaboramos.

Ante el elevado número de APIs que estos elementos ofrecen, se nos plantea la necesidad de disponer de algún sistema que nos permita la gestión de este volumen de APIs.

Hace ya bastantes años, surgió WSO2 API Manager como una solución 100% open-source ya bastante consolidada y que da solución a este problema. Entre otras cosas, nos permite abordar con bastante solvencia todos los aspectos relacionados con la gestión de las APIs: el desarrollo y la publicación, la gestión del consumo, las herramientas para su descubrimiento y documentación de uso, el establecimiento de limitaciones de uso, la aplicación de políticas de seguridad, la gestión de uso para su comercialización como servicio y las herramientas necesarias para la monitorización y el análisis.

Analizando la arquitectura de la solución WOS2 API Manager, podemos identificar los siguientes componentes:

API Manager front end: son dos aplicaciones web que permiten a los desarrolladores crear nuevas APIS y publicarlas y por otro a los consumidores hacer uso de estas.
Key management: Componente para la seguridad de acceso y uso de las APIS.
Traffic management: Gestiona los límites de uso de las APIs
Monitoring/Analytics: Herramientas para la monitorización y el análisis de uso de las APIs
API Gateway (Runtime): Es el componente donde se ejecuta la API y que permite que esta haga su función para la cual ha sido diseñada: Recibe la llamada, se aplican el tratamiento a la información de entrada, se aplican las políticas configuradas, se llama a los servicios de back-ends y se devuelve el resultado al cliente.

Todas las APIs que hayan sido desarrolladas y publicadas, se encapsula en un artefacto que luego será desplegado y ejecutado dentro del mismo motor de ejecución, el cual denominamos API Gateway, luego, estas APIs podrán ser consumidas por los clientes.

¿Por qué aparece WSO2 API Microgateway y qué nos aporta?

WSO2 API microgateway surge como una derivada natural del componente monolítico API Gateway y ha sido diseñado con el propósito principal de adaptarse al nuevo paradigma de arquitectura microservicios-cloud.

Un API Microgateway, a diferencia de API Gateway, es un componente aislado, muy ligero, sin estado, con muy poco consumo de memoria y un arranque muy rápido. No depende de ningún otro componente para su ejecución. Es un motor independiente ejecución de artefactos de APIs que permite el proceso de mensajes de API, le aplica seguridad a nivel de mensaje y transporte, enrutado y políticas comunes relacionadas con la calidad del servicio.

Por tanto, API Microgateway nos ofrece todo lo necesario para un fácil desarrollo y despliegue de APIs en sistemas basados en las actuales arquitecturas distribuidas en microservicios y clouds.

Veamos algunos de los principales escenarios en los que se hace ideal el uso de WSO2 API Microgateway:

Integraciones de microservicios distribuidos y en cloud: son contenedores ligeros y que permiten flujos de automatización CI/CD.
Modernizar formatos de APIs legacy en formatos actuales.
Consumo de varios servicios expuestos como una sola API.
Descubrimiento de microservicios que cambien de IP en tiempo de ejecución como consecuencia de redespliegues.
Escalabilidad y actualización. Debido a que las microgateways se ejecutan de forma aislada y pueden ejecutarse sin dependencia de ningún otro sistema, permite ser escalados y actualizados, según la necesidad, de forma muy fácil.
Desarrollo contract-first: Usa el estándar, lo que permite para que los desarrolladores puedan diseñar, publicar y compartir las APIs fácilmente.
Arquitectura típica usando Microgateways.

Integración de WSO2 API Mcrogateway con WSO2 API Manager

Aunque WSO2 API Microgateway es un componente aislado e independiente, también están diseñado para su integración dentro de WSO2 API Manager si fuese necesario.

De este modo, podemos realizar una gestión integral de las APIs, independientemente de que sean implementadas como Microgateway o no. Además, de este modo, los contenedores API Microgateway no tendrán que renunciar a aspectos tan necesarios como los relacionados con el plano de la gestión de publicación y desarrollo o relativos al plano del control (seguridad, tráfico de mensajes, la monitorización y análisis de datos).

Ejecución de WSO2 API Microgateway en cloud Azure Kubernetes Service

En este apartado vamos a ver en detalle los pasos para desarrollar y desplegar un WSO2 API Microgateway. De entre todas las posibilidades existentes para desplegarlo, vamos a describir de forma detallada todo lo necesario para realizar un ciclo de desarrollo y despliegue en una arquitectura cloud IaaS.

Se podría aplicar a cualquier otra solución cloud como AWS o Google, pero en nuestro caso nos vamos a centrar en Azure Kubernetes Service (AKS).

Ilustración 1. Desarrollo usando servicios de Azure

El uso de una plataforma IaaS Cloud para el alojamiento de microservicios nos va a aportar un beneficio adicional, ya que nos abstrae de problemas subyacentes a la infraestructura y nos ayudará más aun a la escalabilidad y monitorización de la plataforma.

Pre-requisitos en el cloud de Azure

Partimos de la idea de que disponemos de un entorno Azure AKS operativo en nuestra suscripción cloud de Azure. Preparar esta infraestructura de Azure AKS podría ser objeto de otra entrada en el blog.

Nuestro entorno de ejemplo cuenta con los siguientes componentes:

Azure ACR. Repositorio de contenedores. Es un servicio de Azure basado en Docker. En nuestro ejemplo, su nombre es “WSO2LabsRegistry”.

Azure AKS. Es un servicio de Azure para generar la infraestructura de un clúster de Kubernetes. En nuestro ejemplo su nombre es “WSO2LabsAKSCluster”.

Controlador Ingress de NGINX desplegado en nuestro servicio Azure AKS. Los elementos Ingress de Kubernetes redirigen el tráfico HTTP y HTTPS desde el exterior del clúster de Kubernetes hacia los servicios configurados dentro éste, haciendo uso de reglas para balancear la carga de tráfico y redirigirla a los servicios de backend correspondientes. NGINX es uno de los más usados. En nuestro caso de ejemplo, tenemos configurado el controlador en el domain “ingress-basic”.

Las fases para el desarrollo con WSO2 API Migrogateway sería:

Ilustración 2. Fases usando los servicios de Azure

Preparación del entorno

Lo primero que vamos a hacer es preparar nuestro entorno de desarrollo con todo lo necesario.

Instalación del toolkit para desarrollo de WSO2 API Microgateway: Nos descargamos e instalamos micro-gw toolkit de WSO2. Para su correcto funcionamiento debemos tener instalado Java en nuestro entorno y añadir la ruta al PATH.
Instalación un repositorio local Docker. Donde almacenaremos las imágenes de los contenedores API Microgateway que vayamos desarrollando antes de su despliegue en Azure AKS.
Instalación de un cliente de Kubernetes. Necesario para poder realizar los despliegues de las imágenes de las API en Azure AKS.

Desarrollo. Especificación usando Open API

En este paso ser realiza la especificación de la API. En este ejemplo sencillo, vamos a generar una API que aplicar seguridad a un servicio de ejemplo de uso libre (https://restcountries.eu) que no tiene seguridad y que actuará como nuestro servicio de back-end. La siguiente configuración aplica una seguridad “apikey” a la API. Además, sólo vamos a exponer una única operación (all), ocultando las restantes.

def-secure-countries.yaml

openapi: 3.0.1

info:

title: REST COUNTRIES

description: ‘Get information about countries via a RESTful API’

termsOfService: https://www.mozilla.org/en-US/MPL/2.0/

license:

url: https://www.mozilla.org/en-US/MPL/2.0/

version: 2.0.5

externalDocs:

description: More information

url: http://restcountries.eu/

servers:

– url: https://restcountries.eu/rest/v2

– url: http://restcountries.eu//rest/v2

tags:

– name: ALL

description: All countries

externalDocs:

description: More information

url: http://restcountries.eu/

paths:

/all:

get:

tags:

– ALL

summary: Get all countries

description: Get all countries

operationId: all

responses:

200:

description: successful operation

content: {}

400:

description: Invalid status value

content: {}

security:

– ApiKeyAuth: []

security:

– ApiKeyAuth: []

components:

securitySchemes:

ApiKeyAuth: # arbitrary name for the security scheme

type: apiKey

in: header # can be “header” or “query”

Inicialización y compilación

Ahora vamos a crear un proyecto API Microgateway, denominado “secure_countries” para nuestra API de ejemplo.

Generamos el proyecto con el comando:

micro-gw init secure_countries

Crea una estructura como esta:

secure_countries

├── api_definitions

├── conf

│ └── deployment-config.toml

├── extensions

│ ├── extension_filter.bal

│ ├── startup_extension.bal

│ └── token_revocation_extension.bal

├── grpc_definitions

├── interceptors

├── lib

├── policies.yaml

Copiaremos nuestra especificación del API en “api_definitions”:

├── api_definitions

│ └── def-secure-countries.yaml

Modificamos la configuración de deploy “deployment-config.toml”:

├── conf

│ └── deployment-config.toml

Nuestro documento “deployment-config.toml” del ejemplo tiene el siguiente contenido:

deployment-config.toml

[kubernetes]

[kubernetes.kubernetesDeployment]

enable = true

name = ‘secure_countries’

tag = ‘v1’

replicas = ‘1’

buildImage = true

baseImage = ‘wso2/wso2micro-gw:3.2.0′

[kubernetes.kubernetesDeployment.livenessProbe]

enable = true

initialDelaySeconds = ’20’

periodSeconds = ’20’

[kubernetes.kubernetesDeployment.readinessProbe]

enable = true

initialDelaySeconds = ’30’

periodSeconds = ’30’

[kubernetes.kubernetesServiceHttps]

enable = true

name = ‘httpsService’

serviceType = ‘NodePort’

[kubernetes.kubernetesServiceHttp]

enable = true

name = ‘httpService’

serviceType = ‘NodePort’

[kubernetes.kubernetesConfigMap]

enable = true

ballerinaConf = ‘<Ruta del Microgateway toolkit>/resources/conf/micro-gw.conf’

Modificamos el fichero “<Ruta Microgateway toolkit>/resources/conf/micro-gw.conf’” y añadimos:

[apikey.tokenConfigs]

issuer=”https://localhost:9095/apikey”

audience=”http://org.wso2.apimgt/gateway”

certificateAlias=”ballerina”

validateAllowedAPIs=false

Generar la imagen y el documento para despliegue en Azure AKS. Como resultado se genera la imagen y el documento yaml necesario a su despliegue en Azure AKS:

–Comando para construir

micro-gw build secure_countries

Ejecución

Publicación la imagen a Azure ACR: Desde la línea de comandos de nuestro entorno de desarrollo. Podemos comprobar que la imagen se ha generado en nuestro Docker local. Luego, subimos a Azure ACR:

–Comprobamos que está la imagen en nuestro registro local:

docker images

–Nos logamos en Azure ACR (comando Azure CLI)

az acr login –name WSO2LabsRegistry

–Luego, subimos la imagen desde registro local a Azure ACR

docker push wso2labsregistry.azurecr.io/secure_countries:v1

–Comprobamos que la imagen se ha añadido correctamente en el registro de Azure ACR (Comando Azure CLI)

az acr repository list –name WSO2LabsRegistry –output table

Desplegamos el MicroGateway en Azure AKS: El documento para el despliegue en Kubernetes se ha generado en la ruta de nuestro proyecto siguiente: secure_countries/target/gen/target/kubernetes/secure_countries/secure-countries.yaml . Podemos usar el siguiente comando para ejecutar nuestro WSO2 API Microgateway en Kubernetes:

az aks get-credentials –name WSO2LabsAKSCluster –resource-group WSO2-Labs-Microgateways

kubectl apply -f secure_countries/target/gen/target/kubernetes/secure_countries/secure-countries.yaml –namespace ingress-basic

Configuramos ingress de NGINX para el Microgateway. Para ello, configuramos el siguiente fichero:

Secure_countries_ingress.yaml

apiVersion: networking.k8s.io/v1beta1

kind: Ingress

metadata:

namespace: ingress-basic

annotations:

kubernetes.io/ingress.class: nginx

nginx.ingress.kubernetes.io/backend-protocol: “HTTPS”

nginx.ingress.kubernetes.io/use-regex: “true”

nginx.ingress.kubernetes.io/rewrite-target: /$1

spec:

rules:

– http:

paths:

– backend:

serviceName: httpsservice

servicePort: 9095

path: /(.*)

Luego ejecutamos el comando:

kubectl apply -f secure_countries_ingress.yaml –namespace ingress-basic

Si accedemos al dashboard de Kubernetes podremos comprobar los resultados:

Pruebas

Realizaremos alguna prueba sobre la API MicroGateway que acabamos de desplegar en nuestro servicio de Kubernetes.

En nuestro ejemplo, primero, vamos a obtener un token (desde la línea de comandos de Windows):

C:\>for /f %i in (‘curl https://<ip_nginx_controller>/apikey -H “Authorization:Basic YWRtaW46YWRtaW4=” -k’) do set TOKEN=%i

Luego, vamos a llamar al servicio, usando el token generado:

C:\>curl https://<ip_nginx_controller>/rest/v2/all -H “accept: application/json” -H “X-API-KEY:%TOKEN%” -k

Si hubiera algún error, realizamos los ajustes necesarios, repitiendo las fases anteriores hasta que obtengamos los resultados esperados y sin errores.

Publicación

Finalmente, una vez superada la fase de pruebas, la API Microgateway se publica toda la documentación de la API, se etiqueta el código del Microgateway en el repositorio de código, se sube la imagen del contenedor al repositorio de imágenes de producción y se pone en funcionamiento el Microgateway en el servicio de Kubernetes de producción.