Hoy nos centraremos en crear un laboratorio de pruebas de la solución Gravitee API Management basado en docker-compose con seguridad API-KEY y veremos sus diferentes funcionalidades desde un punto de vista práctico.
Seguiremos el siguiente índice:
1. Definición de Gravitee API Management
Gravitee API Management es una solución Open Source bajo licencia Apache 2.0, con posibilidad de soporte Enterprise, de la empresa Gravitee.io. En el siguiente articulo realizamos una review del producto y sus funcionalidades.
-Este artículo te puede interesar: Cómo identificar el nivel de madurez de las APIs y sus necesidades-
2. Arquitectura y componentes de Gravitee API Management
Gravitee API Management se compone de cuatro componentes principales:
| APIM Gateway | encargado del runtime de ejecución de las APIs. Es el encargado de asegurar el cumplimiento de las políticas de seguridad así como la gestión de las transformaciones de las peticiones de entrada y salida que pasan por el Gateway (smart proxy). |
| APIM API | encargado de proporcionar un interfaz de comunicación central mediante un API RESTful para todas las labores de administración necesarias por el producto. Es consumido por la consola de administración y por el Portal de Usuario (Developer). |
| APIM Console | encargado de la administración del producto y la gestión del ciclo de vida de las APIs desplegadas en los correspondientes Gateways. Interfaz de usuario para los roles de Administración y API Publisher. |
| APIM Portal | encargado de proporcionar a los desarrolladores de aplicaciones que consumen las APIs de un interfaz de operaciones desde, el que podrán, visualizar la documentación de una API, suscribirse y realizar pruebas. |
Como capa de persistencia, se disponemos de las siguientes opciones:
| Gestión | encargado de todos los datos relativos a la gestión del producto. Puede ser MongoDB, Redis o fuente JDBC. |
| Rate Limit | encargado de todo lo relativo al control de tráfico. Puede ser MongoDB, Redis o fuente JDBC. |
| Analytics | encargado de la persistencia de todo lo relacionado con la analitica (métricas, logs). Por el momento solo puede ser Elasticsearch. |
Para nuestro laboratorio utilizaremos MongoDB para gestión y control de tráfico y Elasticsearch para todo lo relacionado a analíticas.
El esquema de arquitectura de nuestro laboratorio será el siguiente:
Figura 1. Esquema de arquitectura
Podéis acceder al código fuente del laboratorio en el siguiente enlace https://github.com/ChakrayES/docker-compose-gravitee-api-singlegw (branch main).
3. Inicio del laboratorio de pruebas de la solución Gravitee API Management basado en docker-compose con seguridad API-KEY
Antes de arrancar los servicios de nuestro laboratorio, debemos añadir las siguientes líneas al fichero de DNS local de la máquina. En caso de entornos Linux o Mac, la configuración sería la siguiente:
/etc/hosts 127.0.0.1 portainer.demo.chakray.internal api.demo.chakray.internal mgt-api.demo.chakray.internal mgt-ui.demo.chakray.internal portal-ui.demo.chakray.internal
También existe la opción de registrar los correspondientes registros dentro del Servidor DNS local, en caso de disponer de esta funcionalidad en la LAN.
Una vez registrados los nombres DNS, procedemos con el arranque del laboratorio mediante la ejecución del siguiente comando en el directorio raíz del proyecto:
docker-compose-gravitee-singlegw % docker-compose up -d
Podemos comprobar el estado de los servicios con el siguiente comando:
docker-compose-gravitee-singlegw % docker-compose ps
Figura 2. Estado del servicio
Podemos visualizar los logs de los servicios con el siguiente comando:
docker-compose-gravitee-singlegw % docker-compose logs -f –tail 2
Figura 3. Logs de los servicios
3.1 Uso de Traefik Ingress para enrutar el tráfico desde la máquina anfitriona a cada uno de los contenedores
Para poder enrutar el tráfico desde la máquina anfitriona a cada uno de los contenedores hemos usado Traefik Ingress, a la escucha en el puerto :80 para el tráfico y en el puerto :8080 para su consola de administración. En este caso, al ser una entorno de laboratorio, no se ha securizado ninguno de los dos componentes.
Podemos acceder a la consola de administración de Trefil desde la siguiente dirección http://localhost:8080
Figura 4. Consola Trefil
Dentro de Traefik Ingress, cada contenedor ha publicado sus rutas de enrutamiento de forma dinámica mediante el uso de etiquetas. Por ejemplo, Gravitee API Management Gateway publica su ruta de acceso con la directiva:
gateway:
image: graviteeio/apim-gateway:3.18
container_name: sandbox-gateway
depends_on:
- mongodb
- elasticsearch
environment:
- gravitee_management_mongodb_uri=mongodb://mongodb:27017/gravitee?serverSelectionTimeoutMS=5000&connectTimeoutMS=5000&socketTimeoutMS=5000
- gravitee_ratelimit_mongodb_uri=mongodb://mongodb:27017/gravitee?serverSelectionTimeoutMS=5000&connectTimeoutMS=5000&socketTimeoutMS=5000
- gravitee_reporters_elasticsearch_endpoints_0=http://elasticsearch:9200
extra_hosts:
- "api.demo.chakray.internal:172.29.1.1"
- "mgt-am-api.demo.chakray.internal:172.29.1.1"
- "mgt-am-ui.demo.chakray.internal:172.29.1.1"
- "portal-ui.demo.chakray.internal:172.29.1.1"
labels:
- "traefik.enable=true"
- "traefik.http.routers.api.rule=Host(`api.demo.chakray.internal`)"
- "traefik.http.routers.api.entrypoints=http"
- "traefik.http.routers.api.tls=false"
- "traefik.http.services.api.loadbalancer.server.port=8082"
networks:
- sandbox-frontend-net
- sandbox-storage-net
De esta forma, todo el tráfico que llegue a Traefik Ingress hacia la dirección “api.demo.chakray.internal” será enrutado al contenedor de “gateway” por el puerto :8082.
Desde la consola de administración de Traefik, la ruta quedaría visualmente de la siguiente manera:
Figura 5. Consola de administración de Traefik
Siguiendo la misma estructura, la consola de administración de Gravitee API Management quedaría definida de la siguiente manera:
Figura 6. Consola de administración de Gravitee API Management
Podemos acceder a ella en la dirección http://mgt-ui.demo.chakray.internal/
4. Publicar nuestra primera API en Gravitee API Management
Como ejemplo de servicio de backend usaremos el siguiente servicio: https://restcountries.com/. El objetivo es acceder a este servicio mediante nuestra capa de API Management, añadir seguridad mediante API-KEY y consultar las analíticas de consumo.
4.1 Crear la definición de la API
En este apartado hablaremos de como crear la definición de la API en la consola.
1.Entrar en la consola de administración y acceder al menú “APIs”, añadir una nueva pulsando en el botón “+” de la zona inferior derecha.
Figura 7. Crear la definición de la API
2. Seleccionar la opción “Continue in the wizard”
Figura 8. Proceso para crear una API
3. Completar el nombre, versión, descripción y contexto del API que queremos especificar.
Figura 9. Completar campos
4. Definir el backend hacia el que se van a redirigir las peticiones de entrada en nuestro Gateway. Para nuestro caso, el servicio de backend será https://restcountries.com/v3.1/.
Figura 10. Peticiones Gateway
5. Definir el plan de consumo, en nuestro caso será “api-key”. Posteriormente podremos ir incluyendo nuevos planes de consumo a nuestra API. En caso de ser necesario, definir los límites de consumo y recursos necesarios.
Figura 11. Plan de consumo
6. Incluir toda la documentación disponible para nuestra API. Posteriormente podemos ir enriqueciendo esta documentación añadiendo nuevos contenidos.
Figura 12. Enriquecer información
7. Por último, creamos nuestra API y la desplegamos en el Gateway mediante la opción de “Create and start the API”.
Figura 13. Accionar API
8. Si todo ha ido de forma satisfactoria, podemos consultar nuestra API dentro del catalogo de la consola de administración.
Figura 14. Consultar API
4.2 Suscribirse y obtener un API-KEY
Una vez creada la API, debemos suscribirnos a uno de los planes creados para poder consumirla (a no ser que exista un plan keyless, el cual permite su consumo de forma pública). Para ello, accederemos al menú de “Subscriptions” de nuestra API y pulsaremos el botón “+”.
Figura 15. Suscripciones
Seleccionaremos una de las aplicaciones disponibles y el plan sobre el que nos queremos suscribir.
Figura 16. Crear una suscripción
Figura 17. Suscripción al detalle
De esta forma, obtendremos un api-key que podremos utilizar para consumir nuestra API. En nuestro caso: 7c37aed2-6cf3-416f-9d26-e0ed893af177
4.3 Consumir nuestra API securizada mediante API-KEY
Para consumir nuestra API securizada mediante api-key, utilizaremos la siguiente instrucción con el comando curl:
curl \ -H 'X-Gravitee-Api-Key: 7c37aed2-6cf3-416f-9d26-e0ed893af177' \ "http://api.demo.chakray.internal/myrestcountries/alpha/es" | jq
Figura 18. Consumir API mediante API-KEY
4.3.1 Analíticas de consumo de nuestra API
Para acceder a las analíticas de nuestra API debemos acceder al menú “Analytics” de nuestra API.
Figura 19. Analíticas de nuestra API
Desde este cuadro de mando podremos consultar el número de peticiones en función de diferentes aspectos: aplicación, plan, path. También disponemos de un resumen en función del código de respuesta de nuestra API (http status code) y las diferentes latencias de consumo.
Figura 20. Cuadro de mando
4.3.2 Acceder a los logs de nuestra API
Para acceder a los logs de nuestra API debemos acceder al menú “Analytics” de nuestra API. Dentro, accederemos al submenú “Logs”.
Figura 21. Logs
Cuando accedemos a un registro de log concreto, veremos una versión reducida de los logs. En esta versión reducida no podremos acceder a las cabeceras ni al cuerpo de las peticiones.
Para acceder a una versión ampliada de los logs, configuraremos nuestra API mediante la opción “Configure the logging”. Activaremos las opciones deseadas y guardaremos los cambios.
Figura 22. Configuración Logging
En este momento, al acceder a uno de los registros de log obtendremos una versión ampliada de los mismos, siendo capaces de consultar tanto los encabezados como el cuerpo de las peticiones.
Figura 23. Registro
Figura 24. Registro concreto
5. Chakray y Gravitee.io
Chakray, como Partner Oficial de Gravitee.io, dispone del conocimiento y las herramientas necesarias para abordar cualquier proyecto de API Management, brindando la tranquilidad de contar con un equipo especializado en su despliegue, desarrollo y posterior mantenimiento, así como con el apoyo conjunto con el fabricante para los entornos Enterprise. Estaremos encantados de oír su caso de uso y analizar cuál es la mejor estrategia de APIficación para implementar la capa de API Management en su organización. ¡Contáctanos hoy mismo!
