Python Type Hints: Qué son, para qué sirven y cómo usarlos

Recientemente he retomado el uso de Python para mis proyectos personales y profesionales. Una de las mejoras más relevantes del lenguaje en la última década ha sido la incorporación de type hints en Python, también conocidos como anotaciones de tipo. Esta característica transforma por completo la forma en que escribimos, entendemos y mantenemos el código.

¿Qué son los type hints en Python?

Los type hints en Python permiten indicar de manera explícita los tipos de datos esperados en funciones, variables y estructuras. Aunque Python sigue siendo un lenguaje de programación dinámico, las anotaciones de tipo facilitan el análisis estático del código y mejoran su legibilidad.

Historia

Los type hints se introdujeron oficialmente en Python 3.5, en 2015, mediante la PEP 484. Su objetivo principal fue:

  • Mejorar la legibilidad del código.
  • Permitir análisis estático con herramientas como mypy, pyright o los LSP de los editores modernos.
  • Facilitar la documentación automática de funciones y clases.

Desde entonces, esta funcionalidad ha evolucionado notablemente con cada nueva versión de Python:

  • PEP 563 (Python 3.7): evaluación diferida de las anotaciones, mejora el rendimiento.
  • PEP 585 (Python 3.9): uso de tipos genéricos modernos (list[str] en lugar de List[str]).
  • PEP 604 (Python 3.10): uso del operador | para tipos unión (int | str).
  • PEP 695 (Python 3.12): simplificación de la sintaxis para genéricos con TypeVar.

Ventajas

Incorporar type hints en tus proyectos tiene múltiples beneficios:

  • Mayor legibilidad – Los tipos hacen que el propósito de una función sea más fácil de entender a simple vista.
  • Reducción de errores en tiempo de ejecución – Herramientas como mypy detectan discrepancias antes de ejecutar el código.
  • Mejor experiencia en el editor – Los IDEs ofrecen autocompletado y validación más precisa cuando se utilizan anotaciones de tipo.
  • Código más mantenible – Las anotaciones ayudan a otros desarrolladores a comprender mejor el flujo de datos y las expectativas del código.

Ejemplo práctico

Veamos un ejemplo clásico: una función que calcula el promedio de una lista de números.

Python 3.4

def promedio(numeros):
    return sum(numeros) / len(numeros)

Python +3.10

from typing import Sequence

def promedio(numeros: Sequence[int | float]) -> float:
    if not numeros:
        raise ValueError("La lista no puede estar vacía")
    return sum(numeros) / len(numeros)

Este enfoque es mucho más robusto y explícito, lo cual ayuda a mejorar la calidad del código y facilita su análisis estático.

Conclusión

Aunque los type hints en Python no son obligatorios, su uso marca una diferencia significativa en proyectos de largo plazo. Aportan claridad al código, reducen errores, aceleran el onboarding de nuevos desarrolladores y mejoran la experiencia general de desarrollo en equipo.

Te recomiendo incorporarlos de forma gradual en tus proyectos. Comienza por las funciones más complejas o críticas y, a medida que el código evoluciona, extiende su uso al resto del proyecto. Con el tiempo, notarás una mejora sustancial en la calidad y mantenibilidad del código.

Gestión de proyectos de Python con `uv`

La gestión de entornos y dependencias en Python ha sido históricamente un punto de fricción para muchos desarrolladores. A lo largo del tiempo han surgido herramientas como pip, virtualenv, pip-tools o Poetry, cada una con su propio enfoque para resolver estos retos. Sin embargo, muchas veces implican compromisos en rendimiento, simplicidad o compatibilidad. En este artículo exploraremos cómo uv, una herramienta moderna escrita en Rust, ofrece una alternativa rápida y eficiente para gestionar entornos virtuales y resolver dependencias de forma más fluida y predecible.

En este artículo te presento uv, una herramienta moderna y ultrarrápida para la gestión de proyectos en Python. Escrita en Rust, uv combina la funcionalidad de múltiples herramientas tradicionales en una sola solución liviana, eficiente y fácil de usar. Desde la instalación de dependencias hasta la creación de entornos virtuales con versiones específicas de Python, uv se perfila como una excelente alternativa para mejorar tus flujos de desarrollo.

Ya sea que trabajes en proyectos personales, empresariales o colaborativos, adoptar uv puede ayudarte a reducir tiempos de configuración, evitar conflictos de versiones y simplificar el manejo de herramientas CLI dentro del ecosistema Python.

¿Qué es uv?

uv es una herramienta desarrollada por Astral que proporciona una forma ultrarrápida de manejar la instalación de dependencias, creación de entornos virtuales y resolución de versiones. Esta herramienta fue escrita en Rust, lo que le otorga una gran ventaja en velocidad frente a herramientas tradicionales como pip, virtualenv o Poetry.

