datosgobar / api-gateway Goto Github PK

Cuando se quiere acceder a API-mock desde kong, kong se cuelga, pero si se accede a API-mgmt, la aplicacion funciona bien.

El modelo ApiData tiene en él infromacion que pertenece a los plugins.

• Crear el modelo plugins
• Vincular cada plugin a la api correspondiente

Mostrar la cantidad de visitas por endpoint, parámetros, y por IP.

Discutir con @pilimayora cómo debería verse esto.

Agregar la opcion "preserve_host" al modelo.

Ver https://getkong.org/docs/0.12.x/admin-api/#add-api

Migrar el script de deployment de Kong dsde series de tiempo.

Al deshabilitar una API se espera que la URL base en la que esa API fue registrada devuelva un status 404.

Actualmente está devolviendo la documentación de la aplicación.

Siguiendo la documentacion de kong para el plugin de rate limit, agregar una seccion al admin de APIs para poder agregar opcionalmente el rate limit, pudiendo desactivarlo en cualquier momento.
Las configuraciones que se quieren por el momento son:

• enable
• second
• minute
• hour
• day

@pilimayora la especificaciones es correcta a grandes rasgos?

Entregable:

Entender los pros y los contras de utilizar una solución de POST server-side a google analytics.
El resultado final es evaluar si enviar datos a google analytics nos alcanza para no tener que preocuparnos por analytics en api-management

Por ejemplo, ver todos los analytics desde google analytics y no tener que preocuparnos por una UI de analytics en api-management.
Parte del spike es evaluar si el que se comunica con google analytics podría ser kong, django, o con quien sea

Necesitamos poder ver:

• Cantidad de hits por endpoint
• Detalle de los parametros de cada consulta
• Hits por IP
• Velocidad de respuesta
• Tipo de respuesta (404, 500, 200?)

Algunos pros y contras que podríamos llegar a encontrar:

• Hay alguna de las necesidades que no cubre Google Analytics? Ej: Hits por IP?
• Tiene alguna implicancia grave sobre la performance de las APIs el envío server-side a google analytics?

Recursos útiles:
https://developers.google.com/analytics/devguides/collection/protocol/v1/devguide
https://github.com/merll/server-side-tracking
https://cloud.google.com/appengine/docs/standard/python/google-analytics
https://www.peterbe.com/plog/ga-pageviews-on-non-web"

Crear ruta "secreta" de login (al estilo Andino) y el concepto de usuarios admin de api management.
La ruta de login para api-management debería estar en apis.datos.gob.ar/ingresar.

Kong nos provee de toda esta información en cada request, que podemos loguear en nuestra implementación de Analytics: https://getkong.org/plugins/http-log/#log-format

Actualmente estamos logueando un subconjunto de esta info. Este isssue se usará para definir qué información adicional loguear y modificar el plugin para loguearla.

En la pantalla de edición/creación de una API debe poder especificarse si el uso de esta API requiere o no token.

Nota: Los tokens deben ser JWT.

Actualizar el script de deployment para que instale kong 0.13 o actualice al mismo

Consta de:

• La landing de las APIs tokenizadas deben tener un botón de "Pedir Token"/"Solicitar Acceso"
• La pantalla de "Pedir Token" debería tener un formulario de pedido de token.
  • Persona o área que requiere el token
  • Mail de contacto
  • Aplicación o servicio que consumirá la API
  • Estimación de requests por día a la API

Incluye verlas en el admin.

cc @Lalo73

Agregar un parámetro opcional que permita Ignorar requests que no coincidan con un formato especifico de la URL. Como por ejemplo la API de series de tiempo.

Simil datosgobar/series-tiempo-ar-api#183 pero para este repo

Analizar:

• Cómo escala horizontalmente Kong?
• Puede escalar diferenciadamente por API? (Que cada API tenga recursos de infra distintos y customizables)

Agregar una aplicacion Django2.
La misma debe basarse en el ejemplo de aplicacion.
Hablar con @Lalo73 sobre este ejemplo

