Docker in Action

Note: for more on Docker itself, see here.

Chris Stryker has recently put a lot of effort into getting LabVIEW to run inside of a Docker Container. This is really exciting news. I think this is really a huge step forward in improving Continuous Integration (CI) with LabVIEW. It offers several advantages over traditional CI methods using Virtual Machines (VMs).

1. Docker Containers can be spun up on demand. If you are using a VM for each project/LabVIEW version, then you have to keep each one running just in case some CI process needs it. This is resource intensive and most of the time they will just be sitting there idling. Starting with a fresh container for each CI task also means that every task starts in a fresh uncontaminated container. There is no chance for anything to be leftover from a previous job.
2. Docker Containers are lightweight. Because you are not duplicating the entire OS, the images take up way less disk space and much less memory and CPU when running than a VM. Also the way tagging and layering works in Docker can help save a lot of disk space as well.
3. Docker Containers can easily be run locally. You can easily and quickly pull a docker image and run a build or test in an isolated environment on your local machine. This makes it really easy to test your changes locally before you push them.

There are still a few things to be worked out with getting everything up and running (such as streamlining the LV licensing and getting VIPM to install – apparently JKI has fixed this but I haven’t tested it yet), but Chris has gotten us really close. There are going to be a lot of developments in this area in the next couple months. Now is a good time to learn about Docker and how it works.

Learning Docker

If you want to learn the basics about Docker, then Docker in Action is the book you need. It covers everything you need to know in just enough detail. It’s got plenty of examples to illustrate all the details. One criticism for this particular application is that it tends to focus on Linux. However with 1 or 2 exceptions I was able to do all the exercises on Windows. By the time the book is over you will be very comfortable using Docker. If you combine the knowledge in this book with Chris’ article, that should be enough to get you up and running.

The book contains 3 sections. Sections 1 and 2 are of the most interest for CI with LabVIEW. Section 3 is interesting but not very applicable.

1. Consuming Containers – This section talks about installing Docker and the basics of using containers. It talks about where to get them, how to run them, all the various parameters that can be used when running them, and the docker commands for monitoring and manipulating them. It also talks about storage volumes, networking, and resource controls.
2. Producing and Distributing Images – This section is all about images. Think of an image as a file system and associated settings and metadata. It is roughly the equivalent of a virtual machine’s virtual harddisk and vmx file (if you use VMWare). This section talks all about how to create images with your desired software on it, how to make those images secure, various ways to distribute them, and ways to automate the building and distribution.
3. Orchestration – Orchestration is basically building entire systems that consist of multiple docker images that all communicate and work together. This section covers things like automatic load-balancing and recovery of failed services, rolling out and rolling back changes and using Docker Swarm to spread Docker containers out over a cluster of computers. Very interesting stuff, not super useful for CI and LabVIEW, but maybe useful if you are building WebVIs and web services in LabVIEW.

If you are interested in the idea of using Docker containers for Continuous Integration, the next place to stop after reading this book is probably here: https://docs.gitlab.com/runner/executors/docker.html

If you would like to discuss how we can help you setup a Continuous Integration system for LabVIEW, set up an appointment. We would be happy to talk to you.