Entre sus principales características destacan:

  • Instalación de dependencias extremadamente rápida.
  • Resolución de conflictos de versiones con una experiencia más predecible.
  • Compatibilidad con los archivos pyproject.toml y requirements.txt.
  • Sustitución directa de herramientas como pip, pip-tools, venv y Poetry.

Instalación

Puedes instalar uv de forma muy sencilla desde la terminal con el siguiente comando:

$ curl -LsSf https://astral.sh/uv/install.sh | sh

Esto descargará e instalará la versión más reciente de uv directamente desde su repositorio oficial.

Casos de uso

Creación de código portable

Uno de los casos de uso más interesantes de uv es la posibilidad de crear scripts de Python autocontenidos, es decir, que incluyan las dependencias necesarias declaradas directamente en el archivo fuente. Esto permite distribuir aplicaciones pequeñas de forma mucho más simple, sin necesidad de archivos adicionales como requirements.txt.

Veamos un ejemplo básico. Supongamos que queremos crear un script que imprima un emoji:

from emoji import emojize

print(emojize(":thumbs_up:"))

El código anterior requiere el módulo de emoji, y en lugar de declarar esta dependencia en un archivo externo, podemos usar uv para integrarla directamente al script:

$ uv add --script app.py 'emoji'

Este comando modifica el archivo app.py agregando la información de las dependencias como comentarios:

# /// script
# requires-python = ">=3.8"
# dependencies = [
#     "emoji",
# ]
# ///
from emoji import emojize

print(emojize(":thumbs_up:"))

A partir de aquí, cualquier desarrollador que tenga uv instalado puede ejecutar el script directamente con:

$ uv run app.py
Installed 2 packages in 6ms
👍

Este enfoque no solo simplifica la distribución, sino que también mejora la trazabilidad y portabilidad del código, algo especialmente útil para scripts, prototipos o herramientas CLI internas.

Administración de ambientes virtuales

Otro caso de uso interesante de uv es la flexibilidad que ofrece en la creación y manejo de entornos virtuales. A diferencia de venv o virtualenv, uv permite seleccionar explícitamente la versión de Python que se desea usar, lo cual es especialmente útil cuando se trabaja con múltiples versiones en el mismo sistema.

A continuación, un ejemplo práctico donde se crea un entorno virtual usando Python 3.9, aunque el intérprete activo sea una versión distinta:

$ python -V
Python 3.8.1
$ uv venv py39 --python 3.9
Using CPython 3.9.6 interpreter at: /Applications/Xcode.app/Contents/Developer/usr/bin/python3
Creating virtual environment at: py39
Activate with: source py39/bin/activate

Después de activarlo:

$ source py39/bin/activate
(py39) $ python -V
Python 3.9.6

Esto facilita la administración de proyectos que requieren versiones específicas de Python, sin necesidad de recurrir a herramientas externas como pyenv o manejar manualmente rutas de intérpretes. Basta con tener instaladas las versiones deseadas y uv se encarga del resto.

Uso global de herramientas de línea de comandos

Una funcionalidad destacada de uv es su capacidad para ejecutar herramientas de línea de comandos externas sin necesidad de instalarlas manualmente en el entorno actual. Esto se puede hacer de tres formas: de manera global, local dentro del proyecto, o incluso de forma temporal, sin dejar rastros.

Por ejemplo, si queremos formatear un archivo usando black, pero no lo tenemos instalado en el entorno, podemos simplemente ejecutar:

$ uvx black app.py
Installed 8 packages in 21ms
All done! ✨ 🍰 ✨
1 file left unchanged.

El subcomando uvx detecta que black no está disponible y se encarga de instalarlo automáticamente en un entorno temporal y ejecutarlo. Esto es ideal para tareas puntuales como:

  • Formateo de código con black
  • Análisis estático con ruff o flake8
  • Ejecutar scripts auxiliares de desarrollo sin contaminar el entorno actual

Esta funcionalidad ahorra tiempo y evita la proliferación de dependencias innecesarias en cada entorno de desarrollo.

Conclusión

uv representa una evolución natural en la gestión de entornos y dependencias en Python. Su enfoque en el rendimiento, la simplicidad y la compatibilidad lo convierten en una herramienta poderosa tanto para desarrolladores individuales como para equipos que buscan flujos de trabajo más eficientes y confiables.

A lo largo de este artículo exploramos algunos de sus casos de uso más interesantes:

  • La creación de scripts autocontenidos con dependencias embebidas
  • La gestión versátil de entornos virtuales con distintas versiones de Python
  • La ejecución temporal de herramientas CLI sin necesidad de instalaciones persistentes

En mi experiencia, uv ha reducido significativamente el tiempo que dedico a la configuración de entornos y ha hecho más predecible la resolución de dependencias. Aunque todavía está evolucionando, ya es una alternativa sólida frente a soluciones más tradicionales como Poetry o pip-tools.