El resultado final deberia ser poder levantar una Aplicacion Django para desarrollo y que se pueda entrar al /admin
No preocuparse por el deployment.

Habilitar que una API pueda ser accedida solamente CON token.

Especificaciones:

• #71 - En la pantalla de edición/creación de una API debe poder especificarse si el uso de esta API requiere o no token
• #72 - La landing de las APIs tokenizadas deben tener un botón de "Pedir Token"/"Solicitar Acceso"
• #72 - La pantalla de "Pedir Token" debería tener un formulario de pedido de token que deberá incluir:
• #73 - Para las APIs tokenizadas, los usuarios admin de la API deben tener acceso a una pantalla de administración de tokens, donde podrán aprobar/rechazar solicitudes de tokens.
• #74 - Para las APIs tokenizadas, la distinción de usuarios para Google Analytics es por token. Para las APIs no tokenizadas, la distinción de usuarios para Google Analytics es por IP+agente.

Usar jmeter para correr tests de carga.
Los tests los implementaremos contra el servidor de api-mock.

los endpoints son:

• GET /datos.json/
• GET /datos.csv/
• POST /echo/

Agregar la posibilidad de un deployment con StatsD

Las maquinas para los workers y redis en testing ya estan disponibles.

Actualizar el inventario para hacer uso de las mismas

Crear un modelo KongAPI basado en lo registrado en la wiki.

Como primer implementacion, solo los siguientes campos son necesarios:

• name, único en la base de datos
• upstream_url (AKA. endpoint)
• uri (path, uris en kong)
• strip_uri (mismo setting en Kong)
• enable

Finalmente este modelo debe permitir desde el admin de django crear, activar, desactivar, borrar, modificar la configuracion de un servidor Kong.
El Form de django debe encargarse de esta lógica, haciendo los requests en el momento que sea necesario para dejar la correcta sincronia entre el modelo y la configuracion de Kong.
Como referencia para las llamadas, se tiene la documentacion oficial de Kong

Notas:

El parámetro "hosts" para los requests debe ser tomado de un "setting" de django. (KONG_HOST_DOMAIN) y para saber a que server de Kong pegarle (la url de admin de kong) se debe usar otra (KONG_ADMIN_URL).

@poligarcia Podrías confirmar/corregir lo aquí escrito para que @SebastianHGonzalez pueda empezar a trabajar.

Configurar el Continuous Delivery de la aplicacion a la TS.

Para las APIs tokenizadas, la distinción de usuarios para Google Analytics es por token. Para las APIs no tokenizadas, la distinción de usuarios para Google Analytics es por IP-agent.

Depende de #73

Es necesario agregar una API JSON autenticada para la obtencion de Queries.

La misma debe ser paginada, con máximo, y debe permitir filtros por ID del KongApi, por rango de fechas (desde y/o hasta).

Puede usarse la integracion de Filtering de DRF.

Para la autenticacion, ademas del token, debe tener permisos de lectura sobre el modelo Query. Para eso DRf trae integraciones con permisos

Agregar un campo, semi-opcional, llamado "hosts".
Este campo debe configurar el parámetro "hosts" de las APIs de kong (Ver doc).

El mismo debe ser semi-opcional, esto quiere decir que al menos uris o hosts deben estar definidos, pudiendo estar definidos los dos al mismo tiempo.
El error debe ser un error de validacion del formulario si ambos no están.

El modelo de la aplicación actualmente define el campo request_time del model Query:

    request_time = models.DecimalField(max_digits=30, decimal_places=25)

Habría que garantizar que nunca venga un numero con mas de 25 decimales o truncarlo.
Este numero es enviado desde Lua al terminar el request de kong.
Ver plugin de kong

Loguear el "status_code" y si es posible la API a la que el log se refiere.

La implementacion de Query para analytics no debe bloquear el server.
Para eso, hacer asincronica la creacion mediante el uso de Django-rq

Analizar la factibilidad técnica de:

