Docker support in GNS3
The docker support is a new feature of GNS3 1.5. This features has been start by Goran Cetusic during the Google Summer Of Code and finished by the GNS3 core team.
Bernhard Ehlers and Aj Nouri contribute a lot of their time to the test of this feature.
Containers use the host kernel this mean they consume, less less RAM and CPU. Docker containers are available from a registry, you can fork them in order to add your own tools.
The target is not to simulate the deployment of container infrastructure in production but use containers as light virtual machine replacing heavy qemu instance or VPCS when you want to use tools like telnet, nmap… It’s also not designed to control a docker cluster for production or development. If you want to simulate real life containers infrastructure you need to deploy an OS on qemu and start container on it.
Go to the preferences / Docker containers and click on new.
Now you need to select the container we will use. You can find a lot of containers on the docker hub https://hub.docker.com. Please note that most containers start a daemon and expose ports. This will not work on GNS3 because we need to configure the ip inside the container (in standard usage docker take care of the networking and you can not access containers directly from the network)
We will use for this example an image of Alpine Linux 3.2 a light Linux distribution.
You can see all the alpine linux version available for Docker here:
Next the start command. It’s like the init process on a standard Linux. Often in GNS3 we just want a shell:
Next you can configure environnements variable that will be accessible inside the container. A lot of Docker container use that for configuration.
At the end of the wizard if the base container is not available docker will download it.
Now you can start the container and open a console:
Please note that network interfaces will be available only when a cable is connected.
By default nothing is persisted on disk. The container needs to be designed for that.
If in the Dockerfile the container mount volumes. GNS3 will create in the project folders a folder for each Docker volume and will write file inside.
This mean if you use a container outside GNS3 the data will not be available. But also this mean all the data of the GNS3 project is in the same location.
When you use a normal Docker installation the networking part is manage for you. Because GNS3 use docker to simulate a computer you need to configure it by hand.
A file /etc/network/interfaces is read at container start and you can edit it from the container or via the preferences of the container.
This file contain a sample config that you can tune to adapt the config to your network. The directory /etc/network is persist on disk.
You can launch graphical program if you choose VNC has console type. Under the hood GNS3 will start a fake Xserver (using Xvfb) and inject it in the container. After that this X server is exposed to the network via X11VNC. You don’t need to modify your container to get VNC support. A limitation of that is any container can access to the X socket of the other container.
You can replace the telnet console by a web page if your container as one. This support will not work for some application because we just forward the data not interpreting the HTTP protocol.
By default we start a /bin/sh as an auxiliary console. This allow you to get a shell for a container where the start command is not a shell or if the console type is VNC. Under the hood it’s a docker exec starting a custom busybox shell. For technical reason it’s slower than the standard telnet console.