Si estás buscando una herramienta moderna, rápida y más amigable para el desarrollo en Python, definitivamente vale la pena probar uv.

Container Networks – CNI (Kubernetes)

En el articulo anterior se mencionó como Docker realizo cambios en su arquitectura para delegar responsabilidades del motor de ejecución. Este articulo abordará la segunda propuesta de Container Networks que actualmente es utilizada por Kubernetes para la administración de controladores de red.

Container Network Interface (CNI)

CNI

Es una especificación neutral propuesta por CoreOS y que ha sido adoptada por proyectos como Apache Mesos, Cloud Foundry, Kubernetes y rkt.

Los plugins son implementaciones de las acciones definidas por la especificación del CNI y que son consumidas por el motor de ejecución. Los binarios de los plugins necesitan al menos el permiso de CAP_NET_ADMIN para ser ejecutados correctamente. La acción a ejecutar por el binario es especificada mediante la variable de entorno CNI_COMMAND y esta acción solo puede ser una alguna de las siguientes opciones:

  • ADD: La cual permite agregar una interfaz de red a un contenedor especifico. Esta acción puede ser ejecutada múltiples veces para proporcionar varias interfaces de red a un solo contenedor.
  • DEL: Remueve una interfaz de red especifica a un contenedor.
  • CHECK: Se utiliza por el motor de ejecución para validar que la configuración de red se mantiene según lo solicitado.
  • VERSION: Imprime la versión de CNI soportada por el plugin.

Flujo de asignación de red en Kubernetes

Kubernetes utiliza el concepto de Pod para referirse a un conjunto de uno o mas contenedores que comparten una misma dirección IP. Esta dirección IP permite la comunicación de los contenedores hacia el exterior lo cual resulta importante comprender el proceso de su asignación.

Kubelet es el componente responsable del flujo en la creación del Pod, a continuación tratare de explicar la serie de pasos realizados por el componente de Dockershim en la creacion del Pod y asignación de dirección IP. Cabe señalar que Dockershim sera eliminado en la version 1.23 de Kubernetes, pero debido a la simplicidad de su método RunPodSandbox nos permite conocer mejor el flujo.

  1. Se asegura de tener la imagen del pause container. Este contenedor nos sirve como contenedor padre de los contenedores definidos en el pod y tiene dos funciones primordiales:
    1. Como la base para compartir Linux namespaces dentro del pod.
    2. Como PID 1 para cada pod.
  2. Crea la configuración requerida por el pause container, llamado la API de Docker.
  3. Crea un checkpoint del pause container en /var/lib/dockershim/sandbox a traves del administrador de Checkpoints.
  4. Inicia el pause container, nuevamente consumiendo la API de Docker.
  5. Configura las interfaces red (loopback y default) para el pause container. Esto lo realiza a traves de una serie de llamadas a los binarios de CNI utilizando su acción ADD.

Como puede observarse, la configuración de red del pause container no se realiza a traves del API de Docker sino a traves del CNI. Estos CNIs utilizan archivos de configuración en formato JSON, para definir entradas y salidas de datos esperados. Múltiples CNI plugins pueden ser ejecutados por el motor de ejecución.

Container Networks – CNM

La arquitectura de Docker separó (a partir de la versión 1.6) la creación de Contenedores de la configuración de la red para beneficiar la movilidad de las aplicaciones. En este articulo analizaremos a detalle uno de los estándares propuestos para esta separación.

Container Network Model (CNM)

Es la especificación propuesta por Docker. La biblioteca de libnetwork ofrece una implementación escrita en lenguaje Go. Actualmente proyectos como Cisco Contiv, Kuryr y Weave Net soportan dicha implementación.

Este modelo define tres conceptos principales:

  • Sandbox: El cual almacena la configuración de la red. Esta configuración incluye la administración de las interfaces de rede de los contenedores, la lista de rutas de tráfico y los valores de configuración para el DNS. Una implementación de un Sandbox puede ser Linux Network Namespace.
  • Endpoint: Permite la conexión de un Sandbox con la red. Una implementación de un Endpoint puede ser veth pair.
  • Network: Es un conjunto de Endpoints que se pueden comunicar entre si. Una implementación de un Network puede ser Linux bridge.

Libnetwork utiliza los siguientes objetos en su implementación.

  • NetworkController provee un punto de entrada a la biblioteca a traves de una API simple para asignar y manejar redes.
  • Driver realiza la implementación de la red. Los drivers pueden ser de dos tipos inbuilt (como Bridge, Host, None y Overlay) o remote.
  • Network es la implementación del componente de Network definido anteriormente. El Driver es notificado cada vez que un Network es creado o actualizado.
  • Endpoint ofrece conectividad para los servicios. Un Endpoint solo puede ser adjuntado a un Network.
  • Sandbox representa la configuración de la red como la dirección IP, la dirección MAC, las rutas de tráfico de red y las entradas del DNS. Un Sandbox puede tener varios Endpoints conectados a diferentes Networks.

