Exposición y reparto

1. Problemática

En el capítulo Los contenedores, vimos cómo crear imágenes reutilizables de nuestra aplicación eni-todo y cómo, usando contenedores, desplegarlas en uno o más servidores. Pero aún no hemos visto cómo acceder a ellas desde un único punto de entrada. Necesitamos resolver varios problemas.

En primer lugar, cada contenedor, una vez iniciado, tiene su propia dirección IP en una red que es local a la máquina y no está enrutada, es decir, no es accesible desde ningún otro punto de la red. Tenemos que encontrar la manera de que la aplicación que se ejecuta de forma aislada sea accesible a través de, por ejemplo, la dirección IP del servidor.

En segundo lugar, el servicio de la aplicación eni-todo se distribuye ahora en, al menos, dos servidores, para garantizar su disponibilidad en caso de pérdida de una de las máquinas. Se necesita un único punto de acceso: una dirección, que reenviará las peticiones a uno u otro servidor, pero que también debe ser capaz de detectar la indisponibilidad de la aplicación en uno o varios servidores y reenviar el tráfico a los que aún estén activos.

Si el servicio se va a exponer en Internet, debe tener una dirección IP pública.

Y, por último, todos los servicios deben ser redundantes: debemos...

1. ¿Por qué utilizar un reverse proxyreverse proxy?

Cada contenedor iniciado en el servidor tiene su propia dirección IP. Esta dirección se puede obtener simplemente utilizando el comando docker y el nombre o identificador del contenedor:

$ docker container ps 
CONTAINER ID   IMAGE    COMMAND     CREATED    STATUS    PORTS    NAMES 
296364ae3c93   registry.diehard.net:5000/tomcat-eni-todo:v24.04-eni-
todo-tomcat-mariadb-env   "catalina.sh run"   16 minutes ago   Up 
16 minutes   0.0.0.0:8080->8080/tcp   tomcat-production-eni-todo_1_
v24.04-eni-todo-tomcat-mariadb-env 
$ docker inspect --format '{{ .NetworkSettings.IPAddress }}' 296364ae3c93 
172.17.0.2 

Desde el propio servidor, puede comprobar que el servicio que se ejecuta en el contenedor funciona, con un simple curl:

$ curl -I http://172.17.0.2:8080/eni-todo/ 
HTTP/1.1 200 
Set-Cookie: JSESSIONID=5EFB90378D2336F11E2FFF6348BD6510; 
Path=/eni-todo; HttpOnly 
Content-Type: text/html;charset=UTF-8 
Content-Language: en 
Content-Length: 3333 
Date: Sat, 16 Mar 2024 12:45:40 GMT 

De momento, intentar lo mismo desde la dirección IP del servidor también funciona, porque hemos asociado el puerto 8080 del servidor con el del contenedor que hemos iniciado. Impedir el acceso directo a la aplicación es una mala idea. Iniciar varias aplicaciones utilizando el puerto 8080 es imposible: varias aplicaciones no pueden escuchar directamente en el mismo par IP:Puerto.

$ curl -I http://192.168.56.30:8080/eni-todo/ 
HTTP/1.1 200 
$ nc -l -s 192.168.56.30 -p 8080 
nc: Address already in use 

También puede iniciar el contenedor utilizando la red del host, es decir, el servidor. En este caso, el contenedor utiliza las direcciones y puertos del servidor, por lo que no hay aislamiento de red. Pero también en este caso, dos contenedores no pueden utilizar el mismo puerto del host.

$ docker run --network=host ... 

Podríamos considerar otras soluciones de bajo nivel, con Netfilter, NAT (Network Address Translation), pero volveríamos a encontrarnos con los mismos problemas. Necesitamos utilizar una solución que permita a varias...

1. Presentación

