Docker Containers Tutorial: How to Create and Run Klocwork as a Container

In this Docker Containers tutorial, you will learn how to create and run Klocwork as a container.

The basic definition of Docker is an open-source and popular operating-system-level virtualization (commonly known as “containerization”) technology that is lightweight, portable, and that primarily runs on Linux and Windows. Docker makes it easier to create, deploy, and run applications by using containers.

Fundamentally, a container is nothing but a running process with some added encapsulation features applied to it.  So, with containers, developers (and DevOps administrators) can package an application with everything needed to run the application — including code, run-time, libraries, configured environment variables, and configuration files — and ship it all out as one package. 

It is also worth mentioning that Docker can start up instantly and has built-in mechanisms for versioning and component reusable. What’s more, these docker containers can be shared via the public Docker Hub or private repository — making them accessible and easy to use.

▶️ Sign Up for Your Klocwork Free Trial

There are advantages and disadvantages to Docker.  While this not a comprehensive list, these are some of the most notable benefits:

• Rapid deployment: Docker can decrease deployment process time to seconds.  That’s because it can create a container for each process, which can then be spun-up and torn down quickly on demand and without the need to boot a Platform Operating System (OS).  In addition, Docker image spin-up is almost instantaneous.
• Portability: Docker enables application portability. This means that once you have tested your containerized application, you can deploy it to any other system where Docker is running and be sure that it will perform exactly as it did when you tested it. So, the Docker image can be shared with other teams. This saves time as everything they would need is available, configured, and ready to be used.
• Performance: Although virtual machines are an alternative to the containers, virtual machines (VM) have an OS whereas Docker containers do not, which means that containers have a smaller footprint than the VM, are faster to create, and have faster to spin up and tear-down time.
• Continuous Integration Efficiency: Docker enables you to build a container image and use it across every step of the deployment process from development and testing to deployment. In addition, you to separate non-dependent steps and run them in parallel, which shortens the length of time it takes from the build phase to the production deployment phase. This reduces the amount of time to set up the environments and debug environment-specific issues — making them more reliable and easier to maintain.

However, there are some limitations to the Docker, and even though they have a low to zero impact on the setup of the static code analyzer for Docker, they are nevertheless worth mentioning.

• Docker isn’t a substitute for Virtual Machine: Many apps that run in VM can be moved into a container, but that doesn’t mean all of them can or should be. For instance: Industries with heavy regulatory requirements might not be able to swap containers for VMs as VMs provide more isolation than containers.
• The Data in the container: There are times when a container does go down, and in that instance, it needs a backup and recovery strategy. Although there are several solutions, none are automated or not scalable yet. Another limitation is that unless you save it somewhere first before the container goes down, all of the data inside disappears forever when it shuts down.
• Cross-platform compatibility: This is a major issue if an application is designed to run in a Docker container on a Windows OS platform, which means that it can’t run on Linux or any other platform. However, Virtual Machines are not subject to this limitation, so this limitation makes Docker less attractive to some highly heterogeneous environments that are composed of both Windows and Linux servers.
• Run applications with graphical interfaces:  In general, Docker is designed for hosting applications that run on the command line. Though we have a few ways (like using X11 forwarding or mobaxterm) by which we can make it possible to run a graphical interface inside a Docker container, these processes are clunky.  This is why we can say that Docker is not a good solution for applications that require rich interfaces. 

To help you set up the static code analyzer as Docker and work around these limitations, I will breakdown the setup into three easy parts.

A great starting point to get started would be from this site https://docs.docker.com/get-started/overview, which has plenty of details about setting up the Docker Engine and then how you validate the environment of its proper setting.

📕 Related Resource: Learn more about Rocky Linux.

PART I: Prepare Docker Engine

1. Remove any older version of the Docker (sometimes called docker, docker.io, or docker-engine) before installing the Docker CE (Community Edition).
2. Download and install the Docker Engine from this site: https://docs.docker.com/engine/install/ubuntu
3. Verify that the Docker Engine has installed properly by running the sample Docker image called “hello-world”.  Use this command example:
   • $ sudo docker run hello-world
   • The command will download a simple “hello-world” test Docker image and runs it in a container.  So, when the container runs, it prints an informational message and exits.

In the next part of our Docker container tutorial, our goal is to setup Klocwork. There are few ways to configure the Docker image to support different Klocwork components. You can build the Docker image for individual or combined components in each image and these are the supported components such as the Klocwork Portal, build machines running integration analysis, Continuous (diff) analysis tool, or Desktop command line tools. 

I will only demonstrate how to build a specific Docker image that will be a static code analysis Build-tools machine running Integration Static Code Analysis.  In addition, I will discuss how to handle data persistency when running Klocwork analysis that you can store the Klocwork build specification and analysis data outside of Docker container (such as buildspec, tracefiles, tables, .kwlp/.kwps, and projects_root). 

So, if you’re using the ‘--incremental’ parameter from the kwbuildproject command, then the ‘--tables-directory’ must be preserved from build to build.  Therefore, on my setup, I will be outputting these files to an external project folder on the host machine.

PART II:  Create, Build, and Run

