Containing Klocwork Builds with Docker
There are a number of options when looking at managing Klocwork build machines for multiple environments and tool chains. The original solution involved providing each environment with dedicated hardware. Then the ability became available to host multiple operating systems concurrently on the same hardware using virtual machines. The next step in this evolution further reduces the resource requirements by running multiple containers on the host kernel.
The Docker system allows individual “containers” to be spun up upon request, used as required and then destroyed. Each container makes use of the host machine kernel that allows the containers to be light weight while still providing the performance required.
A configuration file, or Dockerfile, is provided to the tool that describes what should be available in the container, including the OS distribution, additional libraries and any custom tools (such as Klocwork) or startup scripts. In the case of Klocwork build containers, we can ensure that the target compiler, SCM and Klocwork tools are configured and ready to use each time a new instance is activated. Once an instance of this “image” has been downloaded and built on the host machine, further instances make use of this fixed configuration allowing fast start up of containers.
A properly configured container will allow the source to be checked out, a build executed and traced by Klocwork to generate a build specification, the Klocwork analysis performed and then loaded to the Klocwork server. The container can then be shut down and all resources released.
In many cases the use of Docker will be integrated with a continuous integration tool, such as the open source Jenkins tool. Properly configured these can allow containers with the correct configuration to be automatically started, builds performed and then shutdown with a single build request from the CI tool.
When Should We Dock Klocwork
The choice of using Docker, or any container system, primarily depends on the level of unique build environments that are required. Building a single development branch with the same compiler would generally benefit more from a dedicated machine. There are however other factors that may contribute to the decision, these could be driven by compliance or internal requirements:
- Isolation – Reduced possibility of external factors (libs, etc) effecting analysis
- Sanitisation – Each build is performed in a clean environment
- Consistency – Every build is performed with the exact same configuration
- Utilisation – Resources are only allocated when required