When KLA Met Containers

Published August 4, 2020
sebastian revuelta

WRITTEN BY SEBASTIAN REVUELTA
Sebas is a software engineer, obsessed with data and passioned about software quality and security. He runs a website dedicated to R, Running with R, and a blog on personal productivity, Tiempo de Calidad.

Containers have emerged as a fantastic technology to deploy applications. Containers save a lot of time for system engineers dealing with infrastructure issues: servers, networks, operating systems (OS), ports, configuration, etc.

If your application needs be run with Java 8, or be deployed in a Tomcat server 6.23 with a MySQL 5.x database, then you can define the technology you need with just 3 lines of code and deploy it! Not only can you manage infrastructure as code, but the time to deploy your applications is now faster with containers. This is good news for the accelerated DevOps World.

Docker, Kubernetes, and Apache Mesos, etc. help deploy software and solve OS, network, and dependency conflicts, since everything is treated as a one big and consistent container.

Kiuwan On-Premises as a Docker image

Kiuwan has also caught the container train — or maybe it’s more correct to say container ship, as container technology gets its name from the shipping industry. Now you can choose between your cloud account or your on-premises account with a container image.

Every Kiuwan On-Premises server requires technology that can be written in a simple Dockerfile.

Kiuwan needs Java 8, WildFly as the application server, Redis as the cluster and MySQL as the database. Each of these components could be deployed as an individual container which gives us more flexibility and makes changes easier.

Kiuwan Cloud with Kiuwan Local Analyzer as a Docker image

Kiuwan Local Analyzer (KLA) allows you to run local analyses and then upload the results to the cloud. KLA could be deployed as a container image.

The only requirement is to use 64-bit Java 8, but some considerations should be taken into account if you want to run analyses in ephemeral containers.

Challenges

For example, KLA checks for updates every time it starts, including the last KLA version and last Engine distribution. So if it is out of date, it updates all the local software automatically.

When we run analyses in ephemeral containers, the image of the Kiuwan Local Analyzer is always the same. If it is out of date or it has not been refreshed then Kiuwan will check for updates and do the download, taking some valuable time — and time is money in a DevOps environment.

We need pipelines being executed from 1 to 5 minutes, not more; it is what we demand of the steps in a pipeline chain. So, it would be great to save downloading time.

One possible solution is to have a container image always updated with the last KLA version and the last engine. But this can be difficult to maintain as there are new versions frequently.

Solutions

So, the suggested solution is to create a Docker image with the last version of the KLA (including the engine). Follow these steps:

  1. Download from your account the last KLA version
  2. Run the KLA locally in order to download the last engine
  3. Do a zip of this KLA version
  4. Create the container image with this ZIP file.
  5. Lock the engine updates (from Account Management settings in your Kiuwan account). It will save the time to download the engine for each analysis. 
  6. Build the image
  7. Run analysis using this image

Example of docker image using KLA.zip file:

Doing this can save a lot of time in your pipelines.

From time to time (e.g. twice per year), you could update your KLA installation with the last engine, after first unlocking the engine update.

Some useful Docker commands (in case you need them) 😉


Would you like to know more about implementing SAST and SCA in your organization? Get in touch with our Kiuwan team! We love to talk about security. 

Scan your code with Kiuwan banner