El siguiente código en Go muestra la creacion de la red network1 utilizando el driver bridge para mas tarde conectar el contenedor container1 a traves del endpoint Endpoint1.

import (
	"fmt"
	"log"

	"github.com/docker/docker/pkg/reexec"
	"github.com/docker/libnetwork"
	"github.com/docker/libnetwork/config"
	"github.com/docker/libnetwork/netlabel"
	"github.com/docker/libnetwork/options"
)

func main() {
	if reexec.Init() {
		return
	}

	// Select and configure the network driver
	networkType := "bridge"

	// Create a new controller instance
	driverOptions := options.Generic{}
	genericOption := make(map[string]interface{})
	genericOption[netlabel.GenericData] = driverOptions
	controller, err := libnetwork.New(config.OptionDriverConfig(networkType, genericOption))
	if err != nil {
		log.Fatalf("libnetwork.New: %s", err)
	}

	// Create a network for containers to join.
	// NewNetwork accepts Variadic optional arguments that libnetwork and Drivers can use.
	network, err := controller.NewNetwork(networkType, "network1", "")
	if err != nil {
		log.Fatalf("controller.NewNetwork: %s", err)
	}

	// For each new container: allocate IP and interfaces. The returned network
	// settings will be used for container infos (inspect and such), as well as
	// iptables rules for port publishing. This info is contained or accessible
	// from the returned endpoint.
	ep, err := network.CreateEndpoint("Endpoint1")
	if err != nil {
		log.Fatalf("network.CreateEndpoint: %s", err)
	}

	// Create the sandbox for the container.
	// NewSandbox accepts Variadic optional arguments which libnetwork can use.
	sbx, err := controller.NewSandbox("container1",
		libnetwork.OptionHostname("test"),
		libnetwork.OptionDomainname("docker.io"))
	if err != nil {
		log.Fatalf("controller.NewSandbox: %s", err)
	}

	// A sandbox can join the endpoint via the join api.
	err = ep.Join(sbx)
	if err != nil {
		log.Fatalf("ep.Join: %s", err)
	}

	// libnetwork client can check the endpoint's operational data via the Info() API
	epInfo, err := ep.DriverInfo()
	if err != nil {
		log.Fatalf("ep.DriverInfo: %s", err)
	}

	macAddress, ok := epInfo[netlabel.MacAddress]
	if !ok {
		log.Fatalf("failed to get mac address from endpoint info")
	}

	fmt.Printf("Joined endpoint %s (%s) to sandbox %s (%s)\n", ep.Name(), macAddress, sbx.ContainerID(), sbx.Key())
}

Esta propuesta ofrece una gran versatilidad para la creación y administración de las redes de los contenedores, sin embargo el grupo de desarrolladores de Kubernetes no escogió este modelo de red. En su sitio oficial se explica las razones técnicas de dicha selección.

El driver MAC-VLAN

En el articulo anterior revisamos las redes que son creadas por defecto por el servicio de Docker y como el driver bridge agrega un linux bridge entre el contenedor y la interfaz de red del servidor, además de utilizar un veth pair para conectar el contenedor con dicho bridge.

El siguiente bloque de código muestra la relación existente entre contenedor y el servidor donde se ejecuta, se puede observar que la interfaz de red del contenedor eth0@if23 hace referencia a la interfaz numero 23 del servidor que es vethe752504.

$ docker run --detach --name container ubuntu:18.04 sleep infinity
c719a954130f4769afeff28654800e8d7593b14442cfb36bcbd0ed0eade28b83
$ docker exec -ti container ip addr show eth0
22: eth0@if23: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:ac:50:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 172.80.0.2/24 brd 172.80.0.255 scope global eth0
       valid_lft forever preferred_lft forever
$ ip link show type veth
23: vethe752504@if22: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP mode DEFAULT group default 
    link/ether f6:5d:14:36:58:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
$ brctl show
bridge name     bridge id               STP enabled     interfaces
docker0         8000.0242f6f9457f       no              vethe752504

Aunque utilizar un linux bridge resulta útil para la mayoría de los casos, existen aplicaciones las cuales requieren ser conectadas directamente a la red física del servidor donde son ejecutadas.

Existen dos tipos de drivers (macvlan y ipvlan) los cuales ofrecen una conexión más directa. Estos drivers reducen la latencia de red debido a que la ruta de tráfico de los paquetes de red es más corta. En este artículo revisamos a detalle el driver de MACVLAN o MAC-VLAN.

Definición

El driver MAC-VLAN opera en la capa de enlace de datos del modelo OSI y permite conectar múltiples subinterfaces de contenedores o máquinas virtuales a una sola interfaz física. Cada subinterfaz posee una dirección MAC (generada aleatoriamente) y por consiguiente una dirección IP.

