[[TOC]] = Users Guide / Tutorial = This document describes the workflow and commands to create an use a containerized experiment. We work through a couple examples showing the major features of the containers system. Detailed descriptions of the commands and configuration files are in the [wiki:Reference reference section]. == A Containerized Experiment == This example will walk through creating an experimental topology starting with how to describe a topology through building and using the containerized experiment. === Describing the Topology === Our first example is a star topology. We create a central node and connect 10 other nodes to it. It looks like this: [[Image(visualization-small.png)]] For this example we will use the standard DETER topology descriptions. If you have never used DETER, you should work through the [https://trac.deterlab.net/wiki/Tutorial DETER tutorial] first. The container system is largely compatible with the physical DETER interface. A DETER-compatible ns2 description of that topology is [attachnemt:example1.tcl attached to this page]. You can download it to {{{users.isi.deterlab.net}}} and follow along. It is a simple loop, along with the standard DETER boilerplate. This file can be used to create a 11-node (10 satellites and one central node) physical experiment on DETER, although there are not many physical nodes on DETER with 10 interfaces. {{{ source tb_compat.tcl set ns [new Simulator] # Create the center node (named by its variable name) set center [$ns node] # Connect 10 satellites for { set i 0} { $i < 10 } { incr i} { # Create node n-1 (tcl n($i) becomes n-$i in the experiment) set n($i) [$ns node] # Connect center to $n($i) ns duplex-link $center $n($i) 100Mb 10ms DropTail } # Creation boilerplate $ns rtptoto Static $ns run }}} With the detailed experiment description in front of us, we see a few more details. The central node is named "center" and each satellite is names "n-0", "n-1"... through "n-9". Each connection is a 100 Mb/s link with a 10ms delay. The round trip time from n-0 to center will be 20 ms and from n-0 to n-1 will be 40 ms. === Creating The Containerized Experiment === The container system will build the containerized experiment on top of a DETER physical experiment. We do this by running a command from the shell on {{{users.isi.deterlab.net}}}. With a copy of the [attachment:example1.tcl example topology] in your home directory, the following command will create the containerized experiment: {{{ $ /share/containers/containerize.py DeterTest exmaple1 ~/example1.tcl }}} The first two parameters are the project and experiment name to hold the DETER experiment. This invocation will create an experiment called {{{experiment1}}} in the {{{DeterTest}}} project. As with any DETER experiment, you must be a member of the project with appropriate rights to create an experiment in it. {{{containerize.py}}} expecte there to be no experiment with that name, and it will fail if one exists. To remove an experiment you can terminate it through the web interface or use the {{{endexp}}} command. Terminating an experiment is more final than swapping one out, so be sure that you want to replace the old experiment. You can also resolve the conflict by renaming your new containerized experiment. The last parameter is the file containing the topology. That can be an ns2 file, like [attachment:example1.tcl our example], or a [http://fedd.deterlab.net/wiki/TopDl topdl] description. An ns2 description must end in {{{.tcl}}} or {{{.ns}}}. With these default parameters {{{containerize.py}}} will put each node into an [http://openvz.org Openvz container] with about 10 containers per physical node. Running the command above on users -- '''make sure you run it with a project you are a member of''' -- yields: {{{ users:~$ /share/containers/containerize.py DeterTest example1 ~/example1.tcl Containerized experiment DeterTest/example1 successfully created! Access it via http://www.isi.deterlab.net//showexp.php3?pid=DeterTest&eid=example1 }}} Now we can see what a containerized experiment looks like. === The Contents of a Containerized Experiment === If you follow the link to that {{{containerize.py}}} prints, you will see a standard DETER experiment page that looks like this: [[Image(experiment-page.png)]] This may surprise you. In particular, you may be surprised to see that DETER thinks the experiment has only one node: [[Image(hilighted.png)]] The containers system has rewritten the description file and stored additional information in the experiment's per-experiment directory that will be used to create the 11 node experiment inside the single-node DETER experiment. If you look at the ns file DETER has stored (the NS file tab on the experiment page), you will see this file: {{{ set ns [new Simulator] source tb_compat.tcl tb-make-soft-vtype container0 {pc2133 bpc2133 MicroCloud} set pnode(0000) [$ns node] tb-set-node-os ${pnode(0000)} CentOS6-64-openvz tb-set-hardware ${pnode(0000)} container0 tb-set-node-startcmd ${pnode(0000)} "sudo /share/containers/setup/hv/bootstrap /proj/DeterTest/exp/example1/containers/site.conf >& /tmp/container.log" tb-set-node-failure-action ${pnode(0000)} "nonfatal" $ns rtproto Static $ns run }}} That looks nothing like the file we gave to {{{containerize.py}}}, but it does show us a little about what the containers system has done. The single physical node ({{{pnode(0000)}}}) will run the {{{CentOS6-64-openvz}}} image and run on a few kinds of node. On startup {{{pnode(0000)}}} will execute a command from the same {{{/share/containers}}} directory that {{{containerize.py}}} ran from using data in the per-experiment directory {{{/proj/DeterTest/exp/example1/containers/site.conf}}}. There is a separate {{{/proj/DeterTest/exp/example1/containers/}}} directory for each experiment. The path element fater {{{/proj}}} is replaced with the project under which the experiment was created, {{{DeterTest}}} in this example, and the element after {{{exp}}} is the experiment name, {{{example1}}} in this case. These directories are created for all DETER experiments. The {{{containers}}} sub-directory holds information specific to a containerized experiment. There are a few useful bits of data in that per-experiment containers directory that we can look at. To avoid the long pathname we will talk about files in {{{containers/}}}, the subdirectory. First, a copy of the topology that we gave to {{{containerize.py}}} is available in {{{/proj/DeterTest/exp/example1/containers/experiment.tcl}}}. If the experiment is created from a topdl file, the filename will be {{{containers/experiment.tcl}}}. A simple vizualization of the experiment is in {{{containers/visualization.png}}}. This is annotated with node and network names as well as interface IP addresses. The topology depiction [attachment:visualization-small.png above] is an example. A [attachment:visualization.png larger version] is also attached. The {{{containers/hosts}}} file is a copy of the IP to hostname mapping found on each virtual machine in the topology. It can be useful in converting IP addresses back to names. It is installed in {{{/etc/hosts}}} or the equivalent on each machine. The two files {{{/var/containers/pid}}} and {{{/var/containers/eid}}} contain the project name and experiment name. Scripts can make use of these. At this point, as with any DETER experiment, the topology does not have any resources attached. To get the resources, swap the experiment in from the web interface or using the {{{swapexp}}} command. === Using the Experiment === Swapin is just the start for a containerized experiment. Once the DETER web interface reports that the experiment has finished its swap-in, the programs that convert the physical topology into the virtual topology have just started to run. At the moment, the containers system does not have a good mechanism for notifying the world that the virtual topology has been successfully created. We are working on resolving this shortcoming, and in the long run we expect [http://montage.deterlab.net MAGI agents] to provide this functionality. Until then, you can ping or try to ssh to individual nodes in the experiment, or use the [UsersGuide#StartCommands workaround we sugeest below]. Once the containerized elements have all started, the nodes are available as if they were physical nodes. For example, we can access node {{{n-0}}} of the experiment we swapped in by: {{{ $ ssh n-0.example1.detertest }}} Be sure that you replace {{{example1}}} with the experiment name you passed to {{{containerize.py}}} and {{{DeterTest}}} with the project you created the experiment under. This is a DNS name, so it is case-insensitive. When the ssh succeeds you will have access to an Ubuntu 10.04 32-bit node with the same directories mounted as in a physical deter experiment. Your home directory will be mounted, so your ssh keys will work for accessing the machine. To confirm that the containerized experiment is working as we expect, we can ping other nodes, using the [https://trac.deterlab.net/wiki/Tutorial/UsingNodes#Hostnamesforyournodes same node naming conventions] as physical DETER experiments. Containerized nodes access the control net as well, so access them using the [https://trac.deterlab.net/wiki/Tutorial/UsingNodes#Hostnamesforyournodes same node naming conventions]. Here is a ping from {{{n-0}}} to {{{center}}} and {{{n-1}}}. {{{ n-0:~$ ping -c 3 center PING center-tblink-l21 (10.0.0.2) 56(84) bytes of data. 64 bytes from center-tblink-l21 (10.0.0.2): icmp_seq=1 ttl=64 time=20.4 ms 64 bytes from center-tblink-l21 (10.0.0.2): icmp_seq=2 ttl=64 time=20.0 ms 64 bytes from center-tblink-l21 (10.0.0.2): icmp_seq=3 ttl=64 time=20.0 ms --- center-tblink-l21 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 20.052/20.184/20.445/0.184 ms n-0:~$ ping -c 3 n-1 PING n-1-tblink-l5 (10.0.6.1) 56(84) bytes of data. 64 bytes from n-1-tblink-l5 (10.0.6.1): icmp_seq=1 ttl=64 time=40.7 ms 64 bytes from n-1-tblink-l5 (10.0.6.1): icmp_seq=2 ttl=64 time=40.0 ms 64 bytes from n-1-tblink-l5 (10.0.6.1): icmp_seq=3 ttl=64 time=40.0 ms --- n-1-tblink-l5 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 40.094/40.318/40.764/0.355 ms }}} The nodes have the expected round trip times. At this point you can load and run software and generally experiment normally. === Start Commands === DETER provides a facility to run a command when the experiment starts, called [https://trac.deterlab.net/wiki/Tutorial/CreatingExperiments#Startingyourapplicationautomatically start commands]. A containerized experiment offers a similar facility with a few differences: * The start commands are not coordinated across nodes. In DETER the start commands all execute when the last node has reported to the testbed that it has completed booting. In a containerized experiment, the startcommands run when the containerized node has come up. * Start commands have to be shorter than in DETER because the container system is also using the facility. * The event system cannot be used to prplay the start command. While start commands that make use of shell syntax for multiple commands and file redirection will generally work, syntax errors will cause them to fail silently. Because of this, and because containerized experiments cannot have as long a start command string, we recommend that if you are doing anything more complex than calling a single program, you script this and run the script from the per-expriment directory or your home directory. Start commands give offer a simple workaround for detecting that all nodes in an experiment have started. A script like this: {{{ #!/bin/sh STARTDIR="/proj/"`cat /var/containers/pid`"/exp/"`cat /var/containers/eid`"/startup" mkdir $STARTDIR date > $STARTDIR/`hostname` }}} Making that script the start command of all nodes will put the time that each local container came up in the the {{{startup}}} directory under the per-experiment directories. For example, {{{n-0.example1.DeterTest}}} will create {{{/proj/DeterTest/exp/example1/startup/n-0}}}. An experimenter can monitor that directory on {{{users}}} and know which nodes are up. === Releasing Resources === As with a physical DETER experiment, you release resources by swapping the experiment out using the web interface or the {{{swapexp}}} command. If you are using the [UsersGuide#StartCommands startcommand workaround] to detect startup, clear the startup directory when you swap the experiment out. == Advanced Usage == The previous section showed how to create an experiment using only openvz containers packed 10 (or so) to a machine. This section shows how to change those parameters. === Using Other Container Types === To change the container type that {{{containerize.py}}} assigns to nodes, use the {{{--default-container}}} option. Valid choices follow the [NewIntro#KindsofContainers kinds of containers] DETER suports. Specifically: || __Parameter__ || __Container__ || || {{{embedded_pnode}}} || Physical Node || || {{{qemu}}} || Qemu VM || || {{{openvz}}} || Openvz Container || || {{{process}}} || ViewOS process || We can try this on our [attachment:example1.tcl example topology]: {{{ users:~$ /share/containers/containerize.py --default-container qemu DeterTest example2 ~/example1.tcl Requested a QEMU node with more than 7 experimental interfaces. Qemu nodes can only support 7 experimental interfaces. }}} The good news is that the container system is using qemu containers to build our experiment. Unfortunately qemu containers only support 7 experimental interfaces, an internal limit on the number of interfaces the virtual hardware supports. A [attachment:example2.tcl version of the topology with fewer satellites] will containerize without error. {{{ $ /share/containers/containerize.py --default-container qemu DeterTest example2 ~/example2.tcl Containerized experiment DeterTest/example2 successfully created! Access it via http://www.isi.deterlab.net//showexp.php3?pid=DeterTest&eid=example2 }}} The qemu experiment looks much like the openvz experiment above, at this small scale. Qemu nodes more completely emulate hardware and the kernels are independent, unlike openvz containers. For example, a program can load kernel modules in a qemu VM, which it cannot do in an openvz container. The qemu containers load the Ubuntu 12.04 (32 bit) distribution by default. We can also swap in the experiment using ViewOS processes, but processes cannot be manipulated from outside. They are too lightweight to allow an ssh login, though they will run a start command. === Mixing Containers === Mixing containers requires the experimenter to assign container types in their topology assignment. This is done by attaching an attribute to nodes. The attribute is named {{{containers:node_type}}}. If the experiment definition is in [http://fedd.isi.deterlab.net/wiki/TopDl topdl] the attribute can be attached using the [http://fedd.deterlab.net/wiki/TopdlLibrary#SharedFunctions standard topdl routines]. Attaching the attribute in ns2 is done using the DETER {{{tb-add-node-attribute}}} command. {{{ tb-add-node-attribute $node containers:node_type openvz }}} That command in an ns2 topology description will set {{{node}}} to be placed in an openvz container. Using this feature, we can modify our [attachment:example1.tcl first topology] to consist of qemu nodes and a single process container in the center. Process nodes can have unlimited interfaces, but we cannot log into them. The new topology file looks like this: {{{ source tb_compat.tcl set ns [new Simulator] # Create the center node (named by its variable name) set center [$ns node] # The center node is a process tb-add-node-attribute $center containers:node_type process # Connect 10 satellites for { set i 0} { $i < 10 } { incr i} { # Create node n-1 (tcl n($i) becomes n-$i in the experiment) set n($i) [$ns node] # Satellites are qemu nodes tb-add-node-attribute $n($i) containers:node_type qemu # Connect center to $n($i) ns duplex-link $center $n($i) 100Mb 10ms DropTail } # Creation boilerplate $ns rtptoto Static $ns run }}}