22 oct 23 Cómo editar los puertos a un contenedor docker en ejecución
Una de las gracias de ejecutar servicios en un contenedor docker es que, si cambian las necesidades del contenedor (como por ejemplo publicar en un nuevo puerto), es bastante sencillo aprovisionar uno nuevo sin mayores consecuencias. Pero a veces pasa que no puedes destruir y aprovisionar un nuevo contenedor, bien porque tienes determinada información persistente en el mismo (cosa que no debe hacerse, ya que en teoría los contenedores han de poder ser sin estado, pero esa es otra historia) o por cualquier otro motivo, y precisas de mantener el mismo contenedor, pero modificando (bien añadiendo, quitando o reemplazando puertos) el contenedor existente. Aunque no es una buena práctica, es posible realizarlo, siguiendo los siguientes pasos (por supuesto, recomiendo hacer primero una copia de seguridad de los ficheros modificados):
- Detener el contenedor en cuestion: Haremos un docker ps para obtener el listado de contenedores, y poder identificar nuestro contenedor en cuestión. Tras ello, lo detendremos con un docker stop
. - Abrir el directorio que contiene el docker: Lo más normal es que haya que realizarlo con permisos de root. Se encontrará bajo la ruta /var/lib/docker/containers/, y allí tendremos que entrar en una carpeta que comience por el id del contenedor.
- Editar el fichero hostconfig.json para modificar las asociaciones de puertos entre host y contenedor: Una vez en la carpeta, tendremos que editar el fichero hostconfig.json. Esto nos permitirá reconfigurar las asociaciones de puertos entre el host y el contenedor docker. Para añadir un nuevo puerto, tendremos que añadir una entrada en la sección PortBindings. Por ejemplo, si quisiéramos añadir el puerto 18334/tcp a un docker que publique por el puerto 18332, tendríamos que dejar esa sección de la siguiente manera:
“PortBindings”:{“18332/tcp”:[{"HostIp":"","HostPort":"18332"}],”18334/tcp”:[{"HostIp":"","HostPort":"18334"}]}
- Editar el fichero config.v2.json para modificar las exposiciones de puertos del contenedor: Asociar el puerto por sí solo no es suficiente, es preciso decirle al contenedor que tiene que exponer un nuevo puerto, que habrá de coincidir con el añadido en el punto anterior. Para ello, hay que modificar el fichero config.v2.json, bajo la sección ExposedPorts. Como en el caso anterior, si quisiéramos publicar ese puerto 18334/tcp, tendría que quedar como sigue:
“ExposedPorts”:{“18332/tcp”:{},”18334/tcp”:{}},
- Reiniciar el servicio docker: Bastará con un sudo systemctl restart docker.
- Iniciar el contenedor: En caso de que el contenedor no se haya iniciado de manera automática al reiniciar el servicio docker, tendremos que iniciarlo a mano con un docker start
. Posteriormente, con un docker ps podremos verificar que hemos modificado adecuadamente los puertos expuestos.
Referencias:
- Assigning a Port Mapping to a Running Docker Container
- How to open/edit/bind ports to running Docker Containers
Etiquetas: contenedor, docker, microservicios, puertos
24 abr 21 Trazabilidad de activos en exterior con LoRaWAN, Chirpstack, Node-Red y una arquitectura de microservicios
Bonito combo el del título de este artículo, ¿verdad? A resultas de algunas actividades que estoy realizando en el trabajo relacionadas con redes IoT industriales, en mi tiempo libre le he dado una vuelta de tuerca al proyecto, para realizar un piloto de trazabilidad de activos en exterior. Cómo no, basado en el uso de LoRaWAN y Chirpstack, como contaba en un artículo anterior.
Arquitectura LoRaWAN
La cosa es que aprovechando que contaba con una pequeña infraestructura local de Chirpstack desplegada mediante microservicios, me hice con un dispositivo de Dragino bastante interesante, el LBT1:
Dragino LBT1
Este dispositivo es bastante interesante: integra un módulo GPS que permite obtener su ubicación precisa, que es trasmitida mediante LoRaWAN para ser posteriormente explotada. Pero cuenta con capacidad Bluetooth, para realizar ubicación en interiores mediante iBeacons; dispone de un acelerómetro, de tal manera que el dispositivo tiene capacidad de enviar la señal LoRaWAN cuando detecta movimiento y no de manera indiscriminada, con el consiguiente ahorro de batería; tiene una batería recargable de 1000 mAh (que he podido probar que da para más de una semana de actividad sin necesidad de recarga); y cuenta con un botón que -en su configuración por defecto- permite pasar al dispositivo a un modo de emergencia, de tal manera que pasa a emitir la señal de manera periódica (y no activada por el acelerómetro, como en el modo normal), y con una codificación del paquete de datos específica, de tal manera que es posible distinguirlo de una transmisión normal, y actuar en consecuencia.
Estas capacidades, junto con la característica de integración HTTP proporcionada por Chirpstack, permiten algo bastante interesante, y es realizar un sistema de monitorización de activos en exterior, si lo combinamos con un procesamiento en segundo plano. Para ello, en mi caso, he utilizado Node-Red.
Flujo Node-Red para trazabilidad de activos
La idea general es la siguiente: se establece un punto de entrada desde donde recibir los POST HTTP provenientes de Chirpstack, que nos harán llegar cada uno de los eventos provenientes de los dispositivos. Aquí realizamos un primer procesado para obtener información relevante de la señal transmitida (básicamente, latitud, longitud, identificador del dispositivo, cantidad de carga de la batería, y si se trata o no de una señal de emergencia). Con esta información realizamos dos acciones: representar cada objeto definido en la aplicación Chirpstack y que esté enviando señal en el mapa, bien con un icono verde si todo va bien, o con un icono rojo si se ha pulsado el botón de emergencia. Además de esto, se mantiene trazabilidad de los movimiento realizados creando una línea con las distintas ubicaciones GPS enviadas por el dispositivo. Todo ello se representa sobre un mapa, que permite definir zonas de calor, y filtrar por cada uno de los objetos que estén enviando señal. El resultado es algo como esto:
Mapa de ubicaciones resultante
El sistema, además, tiene capacidad para integrarse con sistemas de monitorización de terceros, así como con sistemas de alerta específicos. En mi caso he realizado un procesamiento adicional, que consiste en realizar persistencia de datos para su análisis posterior, en este caso, mediante una hoja de Google Spreadsheet, lo que es interesante de por sí, y puede dar para otro artículo.
Este ejemplo de aplicación tiene bastantes aplicaciones prácticas: realizar seguimiento de activos en una zona exterior de una empresa, seguimiento de personas mayores en zonas urbanas sin coste de transmisión de datos, y con la capacidad de que emitar una señal de emergencia en caso de necesidad, o el seguimiento de visitantes en parques naturales y zonas boscosas, ya que como demostré hace algún tiempo, es posible cubrir zonas muy amplias en entorno forestal con un despliegue de infraestructuras mínimo. E incluso, que es lo que tenía en mente, un sistema para seguimiento de ciclistas o senderistas de montaña en zonas de montaña.
Etiquetas: chirpstack, dragino, lora, lorawan, microservicios, node-red
Medidor de entropía