Existen cuatro tipos de MAC-VLAN:

  • Privada: Donde todas las tramas de red son reenviadas por medio de la interfaz de red principal. No es posible una comunicación entre subinterfaces en el mismo servidor.
  • Virtual Ethernet Port Aggregator: Requiere un switch que tenga soporte IEEE 802.1Qbg el cual permite una comunicación entre subinterfaces en el mismo servidor. Las tramas de red son enviadas a través de la interfaz de red principal lo cual permite que puedan ser aplicadas políticas de red externas.
  • Bridge: Conecta todas las subinterfaces con un bridge lo cual permite que las tramas de red sean enviadas directamente sin salir del servidor.
  • Passthru: Permite conectar una sola subinterfaz a la interfaz de red principal.

Laboratorio

Para el caso de Docker, este servicio utiliza el tipo Bridge en el driver MAC-VLAN, lo que permite una comunicación externa e intercomunicación entre contenedores. El siguiente ejemplo muestra las instrucciones para crear una red de tipo MAC-VLAN en Docker y la creación de dos contenedores dentro de esa misma red.

$ ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 08:00:27:b0:b7:a2 brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic noprefixroute eth0
       valid_lft 85773sec preferred_lft 85773sec
$ docker network create --driver macvlan --subnet=10.0.2.0/24  --gateway=10.0.2.2 --opt parent=eth0 macvlan0
d92d3cf366628e962a0bbd4b922d6ca7b2c50e9dc69c5219a2dbd398ae32d923
$ docker run --detach --name container --network macvlan0 busybox sleep infinity
aa915e2015629361306c80b2e508f94b6855857b14cfe6ea397c151250f12cb2
$ docker run --detach --name container2 --network macvlan0 busybox sleep infinity
dff856cb2457b27bfd2f8e5bef44eada3f63bdc4aa8b4e3e8e3dd2ed52cd53d4

Las siguientes instrucciones muestran las direcciones IP asignadas a los contenedores que fueron creados recientemente.

$ docker exec -ti container ip addr show eth0
13: eth0@if2: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue 
    link/ether 02:42:0a:00:02:01 brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.1/24 brd 10.0.2.255 scope global eth0
       valid_lft forever preferred_lft forever
$ docker exec -ti container2 ip addr show eth0
14: eth0@if2: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue 
    link/ether 02:42:0a:00:02:03 brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.3/24 brd 10.0.2.255 scope global eth0
       valid_lft forever preferred_lft forever

Una vez obtenidas las direcciones IP de los dos contenedores, es posible validar distintos tipos de comunicación.

Las siguientes instrucciones muestran la comunicación de este a oeste, donde se observa que los contenedores pueden comunicarse entre si.

$ docker exec -ti container ping -c 3 10.0.2.3
PING 10.0.2.3 (10.0.2.3): 56 data bytes
64 bytes from 10.0.2.3: seq=0 ttl=64 time=0.081 ms
64 bytes from 10.0.2.3: seq=1 ttl=64 time=0.083 ms
64 bytes from 10.0.2.3: seq=2 ttl=64 time=0.059 ms

--- 10.0.2.3 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.059/0.074/0.083 ms

La comunicación de sur a norte tiene algunas limitantes. Podemos observar que no es posible la comunicación directa con la dirección IP de la interfaz de red principal.

$ docker exec -ti container ping -c 3 10.0.2.15
PING 10.0.2.15 (10.0.2.15): 56 data bytes

--- 10.0.2.15 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss

Sin embargo, es posible la comunicación directa con la dirección IP de la interfaz del Gateway.

$ docker exec -ti container ping -c 3 10.0.2.2
PING 10.0.2.2 (10.0.2.2): 56 data bytes
64 bytes from 10.0.2.2: seq=1 ttl=64 time=0.285 ms
64 bytes from 10.0.2.2: seq=2 ttl=64 time=0.233 ms

--- 10.0.2.2 ping statistics ---
3 packets transmitted, 2 packets received, 33% packet loss
round-trip min/avg/max = 0.233/0.259/0.285 ms

Tipos de red en Docker

Últimamente se habla mucho sobre contenedores, subrayando los beneficios de su uso para el desarrollo y despliegue de aplicaciones, y en ocasiones se hacen comparaciones erróneas con las Máquinas Virtuales. Este articulo pretende cubrir las opciones de red locales que ofrece Docker al crear contenedores.

Cuando el servicio de Docker inicia este crea localmente tres redes que ofrecen distintas capacidades.

$ docker network list
NETWORK ID          NAME                DRIVER              SCOPE
d1cd6bdefdb7        bridge              bridge              local
e14adf7f1918        host                host                local
9c7b12187b80        none                null                local

