New APIs for the Docker Class

[kevin-w-du]

When I was developing the Morris Worm lab, I used the emulator to create the emulated Internet, and then release the worm inside the emulator. Based on the experience, the following APIs should be quite useful:

• Docker::createImageFromFolder(imagename, path, baseonly=true/false, softwarelist): Using this API, I can put all the necessary files of an image inside a folder, and then include it in the emulator. What the compiler will do is to simply copy this folder to the output folder, as well as adding it to the docker-compose.yml file. We can specify whether this image is just for base only (let it exit) or not (don't exit). The softwarelist specifies all the software that has already been installed inside the image. This list can help optimization. This image is immutable (the API creates a DockerImage object, but we cannot make any change to this image).

• Docker::createImage(imagename, baseonly): Using this API, we can create an empty image (DockerImage object), and then using the APIs of DockerImage to add content to the image. This allows us to create a docker image programmatically.

• DockerImage APIs: We can have setBase, setShell, appendRunCommand, setCMDentry, installSoftware. These names are just tentative; we should come up with better names.

• Docker::setBaseImageForNodes(nodename, imagename): set the base images for nodes using the name. The name can be a regular expression to match multiple nodes. There should be a default base image for every node (the one used the current implementation should be set as the default).

• Docker:setBaseImageForClass(classname, imagename): set the base images for all the nodes belonging to certain class. We need to add an API Node::setClass(classname) to associate a node with a classname. Introducing the class makes it easier for us to manage nodes. A node can be associated with multiple classes (we may want to have a Node::setPrimaryClass(classname) to set the primary class, because some APIs can only be conducted on one class). Currently, we are using the name convention for that purpose. We can create a few built-in classes, including host, router, internet-exchange, etc. Users can define their own classes.

• Default base image: A few customized base images should be created inside the Docker constructor, using the APIs defined for Docker and DockerImage. These images are the default base for the built-in classes. They can be the same. In the current implementation, the default base image for all nodes is an image called dummies, which has only one line (FROM). We should move the construction of this base into the constructor, and make it more generic, such as adding the software list to this container.

• Note on optimization: each node has a list of software that needs to be installed. When generating the Dockerfile, we need to remove the items that are already included in the base image (each base image has a software list, could be empty). If the node's list becomes empty, i.e., everything is covered by the base, there is no need to include RUN apt-get.

It should be noted that Docker should be just another layer, so the reference across layers should be strictly using names, not the object reference. This layer is only used by the compiler.

[wonkr]

#78
613e7a3

• Docker::setBaseImageForNodes(nodename, imagename) : implemented with the method name Docker::setImageOverride(node, imagename)