Los nodos de contenedores en Cisco Modeling Labs (CML) 2.9 complementan las máquinas virtuales y ofrecen mayor flexibilidad y eficiencia. Los ingenieros se benefician de tener capacidades livianas, programables y de rápida implementación en sus entornos de simulación. Si bien las máquinas virtuales (VM) dominan los sistemas operativos de red, los contenedores agregan flexibilidad, permitiendo que herramientas, inyectores de tráfico, automatización y aplicaciones completas se ejecuten sin problemas con su topología CML. Las máquinas virtuales tradicionales siguen siendo eficientes, pero los contenedores personalizados introducen una agilidad transformadora.
Crear imágenes que se comporten de manera predecible y se integren limpiamente con redes simuladas es mucho más fácil con contenedores. Como descubre rápidamente cualquiera que haya intentado colocar una imagen estándar de Docker en CML, este no es un proceso sencillo. Las imágenes típicas de Docker carecen de los metadatos, el comportamiento de la interfaz de red y las propiedades del ciclo de vida necesarios compatibles con CML. Usar contenedores con CML es el elemento que falta.
Esta publicación de blog proporciona un tutorial práctico y técnico para crear contenedores que estén realmente preparados para CML.
Nota sobre las mejoras a CML: Cuando se introdujeron los contenedores, solo se permitía una imagen por definición de nodo. Con la versión CML 2.10, esta limitación se eliminó. En particular, se añadirán las siguientes mejoras:
- Doloroso imagen definición, Estibador techo nombres como:
debian:bookworm, debian:buster and debian:trixie
¿Son todas las etiquetas válidas para las mismas definiciones de nodo «debian-docker»? Tres definiciones de imagen válidas para una definición de nodo.
- Especificación de etiquetas Docker como alternativa a los nombres de imágenes (archivos .tar.gz) y SHA256 tienen sumas. En este caso, CML intentará descargar la imagen desde un registro de contenedor, p. Docker Hub a menos que se indique lo contrario.
- Lógica de lanzamiento mejorada para evitar «lanzamientos perpetuos» si la suma SHA256 de la definición de la imagen no coincide con la suma hash real de la imagen.
¿Por qué son importantes los contenedores personalizados en CML?
Los flujos de trabajo de CML tradicionales se basan en nodos basados en VM que ejecutan IOSv, IOS-XRv, NX-OS, Ubuntu, Alpine y otros sistemas operativos. Son excelentes para modelar el comportamiento del sistema operativo de red, pero son pesados para tareas como integrar herramientas CLI, navegadores web, controladores volátiles, aplicaciones en contenedores, microservicios y cableado de prueba en sus simulaciones.
Los contenedores se inician rápidamente, utilizan menos recursos y se integran perfectamente con los flujos de trabajo estándar de CI/CD de NetDevOps. A pesar de sus ventajas, la integración de imágenes Docker estándar en CML no está exenta de desafíos, cada uno de los cuales requiere una solución personalizada para una funcionalidad perfecta.
Los desafíos ocultos: por qué una imagen de Docker no es suficiente
CML no ejecuta contenedores de la misma manera que lo hace un Docker Engine básico. En cambio, envuelve los contenedores en un entorno de ejecución especializado que se integra con su motor de simulación. Esto conduce a varios peligros potenciales:
- Puntos de entrada y sistemas de inicio
Muchas imágenes base asumen que son solo el proceso está en marcha. En CML, se deben proporcionar interfaces de red, scripts de arranque y claridad de arranque. CML también espera un largo proceso de preparación. Si su contenedor finaliza inmediatamente, CML tratará el nodo como «fallido». - Mapeo de interfaz
Los contenedores suelen utilizar eth0, pero CML asigna interfaces secuencialmente según la topología (eth0, eth1, eth2…). Su imagen debe manejar interfaces adicionales agregadas en el arranque y asignarlas a configuraciones específicas del sistema operativo. - Oportunidades y usuarios
Algunos contenedores pierden privilegios de forma predeterminada. El proceso de arranque de CML puede necesitar derechos de acceso específicos para configurar redes o iniciar demonios. - Diseño del sistema de archivos
CML utiliza activos de arranque opcionales inyectados en el sistema de archivos del contenedor. Una imagen de Docker estándar no tendrá los directorios, archivos binarios o permisos correctos para esto. Si es necesario, CML puede «inyectar» un paquete completo de archivos binarios de línea de comandos («busybox») en un contenedor para proporcionar un entorno CLI adecuado. - Expectativas del ciclo de vida.
Los contenedores deben enviar información de registro a la consola para que se pueda observar la funcionalidad en CML. Por ejemplo, un servidor web debe mostrar el registro de acceso.
Si se equivoca en cualquiera de estos aspectos, pasará horas solucionando lo que parece ser un escenario simple de «funciona con la conducción».
Cómo CML procesa contenedores: un modelo mental para ingenieros
Las capacidades del contenedor de CML giran en torno a un archivo YAML de definición de nodo que describe:
- La imagen para cargar o arrastrar
- El proceso de arranque
- Variables ambientales
- Interfaces y cómo se unen
- Comportamiento de simulación (orden de arranque, CPU/memoria, registro)
- Interfaz de usuario de metadatos
Cuando comienza un laboratorio, CML:
- Implementa un nodo contenedor.
- Arrastra o carga la imagen del contenedor.
- Aplica definiciones de red
- Inyecta metadatos, dirección IP y scripts de arranque
- Supervisa el estado del nodo a través de registros y el estado del tiempo de ejecución.
Piense en CML como «Docker-con-restricciones-más-inyección-de-red». Comprender el enfoque de CML hacia los contenedores es fundamental, pero construirlos requiere detalles; aquí se ofrecen consejos prácticos para garantizar que sus contenedores estén preparados para CML.
Consejos para crear un contenedor listo para CML
Las imágenes de contenedor creadas para CML 2.10 y superiores se crean en GitHub. Usamos un flujo de trabajo de GitHub Action CI para automatizar completamente el proceso de compilación. De hecho, puede utilizar el mismo flujo de trabajo para crear sus propias imágenes personalizadas listas para implementarse en CML. Hay mucha documentación y ejemplos sobre los que puedes desarrollar, proporcionados en el repositorio* y en Deep Wiki.**
Nota importante: CML trata cada nodo en una topología como un servicio o aplicación único e independiente. Aunque puede resultar tentador implementar directamente aplicaciones de contenedores múltiples, a menudo definidas mediante docker-compose, en CML al intentar dividirlas en nodos CML individuales, este enfoque generalmente no se recomienda y puede generar complicaciones importantes.
1.) Elige la base adecuada
Comience desde una definición de contenedor ya existente, como por ejemplo:
- nginx (demonio de red de un solo propósito que utiliza una imagen ascendente básica).
- Firefox (interfaz gráfica de usuario, proceso de compilación personalizado).
- O una base personalizada de CI creada con su marco de automatización estándar.
Evite el uso de imágenes que dependan de SystemD a menos que lo configure explícitamente; SystemD dentro de contenedores puede ser complicado.
2.) Defina un punto de entrada adecuado
Su contenedor debe:
- Ejecute un proceso de larga duración.
- No demonices en segundo plano.
- Admite el registro predictivo.
- Mantenga el contenedor «vivo» para la leucemia mieloide crónica.
Aquí hay un script de supervisor simple:
#!bin/sh echo "Container starting..." tail -f /dev/null
No glamoroso, pero sí efectivo. Puede reemplazar tail -f /dev/null con la cadena de inicio de su servicio.
3.) Prepárese para múltiples interfaces
CML puede asignar múltiples interfaces a su topología. CML ejecutará un proceso DHCP en la primera interfaz, pero a menos que la primera interfaz sea L2 adyacente a un conector externo en modo NAT, ¡NO hay garantía de que adquiera uno! Si no puede adquirir una dirección IP, es responsabilidad del administrador del laboratorio proporcionar la configuración de la dirección IP para la configuración del día 0. Normalmente, los comandos ip config… se pueden utilizar para este propósito.
Casos de uso avanzados que puedes desbloquear
Una vez que conquista los contenedores personalizados, CML se vuelve dramáticamente más flexible. Algunos casos de uso populares entre los equipos avanzados de NetDevOps y SRE incluyen:
Tráfico sintético y pruebas.
Motores de automatización
- Nudos de bruja
- Contenedores de arnés de prueba pyATS/Genie
- Controladores de automatización Ansible
Aplicaciones distribuidas
- Experimentos básicos de malla de servicios.
- Puertas de enlace API y servidores proxy
- Cajas intermedias basadas en contenedores
Herramientas de seguridad
- Honeypots
- Componentes IDS/IPS
- Marcos de inspección de paquetes
Trate a CML como un «laboratorio completo» que mejora sus capacidades más allá de un simple simulador de red.
Haga de CML su propio laboratorio
La creación de contenedores personalizados para CML transforma la plataforma de una herramienta de simulación a un entorno de prueba completo y programable. Ya sea que esté validando flujos de trabajo de automatización, modelando sistemas distribuidos, creando prototipos de funciones de red o simplemente creando herramientas livianas, los nodos en contenedores le permiten adaptar CML a sus necesidades técnicas, y no al revés.
Si está listo para expandir su laboratorio de CML, la mejor manera de comenzar es simple: crear un contenedor pequeño, copiar y modificar una definición de nodo existente y colocarlo en una topología de dos nodos. Cuando vea lo bien que funciona, rápidamente se dará cuenta de hasta dónde puede llevar esta función.
¿Le gustaría crear su propio contenedor personalizado para CML? ¡Cuéntanos en los comentarios!
* Repositorio Github: automatización para crear contenedores CML Docker
** DeepWiki – Contenedores Docker CML (CML 2.9+)
Únase a Cisco U. | Únase a Cisco Learning Network hoy de forma gratuita.
Siga Aprenda con Cisco
incógnita| Hilo | Facebook | LinkedIn | Instagram| YouTube
Usar #CiscoU y#CiscoCertpara participar en la conversación.
