===============
Opciones de red
===============

Vamos a ir razonando y descartando -si cabe, las opciones mas rocambolescas:

2. La opcion del contenedor  "Monolito"; esta opcion responde al reequisito de configuracion en el hypervisor, con respecto al recurso de capacidad de computo y memoria, necesarios en un entorno aislado para contenedores. No resultaria un cambio extremo, debido a que ya se opera desde un medio con capacidad para deduplicar los datos a bajo nivel(VDO). Esto ahorra un gasto significativo en almacenamiento, pero que como digo, resultaria en una configuracion de recursos necesarios, ya presentes en ambos componentes; autenticador y proxy.


3. El router; no deberia mal entenderse la capacidad que tienen las maquinas virtuales, de trabajar con independencia. Independencia; si. Rigidez; la justa y necesaria. En todo caso es siempre decision del gestor o administradores, situar el recurso de red en el lugar apropiado. Si bien es cierto, que la implementacion del dispositivo puente "br_lab", nombre identificativo "Bridge-QXG", esta pensado para trabajar en el entorno de virtualizacion puro; no esta implicito o escrito en ningun sito que obligatoriamente deba ser asi. 

Este es el caso de la supuesta maquina, transformada  en un encaminador operativo y dispuesto para la conexion de los contenedores. Resulta obvio, que dicho mecanismo enrutador, estaria conectado a la targeta de red dedicada o destinada a tal efecto; dispositivo de red enp9s0. En ningun caso los dispositivos configurados en el host deban adherirse a un requisito obligatorio. Es mas bien una decision organizativa que operativa en realidad.

En otras palabras esta opcion nos permitiria dedicar la interfaz enp9s0 a una vm, la cual expondriamos a los contenedores. Pero en ningun caso, esta colgaria de la red br_lab, puesto que romperia de forma ridicula y absurda, el aislamiento o independencia operativa. A mi me resulta muy obvio!

4. Esta opcion o es un dos por uno o no lo es. Solo dios lo sabe. Pero como esta infravalorado el efecto negativo de una frase ambigua; inmediatamente vamos a decir que podriamos haberla dividido en una o mas opciones.

5. Capacidades elevadas; es sin lugar a dudas, de las opciones menos malas, en relacion a la lista que acabamos de enumerar. Por un lado, estariamos facultando a un servicio, con capacidades extra; que ademas, esta estrechamente relacionada, con el objeto del servicio. Se trata de recurso de red pensado para trabajar en modo "no usuario administrativo". Asi es como los desarrolladores de passt/passta, han implementado la aplicacion. Estariamos de alguna manera "complementando", la capacidad del recurso. Como digo no me parece de las peores opciones, dado que la capacidad extra, no seria otorgada a ningun usuario en particular. Habria que valorar si el riesgo de dotar al recurso con la capacidad de contectar dispositivos fisicos, es mayor igual o menor, que el que un usuario corriente pueda tener a la hora de "crear" sus propias conexiones sobre un dispositivo fisico!

1. Esta es la opcion que mas me gusta, por su relativa sencillez. La dificultad o grado de complejidad, en cuanto a la implementacion del recurso -puente de red. 
Pero solo es una parte. Hemos aprendido por las malas, que los contenedores trabajan de forma eficiente en el espacio de usuario, y a regañadientes cuando trabajan desde usuarios operativos o de sistema. 
En cualquier caso; no tiene sentido intentar siquiera, su configuracion y posterior implementacion, sin antes averiguar, que la capa de aplicacion para trabajar en el espacio de usuario, es capaz de vincular la conexion al dispositivo artificial o puente.
El riesgo radica en el hecho de que la API, al final, no pueda vincularse directamente al dispositivo de red gestionado desde el sistema operativo. Hay mucha posibilidades, como digo, de que esto sea impracticable. Deberiamos contatar mediante la documentacion su supesta imposibilidad.