• Rutear dos aplicaciones distintas por uris con el mismo hostname.
• Verificar si hace falta o no especificar el hostname si usamos uris.
• Definir requerimientos de paths para las APIs que serán administradas por Kong (ejemplo: si la URL final va a ser /series/api/v1.0/series, qué parte de la URL maneja Kong y qué parte la aplicación API?
  • Puede mi app vivir en /gr/ y la URL ser /georef/api/v1.0/ ?
  • Si ruteamos por uris, hay que usar SCRIPT_NAME?
  • Hay que forzar que la uris de Kong coincida o se solape con la URL de la aplicación API?
  • Si forzamos a que coincidan la URL de la aplicación API y el Path de la API (cuando se carga en el form de alta), que rol juega uris y strip_uri?

Crear un plugin custom de kong similar a http-log, para lograr guardar metricas.

Para las APIs tokenizadas, los usuarios admin de la API deben tener acceso a una pantalla de administración de tokens, donde podrán aprobar/rechazar solicitudes de tokens.

Al crearse una Query para un request, validar con una regex el request.
la Regex sólo debe dejar pasar los request que no pasen la validacion, algo así como un "exclude".

Por ejemplo, si la refex es ^\/[static|media]\/ esta evitara que los requests con path que comienza con /static/ o /media/ lleguen a GA.

Si se crea una api estando activada, los logs por http no funcionan.

Esto se produce porque al crearse una api, está no tiene id por lo que no se puede configurar de manera correcta el plugin httplog2.

Ver de utilizar lo implementado en #37 para lograr hacer andar la aplicacion.

Actualmente la aplicacion requiere Workers de RQ.

Implementar su deployment

Estructura de URLs:

Version actual propuesta:

• apis.datos.gob.ar/series/api/series?...

Version anterior:

• apis.datos.gob.ar/series/api/v1.0/series?...

Version actual propuesta:

• apis.datos.gob.ar/georef/api/provincias?...

Version anterior:

• apis.datos.gob.ar/georef/api/v1.0/provincias?...

URLs productivas de referencia:

• http://apis.datos.gob.ar/series/api/series/?ids=138.1_PAPDE_0_M_41
• http://186.33.216.98/api/v1.0/municipios

Documentacion de Kong sobre URIs: https://getkong.org/docs/0.12.x/proxy/#request-uri

Discutir con @pilimayora cual es la mejor solución de acuerdo con la documenacion de Kong.

Dentro de los campos que el administrador define para crear una API, debería haber un campo que sea "URL absoluta a la documentación", donde al configurar una API le ponemos la URL que publica la documentacion en formato openApi

ejemplo

Probar el deployment en testing.

En este issue voy a implementar lo necesario, probandolo con Vagrant.

La aplicación debe configurar el plugin httplog2-kong a demanda para cada API creada desde el administrador de django.

En el formulario de creación/edición de una API agregar dos atributos nuevos:

• enable_logs: Boolean, default False.
• api_key: Char. Sólo requerido si enable_logs es True.

Luego de guardarse los datos de la API, el sistema debe habilitar o deshabilitar el plugin para la API en base al valor de enable_logs (y usando la api_key para autenticar las llamadas.

Criterio de aceptación

Lo que yo espero (o como lo voy a probar) es que cuando le configuro una key válida y habilito los logs, al consumir la API se van acumulando logs.
Cuando lo deshabilito, se dejan de acumular logs.

Segun lo implementado y mergeado en el pull-request 52, la aplicacion requiere una variable llamada ANALYTICS_TID para funcionar bien.

En desarrollo esto puede dar al mal funcionamiento de la aplicacion si uno no sabe que la necesita.
En produccion tambien.

En desarrollo se podria hacer opcional la funcionalidad, o dar un mecanismo para que no falle si no se tiene la variable, o documentar como obtener la variable y configurarla.
La funcionalidad no tiene tests, por eso no fallan los tests por la falta de esta variable. 👎
En produccion deberiamos obligar a setearla o que falle el deployment.

La aplicacion debe poder deployarse con ansible como lo hacemos con Kong

Testear distintos escenarios y reportar cantidad máxima de conexiones simultáneas a api management y tiempo de respuesta promedio:

• 100% tráfico a API-mock
• 100% tráfico a georef
• 100% tráfico a series
• 50% tráfico a series, 50% tráfico a georef

Usando el ambiente de testing:

http://192.168.65.1/management/ingresar

Temas:

• Login de la aplicación
• Alta de una API
• Ver documentación
• Probar ratelimit

Generar documentación dinámica a partir de las especificaciones openAPI en yml/json de cada API.

Esta documentación debe vivir en la landing de cada API agregada a API management. Ejemplo: apis.datos.gob.ar/georef

Esta historia asume que al agregar una API nueva a API management, se especifica cuál es el archivo con path absoluto que tiene la especificación en openAPI.

Librerías de ejemplo para levantar las especificaciones:

• Swagger UI
• https://github.com/sourcey/spectacle

Sitios de documentacion de ejemplo:

• https://zeit.co/api

Primera entrega: mostrar documentación a partir de especificación de openAPI sans diseño.
A posteriori: mostrar la documentación siguiendo hermosos diseños de Seba.

@pilimayora No es responsabilidad de cada aplicacion mostrar en el / la documentacion?
Que pasa si la aplicacion ya tiene algo en el / deberiamos ocultarlo?

La solucion mas simple que veo es que cada app (georef, TS, webmock) muestren su documentacion en el /, entonces no implica nada desde nustro lado, porque ya estariamos ruteando a la documentacion.

Por ejemplo, si le pegamos a /geored/ mustra la documentacion, que seria como pegarle al / de la app.

La otra es generarla en base a cada app, pero quien provee esta especificacion?
Al crear una API deberiamos en API-mgmt deberiamos dar al especificacion o cada app debe tener un path predefinido (por ejemplo: /swagger.yml) de donde lo bajamos.

Haciendo uso del plugin de Kong para stastd y el exporter de statsd a prometheus, instalar y configurar prometheus para monitoring

El cid en las llamadas a Google Analytics debe ser lo mas unico posible.

Se puede usar la IP + alguna cookie que tengamos de sesión o user-agent, algo asi como el footsprint.
Podria ser un hash calculado del lado de LUA.

Ahora los tonkens generados por jwt son validos para todas las apis registradas.

Este no es el comportamiento deseado.

Como usuario, el token obtenido tras haber echo una solicitud debe solo ser valido para la api que se pidió.

• Modificar plugin jwt de kong para cumplir con este comportamiento

Basandose en lo implementado para las analiycs de series de tiempo, implementar un endpoint syncronico. Esto quiere decir que no hace falta meter DjangoRQ en la aplicacion. Lo que si sera un requerimiento es que la API sea accesible usando un Token de autenticacion.

Para esta implentacion se puede usar DjangoRestFramework junto con Django Djoser.

El resultado final es la posibilidad de autenticar un usuario por API, obtener un token y luego solo si es staff o admin puede crear usar la api de analytics.

Duplicado de datosgobar/api-mock#7

Tener documentación de la mock API siguiendo la especificación de openAPI

Crear una API mock REST para usar para desarrollar y testear funcionalidades de api-management.
La misma debería tener:

• Dos o más endpoints diferentes que acepten dos o más parámetros
• Devolver respuestas tanto en formato json como en formato csv
• Tener documentación de la mock API siguiendo la especificación de openAPI

@pilimayora tenemos que nosotros decidir que enpoints? con que formatos?

Se me ocurren estos endpoints:

• GET / : Devuelve html estatico
• GET /datos.json : Devuelve los datos de prueba creados
  • Acepta el parametro ?q= para filtar en el titulo o descripcion
  • Acepta el parametro ?only_id= para devolver solo un array de IDs
• GET /datos.csv : Devuelve los datos de prueba creados en formato csv
• GET /admin : Muestra el formulario de login del admin