Despliegue de infraestructura y servicios de red en la residencia universitaria “ALBERTO JIMÉNEZ FRAUD”: despliegue de infraestructura, virtualización en contenedores y desarrollo del frontend de la aplicación de gestión "panel de residente"

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA GRADO EN INGENIERÍA DEL SOFTWARE DESPLIEGUE DE INFRAESTRUCTURA Y SERVICIOS DE RED EN LA RESIDENCIA UNIVERSITARIA “ALBERTO JIMÉNEZ FRAUD”: DESPLIEGUE DE INFRAESTRUCTURA, VIRTUALIZACIÓN EN CONTENEDORES Y DESARROLLO DEL FRONTEND DE LA APLICACIÓN DE GESTIÓN “PANEL DEL RESIDENTE” NETWORK INFRASTRUCTURE AND SERVICES DEPLOYMENT AT THE MÁLAGA UNIVERSITY’S DORMITORY “ALBERTO JIMÉNEZ FRAUD”: NETWORK INFRASTRUCTURE DEPLOYMENT, CONTAINER VIRTUALIZATION AND FRONTEND DEVELOPMENT OF THE MANAGEMENT APPLICATION “PANEL DEL RESIDENTE” Realizado por MELCHOR ALEJO GARAU MADRIGAL Tutorizado por PEDRO MERINO GOMEZ ALMUDENA DIAZ ZAYAS VICTORIANO FRANCISCO GIRALT GARCÍA Departamento TECNOLOGIA ELECTRONICA UNIVERSIDAD DE MÁLAGA MÁLAGA, SEPTIEMBRE 2018 Fecha de defensa: El secretario del Tribunal! 3 4 Resumen: En la Residencia Universitaria “Alberto Jiménez Fraud”, se tratará la renovación de la instalación de internet por cable y el diseño y configuración de una instalación inalámbrica (WiFi), que facilite la conexión a internet de los residentes, con la adición de nuevos servicios para los mismos y, además, de mejorar la administración de la red. Aprovechando algunos servicios existentes, que se fueron añadiendo sobre la marcha, y otros nuevos, fruto de este trabajo y del trabajo complementario a este, se realizará un despliegue de servicios virtualizados de fácil administración. De entre los nuevos servicios, destacamos el “Panel del residente” que permitirá gestionar y centralizar los servicios actuales y los nuevos por venir, para uso de los residentes." La aplicación de la nueva infraestructura de red está dando buenos resultados entre los residentes. Para los administradores de la red, la gestión y monitorización de todo el equipamiento se ha simplificado usando un solo panel de administración. Los servicios virtualizados han sido simplificados de cara al mantenimiento, actualización y mejora de éstos, de tal manera que son más ágiles realizar cambios en ellos sin tener que realizar grandes cortes en el despliegue final." Palabras clave: Despliegue de red, redes inalámbricas, WiFi, despliegue de servicios, contenedores, docker, aplicación web, residencia, unifi" Abstract: In the University’s Residence “Alberto Jiménez Fraud”, we will make not only an upgrade to the wire network infrastructure, but also a design and configuration of a brand new wireless network infrastructure (WiFi) in which residents will be able to use internet easily. New services will be added for the residents, and the network administration will be improved too. With that new network infrastructure and benefiting from some already existing services, ones created over the days and others being new, as a result of this project and the complementary project, a deployment of virtualised services will be done, and will be easily administrable. 5 Between the new services, “Panel del residente” is the most remarkable which will allow to manage and centralise the current services and the new ones yet to come, whose target users are the residents." The results of applying the new network infrastructure are being really positive among the residents. For the network administrators, the new infrastructure can now be managed from one dashboard which allow them to simplify the tasks of monitoring and configuring all the equipment. The maintenance, update and improvement of the services have been simplified finally, allowing more agile changes in the services and avoiding big outages of the services in the production environment." Keywords: " Network deployment, wireless networks, WiFi, services deployment, containers, docker, web application, residence, unifi" 6 1. Introducción#9" Contexto#9" Motivación y objetivos#10" Estado del arte#11" Tecnologías#12" 2. Diseño, configuración y despliegue de la infraestructura de red#13" Descripción del estado inicial de la red#13" Obtención de requisitos de la nueva instalación#19" Toma de decisiones en base a los requisitos#20" Diseño y configuración de la red fija#23" Diseño de la red WiFi#25" Despliegue de nuevo cableado para el WiFi#29" Configuración de la red WiFi#30" 3. Requisitos del sistema software de gestión#33" Análisis#33" Metodología del desarrollo software#33" Requisitos#34" Modelo#38" Descripción de la API#41" 4. Desarrollo del frontend del software de gestión#44" Tecnologías, modularidad y consideraciones#44" Descripción de la interfaz de los módulos#47" ‣Módulo común#47" ‣Página inicial - Página de inicio de sesión#50" ‣Página resumen del blog#52" ‣Módulo para consumo de internet#54" ‣Módulo para historial de llamadas#59" ‣Módulo para partes informáticos#61" ‣Módulo para notificaciones#64" 5. Despliegue de servicios#67" Estado actual de los servicios#67" ‣dnsmasq#67" ‣Controlador Unifi#68" ‣Servidor Web#68" ‣Monitorización de servidores#69" 7 Nuevos servicios#70" ‣Servidor VoIP#70" Migración de servicios existentes a Docker#71" Preparando nuevos servicios para virtualizar#76" ‣Træfik#77" ‣Medidor de uso de internet#77" ‣Autenticación SAML#78" Despliegue de los servicios#79" ‣Træfik#81" ‣Bases de datos#82" ‣Servicios web#84" ‣Asterisk#88" ‣Servicios en la puerta de enlace#89" 6. Conclusiones y trabajos futuros#91" 7. Referencias#93 8 1. Introducción Contexto En los últimos años, el avance en las tecnologías de la información y la comunicación (TIC) ha sido enorme indudablemente. Tal es que, actualmente, la mayoría de trabajos dependen de ellos (de alguna forma), e incluso nuestras vidas se han visto influenciadas por las TIC. Además, en el área de la educación, las nuevas tecnologías están entrando en las metodologías de enseñanza, haciendo imprescindible su uso en las aulas, bibliotecas y en los hogares de los estudiantes." La modernización de las tecnologías en las empresas e instituciones publicas es necesario para seguir la ola de “la modernización” y sobrevivir en este mundo informatizado en constante cambio. Los estudiantes universitarios dependen, por tanto, de estas tecnologías y requieren que los espacios para ellos tengan de una conexión suficiente para sus tareas. Además las innovaciones ayudan al control de las instalaciones y facilitan los despliegues de WiFi y telefonía VoIP." La Residencia Universitaria Alberto Jiménez Fraud, sobre la que se centra la actividad de este proyecto, alberga unos 250 miembros de la Universidad. La mayoría son estudiantes de grado, pero también hay otros estudiantes y profesores. En un lugar como este resulta impensable no tener una instalación TIC adecuada para el uso y disfrute de los residentes, para poder trabajar y, además, para poder vivir. Un entorno como este, permite ofrecer un conjunto de servicios a los estudiantes, y dan cabida a renovar otro tipo de servicios que actualmente no ofrecen nada desde el punto de vista informático." Antes del proyecto, la residencia (de esta forma nos referimos a la residencia mencionada anteriormente) no disponía de un servicio WiFi suficiente para tantas personas y el servicio de telefonía, que se proporcionaba a través de la tradicional red de telefonía conmutada. En cambio, la instalación de cable de internet era bastante aceptable, pero su administración era algo manual. Todo esto hacía muy complejo la administración y el mantenimiento del despliegue de comunicaciones de la residencia." 9 •Servidor DNS: el propio dnsmasq hace de servidor DNS también, incluye también los dispositivos conectados, cada uno obtenía un dominio propio local." Como se puede observar, el servidor necesita dos tarjetas de red, y así es. Una es la que conecta con la infraestructura interna, anteriormente comentada; y la otra es la que conecta con el servicio de internet ofrecido por Ono/Vodafone. Este servicio inicialmente eran 50Mbps simétricos y se consiguió ampliar a 200Mbps simétricos, ambos de fibra óptica." A modo de ejemplo, para ilustrar la infraestructura, un usuario que se conecta por cable o por alguno de los puntos de acceso (que se comentará en breve), recibía una dirección IP del servidor DHCP. Al enviar un paquete, pasaba por los switches hasta llegar al servidor, que aplicaba las reglas de NAT (traducir la IP de origen y el puerto) y emitía el paquete hacia la puerta de enlace de Ono y volvía a aplicar otro NAT, para acabar finalmente en internet." Tratemos ahora la situación del despliegue de WiFi. Había repartidos por varios apartamentos unos routers neutros como puntos de acceso. Con router neutro nos referimos a routers que uno puede comprar en cualquier lugar, que no son de ninguna empresa telefónica y que sirven para cualquier tipo de servicio que trabaja a nivel de capa de red. Los puntos de acceso son los aparatos que trabajan sólo hasta nivel de enlace y emiten la señal inalámbrica. Se conectan al router a través de un cable Ethernet, y en algunos casos, a través de otro punto de acceso." Estos routers neutros tienen incorporados también la funcionalidad de punto de acceso (o AP para acortar). Repartidos por la residencia, se podían encontrar puntos de acceso de diversos modelos: la mayoría eran TP-Link WR841N(D), algunos TP-LINK WR1043ND que son mas potentes, y algún que otro OvisLink (de modelo desconocido) de peor potencia que el resto. La colocación de éstos era aleatoria, incluso algunos los movían los propios residentes sin notificarlo. En ambos casos, hacían que en algunas zonas no hubiera cobertura a penas, y en otras, los APs se interfirieran entre ellos." Para finales del primer cuarto de 2016, se consiguió comprar unos puntos de acceso Unifi AP-LR. Con ellos, se consiguió mejorar la cobertura, pero aún así no era suficiente." 16 En el gráfico superior se puede observar lo que se denominan como heatmaps de cobertura de WiFi en uno de los mejores bloques en cuanto a cobertura. El gráfico junta las tres plantas de un bloque (numerado como el 2º) y solo muestra la potencia de señal de todos los puntos de acceso pertenecientes a la residencia. Como se puede observar, una mitad del bloque se ve bastante desfavorecida por una calidad de señal muy inferior; mientras que en la otra mitad, la señal llegaba a casi todos los lugares. Otro factor importante a tener en cuenta es que los apartamentos de la izquierda (en el gráfico, los que están más abajo) están dando junto a la calle y las interferencias de los otros puntos de acceso de los bloques de pisos hace que la conexión sea peor." Los modelos de routers neutros que se han mencionado anteriormente, su objetivo no es el mercado profesional como se demanda en un lugar como este. En palabras de la web oficial del TP-Link WR841N, ”Excelente capacidad para mitigar la pérdida de datos a larga distancia y a través de obstáculos en una pequeña oficina o en una vivienda grande”[12], aunque no describe el modelo que se tenia en la residencia, da una idea de que el objetivo no es el uso profesional. Por tanto, estos routers neutros no eran los ideales para ofrecer una conexión por WiFi en la residencia." Como medida temporal, se permitió a los residentes traer sus propios aparatos para que ellos se pudieran conectar por WiFi, ante la falta de una instalación adecuada. Esta decisión traía consigo una serie de problemas, pasando por que la mayoría de 17 Heatmap de cobertura - Rojo mas potencia, Azul menos potencia residentes no saben como instalarlo y hacerlo funcionar, además, si alguno se desconfiguraba, podia hacer que dejara de ir la conexión de internet en parte o toda la residencia." Los dueños, muchos de ellos, solían traernos sus aparatos para que se lo dejáramos preparado para usar, pero otros lo enchufaban directamente y provocaban "el caos”. En el caso de que alguno se desconfigurase (incluyendo a los APs de la residencia) podían provocar el mencionado “caos”. Con esto nos referimos a que dichos aparatos volvían a su configuración inicial, donde tenían un DHCP ya que actuaban como routers. Para actuar como APs, se tenia que conectar el cable ethernet en el switch para LAN (justo lo contrario a lo común que es conectarlo en el puerto WAN o de internet). La configuración por defecto es ofrecer un servidor DHCP que funciona tanto por su WiFi como por su switch LAN, haciendo que los equipos de la residencia fueran a conectarse a este router (sin internet) en lugar del servidor de la residencia." Esta situación hace inviable el modelo actual de instalación WiFi, haciendo trabajar a los becarios en exceso, cuando las alternativas profesionales no requieren de tanto trabajo. Como ejemplo, los APs Unifi, aquellos mencionados anteriormente que se compraron, se manejan desde un panel de administración web centralizado, ayudando enormemente en el trabajo de administración de la red." La red WiFi de la residencia se ofrecía sobre una red abierta, y las redes de cada residente que traía su propio aparato era a elección de él mismo, aunque la mayoría eran con contraseña. El mayor problema de estas redes es que al ser abiertas no tienen ningún cifrado y ”la captura de estos paquetes de información es muy sencilla; utilizan programas que capturan los paquetes que viajan por la red, y que no son complicados de utilizar”[13]. Incluso se pueden realizar “honeypot”s que consiste en una persona (ladrón) que “crea una red WiFi abierta, muchas veces haciéndose pasar por un comercio o lugar conocido, para que nos conectemos a ella. E intentará robarnos la mayor cantidad de información posible”[14]." Por último, aunque el equipamiento para la infraestructura de cable era bueno, alguno de los switches dejaron de funcionar momentáneamente, en ciertas ocasiones. Además, uno de los conversares de fibra no era gigabit (1000Mbps), lo que podia provocar un cuello de botella." 18 Obtención de requisitos de la nueva instalación Después de analizar el estado inicial de la instalación, sus puntos positivos y negativos, se puede realizar una búsqueda de requisitos sobre como debería quedar la instalación final, que permitirá guiar en las decisiones para la implementación de la instalación." Los usuarios finales de la instalación serán los residentes, a cada uno de los cuales se les quiere proporcionar conectividad Wi-Fi, Ethernet y un teléfono VoIP. Suponiendo que cada residente tendrá al menos dos dispositivos (un ordenador y un teléfono), y sabiendo que la residencia puede albergar unas 250 personas, la instalación debería soportar 500 dispositivos conectados simultáneamente." Los residentes, como se ha comentado anteriormente, no solo estudian, también viven, por lo que la instalación debería ser capaz de soportar a residentes con casos de uso como videojuegos online o videos y música en streaming. La navegación por internet también es un requisito, pero requiere menos recursos que lo anterior por lo que se considera ya incluido." La seguridad es uno de los puntos mas importantes actualmente. La red WiFi, que se preve que será la más usada, debe estar protegida con WPA2-PSK o WPA2Enterprise (protocolos de protección y cifrado de una red WiFi)." Para evitar un flujo de paquetes innecesarios entre dispositivos por WiFi, reduciendo el uso de la red, se debería poder usar un mecanismo de aislamiento entre dispositivos y bloquear los mensajes de “broadcast” para éstos. Al ser una red grande, mantener el uso de los APs al mínimo es importante para tener una red estable y usable. Así se evitarían problemas como el del Chromecast a principios de 2018[15], en el que saturaba la red WiFi de los hogares por enviar demasiados paquetes por la red WiFi, saturándola." Con el objetivo de separar el tráfico de cada una de las redes y aumentar la seguridad, se debería implementar diversas VLANs, aislando los dispositivos por diversos segmentos. Dicha separación podría ser un segmento para la instalación VoIP, otra para el manejo de los switches y APs, y una última para el acceso a internet de los usuarios. Con las VLANs, se pueden crear redes virtuales que viajan 19 por la misma instalación pero dando la sensación de que son instalaciones distintas y separadas con un único punto en común." Toma de decisiones en base a los requisitos Conforme a los requisitos anteriores, en este apartado se detallarán las decisiones mas técnicas para el despliegue que influirán en los siguientes apartados." Lo primero que se pensó fue que había que pensar cuantos puntos de acceso iban a hacer falta y de que marca y modelo se comprarían. Y sobre lo primero dependenderian las necesidades de los switches. Teniendo claro estas decisiones, se podría empezar a pensar el resto de apartados de diseño y configuración." Se va a describir la estructura de los edificios de la residencia brevemente para que se entienda la gran problemática de una instalación WiFi en ella. La residencia se distribuye en 8 bloques: 7 bloques de 12 apartamentos y uno de 6 apartamentos. Cuatro van a una mitad (izquierda del mapa), los otros cuatro a la otra (derecha del mapa); separados por un pasillo ancho. Siete de los ocho bloques está dividido en dos, y en medio de la separación, se encuentra un pequeño pasillo." Los lados izquierdos de cada bloque (mirando desde la entrada, abajo de la imagen hacia arriba) tiene tres apartamentos en la planta baja (de 2 personas) y tres apartamentos en la segunda planta (de 4 personas), con dos plantas cada uno (dúplex). En los lados derechos de cada bloque, en cambio, hay dos apartamentos en la planta baja, dos en la primera planta y dos en la segunda; todos de tres personas. El bloque con una sola mitad, sigue la estructura del lado izquierdo." 20 Residencia Universitaria[30] En cada apartamento, solo hay una toma de pared de cable Ethernet. Eso incluye a los apartamentos de dos plantas, que solo hay toma en la planta superior." Resumiendo estos datos, tenemos que la residencia puede albergar como máximo a unas 260 personas como máximo en 90 apartamentos." Este es el reto a solventar: analizar cual seria la cantidad de puntos de acceso necesarios para una instalación a la altura para esta residencia, con tantos huecos y tan esparcida." " Una de las primeras ideas que se barajó, fue instalar un punto de acceso de pared en cada apartamento, al igual que algunos hoteles acaban haciendo (según informó un comercial de Ono/Vodafone). De esta forma, se conseguiría una gran cobertura en todos los apartamentos. En contra tenemos que al ser algo que está en la pared, y se debería colocar en un lugar próximo a la toma de cable, tenemos el problema de que podría sufrir muchos golpes de los residentes. Otro motivo por lo que se estuvo en contra es que la mayoría de ellos (de los modelos que se observaron) emiten la señal WiFi principalmente para una planta, por lo que los residentes de los dúplex (los apartamentos de dos plantas) podrían sufrir de mala cobertura en la planta inferior. Por lo que se descartó la idea de este tipo de puntos de acceso." Decidimos que usaríamos modelos de APs mas tradicionales, que se parezcan a los que la propia Universidad está usando actualmente. Con estos modelos, los APs se podrían colocar en lugares donde sufran menos de golpes accidentales, incluso deberían bastar para llegar a la planta inferior de los dúplex. Este tipo de APs son bastante mas potentes que los anteriores, incluyendo los modelos pensados para baja densidad de dispositivos. Esto nos llevó a la idea de que un punto de acceso por apartamento iba a ser demasiado, ya que estos modelos emiten con mayor potencia, podrían llegar a más lugares, pero a la vez podría haber mucha interferencia entre ellos." 21 Siguiendo con el mismo modelo de punto de acceso, plantemos si poner un punto de acceso por cada dos apartamentos o un punto de acceso por cada tres. Ahora entra en juego como seria la cobertura de los puntos en un entorno real para saber responder a esta pregunta, por lo que hay que decidir marca y modelo de AP para poder ir a la siguiente fase." Aunque partíamos de la idea de usar Cisco Meraki para los puntos de acceso, acabamos decidiendo que iba a ser mejor opción usar Ubiquity Unifi por tener ya algún equipamiento de esa empresa de antes, además de haber comprobado que su rendimiento era el adecuado para el tipo de despliegue que se necesitaba." Ahora quedaba elegir qué switches íbamos a usar para el despliegue, para complementar la instalación. Inicialmente se sugirió usar switches de Cisco, pero como los puntos de acceso iban a ser de Ubiquity Unifi, iba a ser mejor opción usar switches de la misma marca para tener una mejor integración en la instalación y en el panel de administración de Ubiquity." Un requisito indispensable para los switches es que debían de ser de 48 puertos mínimo, y tener 4 de estos. El porqué se debe a que, como se comentó en el apartado “Descripción del estado inicial de la red”, hay que repartir internet a 48 apartamentos para una mitad y otros 42 para la otra mitad de la residencia. Además, al añadir puntos de acceso, se necesitarán más cables para éstos. Poniéndonos en el peor caso de un AP para cada dos apartamentos, se necesitarían 24 cables extra en la primera mitad y 21 cables extra para la segunda. El total se resume en la siguiente tabla:" Por tanto, dos switches para cada mitad: uno dedicado a apartamentos y otro dedicado a los puntos de acceso." Mitad 1 Mitad 2 Apartamentos 48 42 Puntos de acceso 24 21 Total puertos en switches 72 63 22 Además, existen dos puntos de acceso fuera de los apartamentos: uno en la sala de estudios y otra en el salón de actos. Para hacer llegar internet a esta sección, con un switch de 8 puertos bastaba (es lo más pequeño que se puede encontrar)." Resumiendo, se decidió lo siguiente respecto a la instalación nueva de red:" •1 AP por cada dos o tres apartamentos" •APs de Ubiquity Unifi" •4 switches de 48 puertos de Ubiquity Unifi - 2 por mitad" •1 switch de 8 puertos de Ubiquity Unifi" Diseño y configuración de la red fija Este es uno de los puntos más importantes de la red, ya que es la parte de la infraestructura que soporta al resto. Por lo que un buen diseño hará que dé un buen resultado la red por cable." Como se comentó al principio de la sección “Descripción del estado inicial de red”, el diseño inicial fue creado por un grupo del Servicio Central de Informática de la 23 Gráfico que describe la distribución de la red fija (o de cable) Universidad, por lo que vimos adecuado replicar la estructura para el nuevo despliegue, pero adaptándolo a los nuevos dispositivos y sus posibilidades." La nueva distribución, que se describe visualmente en el gráfico de la anterior, consiste en que el servidor se conecta al primer switch de la primera mitad. Éste se decidió que repartiera la conexión a los 48 APs de la misma mitad. Por enlace de fibra, se conectaba con el segundo switch de esta primera mitad y con el switch de recepción (que luego se comentará). Los switches de este modelo tienen todos 4 puertos adicionales. Por lo que, estos puertos se usan para los enlaces de fibra switch-switch." El segundo switch tenia todas sus puertos ocupados con los 48 apartamentos. Por lo que se conecta con el primer switch de la otra mitad de la residencia mediante enlace de fibra, usando esos puertos adicionales." El de la segunda mitad reparte conexión a los 42 apartamentos de esta mitad de la residencia. Y, por enlace de fibra, se conectaba con el segundo switch." El segundo switch de esta mitad reparte la conexión a los puntos de acceso de esta segunda mitad." Por último, el switch de recepción. Como se comentó, iba a ser inicialmente un switch de pocos puertos, pero a la residencia apareció un Unifi EdgeSwitch de 48 puertos. Éste es de otra linea de productos, por lo que no se conecta con el panel de Unifi, y se configura manualmente mediante su propio panel. Continuando con la descripción de la topología, este switch por fibra recibe la conexión y la reparte a los puntos de acceso de la sala de estudios y el salón de actos, además de tres teléfonos VoIP." Respecto a la configuración de la red, distinguimos 4 redes, que se implementan sobre VLANs:" •Red de administración: es la red que usan los switches, puntos de acceso y el controlador Unifi para comunicarse y controlar la red." •Red WiFi: es la red que usan todos los usuarios que se conectan por WiFi." •Red cableada: es la red que usan todos los usuarios que se conectan por cable al teléfono del apartamento[16], los teléfonos ofrecen un puerto extra para conectarse por cable a la red, y éste etiqueta el tráfico de ese puerto de forma distinta al del VoIP." 24 •Red VoIP: los teléfonos VoIP son los que usarán esta red para la comunicación con la centralita y entre los teléfonos." Una vez descritos el objetivo de las redes, se va a describir la configuración más técnica de cada una, mediante la siguiente tabla:" En la tabla anterior, se puede ver cuales son las redes IPv4 (descritas por IP de la red y máscara), la puerta de enlace, el numero de la VLAN, si los switches hacen aislamiento entre dispositivos y si el DHCP es estático. Con esto último se está refiriendo a que el DHCP en modo estático no ofrece una IP si no está dentro de una lista definida manualmente. De esta forma, es más difícil que una persona se conecte a una de esas redes y que le funcione." Diseño de la red WiFi Para empezar con esa fase, el Servicio Central de Informática nos proporcionó un mapa de cobertura que realizaron mediante una simulación con el software Ekahaut sobre la banda 2,4GHz, suponiendo que los puntos de acceso serian los Unifi AC Lite. Además, nos recomendaron usar este modelo de puntos de acceso ya que veían que iban a ser idóneos para el despliegue." Sobre este modelo de APs, uno solo es capaz de soportar a 200 clientes en condiciones normales tanto en 2,4GHz como en 5GHz, según el documento de especificaciones del modelo[17], además de que su alimentación se realiza sobre el propio cable de internet (Power over Ethernet)." La simulación, realizada por el SCI, consistía en colocar dos puntos de acceso por módulo formando una diagonal. Con módulo se refiere a una mitad de un bloque, y la diagonal es colocar uno en la planta baja y en un lado del módulo, y el otro en la segunda planta en el lado opuesto del módulo. El dibujo de la esta siguiente página Administración WiFi Cableada VoIP Red IPv4 10.10.10.0/24 10.10.0.0/21 10.10.20.0/24 10.10.11.0/24 Puerta de enlace 10.10.10.254 10.10.0.1 10.10.20.1 10.10.11.254 VLAN No 10 15 7 Aislamiento No Si No No DHCP Estático Si No No Si 25 Para su funcionamiento, se requiere de un servidor RADIUS, que permite identificar al usuario. Este servidor lo provee la Universidad, y los puntos de accesos intentan autenticar directamente con éste. La red eduroam usa un sistema de autenticación por universidades, y para conectarse con otros países, se hace a través de los servidores del NREN (National Research and Education Network) del país correspondiente. Por tanto, nuestro servicio se conecta a un servidor RADIUS que redirecciona las peticiones al servidor correspondiente dependiendo del dominio que tenga el email del usuario." Para los invitados, o aquellas personas que no hayan configurado aún la red eduroam, se implementará un portal cautivo en esta red para poder identificar a cada uno de los usuarios y limitar el uso que hacen de la red." Todo el tráfico de la red WiFi va por la VLAN 10, que se explicó en “Diseño y configuración de la red fija”.& 32 3. Requisitos del sistema software de gestión Análisis Vivimos en un mundo donde todo está en internet, que nos ofrece la comodidad de poder hacer o ver cosas desde tu ordenador o móvil, centralizado en nuestros dispositivos. Para la residencia, poder ofrecer un conjunto de servicios y que se puedan ver desde tu apartamento es posible gracias a la nueva instalación de cable e inalámbrica, y las facilidades que ofrecen los contenedores. Además, agrupar diversos servicios, inicialmente separados, en un solo lugar ayuda a visibilizarlos. Y poder informatizar algún servicio que actualmente no lo es, permite simplificar las gestiones de ellas y dar comodidad de uso." Actualmente tenemos datos de uso de tráfico por dispositivo, un servicio de partes informáticos, el blog de temas relacionados con la residencia, o nuevos datos como los que ofrece el servicio de telefonía ahora son elementos que podrían estar presentes en dicho software que pueden interesar a los residentes. Tenerlos en un mismo lugar puede facilitar a los usuarios encontrar todo esto y poder ver esa información en cualquier lugar, sea en la residencia o fuera." Además, este software no debería ser cerrado, si en el futuro se quiere extender, debería poderse extender sin mucha dificultad. Para este trabajo no se va a poder abarcar muchas de las ideas que puedan surgir, este punto es importante para que los futuros estudiantes que trabajen en el área de informática de la residencia puedan ampliarlo con las ideas no contempladas en dicho trabajo o con sus propias ideas." Metodología del desarrollo software Para esta fase del trabajo, se usará una metodología basada en Scrum. La toma de requisitos se realizará mediante obtención de lo que se denominan “User Stories”, que pueden ser uno o varios requisitos de las metodologías mas clásicas. De los requisitos, se obtendrá un modelo para la base de datos que servirá para el backend que realiza Antonio para almacenar información. Con el modelo realizado, se definirá un conjunto de endpoints de la API para que no haya discrepancias entre 33 el backend y el frontend, que realizo yo. Esos endpoints son las rutas disponibles en el servidor que permiten realizar el intercambio de información y realizar acciones entre el backend y el frontend." El proceso de desarrollo del servidor web se podrá encontrar en la sección «Desarrollo del backend de la apliación "Panel del residente”» del trabajo de Antonio Ángel. El trabajo del frontend, en cambio, se encontrará en la siguiente sección. De esta forma, cada uno trabajará independientemente en cada una de sus tareas, pero podrá dar opinión sobre las historias de usuario o la especificación de los endpoints en cualquier momento." En la ultima fase, habrá que hacer un proceso de pruebas manuales para comprobar que todo funciona correctamente y que la integración entre ambos componentes es correcta." Requisitos En este apartado, se expondrán los requisitos recabados para esta aplicación web. Al seguir una metodología Scrum, los requisitos serán “historias de usuario”, que son puntos más genéricos, que incluyen más información sobre lo que se pide, pero permite poder modificarlos o extenderlos más fácilmente que los requisitos clásicos. Estos requisitos están muy bien estructurados y definidos, pero que en muchas ocasiones realizar un cambio sobre ellos conlleva a hacer una reestructuración de algunos de ellos, tal y como hemos comprobado en los trabajos de los estudios de la carrera." Desde la primera versión hasta la final, han habido diversos cambios y mejoras en estas historias de usuario, siguiendo la agilidad de la metodología SCRUM, que han permitido obtener el siguiente estado de ellos. Estos son los “requisitos” finales de la aplicación:" •Aspectos generales de la aplicación web •La aplicación web debe ser modular, permitiendo su extensión fácilmente." •La aplicación debe poder usarse desde una navegador web en cualquier dispositivo." 34 •La aplicación está perfectamente en dos partes, se debe garantizar la interoperabilidad entre ambas mediante el estilo arquitectónico REST y usando el formato de intercambio de datos JSON:" -La parte visual - Interfaz de Usuario - con la lógica de control de la interfaz, a la que llamaremos frontend." -La parte de lógica de negocio y base de datos, con las operaciones específicas de ésta, a la que llamaremos backend." •Permisos de la aplicación •En la aplicación se distinguen varios roles, cada uno de ellos determinará las acciones que el usuario puede llevar a cabo en esta. Los roles principales serán:" -Administrador" -Residente" -Personal de la UMA no residente" -Personal de administración" •Los permisos se distinguirán cada módulo, dentro de un módulo habrá páginas y dentro de cada página habrá uno o varios permisos. Por tanto, se dirá que un rol tendrá X permiso sobre el módulo A y la página B." •La visibilidad de los módulos y los distintos apartados dentro de un módulo dependiendo de los permisos que tenga el usuario debe poderse obtener mediante la API." •Módulo de consumo de internet •La aplicación permitirá ver el consumo de internet de cada uno de los dispositivos ligados a un residente. Cada usuario podrá identificar a la aplicación cuales son sus dispositivos entrando a este módulo con cada uno de sus dispositivos y con su cuenta. Se mostrarán gráficos de consumo de internet por cada uno de sus dispositivos identificados e información relacionada a cada uno, como consumo agregado, dirección IP, etc." •Los administradores pueden ver todos los dispositivos asociados, para ver información sobre ellos o realizar acciones sobre ellos." •Si un usuario reclama que su dispositivo, siendo suyo, no puede encontrarlo en la página, porqué alguien se ha apropiado de él, podrá notificarlo a los becarios de informática y realizar el cambio de “dueño”." 35 •Sobre consumo agregado, se podrá ver dicho consumo en un rango de fechas, que va de 1 día hasta 1 semana, con una precisión de 1h hasta 1 día, o de 1 día hasta 1 mes con precisión de 1 día." •Para los datos en tiempo real, el rango oscilará entre dos valores X e Y. X será del momento actual hasta 1 día, 23 horas y 59 minutos antes; el valor de Y será de 1h antes hasta 2 días. La diferencia en el rango debe ser mínimo de 1 minuto. La precisión será de 1s hasta 1 hora." •Módulo de resumen para el WordPress •Una sección que muestre un resumen de las últimas noticias del blog, cargando el RSS de éste, y mostrando un enlace para acceder a él. También se mostraría los métodos para mantenerse informado." •Módulo de historial de llamadas •Un usuario residente será capaz de ver el historial de llamadas de su apartamento." •El personal de administración debe ser capaz de ver el historial de llamadas de cualquier apartamento." •En cualquier caso, debe haber un filtrado por fecha y número de teléfono del otro extremo." •Módulo de incidencias informáticas •La notificación y gestión de incidencias informáticas debe hacerse a través de la aplicación. Existirá un formulario que un usuario del sistema pueda rellenar para notificar la avería o el problema, o simplemente hacer una consulta informática. Los administradores pueden ir actualizando el estado de la incidencia y los usuarios, hacer su seguimiento." •En la página de una incidencia, los administradores serán capaces de modificar el estado del mismo. Al realizar un cambio de estado, deben escribir un mensaje que explique el motivo." •El usuario puede descartar en cualquier momento una incidencia, explicando la razón de tal descarte." •Además, los administradores pueden ver cuales son las incidencias activas y resueltas." •Los estados que puede tener una incidencia son:" -Pendiente: nueva incidencia, esperando a que algún becario lo vea" 36 -Esperando: incidencia lista para ser arreglada, pero no pueden ir aún (no pueden ir por no ser la hora de disponibilidad o no están disponibles ningún becario)" -Trabajando: algún becario está trabajando en ello" -Esperando a usuario: se espera alguna respuesta del usuario por algún motivo" -Resuelto: la incidencia se ha resuelto" -Descartado: el usuario ha descartado la incidencia" -No se arreglará: por algún motivo (razonable), la incidencia no se va a arreglar" •Notificaciones y módulo de notificaciones •La aplicación enviará notificaciones a los usuarios antes distintos eventos que ocurran en el sistema. Esta contará con distintos métodos de notificación:" -Correo institucional UMA, método de notificación por defecto." -Bot de telegram, el bot mandará a los usuarios con los que mantiene conversación las notificaciones oportunas" •Cada usuario puede seleccionar qué medios de notificación desea, y tener varios (o ninguno activo). Como mínimo se tendrán las notificaciones in-app." •Dentro de la aplicación habrá un “centro de notificaciones”, desde donde se pueden consultar todas las notificaciones (pendientes, vistas…)." •Una notificación ya vista será borrada al cabo de un tiempo prudente. (1-3 meses)." •Gestión de la sesión •Cualquier usuario de la aplicación a excepción del personal de administración, debe identificarse en la aplicación usando sus credenciales de iDUMA. El personal de administración empleará unas credenciales para la autentificación usando un directorio propio." •La sesión se mandará en cada petición en la cabecera HTTP en la forma de token JWT. La validez de un JWT será de 2 días." -En una respuesta HTTP se mandará una cabecera de extensión cuando el token esté a punto de expirar, esto es, cuando le queden 1h. " 37 -Se usará una cabecera HTTP con valor a 1, y aconseja al cliente que pida un token nuevo en una ruta específica (descrita más abajo) y empleando el token que tiene aún válido." -La ruta será /renew_token, y a esta se le hará simplemente una petición GET (con el campo de la cabecera Authorization: Bearer JWT_TOKEN) y la respuesta será un JSON: { token: NEW_TOKEN }" -Habrá una ruta disponible que le permitirá renovar el token al cliente, empleando access token para entonces aún válido. El token nuevo que se proporcione, tendrá una validez de 2 horas desde el momento de su expedición. Si el token ya ha sido renovado, el aviso de expiración se hará cuando a este le queda 30min en el caso del token de 2h." •El mecanismo de persistencia del token JWT en el cliente será empleando la API local storage/session storage del navegador web." -local storage permite mantener la sesión incluso si cierra la pestaña o el navegador" -session storage, en cambio, cierra la sesión al cerrar las pestaña de la web" -Permite implementar el mecanismo de “recuerdame”" •Si un cliente realiza una petición al servidor para realizar una acción, pero el usuario que lo realiza no tiene permisos, debe fallar la petición indicando que no tiene permisos para realizar dicha acción." •En el frontend, si intenta acceder a una página que no tiene permisos, aparecerá que la página no existe." Modelo Para este proyecto, el modelo de datos debe poder permitir almacenar toda la información descrita anteriormente en una base de datos. Pero, los datos de consumo y llamadas telefónicas se encuentran disponibles en otras base de datos, a las que la aplicación se conectará para obtener esa información." El modelo siguiente solo representará los datos que manejará directamente la aplicación web, otros datos como el historial de llamadas o consumos de internet se encuentran en otras bases de datos." 38 39 Modelo relacional de la base de datos - Antonio Ángel El modelo lo ha realizado Antonio Ángel, aunque el modelo inicial fue un trabajo en equipo." El centro del modelo es la entidad Usuario. Esta entidad almacena la suficiente información del usuario para que pueda usar la aplicación. El NIU, su nombre y, si es residente, el número de apartamento son los datos necesarios. Para los usuarios de la administración de la residencia, al no ser personal de la universidad, se debe ofrecer un inicio de sesión alternativo. Eso está recogido en la entidad Credenciales, cuyo NIU será uno cualquiera que no interfiera con los de la Universidad (como por ejemplo números bajos como el 1, 2, 3…)." Los permisos están recogidos en las entidades Rol y Permiso (con la relación de muchos a muchos representada por la entidad rol_has_permiso). Por tanto un rol determinado tendrá un conjunto de permisos, y esos permisos se pueden ir repitiendo entre los diversos roles. A su vez, cada Usuario está relacionado con el rol al que pertenece. Los permisos contienen tres claves que permiten determinar a donde pertenece el permiso y cual es. Los atributos module_name y page_name identifican donde pertenece el permiso permission. El módulo identifica un grupo de datos y acciones relacionados, como puede ser los partes de informática. La página, que está más relacionado con el frontend, permite poder entrar en una o varias secciones del módulo." Sobre notificaciones, estas se almacenan en la base de datos en la entidad Notificacion. En ella se almacenan el título, la fecha y si se ha leído o no, además de a quién va dirigido la notificación. Opcionalmente se puede almacenar un cuerpo, con contenido que describa más la notificación, y un enlace, en caso de que se conozca el origen de la notificación." El sistema de notificaciones tiene diversos canales para distribuirlas, como se ha comentado ya. Para configurarlas, se han creado cuatro entidades de las cuales tres “heredan” (usando el mismo concepto de herencia de Orientación a Objetos) de una. Esta super-entidad es base_notificación que relaciona un usuario con una configuración, además de indicar si está activo o no ese canal. De esta, sale una configuración para Telegram, otro para los Correos y una última para notificaciones 40 PUSH (aunque no se usen, el sistema esta preparado para añadir este nuevo canal). Para el canal de correos electrónicos no se almacena ningún dato adicional, pero para poderlo identificar dentro del backend, se debe crear dicha entidad. Para Telegram, hay que almacenar el chat_id (o user_id, que son el mismo identificador) para poder enviar mensajes directos al usuario." En el sistema de partes informáticos también se debe modelar, y lo encontramos con las entidades ParteInformatica y Seguimiento. El primero, ParteInformatica, almacena la información necesaria para un parte. Contiene el tipo de parte (is_wifi, is_wire y is_other) donde se puede seleccionar más de un tipo a la vez. También incluimos una descripción del problema o consulta, que es obligatoria, la fecha de creación, el estado en el que se encuentra el parte y una disponibilidad en forma de horarios almacenados como json (availability_json). Este último permite al usuario que crea el parte dejar anotado su disponibilidad horaria para que se pueda resolver lo antes posible. El formato del JSON se especificará en la API. Por último, cada parte está relacionado con un usuario, que es su creador. El seguimiento sirve para ver el historial de modificaciones del estado del parte, y poder visualizar los cambios del mismo. En un seguimiento, almacenamos la fecha de cuando se realizó esa modificación, un mensaje que indica el motivo del cambio, y, si hay un cambio de estado, se almacena también el estado en el que se encontraba el parte antes de modificar. De esta forma, se puede observar el flujo de transiciones de estado del parte." La última entidad es Dispositivo. Esta entidad permite relacionar un usuario con un dispositivo de la residencia. Permite ofrecer la utilidad de ver los consumos de internet al saber cuales son los dispositivos del usuario. Lo importante de la entidad es la MAC (o dirección MAC) que es la que permite la identificación. Los otros dos atributos sirven como caché, para acceso rápido de esos datos." Descripción de la API La base común entre el backend y el frontend es la API que expone el primero que consumirá el segundo. Se describirá cual es esta especificación, que 41 Para React, se han definido algunos componentes que se pueden reutilizar tantas veces como sea necesario. Algunos son componentes de Bootstrap convertidos para su fácil uso en React, como botones[56], modal[57] o collapse[58]." Para comunicarse con la API del backend, se ha definido una pequeña biblioteca que simplifica la comunicación con éste. El uso de estos métodos dentro de una acción de redux (código que permite modificar el estado del módulo) debe meterse dentro de un decorador (del patrón de diseño decorador) que captura los errores y los almacena en redux, de esta forma se evita repetir código para errores, y cualquier componente puede conocer que ha habido un error usando siempre el mismo mecanismo (ver el estado de los errores)." Este módulo, además, escucha a las nuevas notificaciones que puedan aparecer mientras el usuario usa la aplicación. Ya que es un comportamiento que se va a compartir entre todos los módulos, se ha decidido colocarlo en este componente común. Al recibir una nueva notificación, la mostrará en una esquina del navegador (como una notificación), a la vez que incrementará el contador de notificaciones no leídas (se encuentra en la parte superior de una página, a la derecha)." Sobre esta cabecera, el botón de “Salir” permite cerrar sesión en cualquier momento. El texto de la izquierda “Inicio” indica el nombre del módulo en el que te encuentras. Esta cabecera siempre aparece en todos los módulos." También se ha colocado una barra de navegación entre los distintos módulos, y el mismo módulo en el que uno se encuentra. Se encuentra a la izquierda del navegador (captura derecha abajo), y en los móviles se muestra mediante un botón que aparece al lado del texto de la izquierda de la cabecera (captura derecha arriba)." Por último, también se encarga de preparar la detección del idioma del navegador para poder mostrar los textos en 48 el idioma del usuario (si está disponible)." Hay un componente llamado App que es el encargado de realizar la mayoría de las tareas descritas anteriormente. La barra de navegación, la cabecera, las notificaciones, los estilos base (CSS), el sistema de rutas, que muestra las páginas dependiendo de la ruta del navegador, y la comprobación de permisos son tareas que realiza este componente. App se muestra siempre y es antecesor de cualquier página del sistema de rutas." En el caso de que una página no exista (o el usuario no la pueda ver), la página que se muestra también esta incluida en este módulo. También, durante la comprobación de los permisos y de la sesión, si ocurre un error, se mostrará otra página que está incluida en este modulo común también." 49 ‣Página inicial - Página de inicio de sesión" 50 (↑) Página de inicio de sesión, con las dos modalidades" (↓) Página inicial después del proceso de inicio de sesión Para que los usuarios puedan iniciar sesión a través del mecanismo de autenticación SAML de la Universidad, se ha preparado un botón que permite empezar el proceso de autenticación. Con un sencillo click, redirigirá a la ruta / alberginia que es el que empieza todo el proceso. Al final del proceso, como se ha descrito, la aplicación web recibirá un token dentro de los parámetros de la URL, que la aplicación almacenará dentro del localStorage o sessionStorage, dependiendo de si se ha apretado el botón de recordar o no (respectivamente). En el caso de que el usuario viniera de algún otra página y haya acabado en la página de inicio de sesión por haberle caducado la sesión, se intentará redirigir a la página en la que se encontraba anteriormente." En la página de inicio de sesión también encontramos un modo alternativo de inicio de sesión. Este modo es para la administración de la residencia, ya que no son usuarios de la Universidad, necesitan de un método alternativo de inicio de sesión. Este método es el tradicional usuario y contraseña, con las mismas funcionalidades que el anterior método, aunque el token de la sesión se obtiene en la misma respuesta de comprobación de las credenciales. Esa comprobación se realiza directamente al backend de la aplicación web." El botón de abajo de ambas capturas permite cambiar entre ambos métodos de inicio de sesión, que se realiza al momento." Si hay ya un usuario que haya iniciado sesión, esta página se convierte en una especie de escritorio con enlaces a los diversos módulos y páginas donde el usuario tiene permisos para acceder, además de un módulo extra con enlaces rápidos a páginas de la web de la Universidad que pueden ser útiles a los usuarios." 51 ‣Página resumen del blog" " 52 Este módulo es un acceso para el blog en WordPress. Al entrar, se le mostrará al usuario una lista de últimas entradas del blog, a modo de resumen sin tener que entrar en el blog para visualizarlos. Al clickar en una “tarjeta” de un post, se abrirá una nueva pestaña con la entrada completa. Encima de este listado, se encuentran dos botones: grande y azul para ir al blog, mas pequeño y gris para ir a otra página." Esta otra página explica al usuario diversas maneras de recibir notificaciones cada vez que se publica una entrada." 53 ‣Módulo para consumo de internet" 54 Panel con dispositivos y gráficos Gráfica de tiempo real con selector de rango de tiempo " " 55 Datos hora a hora de la última semana sobre velocidad media Datos hora a hora de la última semana sobre consumo agregado " 56 Gráfica día a día del mes sobre consumo agregado Panel de administración (listado de dispositivos) " En el módulo de consumo de internet, un residente es capaz de visualizar diversas gráficas sobre los datos que se obtienen del uso de internet que realizan sus dispositivos. En la parte superior de la página encontrará una lista de pestañas con cada uno de los dispositivos asociados a su cuenta. Al hacer click en alguno, aparecerán las gráficas. Además, la URL se modificará permitiendo recargar la página o llevarla a otra pestaña (copiando y pegando) sin perder el dispositivo seleccionado. En caso de entrar con una URL inválida o con un dispositivo que no es del residente, no hará nada." La primera gráfica que encontramos muestra en tiempo real el consumo de ancho de banda del dispositivo. En la gráfica, hay un campo que permite seleccionar el rango de fechas a mostrar en el gráfico. El rango usa fechas relativas al momento actual, este es el motivo por el cual la fecha más próxima a la actual está más a la derecha, y la más lejana a la izquierda, expresando así el paso del tiempo y siguiendo el mismo esquema que la gráfica. El campo escala sus valores máximo y mínimo de acuerdo a los valores actuales, permitiendo dar mayor precisión cuando ambos valores del campo son próximos, y menor precisión cuando la diferencia es mayor. El valor más antiguo que se puede obtener es de 1 día." 57 Panel de administración con filtrado (más botones de la tabla) ‣Módulo para notificaciones" " 64 Configuración de notificaciones Configuración de notificaciones, con el código de activación para Telegram " 65 Listado de notificaciones sin leer Listado de todas las notificaciones El módulo de notificaciones permite al usuario configurar los canales de notificaciones y ver sus notificaciones, sin leer o todas." En la configuración, con un simple click se puede activar o desactivar los canales de notificación disponibles. En cada canal se incluye una breve descripción de a donde se envían las notificaciones y debajo la casilla para activar o desactivar dicho canal. En el caso de Telegram, antes de poder usar ese canal hay que configurarlo. Para ello, tal y como se muestra en la segunda captura, el usuario debe hablar al bot (el que aparece es un ejemplo, no es uno real) y le debe enviar el código que aparece en pantalla, y después debe apretar el botón de “Comprobar activación” que le notificará si el proceso ha funcionado correctamente." En el listado de notificaciones sin leer, que corresponde con la tercera captura, permite ver dichas notificaciones e interactuar con ellas. Si las notificaciones contienen un enlace, se mostrará como “Ver más”. Al apretar el enlace, se marcará como leído. En el resto de notificaciones, se puede marcar como leído con el botón verde. El botón rojo de “Descartar” permite eliminar la notificación completamente del sistema." En el listado de notificaciones, el usuario puede ver todas las notificaciones (leídas y sin leer), y hacer las mismas operaciones que en el listado de notificaciones sin leer." 66 5. Despliegue de servicios Estado actual de los servicios Empezaremos describiendo los servicios actuales en la residencia, como están instalados y funcionando, y como podría ayudar el uso de virtualización mediante contenedores." Actualmente, en la residencia, tenemos un conjunto de servicios que sustentan la residencia o complementan las actividades de los residentes. Una buena parte son servicios web, pero otros son servicios de sistemas y redes." ‣dnsmasq" Tenemos primero el servicio de DHCP + Caché DNS que, como se ha mencionado diversas veces en la sección 2 (Diseño, configuración y despliegue de la infraestructura de red). Es un servidor que ofrece DHCP (para IPv4) a las distintas redes de la residencia, para que los dispositivos reciban su IP asignada (estática o dinámicamente). Además, tiene un servidor DNS que almacena localmente copias de entradas DNS para una mayor respuesta a nivel local, además de tener en su registro los dispositivos que se les ha asignado una IP por DHCP (y hayan dado un nombre de dispositivo - conocido como hostname). Es un elemento esencial de la red que permite a todos poder configurar sus dispositivos automáticamente, incluyendo teléfonos VoIP, switches y APs." Virtualizado serviría para hacerlo portable, fácilmente instalable y se reducirían los tiempos de despliegue en caso de fallo. Pero nos quitaría de actualizaciones 67 dnsmasq Controlador Unifi nginx php-fpm MySQL WordPress Medidor de consumo de internet PostgreSQL + timescaleDB netdata Gráfico con los servicios actuales que se pueden virtualizar, agrupados en columnas por relación automáticas de seguridad que vienen con Ubuntu Server y la estabilidad que ofrece este paquete, además de la fuerte dependencia con las interfaces de red del sistema host. La configuración del servidor, teniendo una copia de los archivos de configuración, solo sería copiar y pegar. Con estos pros y contras, veo que no seria necesario virtualizar el servicio ya que actualmente como está, va bien y no da problemas." ‣Controlador Unifi" El siguiente servicio es el controlador Unifi. Es el que se encarga de gestionar los APs y los switches (menos el de la zona de recepción). Además nos permite poder ver el estado de todos ellos, configurarlos, actualizar su firmware…, a través de un panel web. El controlador usa diversos puertos para el control de los dispositivos." También podría ser buen candidato para virtualizar, pero debido a que, al igual que el servidor DHCP, necesita acceso directo a la red de los switches y APs, dificulta su proceso. Existe dos métodos para poder usar este servicio en un contenedor: uno es usar las mismas redes que el del sistema (exactamente igual que como está ahora) y que no es compatible con orquestadores de contenedores como Kubernetes o Docker Swarm, o usar una red macVLAN[19] que permite conectar el contenedor directamente a una red real y es compatible con orquestadores. Aunque, en mi opinión, posiblemente sea más difícil montar todo el sistema virtualizado que dejar el servicio tal y como está. Existe un ejemplo de contenedor que permite ambos modos de red[20]." ‣Servidor Web" También tenemos una web. La web está dividido en diversos elementos, por lo que primero describiremos el servidor web al que se conectan todos los usuarios. El servidor es un nginx[21] que sirve archivos estáticos que se encuentran en la carpeta de archivos web. Además tenemos un WordPress donde se publican algunas circulares, información que ofrecen los becarios (si lo desean) o ciertas noticias relacionadas con la residencia. Este usa también nginx, aunque delega gran parte del trabajo a PHP por ser una aplicación web hecha en PHP." Este servicio se podría dividir en un proxy inverso (un servidor web que redirecciona peticiones web a otros servidores dependiendo de cual sea), otro para los archivos 68 estáticos de la web y otro para WordPress con un apache + mod_php (ya que WordPress se lleva muy bien con este tipo de configuraciones). Para el proxy inverso se usaría træfik[22] que se define como “The Cloud Native Edge Router”[22]. Este software permite el auto-descubrimiento de servicios y su configuración mediante parámetros que se ofrecen dentro del mismo descubrimiento. Con este træfik, añadir y quitar partes de la web será tan fácil como ejecutar y parar contenedores. Para los archivos estáticos, se podría usar nginx también, ya que es bastante ligero. Para WordPress[23], ya se ha descrito que contenedor se podría usar. Además éste requiere de una base de datos MySQL[24] o MariaDB[25], por lo que añadir uno al despliegue es bastante fácil: con solo escribirlo en un archivo que describe los servicios es suficiente (más adelante se comentará sobre esto)." Dentro del servidor web, también tenemos una pequeña web que muestra el consumo de ancho de banda que está haciendo el dispositivo con el que accedes al mismo, siempre que el dispositivo está dentro de la residencia. Para su funcionamiento, requiere de una aplicación que capture el tráfico, lo clasifique, calcule el consumo y lo almacene en una base de datos. Este servicio pasará a ser parte de la aplicación web que se describirá más adelante en este trabajo." Por lo que la parte de la web, se describirá en esa sección como quedaría, pero la aplicación que mide el uso se va a colocar en un contenedor en el servidor/puerta de enlace. Además, esta aplicación requiere de una base de datos PostgreSQL[26] con la extensión timescaleDB[27], ya que almacena la información con tiempo y dicha extensión permite manejar los datos de una forma muy cómoda para agrupar por tiempo." ‣Monitorización de servidores" Para monitorizar el estado del servidor, usamos una aplicación llamada netdata[28]. Es capaz de obtener métricas de todo tipo y mostrarlas en una web." Existe una versión para contenedor de este software. Aunque este contenedor no es capaz de acceder a toda la información que nos podría interesar de la puerta de enlace (no es capaz de leer datos de las tarjetas de red)[29]. Por lo que para este servidor se dejará como se encuentra actualmente, sin contenedor, y se enlazaría con træfik (el proxy inverso) mediante configuración manual. Si se instala un nuevo 69 servidor, es posible que sea más cómodo para éste usar la version del contenedor, ya que no interesaría tener tanta información más allá de los propios contenedores y el estado del sistema." Para resumir, se va a exponer una tabla con los componentes que estarán virtualizados y los que no, con lo que llevamos descrito hasta el momento:" Nuevos servicios Sobre la marcha, han ido apareciendo nuevos servicios que son necesarios para algunas partes que se describirán en este trabajo posteriormente o en el trabajo de Antonio Ángel Cruzado Castillo." ‣Servidor VoIP" El primer servicio que se va a añadir es el de la centralita VoIP usando el programa Asterisk. Este servicio es el que permite a los teléfonos VoIP poderse comunicar con otros teléfonos de la residencia y con el servicio de telefonía de Vodafone (al exterior de la residencia). Más detalles sobre este servicio lo podrán encontrar en la sección «Configuración de asterisk» del mencionado trabajo de Antonio Ángel." Y, ¿podría ser virtualizado este servicio? Como un servicio que puede ir 100% sobre la red de internet, podría ser virtualizado sin problemas. Un detalle a tener en cuenta es que, por como es el protocolo SIP, es posible que asterisk requiera de muchos puertos efímeros. Aunque no debería ser problema ya que se pueden configurar qué puertos efímeros usar y se pueden “publicar” todos ellos fácilmente. O usar una configuración de red “host”, donde las redes del contenedor son las mismas que las En contenedores Fuera de contenedores træfik (proxy inverso - cloud native edge router) dnsmasq (DHCP + DNS) nginx (para archivos estáticos) Controlador de Unifi WordPress con apache + php netdata en la puerta de enlace MariaDB o MySQL Medidor de uso de internet PostgreSQL + timescaleDB netdata en otros servidores 70 del servidor, pero disminuyendo el aislamiento. Además, para este servicio, también requiere de una base de datos MySQL (o MariaDB) para almacenar cierta configuración y datos sobre las llamadas." Otro servicio que va a hacer falta es el backend de la aplicación web. También añadir el sistema de autenticación con la UMA, que requerirá de un servidor redis." Este servicio está pensado para virtualizarse en contenedores. No requiere de más extras a parte de ponerse detrás del proxy inverso (træfik). También se requerirá una base de datos PostgreSQL para almacenar datos de la aplicación, y para obtener los datos del medidor de uso de ancho de banda. Y también necesitará acceso a la base de datos de Asterisk para alguno de sus servicios. Además de la mencionada base de datos redis, que se usa en el sistema de autenticación." Un elemento importante del backend es el módulo de inicio de sesión con la Universidad mediante SAML[44], que se desplegará por separado." Migración de servicios existentes a Docker En este apartado se describirá la metodología seguida para pasar los servicios actuales a imágenes de Docker, se explicará el funcionamiento que tiene Docker y algunos de los problemas que han ocurrido en el proceso." " 71 Comparativa entre contenedores y máquinas virtuales[31] Antes de empezar con la migración, se explicará como funciona Docker para que se entienda antes de explicar el trabajo realizado para migrarlos." Docker es un servicio de contenedores, que no son mas que una especie de máquinas virtuales, pero más ligeros. Los contenedores virtualizan parte del sistema operativo, en contraposición a las máquinas virtuales que virtualizan hardware. Todos comparten el mismo kernel, pero solo son capaces de ver lo que el creador de la imagen y del contenedor quieren que vean éstos. Esto permite virtualizar servicios y que se ejecuten en segundos, que puedan ser fácilmente escalables (aumentar o reducir réplicas del mismo servicio) e independientes del sistema operativo en el que se ejecutan (Linux o Windows en caso de Docker)." La base de los contenedores son los que Docker llama “imágenes”. Es el sistema de archivos inicial que tendrá el contenedor cuando se ejecute por primera vez. Contiene una base de bibliotecas y ejecutables que permiten al contenedor funcionar con lo que se desee. Las imágenes se montan sobre capas, por lo que permite tener varias imágenes que comparten una misma base, y reducir espacio. Por lo que un “contenedor” no es más que una imagen en ejecución. En un contenedor se puede configurar qué archivos puede ver y donde almacenarlos, además de qué redes puede ver. También ofrece la posibilidad de limitar el uso de CPU y de memoria de cada uno de ellos." Con la ayuda de un orquestador, como Kubernetes o Docker Swarm, Docker puede elevar su funcionalidad a multiples nodos (servidores que ejecutan contenedores) que trabajan conjuntamente para ejecutar todos los contenedores, permitiendo escalabilidad y alta disponibilidad. Con un orquestador, uno podría montar un “cloud” como los que se encuentran en los servicios PaaS (Platform as a Service)." Para nuestro caso, no se usará dicha funcionalidad porque la infraestructura no es tan grande que la diferencia entre usar un orquestador y no usarlo son pocas." Tratando el tema de cómo migrar lo servicios, se seguirá estos pasos:" 1. Analizar los componentes que conforman el servicio (analizado en los apartados anteriores)" 2. Buscar si existen imágenes en https://store.docker.com[33] con el componente listo para usarse y analizar si valen la pena" 72 3. Preparar el archivo para generar la imagen (Dockerfile) y los archivos extra para configurar el componente" 4. Probar su funcionamiento" A la hora de buscar imágenes existentes, se intentarán que todos se basen en la misma imagen, que suele ser Debian Stretch, en la fecha de escritura de la memoria." El primer componente que se convertirá es el servidor nginx. En la tienda de Docker, se encuentra la imagen oficial de nginx[34] y con una versión en Debian. Esta imagen viene con una configuración por defecto del servidor, según se puede leer en la misma página [34]." Para nuestro caso, tenemos que añadirle algún que otro archivo de configuración para poder personalizar los archivos de error (errores como estos códigos de estado HTTP: 404, 401, 500…)[35]. El servidor actual tiene soporte para PHP mediante la versión php-fpm que usa el protocolo FastCGI, por lo que hay que añadirlo también a la imagen. Por lo que, se necesitarán dos archivos de configuración: uno que contenga la configuración para que nginx se pueda conectar con php-fpm (fastcgiphp.conf), otro con la configuración por defecto de nginx con los añadidos (default.conf)." El archivo que genera la imagen se quedaría de la siguiente forma:" Describiendo lo que hace el archivo, la primera linea indica cuál es la base de esta nueva imagen, que es nginx. Nótese que al final está :latest, que indica qué etiqueta (versión) de la imagen se va a usar. Los dos siguientes son los que copian los archivos de configuración al interior de la imagen. El último indica que en el puerto 80 (tcp) nginx va a estar escuchando para peticiones." Estos archivos se pueden encontrar adjunto, dentro de la carpeta de web-nginx en repositorios." 73 herramienta docker-compose y como usarlo en un despliegue en local y en uno en la residencia." docker-compose es una herramienta de Docker que permite definir componentes y sus necesidades, y relacionar todos entre ellos, usando un simple archivo de definición. Con sencillos comandos, puedes ejecutar varios contenedores, y actualizarlos cuando haya cambios de configuración o una nueva imagen. Es una forma sencilla de poder ejecutar diversos contenedores y agruparlos." Para este trabajo, se usará dicha herramienta para hacer los despliegues tanto de pruebas como el entorno real." Para permitir distinguir entre diversos entornos donde se hace el despliegue, docker-compose nos permite usar variables de entorno para dar valor a partes del archivo de definición, con lo que para ciertos valores de los componentes que dependen de donde se despliegue se definirán con esas variables. De esta forma, no hay que modificar los archivos docker-compose.yaml (los de despliegue) para adaptarlos a cada entorno. Se usará un archivo plantilla, como el de la imagen anterior, que contenga todas las variables de entorno sin rellenar para su copia y uso en cada entorno." 80 træfik Bases de datos Web Asterisk Servicios para la puerta de enlace træfik MariaDB" Redis" postgreSQL Nginx" php-fpm" Wordpress" Saml" Backend Asterisk Speedy" Componente backend Gráficos de dependencias entre grupos de servicios (arriba) y los servicios dentro de cada grupo (abajo) Para el despliegue, se dividirán 5 grupos los distintos componentes de la siguiente forma:" •Bases de datos:" •MariaDB" •Redis" •postgreSQL" •Træfik" •Web •nginx (para archivos estáticos y el frontend de la aplicación web)" •php-fpm (para ejecutar scripts en PHP en nginx)" •wordpress (apache + PHP para usarlo en Wordpress)" •saml (modulo de autenticación SAML con la Universidad)" •Backend aplicación web" •asterisk •Servicios para la puerta de enlace •speedy (medidor de ancho de banda por dispositivo)" •Componente externo del backend de la aplicación web" Cada grupo de servicios corresponde un un fichero docker-compose.yaml para el despliegue de los mismos." " ‣Træfik" El archivo de despliegue para træfik es ciertamente sencillo, pero crea la base para que los componentes que quieran publicar un servicio a través del proxy inverso, puedan hacerlo." Hablamos de una red interna entre contenedores que conecta dichos servicios con træfik. De esta forma, dichos servicios solo son accesibles directamente (sin tener que pasar por træfik) desde los contenedores conectados a dicha red (llamada traefik_net)." 81 El contenedor tiene un archivo de configuración (montado como volumen) que te permite preparar lo que la aplicación denomina “entry points” y el autodescubrimiento de los servicios. Con entry points nos referimos a qué puertos va a escuchar el proxy inverso para ofrecer sus servicios. En este caso, usaremos el estándar puerto 80/tcp para HTTP, 443/tcp para HTTPS y el puerto alternativo 8080/ tcp para el panel de métricas de træfik (definido en la sección ports en la captura de código). En cambio, el auto-descubrimiento permite reconfigurar el proxy inverso cuando aparece un nuevo contenedor con la configuración correcta y desconfigurarlo cuando se para." Para su uso en Docker, hay que etiquetar los contenedores (en web se explicará cuáles son) con cierta configuración que incluye la regla que debe aplicarse a una petición para redirigir a ese servicio, la red interna (si el contenedor tiene más de una) y una para activar dicho contenedor para que el proxy inverso redirija las peticiones - en la configuración está puesta para que no haga eso por defecto, y permite filtrar contenedores con servicios web de los que no. Y para que todo esto funcione, necesitamos pasar el socket de Docker al contenedor de træfik, de ahí que en la sección de volúmenes se monte el socket." ‣Bases de datos" Para el grupo de contenedores de las base de datos, se irá explicando por cada base de datos, y mostrando la parte correspondiente del archivo dockercompose.yaml para reducir las medidas de la imagen." La base de datos MariaDB se despliega con la configuración de la imagen superior. " Para empezar, la base de datos se inicia con unos argumentos (colocados en commands) para que use UTF8 como codificación de texto por defecto, en 82 concreto la codificación utf8mb4, que tiene soporte completo de la codificación, a diferencia de otros modos que en MySQL (y MariaDB) no soportan todo el estándar." Para persistir los datos de la base de datos, usamos un volumen, en concreto lo que se denomina bind mount ya que enlaza algo existente dentro del contenedor. La ruta de los datos se encuentra dentro de una variable de entorno que se puede encontrar en el archivo comentado anteriormente." También se monta la carpeta sql que se encuentra en el mismo lugar del archivo de despliegue. Los ficheros SQL de esa carpeta se ejecutarán en el servidor cuando se estén creando los archivos de la base de datos (cuando es la primera ejecución por ejemplo). Permite dar un valor inicial a la base de datos." Por último, el usuario por defecto es root y la contraseña se define dentro de otra variable de entorno." La siguiente base de datos es la de postgreSQL con la extensión de timescaleDB." La configuración es parecida a la de MariaDB: una ruta donde persistir los datos, una carpeta para que al crear las estructuras de almacenamiento de la BD se ejecuten diversos SQL y la contraseña del usuario por defecto. En este caso, el usuario por defecto es postgres." Por último tenemos redis. Al ser una base de datos tan sencilla, no hace falta contraseña. El volumen montado es de uso temporal ya que redis por defecto no persiste el contenido de la base de datos. 83 Si hiciera falta, en [40] te explican como activarlo." La red que crea este archivo de despliegue, para su uso fuera de él, es databases_net. Se usará para conectar otros contenedores a la red de bases de datos, tal y como veremos ahora en los próximos párrafos." ‣Servicios web" Ahora describiremos la configuración de despliegue de la parte de la web. Al igual que en la anterior parte, se irá dividiendo en partes por cada uno de los contenedores." El servidor nginx, para archivos estáticos, se define tal y como aparece en la imagen superior." Lo primero son los volúmenes. El primero es la ruta, fuera del contenedor, donde se encontrarán los archivos estáticos que se servirán en nginx, cuyo valor se define mediante una variable de entorno. El segundo volumen es para una cache que tiene configurado nginx. En este caso usamos un volumen que gestiona enteramente Docker ya que no es necesario acceder a esos datos ni hacer copias de seguridad. El nombre ncache es el nombre que tiene el volumen." 84 En la sección de redes (networks) definimos a qué redes tiene acceso el contenedor, que en este caso es la red que conecta con træfik y una red interna de este despliegue. El último sirve para conectarse con php-fpm." La sección depends_on define que este contenedor debe ejecutarse después de lo que haya dentro (en este caso, php-fpm)." La sección labels define las etiquetas del contenedor (siempre que no se despliegue en Docker Swarm o Kubernetes). Aquí definimos la configuración que usará træfik para configurar lo que ellos denominan el backend y el frontend. El frontend es la configuración que permite definir un servicio y el backend son los servidores disponibles que sirven ese contenido o servicio. De esta forma, puede haber más de un servidor para el mismo servicio que permite hacer distribución de carga y estar mejor protegido ante fallos. En lo que se puede observar de la imagen, la primera etiqueta dice a træfik que ese contenedor se puede usar para configurar un nuevo backend y/o frontend. La segunda le da un nombre al backend (para poderlo identificar). La tercera es la regla que permitirá identificar qué peticiones van directos a este servicio. Host:${DOMAIN} indica que todas las peticiones cuyo host (el dominio al que se accede) sea el de la variable de entorno DOMAIN entonces irá a ese servicio. El orden de aplicación de reglas, por defecto, es del más largo al más pequeño, y este al ser una regla pequeña se comprobará en las ultimas posiciones (menor prioridad). La última etiqueta sirve para decir cuál red es la que se conecta con træfik, para poder acabar de configurar el backend." Para php-fpm, no se requiere de mucha configuración para hacerlo funcionar." Montamos la misma ruta de archivos que en nginx, por si se desea ejecutar scripts en PHP, de esta forma coinciden las rutas entre nginx y php." Las redes que se conecta son la red interna (para conectarse con nginx) y el de base de datos, por si se desea conectar con alguna de las bases de datos." 85 Para wordpress, usamos la siguiente configuración." Primero, se monta la carpeta donde se encuentren los archivos de WordPress. Nótese que la ruta dentro del contenedor acaba en noticias-rafj. La ruta está mal escrita (rafj en lugar de rajf que viene de Residencia Alberto Jiménez Fraud) ya que cuando se configuró inicialmente, ni a Antonio ni a mi nos dimos cuenta del fallo y ahora cambiar la ruta de un WordPress funcionando es muy complicado." Las redes a las que se conecta son la de las base de datos, para conectarse con MariaDB, y la de træfik, para poderse publicar." Sobre las etiquetas, muchas ya se conocen, aunque se van a explicar los mas diferentes. Primero, la regla es más larga y contiene ahora un PathPrefix. Entre ambos, se separa mediante un punto y coma (;) que significa Y. Por tanto, esta regla al completo es “todas las peticiones al dominio ${DOMAIN} y cuya ruta empiecen por /noticias-rafj”." Las tres siguientes etiquetas, después de la regla, son para configurar unos archivos de error. Así, cuando salta un error 404 (no encontrado), un error 500 (error interno) o 502 (cuando el contenedor está parado - no aparece en la captura) se servirá lo que resulte de hacer la petición al nginx en la ruta /errores/404.html, /errores/500.html y / errores/502.html respectivamente." Ahora es el turno del módulo de autenticación SAML." 86 En este contenedor, el volumen es para el certificado necesario para el correcto funcionamiento de la autenticación SAML. Se generan con un simple comando en la herramienta por terminal de OpenSSL, por ejemplo, y con eso ya sería suficiente. El certificado debe llamarse cert.pem, y la clave privada, key.key." Las redes vuelven a ser la de base de datos y la de træfik. Como la autenticación usa redis para almacenar temporalmente unos datos, debe poderse conectar a él." Por último, las etiquetas todas son conocidas, aunque se comentará la etiqueta de la regla. En este caso la parte de PathPrefix tiene dos valores separados por una coma (,) que viene a decir O. Esta regla significa “las peticiones al dominio $ {DOMAIN} que tengan como prefijo de ruta /mellon o /alberginia”." 87 El backend de la aplicación web (que podéis ver más detalles en «Desarrollo del backend de la apliación "Panel del residente”» en el trabajo de Antonio Ángel) necesita conectarse a todas las base de datos desplegadas (postgreSQL, MariaDB y redis), por lo que se le ha asociado a la red de base de datos. Además, como se debe publicar la API dentro de la web, se tiene que añadir las etiquetas correspondientes (labels) para que træfik lo detecte y configure un camino para poder publicar dicha API." Por completitud, comentaré también la parte final del archivo docker-file.yaml. En él podemos ver como se definen las distintas redes, donde la de træfik y la de las bases de datos se marcan como externas ya que no los maneja este a través de este grupo." Los volumenes que maneja Docker se tienen que definir también en el archivo." ‣Asterisk" La centralita de telefonía por IP (VoIP) asterisk se desplegará como su propio grupo de servicios. Un requisito indispensable para el funcionamiento correcto de asterisk es que debe usar el modo de red host (opción network_mode), en el que realmente es deshabitar el aislamiento de redes y el contenedor tiene acceso a las redes del 88 servidor directamente. El contenedor ejecuta por defecto una shell de comandos, por lo que para ejecutar asterisk tenemos que decirle exactamente que debe ejecutar. Eso se consigue en la opción cmd. El valor es una lista de argumentos que el contenedor interpretará y ejecutará. Con la opción “-f” de asterisk conseguimos que funcione sin que el contenedor se detenga, ya que el servidor se ejecuta en lo que se conoce como “foreground” (el proceso que ejecutas es el servidor, en lugar de crear otro proceso que se ejecutará de fondo que realizará esa tarea). En caso de no ponerlo, asterisk crea un segundo proceso donde ejecutará el servidor de fondo, y el que se ha creado por motivo de ejecutar el comando se cierra. Al cerrar ese proceso, que en Docker es el principal, el contenedor se para ya que solo tiene en cuenta dicho proceso como comprobación del estado, e ignora procesos secundarios. Por último, queda configuración para que la centralita se pueda conectar con la base de datos MariaDB, necesaria para almacenar cierta información." Más detalles sobre la configuración de la centralita la podéis encontrar en «Configuración de asterisk» del trabajo de Antonio Ángel." ‣Servicios en la puerta de enlace" Para terminar, hablaremos de los contenedores que se desplegarán en el servidor/ puerta de enlace, que es distinto al resto de contenedores. En este, como se comentó, tiene el medidor de tráfico por dispositivo (speedy) y, como se puede observar en la imagen, también tiene un trozo del backend de la aplicación web." 89 [49] https://code.visualstudio.com/ - IDE de Microsoft genérico, al que se le pueden insertar complementos para desarrollo web" [50] https://sass-lang.com - CSS with superpowers [51] https://unix.stackexchange.com/a/198591 - What is bind mount? (respuesta en Unix & Linux Stack Exchange)" [52] http://man7.org/linux/man-pages/man8/mount.8.html - Manual de mount en Linux, incluye sección para bind mounts llamada “Bind mount operation”" [53] https://bindfs.org - Implementación de bind mount para sistemas otros operativos mediante FUSE (útil para macOS o FreeBSD)" [54] https://git-scm.com/docs/gitsubmodules - Descripción y documentación de los submódulos en el sistema de control de versiones git [55] https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md - Especificación de OpenAPI 2.0/swagger" [56] http://getbootstrap.com/docs/4.1/components/buttons/" [57] http://getbootstrap.com/docs/4.1/components/modal/" [58] http://getbootstrap.com/docs/4.1/components/collapse/ [59] https://help.ubnt.com/hc/en-us/articles/115002806907-UniFi-High-DensityWLAN-Scenario-Guide (6 de agosto 2018) [60] Mell, P., & Grance, T. (2011). The NIST definition of cloud computing." 96