Ahora que los servicios en contenedores son accesibles desde la dirección IP de un host, necesitamos exponer todos estos servicios y, por lo tanto, todos los hosts, a todos los clientes, ya sea en la red corporativa (la intranet) o en una red pública (Internet). En las pruebas anteriores sólo se utilizaba un único host. Sin embargo, el servicio se desplegará en, al menos, dos hosts. No vamos a exponer directamente un servidor de aplicaciones en Internet. Como los servicios están repartidos entre varios servidores, es necesario un proceso de decisión para repartir la carga entre todos los servicios.

El objetivo de un load balancer o repartidor de carga es distribuir las conexiones de los clientes entre varios servidores o servicios, según criterios de decisión. El repartidor de carga suele tener, al menos, dos interfaces de red: una accesible desde la red que expone la dirección IP a los clientes y otra en una subred interna dedicada, a través de la cual accede a los hosts (puede tener una sola interfaz si la IP expuesta está en la misma subred que los servidores).

El primer papel del repartidor de carga es el de proxy: enrutar las conexiones a las aplicaciones a los hosts correctos, de acuerdo con reglas basadas, como con un proxy de host, en el nombre del servicio. En este sentido, su papel es similar al del reverse proxy Nginx.

Su segunda función...

1. Elección de productos

Se necesitan al menos tres productos para implementar esta arquitectura. El propio repartidor de carga debe gestionar la conexión de un cliente a un servicio y devolverla a un host (el host, a través de su reverse proxy, la devuelve a un contenedor). Como esto implica la gestión de varios tipos de protocolos y reglas basadas en estos protocolos (agrupación de direcciones y enrutamiento basado en nombres de host), esto descarta automáticamente una solución basada únicamente en las capas 3 y 4 del modelo OSI (Open Systems Interconnection). Esto significa que Keepalived no puede ser seleccionado para su papel de dispatcher (repartidor). Utilizaremos la mejor solución actual: FRRouting. 

Las direcciones IP de servicio se pueden configurar manualmente en las interfaces correspondientes. Pero, ¿cómo cambiarlas de un dispatcher a otro? Aquí es donde el protocolo VRRP (Virtual Router Redundancy Protocol) realmente entra en acción. Utilizaremos el módulo asociado Keepalived, que se utilizará para gestionar un router virtual formado por, al menos, dos routers físicos y que se encargará de la alta disponibilidad de las direcciones IP.

Exponer una dirección IP en Internet es diferente de exponerla en una red privada. La dirección se debe anunciar a los distintos routeres a través de protocolos especializados como OSPF y BGP. Estos protocolos se pueden configurar utilizando Quagga.

2. HAProxy

1. Implementación

En este apartado, la simplicidad es la clave para una mejor comprensión.

Los repartidores de carga se basan en VRRP (Keepalived). Portarán direcciones IP públicas a una interfaz de red dedicada que está directamente expuesta y, por tanto, accesible en Internet. Esto significa que configuraremos directamente una o más IPs públicas en esta interfaz, como si fueran cualquier otra IP y, de esta manera, estas direcciones serán visibles con un comando ip addr show.

Otros métodos incluyen la configuración de direcciones en la interfaz loopback, la modificación de las tablas ARP y la configuración dinámica del kernel para aceptar paquetes IP no configurados en las interfaces. FRRoutingt ambién se puede utilizar para configurar interfaces.

Pero como hemos utilizado la configuración VRRP para la alta disponibilidad de nuestras VIPs, vamos a hacer lo mismo para configurar nuestras direcciones IP públicas. El papel de FRRouting es anunciar estas direcciones a los otros routeres, dándoles la ruta para acceder a ellas desde Internet.

Por tanto, nuestros balanceadores de carga tienen una tercera capa añadida, OSPF, para anunciar las IPs públicas que llevan en Internet, aquellas que han sido configuradas como VIPs en los routeres maestros VRRP.

2. Instalación y configuración

El paquete FRRouting instala todos los componentes necesarios.

$ sudo apt install...