Building Custom Containers for Cisco Modeling Labs (CML): A Practical Guide

[ad_1] Container nodes in Cisco Modeling Labs (CML) 2.9 complement digital machines, providing better flexibility and effectivity. Engineers profit from having light-weight, programmable, and quickly deployable choices inside their simulation environments. Whereas digital machines (VMs) dominate with community working programs, containers add flexibility, enabling instruments, visitors injectors, automation, and full functions to run easily along with your CML topology. Conventional digital machines are nonetheless efficient, however customized containers introduce a transformative agility.

Constructing photographs that behave predictably and combine cleanly with simulated networks is way simpler with containers. As anybody who has tried to drop a inventory Docker picture into CML shortly discovers, this isn’t a simple course of. Typical Docker photographs lack the mandatory CML-compatible metadata, community interface behaviors, and lifecycle properties. Utilizing containers with CML is the lacking factor.

This weblog put up gives a sensible, engineering-first walkthrough for constructing containers which can be actually CML-ready.

CML system (AI-generated) Be aware about enhancements to CML: When containers had been launched, just one picture per node definition was allowed. With the CML 2.10 launch, this restriction has been lifted. Specifically, the next enhancements will likely be added:

Per picture definition, Docker tag names corresponding to:

debian:bookworm, debian:buster and debian:trixie Are all legitimate tags for a similar “debian-docker” node definitions—three legitimate picture definitions for one node definition.

Specification of Docker tags as a substitute for picture names (.tar.gz information) and SHA256 has sums. On this case, CML will attempt to obtain the picture from a container registry, e.g., Docker Hub, if not in any other case specified. Improved launch logic to keep away from “perpetual launches” in case the SHA256 sum from the picture definition didn't match the precise hash sum within the picture.

Why do customized containers in CML matter? Conventional CML workflows depend on VM-based nodes working IOSv, IOS-XRv, NX-OS, Ubuntu, Alpine, and different working programs. These are wonderful for modeling community working system conduct, however they’re heavyweight for duties corresponding to integrating CLI instruments, internet browsers, ephemeral controllers, containerized apps, microservices, and testing harnesses into your simulations.

Containers begin shortly, eat fewer assets, and combine easily with commonplace NetDevOps CI/CD workflows. Regardless of their benefits, integrating commonplace Docker photographs into CML isn’t with out its challenges, every of which requires a tailor-made answer for seamless performance.

The hidden challenges: why a Docker picture isn’t sufficient CML doesn’t run containers in the identical manner a vanilla Docker Engine does. As an alternative, it wraps containers in a specialised runtime surroundings that integrates with its simulation engine. This results in a number of potential pitfalls:

Entry factors and init systemsMany base photographs assume they’re the one course of working. In CML, community interfaces, startup scripts, and boot readiness needs to be offered. Additionally, CML expects a long-running foreground course of. In case your container exits instantly, CML will deal with the node as “failed.” Interface mappingContainers usually use eth0, but CML attaches interfaces sequentially based mostly on topology (eth0, eth1, eth2…). Your picture ought to deal with further interfaces added at startup, mapping them to particular OS configurations. Capabilities and usersSome containers drop privileges by default. CML’s bootstrap course of might have particular entry privileges to configure networking or begin daemons. Filesystem layoutCML makes use of elective bootstrap belongings injected into the container’s filesystem. A normal Docker picture gained’t have the best directories, binaries, or permissions for this. If wanted, CML can “inject” a full suite of command-line binaries (“busybox”) right into a container to supply a correct CLI surroundings. Lifecycle expectationsContainers ought to output log info to the console in order that performance will be noticed in CML. For instance, an online server ought to present the entry log.

Misalign any of those, and also you’ll spend hours troubleshooting what seems to be a easy “it really works with run” state of affairs.

How CML treats containers: A psychological mannequin for engineers CML’s container capabilities revolve round a node-definition YAML file that describes:

The picture to load or pull The bootstrap course of Setting variables Interfaces and the way they bind Simulation conduct (startup order, CPU/reminiscence, logging) UI metadata

When a lab launches, CML:

Deploys a container node Pulls or hundreds the container picture Applies networking definitions Injects metadata, IP tackle, and bootstrap scripts Displays node well being by way of logs and runtime state

Consider CML as “Docker-with-constraints-plus-network-injection.” Understanding CML’s strategy to containers is foundational, however constructing them requires specifics—listed here are sensible ideas to make sure your containers are CML-ready.

Suggestions for constructing a CML-ready container The container photographs constructed for CML 2.10 and ahead are created on GitHub. We use a GitHub Motion CI workflow to totally automate the construct course of. You possibly can, the truth is, use the identical workflow to construct your individual customized photographs able to be deployed in CML. There’s loads of documentation and examples which you could construct off of, offered within the repository* and on the Deep Wiki.**

Necessary notice: CML treats every node in a topology as a single, self-contained service or software. Whereas it may be tempting to instantly deploy multi-container functions, usually outlined utilizing docker-compose , into CML by trying to separate them into particular person CML nodes, this strategy is usually not advisable and might result in vital issues.

1.) Select the best base Begin from an already current container definition, like:

nginx (single-purpose community daemon utilizing a vanilla upstream picture). Firefox (graphical person interface, customized construct course of). Or a customized CI-built base along with your commonplace automation framework.

Keep away from utilizing photographs that depend on SystemD until you explicitly configure it; SystemD inside containers will be difficult.

2.) Outline a correct entry level Your container should:

Run a long-lived course of. Not daemonize within the background. Assist predictable logging. Hold the container “alive” for CML.

Right here’s a easy supervisor script:

#!bin/sh echo "Container beginning..." tail -f /dev/null Not glamorous, however efficient. You possibly can substitute tail -f /dev/null along with your service startup chain.

3.) Put together for a number of interfaces CML could connect a number of interfaces to your topology. CML will run a DHCP course of on the primary interface, however until that first interface is L2-adjacent to an exterior connector in NAT mode, there’s NO assure it should purchase one! If it can't purchase an IP tackle, it's the lab admin’s duty to supply IP tackle configuration per the day 0 configuration. Usually, ip config … instructions can be utilized for this objective.

Superior use circumstances you may unlock When you conquer customized containers, CML turns into dramatically extra versatile. Some in style use circumstances amongst superior NetDevOps and SRE groups embody:

Artificial visitors and testing

Automation engines

Nornir nodes pyATS/Genie take a look at harness containers Ansible automation controllers

Distributed functions

Fundamental service-mesh experiments API gateways and proxies Container-based middleboxes

Safety instruments

Honeypots IDS/IPS elements Packet inspection frameworks

Deal with CML as a “full-stack lab,” enhancing its capabilities past a mere community simulator.

Make CML your individual lab Creating customized containers for CML turns the platform from a simulation device into a whole, programmable take a look at surroundings. Whether or not you’re validating automation workflows, modeling distributed programs, prototyping community capabilities, or just constructing light-weight utilities, containerized nodes mean you can adapt CML to your engineering wants—not the opposite manner round.

For those who’re prepared to increase your CML lab, one of the simplest ways to begin is easy: construct a small container, copy and modify an current node definition, and drop it right into a two-node topology. When you see how easily it really works, you’ll shortly understand simply how far you may push this characteristic.