Se puede observar los distintos tipos de red local en la columna de DRIVER.

  • Bridge: Valor por defecto. Se utiliza cuando las aplicaciones son ejecutadas en contenedores independientes que necesitan comunicarse entre ellos.
  • Host: Valor usado en contenedores independientes donde se busca compartir los servicios de red ofrecidos por el servidor donde el contenedor fue creado.
  • Null: Deshabilita los servicios de red para dicho contenedor.

Host network

Este tipo de red comparte los servicios de red del equipo donde se ejecuta.  Además de ofrecer las siguientes capacidades:

  1. Las interfaces de red del contenedor son idénticas a las de la máquina donde se ejecuta.
  2. Solo existe una red de tipo host por máquina.
  3. Es necesario especificar el tipo de red como argumento «–net=host».
  4. Ni container linking ni port mapping son soportados.
$ ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:00:27:92:e3:8c brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global eth0
       valid_lft forever preferred_lft forever
$ docker run --net=host bash:5.0.17 ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:92:e3:8c brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global eth0
       valid_lft forever preferred_lft forever

None network

Es posible crear un contenedor sin algún tipo de red asignada a el. Este contenedor es solo accesible a traves del shell del servidor donde fue creado.

Estos contenedores pueden ser útiles para la ejecución de tareas por lotes que no requieren conectividad hacia o desde ellos.

$ docker run --net=none bash:5.0.17 ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever

Bridge network

Permite la creación de múltiples redes en el mismo servidor ofreciendo una separación lógica de la red, es decir, solo contenedores conectados a la misma red se pueden comunicar entre si.

$ docker run --net=bridge bash:5.0.17 ip addr show eth0
11: eth0@if12: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP 
    link/ether 02:42:ac:50:00:03 brd ff:ff:ff:ff:ff:ff
    inet 172.80.0.3/24 brd 172.80.0.255 scope global eth0
       valid_lft forever preferred_lft forever

La red predeterminada creada por el servicio Docker al momento de iniciar es llamada bridge y crea un bridge llamado docker0 con los valores de una subnet en el rango de 172.80.0.0/24.

$ brctl show
bridge name     bridge id               STP enabled     interfaces
docker0         8000.0242eaa3ec7c       no

Todos los contenedores creados en este servidor donde no se especifique su red serán conectados a esta red.

OPNFV y CNTT

Network Function Virtualization (NFV) representa el cambio mas significante en las redes de comunicación global en los últimos 30 años.  Es por ello que resulta esencial adoptar una estrategia donde se maximice la flexibilidad, agilidad e interoperabilidad de la red, aprovechando la rápida innovación del ecosistema.

OPNFV

La Plataforma Abierta para NFV o por sus siglas en ingles OPNFV,  es la comunidad de la Linux Foundation que provee herramientas para realizar una validación de proyectos upstream a traves de un proceso de integración continua. Cuenta con un programa de verificación de equipos que permite acelerar la transformación de las redes de proveedores de servicios y empresas.

OPNFV facilita la implementación y desarrollo de la tecnología de NFV permitiendo su amplia adopción.

Para entender el alcance de los proyectos upstream que OPNFV valida e integra, es necesario conocer las distintas partes que componen el modelo que el Instituto Europeo de Normas de Telecomunicaciones (ETSI) publicó en su especificación ETSI GS NFV-INF 001 V1.1.1 (2015-01) donde se representa la arquitectura de su infraestructura de la siguiente manera:


A continuación se definen algunos conceptos:

  • Network Function (NF): Es un bloque funcional dentro de una infraestructura de red en el cual tiene bien definido sus interfaces externas y su comportamiento funcional.
  • Physical Network Function (PNF): Refiere a un dispositivo de hardware que ofrece un propósito de red especifico o un Network Function.
  • Virtualised Network Function (VNF): Es una implementación de una Network Function en una o varias Máquinas Virtuales.
  • Cloud-Native Network Function (CNF): Es considerado como la siguiente generación de VNFs donde se utiliza paradigmas de desarrollo para la Nube en la implementación de Network Function.
  • Network Functions Virtualisation Infrastructure (NFVI): El conjunto de los componentes de hardware y software en el cual se crea un ambiente para desplegar VNFs y/o CNFs.
  • Virtualised Infrastructure Manager (VIM): Es responsable de controlar y administrar la infraestructura para NFV (NFVI), manteniendo un inventario de los recursos virtuales asignados a los recursos físicos.

CNTT

El desarrollo y despliegue de aplicaciones VNFs y/o CNFs requiere retos técnicos significantes que sumado a la proliferación de nuevas tecnologías afectan drásticamente las estrategias operacionales de cualquier negocio.

Es por eso que a principios del 2019 eso fue creado el comité de Cloud iNfrastructure Telco Taskforce (CNTT) el cual es responsable de la creación y documentación de un marco de trabajo común para la Infraestructura de la Nube.