1. Download Klocwork installation file kit and extract its contents to a known folder location on your host machine. Make sure you have a Klocwork server (Klocwork Web Portal) installed the on the same machine or on another server that you can easily access. A couple of files that you would need from extracting the install kit would be: 
   • kwbuiltools.<version>.zip
   • kwciagent.<version>.zip
      
2. Create a file — for example, “kwDockerfile” — with no file extension (default name is Dockerfile). This file will be used by the Docker engine to create your Docker image.  Basically, it has a list of commands to send to the Docker engine to execute them from top-down order. 
   • These are the only three files you would need to generate this Docker image.  I placed them under my local folder on a host machine (folder name is “vDockerBuilds”) and also it is where I placed the file created  (“kwDockerfile”) into this folder.

• Here is the content of “kwDockerfile” file, and with some explanation as followed:

• Line 1 is started out with using the Ubuntu 20.04 as a base image.
• Line 8  is optional but recommended adding these useful tools because base image is barebone.
• Line 12 thru 14 will install the libraries dependencies that Klocwork application needs.
• Line 19 will install the gnu compiler dependencies, and this step would be different for your compiler usage. However, in my case, this image will be using gcc/g++ 8 compiler.
• Line 24 tell the Docker engine to create a working directory calls ‘klocwork’, and all sub-sequential commands will be using that directory.
• Line 27 thru 31 basically, unzip the build tools into the Klocwork working directory and then clean up by removing the zip files.

3. Run this command to build the Docker image:

• $> docker build -f  kwDockerfile -t kwscatools:20v3 .  
  • -f is the kwDockerfile name, by defaults the name is dockerfile
  • -t is the format ‘name:tag’ which name is ‘kwscatools’, and tag is ‘20v3’
  • Don’t forget the “dot” at the end, which indicate it is a local directory
• Once the build image process has completed, you can see the last two-line messages which indicate writing to a file and tag the image.  To verify the build was success, then run the follow command to displays the list of all available Docker images.  In the image below the image Tag ID is 11ec8d62c0d6
  • $>docker images

PART III: Run the SCA Docker on Local Project

You will need the ltoken file that is associated with the authenticated Klocwork tools user account. Then setup the script to run the SCA docker to allow the project data file to persistence external to the docker. This ensures that all the data won’t disappear when the docker image stops.

1. Get the ltoken file and follow the commands sequence to help generate the ltoken to a known location.
   • Select a machine that has access to Klocwork Server and license, then run these commands:
     • $> export KLOCWORK_LTOKEN=~/<To_A_Known_Location>/ltoken
     • $> kwauth --url http://<klocwork_server>:8080

For clarity, here is the actual command that I have used to generate the ltoken file to put it to a known location:

Here is the text view of the ltoken file content. Each value separated by a semi-colon:

• IP address (or FQDN name) of Klocwork server, Server Port number, Valid User Account, and a very long hash code

Place the ltoken file under your local project root folder. As you can see, each has its own ltoken file:

2. Output these data files (buildspec, kwtable, etc.) to the project folder on the host machine  by creating a shell script file that will run the three typical SCA operations (kwinject, kwbuildproject, and kwadmin) in the Docker image. The script file will also use the Docker command to mount the local project volume to the Docker project volume so that the analysis data files data will be persisted when Docker image run process has completed.  Here is the “runKWSCA.sh” file content (see above screenshot).
   • Example: The “MyCppCode” project script file:

• Line 4 is the project folder name.
• Line 6 thru 8 is reference to Klocwork Server on another machine.
• Line 11 thru 14 is the working directory mapped inside of the Docker image.
• Line 19, 20 is the “ltoken” file location mapped to project volume (important).
• Line 26 is to make sure you are in the project root directory mapped volume.
• Line 31 thru 33 is project clean up.
• Line 37, 41, and 46 is the Klocwork tools operation steps.

3. Run the following Docker commands which will map the local project volume to the Docker project volume so that the analysis data files will be persisted. Pay close attention to the ENTRYPOINT argument, where the script file “runKWSCA.sh” is to be executed from the project root folder.  Here is the Docker command:
   • $> docker run --rm -it -v ~/ProjectsSandbox/MyCppCode:/klocwork/MyCppCode --entrypoint=/klocwork/MyCppCode/runKWSCA.sh kwscatools:20v3
     • run, is to execute
     • The -it runs Docker interactively (so you get a pseudo-TTY with STDIN).
     • The --rm causes Docker to automatically remove the container when it exits.
     • The -v for the volume mapping LocalHostVolume:DockerVolume
     • The --entrypoint is for where to start when logged in, either command-line start running the location/file_name.sh with instructions contents.

Result output screen captured:

4. Optionally, you can also run this Docker container for the CMakeNinja project, which has a similar command as previous project.  However, you would need to make sure to attach the correct project volume (CMakeNinja) in the command line as shown below:

• $> docker run --rm -it -v ~/ProjectsSandbox/CMakeNinja:/klocwork/ CMakeNinja --entrypoint=/klocwork/ CMakeNinja /runKWSCA.sh kwscatools:20v3

▶️ Klocwork Free 7-Day Trial