Pasar a producción un API en python con flask / connexion

Hacer un servicio que sirva un API en python es muy, muy sencillo usando flask o connexion. Mi método favorito de hoy (esto cambia día a día) es usar connexion que nos permite crear un servidor teniendo su definición en un archivo openapi con simplemente tres líneas de código:

app = connexion.App(__name__,specification_dir='./')
CORS(app.app)
app.add_api('openapi.yml')
app.run(port=8080)

Con estas cuatro líneas de código (además de los imports correspondientes) ya tendríamos un servidor web en el puerto 8080 de la máquina. Luego basta con tener en el openapi.yml definido el nombre de las operationId e implementarlas adecuadamente… Me tienta, pero en este momento no voy a hacer un tutorial sobre connexion o sobre cómo generar un proyecto python usable. Para esta entrada supongamos que ya tenemos el servidor implementado y corriendo… Veremos que cuando lo arrancamos nos muestra este mensaje:

 * Serving Flask app 'app'
 * Debug mode: off
2024-01-25 20:57:13,203 - werkzeug - INFO - WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.
 * Running on all addresses (0.0.0.0)
 * Running on http://127.0.0.1:8080
 * Running on http://172.18.0.20:8080
2024-01-25 20:57:13,204 - werkzeug - INFO - Press CTRL+C to quit

Si nos fijamos nos está advirtiendo de que el servidor que está usando es el propio de Flask y no es muy adecuado para entornos de producción. ¿Qué significa esto? Que si recibe muchas peticiones el tiempo de proceso de las mismas va a ser muy alto. El mismo mensaje nos recomienda usar un servidor WSGI para entornos de producción.

De hecho, si estás ejecutando una versión más moderna de connexion te aparecerá este mensaje en su lugar:

2024-01-25 22:05:31,351 - connexion.middleware.main - WARNING - `ConnexionMiddleware.run` is optimized for development. For production, run using a dedicated ASGI server.

Que es lo mismo pero con ASGI en lugar de WSGI. La receta para ejecutarlo mas en «producción» en este caso sería instalar gunicorn y lanzarlo con un tipo de worker ASGI (uvicorn en este caso) teniendo en cuenta que app está definido dentro del archivo app.py:.

pip install gunicorn
gunicorn -k uvicorn.workers.UvicornWorker --bind "0.0.0.0:8080" app:app

Con eso ya lanzamos un proceso, si queremos lanzar más lo podemos hacer con el parámetro -w poniendo, por ejemplo:

gunicorn -k uvicorn.workers.UvicornWorker -w 4 --bind "0.0.0.0:8080" app:app

Con esto ya se lanza 4 procesos para dar servicio al API… Esto debería mejorarlo.

Y una cosa más… Si tenéis algún proceso en la aplicación que no deba replicarse con cada worker (un scheduler por ejemplo), tenéis que lanzar gunicorn con el parámetro --preload para que se ejecute solo una instancia de la aplicación (de todo lo que no dependa de las peticiones)

Cómo dar de alta tu propia librería en el gestor de librerías de Arduino