El CNTT ofrece cuatro niveles de documentación necesarios para la descripción de componentes y su correcta aplicación:

  1. Modelos de Referencia: Enfocado en la abstracción de la Infraestructura y como los recursos y servicios son expuestos a las VNFs y/o CNFs.
  2. Arquitectura de Referencia: Define los componentes y propiedades de la Infraestructura en los cuales VNFs y/o CNFs son ejecutados, desplegados y diseñados.
  3. Implementación de Referencia: Es construido con base en los requerimientos y especificaciones de los Modelos y Arquitectura de Referencia agregando detalles sobre su implementacion.
  4. Consenso de Referencia: Verifica, prueba y certifica los requerimientos y especificaciones desarrolladas en otros documentos.

A continuación se muestra los diferentes tipos de elementos de una plataforma típica de la Nube.

CNTT Scope

 

Instalación de servicios OpenStack

OpenStack Kolla

A traves de los artículos anteriores realizamos la creación un repositorio para el almacenamiento de las imágenes Docker utilizadas por los servicios de OpenStack para así mas tarde configurar las herramientas y los nodos que almacenaran dichos servicios. Es por ello que solo resta realizar el último paso que es el proceso de Instalación de servicios de OpenStack. Este proceso consta de las siguientes etapas:

  1. bootstrap-servers: Inicializa los nodos destino con la instalación de dependencias necesarias por el proceso de Instalación de servicios de OpenStack. Entre las tareas que este proceso realiza se encuentra:
    • La configuración del archivo /etc/hosts.
    • Asegura que los grupos sudo y kolla existan en cada uno de los nodos.
    • La instalación de dependencias, certificados y claves GPG
    • Configuración del cortafuegos.
    • Instalación y configuración del servicio de Docker.
    • Sincronización los relojes.
  2. prechecks: Realiza una validación de requerimientos necesarios por el proceso de Instalación. Donde principalmente se valida que los puertos a ser usados por los servicios habilitados se encuentren disponibles.
  3. pull: Descarga de las imágenes de los servicios de OpenStack basándose en los roles que fueron definidos para cada nodo.
  4. deploy: Despliegue de servicios. Durante este proceso se realiza las siguientes tareas para cada servicio:
    • Creación de base de datos y tablas.
    • Creación y registro de usuarios.
    • Configuración de políticas de acceso.
  5. check: Realiza una validación a traves de tareas de sanity checks donde se determina el correcto funcionamiento de algunos servicios.
  6. post-deploy: Genera el archivo openrc para el usuario admin.

Estas etapas son traducidas en argumentos utilizados por la herramienta de kolla-ansible(la cual hemos instalado y configurado previamente). De manera que nuestro proceso puede ser realizado en una iteración de los distintos argumentos mediante ciclo.

for action in bootstrap-servers prechecks pull deploy check post-deploy; do
    sudo kolla-ansible -vvv -i $inventory_file $action -e 'ansible_user=kolla' -e 'ansible_become=true' -e 'ansible_become_method=sudo' | tee $action.log
done

Nota adicional: El repositorio de GitHub ha sido actualizado para incorporar las instrucciones necesarias para realizar un Instalación de servicios OpenStack para el release de Stein.

Configuración previa a la Instalación de OpenStack

En el articulo anterior creamos un servidor el cual administra las imágenes Docker que son utilizadas durante el proceso de instalación de OpenStack. A lo largo de este articulo sera explicado el proceso de configuración previa a la instalación de OpenStack.

Soluciones de Infraestructura como Servicio como lo es OpenStack, buscan maximizar el uso de los recursos del centro de datos, por lo cual se recomienda habilitar varios módulos del kernel que nos ayuden a mejorar el desempeño en cada uno de los equipos.

La virtualización anidada es la capacidad que permite a los usuarios la creación de máquinas virtuales dentro de una máquina virtual. El proceso de habilitación de esta capacidad depende de la arquitectura del procesador que se este utilizado, el comando lscpu nos proporciona la información acerca del CPU.

$ lscpu 
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                88
On-line CPU(s) list:   0-87
Thread(s) per core:    2
Core(s) per socket:    22
Socket(s):             2
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 79
Model name:            Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz
Stepping:              1
CPU MHz:               1578.328
CPU max MHz:           3600.0000
CPU min MHz:           1200.0000
BogoMIPS:              4391.44
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              56320K
NUMA node0 CPU(s):     0-87
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb invpcid_single intel_pt ssbd ibrs ibpb stibp kaiser tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm rdseed adx smap xsaveopt cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts flush_l1d

En este caso la arquitectura del procesador del servidor utilizado es x86, por lo que las instrucciones para habilitar son:

$ rmmod kvm-intel
$ echo 'options kvm-intel nested=y' >> /etc/modprobe.d/dist.conf
$ modprobe kvm-intel

Otro modulo del kernel que nos mejora el desempeño es vhost_net. De acuerdo a este articulo de RedHat, este modulo ayuda a reducir las operaciones de escritura, latencia y uso de CPU y se habilita a traves de la instrucción:

