The name Docker pops up in the data center and cloud world, but more and more in networking as well. OpenSwitch can run in Docker (see: this guide or this video) and even Aruba ClearPass Extensions are little Docker containers running on your ClearPass appliance. On first impressions, it must be fantastic, those containers scale up in the cloud very well.
For me as a networking person, it might be a good time to understand this new technology. Initially, I had issues that you might recognise: where to start, and how to wade through the sea of marketing that keeps the good people from understanding what it really is about. Personally, I learn and understand by doing things. I need to test and see stuff in my lab to really gain understanding, to get to the core and validate that my understanding is indeed correct.
As a nice surprise, at the recent HPE Technical Solution Summit event in Gothenburg, Sweden, I came across an Open Lab session about Docker and decided to attend. After a short presentation that already brought some clarity, there was a guided lab available to run you through the first steps in Dockerland. The lab starts simple, but goes into some of the finer details and leaves you with a working ownCloud server running in Docker.
What I got from the intro presentation is that Docker fits nicely between a dedicated server running multiple applications, and a full hardware virtualization à la ESXi or Hyper-V. Docker uses the same Operating System and shares that with multiple containers:
Where virtual machines take the time to boot and startup, Docker containers start up almost as quick a starting a new process. This property makes them great for 'cloudy' apps where you might need to spin up more instances in a short space of time.
In the spirit of Open Source, this lab has been published on GitHub and is freely available for everyone: https://github.com/bcornec/Labs/tree/master/Docker
If you have a Linux system available, the lab describes both for Ubuntu and RedHat, you can work in about 2 hours through the lab steps yourself. Some Linux experience may help. The lab includes:
- Installation of Docker.
- Getting images from Docker Hub (images can be a very basic Ubuntu or Fedora, with just the libraries and tools to install additional packages; or they can be complete installed applications).
- Creating containers from the images (containers are the running applications that are started from an image)
- Building your own images, a step-by-step guide to making an ownCloud Docker image.
- Managing containers and images with the docker command-line.
- Connecting the container to the network and local file system.
For me, the approach worked great as I do have some Linux and Virtual Machines experience. During the lab steps you do need to apply some thought to what you are doing, just blindly using copy and paste will not work. Also, new concepts are introduced in steps during the lab. For me, each new step was explained just at the moment I was wondering: how should this work, or would that be possible as well?
This 2-hour crash-course allowed me to understand at least the basics of Docker, images, containers and how to create or work with them. The way you create a Docker image made me realise that Docker is just a basic, infrastructure technology. If you need to deliver the marketing promises of automatic deployment, scaling, version controls, you will need additional tooling that will do this automation.
Docker automation is where tools like Docker Compose (create and manage applications that use multiple containers, like frontend, middleware, and database), Docker Machine (automate provisioning of machines to run Docker containers on), Docker Swarm (cluster multiple machines together to run docker applications) and Google Kubernetes (run it in large distributed data centers and automate the deployment and resource control) play a role. If I run into a similar opportunity to learn about those tools, I will share in another blog. Or if you can help, please write your blog on these automation topics below.
The automation is where it becomes pretty close to networking because as you start to automate you soon learn: Applications Move, Networks must Follow.
Acknowledgements to Bruno Cornec and René Ribaud from HPE to create this awesome lab content.