De un tiempo a esta parte he estado haciendo cositas con microcontroladores y Ardunio (ultimamente con platformio), y el caso es que he querido dejar como librerías libres algunos de los códigos que he generado (o mejorado), como por ejemplo la librería para generar códigos QR en displays OLED o TFT (https://github.com/yoprogramo/QRcodeDisplay). La gestión de librerías en Arduino es una de las cosas que hacen el entorno interesante (en platformio mejor todavía) y es muy interesante tener disponible tu librería en el gestor de librerías de arduino.

Hasta hace poco el hacer que tu librería estuviese disponible para todo el mundo en el gestor de librerías de Arduino IDE era una tarea muy «manual», básicamente poner un mensaje en los foros de soporte de Arduino y esperar por la respuesta… Esto ha cambiado un poquito y podemos encontrar un nuevo método aquí:

https://github.com/arduino/library-registry#readme

Os lo resumo para los que seais impacientes. Los pasos una vez que tengáis el código de la librería en github son los siguientes:

  • Crear una release en github y darle un número
  • Crear un archivo llamado library.properties con el número de versión y los datos correspondientes de las plataformas y dependencias
  • Abrir este enlace para hacer un fork del repositorio: https://github.com/arduino/library-registry/edit/main/repositories.txt
  • Hacer fork del repositorio
  • Editar el archivo repositories.txt añadiendo la url de github del repositorio
  • Hacer click en «Proponer cambios»
  • Crear un pull request

El pull request genera una petición para que un bot revise los cambios, si todo está ok la librería aparecerá al día siguiente en el gestor de arduino, si hay algún problema se puede poner un comentario mencionando a @ArduinoBot o hacer un commit con las modificaciones en el archivo (en la rama de nuestro fork).

Nuestra librería en el gestor de librerías de Arduino

Gestión de versiones de Flutter

Flutter es un framework que me está gustando bastante, es muy consistente en cuanto a las distintas versiones, se ve muy similar en todas las plataformas y Dart como lenguaje es bastante interesante y nada esotérico (por eso de que usa cosas que ya manejamos y no se dedica a reinventar la rueda).

Flutter Version Management

Tanto es así que empezamos hace unos meses un proyecto de aplicación móvil con Flutter, coincidiendo con la llegada de la versión 2.0 y las cosas empezaron a ir «demasiado deprisa». La comunidad y los mantenedores del sdk parece que se han puesto las pilas y han decidido incluir mejoras a un ritmo trepidante, cuando escribo estas líneas ya vamos por la versión 2.8.1.

Nosotros estabilizamos la app en un contenedor docker usando la versión 2.5.2 de Flutter y nos encontramos ahora que no hay manera de instalar desde cero esa versión con los sistemas que proporciona Flutter. Todos aquellos sistemas en los que hicimos un upgrade ya no los podemos utilizar para desarrollo porque, entre otras cosas, han cambiado librerías y ya no son compatibles algunas partes de nuestro código.

Pero no soy el único con ese problema. Varios de los desarrolladores de Flutter se han encontrado con la misma situación y, afortunadamente, han desarrollado una manera de poder disponer de una versión propia de flutter para cada proyecto… Mediante FVM.

Os cuento los pasos básicos para tener FVM funcionando (partiendo de que has instalado flutter en tu sistema) y cómo usarlo para cada proyecto:

1. Instalar FVM

dart pub global activate fvm

Esto te instala el paquete, pero tendrás que cambiar el entorno para poder acceder al comando fvm cada vez, en mi caso es algo como:

export PATH="$PATH":"$HOME/.pub-cache/bin"

Añadiendo esta línea al final del ~/.bashrc conseguiréis meter en el path el comando FVM

2. Instalar una versión de flutter para su uso posterior

En mi caso quería instalar la versión 2.5.2 y tuve que ejecutar esto:

fvm install 2.5.2

Puedes instalar tantas como quieras (o necesites), puedes conseguir la lista de todas las instaladas con el comando fvm list

3. Usar una versión concreta en tu proyecto

Dentro del directorio del proyecto en el que quieras usar esta versión puedes sustituir el uso del comando flutter por el comando fvm flutter que te ejecutará la versión correspondiente, para indicar qué versión quieres usar debes escribir:

fvm use 2.5.2

Esto te genera un directorio .fvm en donde se almacenarán los enlaces correspondientes, no olvides incluir en tu .gitignore el directorio .fvm/flutter_sdk

Con esto y algunas cosillas más (os dejo consultar la documentación) ya podréis desarrollar y depurar con la versión de flutter que queráis.

log4j, las vulnerabilidades, los parches y la sobre-ingeniería

Durante estos días si te dedicas mínimamente a esto de la informática y has creado algún sistema con Java habras sufrido el problema del log4jshell. Si es que no, pues te lo explico:

log4j es una librería de Java que lleva existiendo desde hace innumerables años y que es muy utilizada para registrar los eventos que tienen lugar en un sistema y poder controlar qué se registra y qué no. Pues bien, la versión 2 de esta librería incluía funcionalidades para hacer sustituciones en las cadenas que se guardan en el log y, continuando con la tradición más añeja de Java, se les ocurrió que sería buena idea que esas cadenas a sustituir pudiesen hacer llamadas a sistemas externos y recibir objetos completos. Utilizando el estandar jndi permitían incluso hacer llamadas RMI o acceder a servidores LDAP. Supongo que el programador que añadió estas funcionalidades vería su utilidad en algún momento, pero también es cierto que yo nunca he visto a nadie usarla.

En fin, que esto llevaba ahí un tiempo y a algún «hacker malvado» se le ocurrió probar qué pasaba si en la url que le pasaba a la cadena a loguear incluía la dirección de un servidor que él controlaba y que permitía descargarse un objeto que hacía «cosas malas» en el sistema… Y la prueba funcionó y en cuanto alguien se dió cuenta que había cadenas extrañas que empezaban por ${jndi:ldap:// y que provocaban funcionamientos anómalos se dio la voz de alarma y se creó un registro de vulnerabilidad (CVE-2021-44228) y con un exploit super-sencillo y que mostraba que había cientos de miles de sistemas afectados.

El parche a esa vulnerabilidad llegó pronto (y eso que log4j está mantenido solo por voluntarios) y mucha gente se pasó buna parte del fin de semana parcheando los sistemas (alguno tardó algo más), aunque sin tener muy claro si el sistema había sido comprometido y modificado antes, cosa que requiere otras medidas adicionales y muy costosas. A día de hoy se ha encontrado que el parche que se hizo no contempla todos los casos y se ha registrado otra vulnerabilidad (CVE-2021-45046) que requiere otro parche… Parches, que, al fin y al cabo lo único que hacen es deshabilitar esa funcionalidad que, en algún momento, a alguien, le pareció interesante.

Son incontables el número de horas que el personal de IT (desde programadores hasta técnicos de sistemas) se han dedicado a tapar este agujero (y seguro que habrá muchos agujeros sin tapar todavía). Eso se traduce en muchos millones de Euros de dinero gastado sin sentido… Y todo porque a alguién «le pareció una buena idea esa funcionalidad» y porque todo el mundo usa componentes que no conoce, en los que «confía», aunque no poga un duro para su desarrollo…

Por cierto… Hay por ahí ya los «negacionistas de los parches» que van diciendo que si los parches son malos, que no saben lo que hay dentro, que todo es parte de una conspiración y esas cositas… En fin, el ser humano es lo que tiene (o no).

ACTUALIZACIÓN 17-12-2021: Hay todavía otro parche que meter, el 2.17.0 ya que hay una cadena especial que puede dar como resultado un DDoS… A ver lo que nos dura.

Automatiza tu casa

Creí, francamente, que ya había escrito sobre el tema de la domótica en mi blog, pero revisando me he encontrado que no he escrito casi nada sobre el tema, así que comienzo ahora a desvelaros, muy poco a poco, qué es esto de la automatización y cómo puedes controlar tu casa y hacerla más inteligente con un coste ridículo (y aprendiendo un montón).

domótica

Como resumen, la domótica aglutina todo lo que podemos controlar de manera remota 8o programar localmente) en nuestro hogar. Son esas cosas que nos permiten encender la calefacción horas antes de que lleguemos de un viaje, abrir y cerrar persianas sin que estemos o apagar y encender luces cuando se detecta nuestra presencia. Dado que esto es un campo muy amplio, os recomiendo que visitéis webs más especializadas para descubrir el montón de cosas que se pueden hacer. Yo, por mi parte, iré recopilando las cosas interesantes que voy haciendo por si os sirve de algo.

Lo primero…

Para poder «jugar» un poco con la domótica necesitamos algún controlador en el que centralizar todas estas opciones. En mi caso me he decidido por home assistant, que tiene un montón de información en internet y del que disponéis de plugins y librerías para cadsi todo. La instalación es tremendamente sencilla si vamos a utilizar una raspberry pi (recomiendo que sea la 4, pero la 3 también nos serviría igualmente). La guía de instalación para raspberry pi está bastante bien y la podéis encontrar en este enlace.

El proceso consiste, básicamente, en descargarte la imagen de internet, grabar con esa imagen una tarjeta SD y si tenéis conexión por cable simplemente meter la sd en la rasperry, enchufar el cable de red y esperar a que arranque, tendréis el sistema de configuracion en la url http://homeassistant.local:8123/. Si vais a usar wifi desde el primer momento el proceso es un poco más complicado, básicamente consiste en copiar este archivo (modifica a tu gusto el SSID y contraseña) en la particion de boot del SD que acabáis de grabar (en CONFIG/network/) y llámalo my-network:

[connection]
id=my-network
uuid=72111c67-4a5d-4d5c-925e-f8ee26efb3c3
type=802-11-wireless

[802-11-wireless]
mode=infrastructure
ssid=MI_SSID
# Uncomment below if your SSID is not broadcasted
#hidden=true

[802-11-wireless-security]
auth-alg=open
key-mgmt=wpa-psk
psk=MI_CONTRASEÑA_WIFI

[ipv4]
method=auto

[ipv6]
addr-gen-mode=stable-privacy
method=auto

En fin, una vez que tengáis home assistant instalado toca poner los datos tuyos y los del domicilio donde vas a instalarlo y el sistema se encargará de buscar por red las integraciones a las que pueda acceder directamente.

En siguientes entradas veremos aspectos interesantes sobre cómo configurarlo para tener acceso a dispositivos zigbee, a detectar presencia propia o a hacer automatizaciones… Por ahora intentad tener el controlador preparado e id buscando dispositivos para hacer de vuestra casa una casa inteligente.