When containerlab deploys a lab it creates a Lab Directory in the current working directory. This directory is used to keep all the necessary files that are needed to run/configure the nodes. We call these files configuration artifacts.
- CA certificate and node' TLS certificate and private keys
- node config file (if applicable and supported by the kind)
- node-specific files and directories that are required to launch the container
- license files if needed
all these artifacts will be available under a Lab Directory.
If you configure a node with
binds mounts and the source of the bind is not within the lab directory already, containerlab will copy over the source files/dirs into the lab directory on users behalf.
Identifying a lab directory#
The lab directory name follows the
clab-<lab_name> template. Thus, if the name of your lab is
srl02 you will find the
clab-srl02 directory created by default in the current working directory. The location can be altered via the CLAB_LABDIR_BASE envorinment variable.
❯ ls -lah clab-srl02 total 4.0K drwxr-xr-x 5 root root 40 Dec 1 22:11 . drwxr-xr-x 23 root root 4.0K Dec 1 22:11 .. drwxr-xr-x 5 root root 42 Dec 1 22:11 .tls drwxr-xr-x 3 root root 79 Dec 1 22:11 srl1 drwxr-xr-x 3 root root 79 Dec 1 22:11 srl2
The contents of this directory will contain kind-specific files and directories. Containerlab will name directories after the node names and will only created those if they are needed. For instance, by default any node of kind
linux will not have it's own directory under the Lab Directory.
Persistance of a lab directory#
When a user first deploy a lab, the Lab Directory gets created if it was not present. Depending on a node's kind, this directory might act as a persistent storage area for a node. A common case is having the configuration file saved when the changes are made to the node via management interfaces.
Below is an example of the
srl1 node directory contents. It keeps a directory that is mounted to containers configuration path, as well as stores additional files needed to launch and configure the node.
~/clab/clab-srl02 ❯ ls -lah srl1 drwxrwxrwx+ 6 1002 1002 87 Dec 1 22:11 config -rw-r--r-- 1 root root 2.8K Dec 1 22:11 license.key -rw-r--r-- 1 root root 4.4K Dec 1 22:11 srlinux.conf -rw-r--r-- 1 root root 233 Dec 1 22:11 topology.clab.yml
When a user destroys a lab without providing the
--cleanup flag to the
destroy command, the Lab Directory does not get deleted. This means that every configuration artifact will be kept on disk.
Moreover, when the user will deploy the same lab, containerlab will reuse the configuration artifacts if possible, which will, for example, start the nodes with the config files saved from the previous lab run.
To be able to deploy a lab without reusing existing configuration artifact use the
--reconfigure flag with
deploy command. With that setting, containerlab will first delete the Lab Directory and then will start the deployment process.