$ modprobe vhost_net

vhost_net

En este punto nuestros servidores o nodos destino han sido configurados para obtener un mejor desempeño. Ahora es momento de proceder con la instalación de la herramienta Kolla-Ansible y sus respectivas dependencias.

Todas instrucciones que se mostrarán a continuación pueden ser ejecutadas desde cualquier máquina que tenga conectividad a los nodos destino. En nuestro diagrama de ejemplo el servidor con nombre de undercloud mantiene conexión con el resto de nodos destino a traves de la red de administración con CIDR de «192.168.121.0/27».

Diagrama de ejemplo

Esta máquina utilizará kolla-ansible para realizar la Instalación de OpenStack. Este programa puede ser instalado de distintas formas, sin embargo en este caso sera instalado desde su código fuente.

$ wget http://tarballs.openstack.org/kolla-ansible/kolla-ansible-stable-rocky.tar.gz
$ tar -C /opt -xzf kolla-ansible-stable-rocky.tar.gz
$ mv /opt/kolla-*/ /opt/kolla-ansible
$ sudo cp /opt/kolla-ansible/etc/kolla/passwords.yml /etc/kolla/
$ pip install /opt/kolla-ansible

Como ultimo paso previo a la instalación de OpenStack, se necesita un archivo de configuración el cual especifique los detalles de la instalación (versión de OpenStack a instalar, dirección IP del VIP, dirección IP del repositorio de imágenes, habilitación de servicios, etc.). Estos son algunos de los valores utilizados en el archivo globals.yml:

openstack_release: "7.0.0"
kolla_internal_vip_address: "10.10.13.3"
docker_registry: "10.10.13.2:5000"
network_interface: "eth0"
kolla_external_vip_interface: "eth1"
api_interface: "{{ kolla_external_vip_interface }}"
storage_interface: "eth2"
cluster_interface: "eth2"
tunnel_interface: "eth1"
neutron_external_interface: "eth2"
neutron_plugin_agent: "opendaylight"

En este punto se cuenta con la configuración previa a la instalación de servicios de OpenStack. El siguiente articulo proporcionará los pasos necesarios para realizar el despliegue de los servicios de OpenStack en una configuración de Alta Disponibilidad.

Nota: El script undercloud.sh contiene las instrucciones mencionadas en este articulo

Creación de Imágenes de OpenStack usando Kolla

En el articulo anterior detallaba el proceso para la creación de imágenes de OpenStack en un repositorio Docker privado a traves del proyecto de Kolla. Dichas imágenes serán utilizadas mas parte por las tareas del proyecto de kolla-ansible durante el despliegue de servicios de OpenStack en una configuración que ofrezca Alta Disponibilidad.

Para esta serie de artículos fue necesario crear un repositorio el cual pudiera almacenar las instrucciones. La validación de este proyecto se realiza a traves de la tecnología de vagrant la cual nos permite provisionar automáticamente Máquinas Virtuales.

Con el fin de agregar mas nodos con fines mas especializados fue necesario modificar la arquitectura inicial, dando como resultado tenemos el siguiente diagrama:

Diagrama de la arquitectura de nodos

El servidor llamado «registry» realizara la creación de imágenes. Este cambio ofrece un mejor control y administración de las imágenes de OpenStack utilizadas durante el proceso de provisionamiento. Para la creación de este servidor es necesario instalar las dependencias del proyecto, para ello necesitaremos el manejador de paquetes de python(pip) y el código fuente del proyecto.

apt remove -y python-pip
apt-get install -y python-dev
curl -sL https://bootstrap.pypa.io/get-pip.py | sudo python

wget http://tarballs.openstack.org/kolla/kolla-stable-rocky.tar.gz
tar -C /opt -xzf kolla-stable-rocky.tar.gz
mv /opt/kolla-*/ /opt/kolla
pip install /opt/kolla

Una vez instalado los módulos de python, es necesario instalar e iniciar el servicio de Docker. La comunidad de Kolla utiliza el directorio de tools para los procesos Jenkins durante la validación de cambios propuestos en el código fuente, el script setup_Debian.sh nos permite instalar el servicio de Docker y el script start-registry crea un repositorio Docker privado a traves de un contenedor.

pushd /opt/kolla/tools/
./setup_Debian.sh
./start-registry
popd

Por ultimo procederemos a la creación de imágenes de OpenStack Kolla, el comando kolla-build utiliza el archivo de configuración kolla-build.ini, en este archivo es necesario especificar la IP del servidor de registry el cual almacenará las imágenes de OpenStack y también habilitaremos la publicación automática de las imágenes creadas con del valor de configuración «push».

push = true
registry = 10.10.13.2:5000

Una vez todo configurado podemos comenzar con el proceso de creación de imágenes con la ejecución del siguiente comando:

kolla-build --config-file /etc/kolla/kolla-build.ini