Container nodes in Cisco Modeling Labs (CML) 2.9 complement digital machines, providing larger 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 techniques, containers add flexibility, enabling instruments, site 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 photos that behave predictably and combine cleanly with simulated networks is far simpler with containers. As anybody who has tried to drop a inventory Docker picture into CML shortly discovers, this isn’t an easy course of. Typical Docker photos lack the mandatory CML-compatible metadata, community interface behaviors, and lifecycle properties. Utilizing containers with CML is the lacking ingredient.
This weblog submit supplies a sensible, engineering-first walkthrough for constructing containers which can be actually CML-ready.
Be aware about enhancements to CML: When containers have 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 might be added:
- Per picture definition, Docker tag names comparable 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 recordsdata) 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 techniques. These are glorious for modeling community working system conduct, however they’re heavyweight for duties comparable to integrating CLI instruments, net 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 photos into CML isn’t with out its challenges, every of which requires a tailor-made resolution for seamless performance.
The hidden challenges: why a Docker picture isn’t sufficient
CML doesn’t run containers in the identical method a vanilla Docker Engine does. As a substitute, 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 techniques
Many base photos assume they’re the solely course of working. In CML, community interfaces, startup scripts, and boot readiness needs to be supplied. Additionally, CML expects a long-running foreground course of. In case your container exits instantly, CML will deal with the node as “failed.” - Interface mapping
Containers typically use eth0, but CML attaches interfaces sequentially primarily based on topology (eth0, eth1, eth2…). Your picture ought to deal with extra interfaces added at startup, mapping them to particular OS configurations. - Capabilities and customers
Some containers drop privileges by default. CML’s bootstrap course of might have particular entry privileges to configure networking or begin daemons. - Filesystem structure
CML makes use of optionally available bootstrap belongings injected into the container’s filesystem. A regular Docker picture gained’t have the appropriate directories, binaries, or permissions for this. If wanted, CML can “inject” a full suite of command-line binaries (“busybox”) right into a container to offer a correct CLI surroundings. - Lifecycle expectations
Containers ought to output log data to the console in order that performance may be noticed in CML. For instance, an internet 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” situation.
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
- Atmosphere 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 handle, and bootstrap scripts
- Screens node well being by way of logs and runtime state
Consider CML as “Docker-with-constraints-plus-network-injection.” Understanding CML’s method to containers is foundational, however constructing them requires specifics—listed below are sensible suggestions to make sure your containers are CML-ready.
Suggestions for constructing a CML-ready container
The container photos constructed for CML 2.10 and ahead are created on GitHub. We use a GitHub Motion CI workflow to completely automate the construct course of. You’ll be able to, in actual fact, use the identical workflow to construct your personal customized photos able to be deployed in CML. There’s loads of documentation and examples that you could construct off of, supplied within the repository* and on the Deep Wiki.**
Necessary notice: CML treats every node in a topology as a single, self-contained service or utility. Whereas it is perhaps tempting to straight deploy multi-container functions, typically outlined utilizing docker-compose , into CML by trying to separate them into particular person CML nodes, this method is mostly not really useful and may result in vital issues.
1.) Select the appropriate base
Begin from an already present 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 photos that depend on SystemD until you explicitly configure it; SystemD inside containers may be tough.
2.) Outline a correct entry level
Your container should:
- Run a long-lived course of.
- Not daemonize within the background.
- Help predictable logging.
- Preserve 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’ll be able to change 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 is going to purchase one! If it can’t purchase an IP handle, it’s the lab admin’s duty to offer IP handle configuration per the day 0 configuration. Sometimes, ip config … instructions can be utilized for this objective.
Superior use instances you’ll be able to unlock
When you conquer customized containers, CML turns into dramatically extra versatile. Some common use instances amongst superior NetDevOps and SRE groups embody:
Artificial site visitors and testing
Automation engines
- Nornir nodes
- pyATS/Genie check harness containers
- Ansible automation controllers
Distributed functions
- Primary 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 personal lab
Creating customized containers for CML turns the platform from a simulation device into a whole, programmable check surroundings. Whether or not you’re validating automation workflows, modeling distributed techniques, prototyping community features, or just constructing light-weight utilities, containerized nodes help you adapt CML to your engineering wants—not the opposite method round.
Should you’re prepared to increase your CML lab, the easiest way to start out is straightforward: construct a small container, copy and modify an present 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’ll be able to push this characteristic.
Would you wish to make your personal customized container for CML? Tell us within the feedback!
* Github Repository – Automation for constructing CML Docker Containers
** DeepWiki – CML Docker Containers (CML 2.9+)
Join Cisco U. | Be a part of the Cisco Studying Community immediately at no cost.
Comply with Be taught with Cisco
X | Threads | Fb | LinkedIn | Instagram | YouTube
Use #CiscoU and #CiscoCert to hitch the dialog.