CI With Datree

Michael Levan - Sep 23 '21 - - Dev Community

With the ever-growing need for orchestration in a containerized world, many engineers and organizations are utilizing Kubernetes more and more. As we know, new infrastructure brings new implementations across technology departments.

When the need arises to implement a new product, like Kubernetes, any amount of error-prone configurations can occur. These errors can be anything from trying to use a container image that doesn't exist, to misconfigured memory limits.
There's really no cap to how many misconfigurations can be accidentally implemented into an environment.

Whether it be in dev environments, staging, or even production, engineers need a way to know about these errors before they reach any environment.

In this blog post, you're going to learn all about Datree, the leader in Kubernetes static code analysis; Helm chart analysis; and how to ensure that all manifest configurations are working properly in a Continuous Integration (CI) build process.

Why Test Kubernetes Manifests and Helm Charts?

Regardless of whether you're using Kubernetes manifest files or Helm charts (which are just a curated list of Kubernetes manifests) for deployments, services, ingress, etc., you need to ensure that what's being built and deployed is valid.

With any application or piece of software, a developer wouldn't deploy code without properly understanding what's happening in the code. This includes:

  • Meeting proper policies and standardization requirements
  • Testing for any bugs or misconfigurations
  • Implementing security policies to ensure things like no hard-coded passwords

And many other components to testing for any sort of misconfiguration.

The stability of the product should be your primary concern. As soon as a piece of code is in the CI process, it's going to be built and deployed, so you should run tests and verifications to know exactly what's happening before the code hits the deployment process.This process should be no different for Kubernetes manifests or any other type of configuration language.

As automation spreads and enables engineers to worry about more impactful work than putting out Kubernetes fires, the need for pre-testing Kubernetes manifests is crucial.

The Push For Kubernetes Static Code Analysis

In this previous section, Why Test Kubernetes Manifests and Helm Charts, you learned why it's crucial to test any type of code, including a Kubernetes manifest. However, you didn't learn about the key type of test for something like a Kubernetes manifest.

The best type of test for a Kubernetes manifest is linting and static code analysis.

A linter test searches for stylistic bugs, formatting issues, memory leaks, etc. There are several different types of linters for security purposes, to check for code vulnerabilities.

Static code analysis can do everything a linter can do, plus checking for dependencies, requirements, and other key factors, all without an engineer having to physically run the code.

Static Code Analysis is crucial for a Kubernetes manifest because you don't want, for example, to have to run a Kubernetes deployment and then find the issue. Instead, you want to scan the code prior to running it so you can fix the problems you discover before any misconfigurations reach an environment.

Why Datree?

With the push for testing Kubernetes manifests, static code analysis for manifests, and ensuring you don't have misconfigurations in your code prior to deploying it, how can you confirm all of this information?

With Datree.

Datree is a CLI tool with an impressive UI that supports engineers working with Kubernetes by preventing errors in Kubernetes configurations that could cause clusters to fail in any environment, including production.

When you're setting up static code analysis for a Kubernetes manifest, you want seamless integration. You never want to have to go above and beyond to get something like this running; instead, you want a platform that's ready to ingest Kubernetes manifests out of the box.

To make the platform even easier to use, Datree is available for MacOS, Linux, and Windows. While it's a CLI tool, the real power comes from utilizing the UI and dashboards, and sharing Datree’s results with your teammates.

Datree is a 100% open-source platform with a plethora of amazing policies and rules right out of the box.

Quick Getting Started With Datree

If you’re new to Datree, you’ll want to know how to use it before deploying it in the CI environment. You can learn how to use it right from your terminal.

1. Install Datree

First things first, install Datree. You can do so from the terminal via Windows, Linux, or macOS.

On macOS, run the following command:
curl <https://get.datree.io> | /bin/bash

If you're installing on another operating system, check out the different installation options here.

2. Import a Kubernetes manifest for testing

To make things easy, use this straightforward Nginx Kubernetes manifest.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
Enter fullscreen mode Exit fullscreen mode

Save the Kubernetes manifest to a location on your local computer, so you can test it via the terminal.

3. Run the test

Next, open a terminal so you can run the Datree command to test the Kubernetes manifest. You'll have to point the Datree command to where you saved the Kubernetes manifest. Change directory (cd) into the directory that has the Nginx manifest and run the following command:

datree test name_of_manifest.yml

After you run the command, you'll receive valuable information about the manifest which you can use to find and fix errors. For even more details, open the Summary section and click See all rules in policy with a URL.

Signing up to Datree

Copy the URL, open up a web browser, and sign up via GitHub.

There are several plans available, but you can get started with the free version which supports 1,000 policy checks per month. Teams might need the Premium or Enterprise plans.

Once you sign in, you can see the history of the test you performed on the terminal.

CI For Datree With GitHub Actions

Now you can take the Kubernetes Nginx manifest you created in the previous section, and run it through a CI pipeline via GitHub Actions.

If you don't already have a GitHub account, sign up now and use GitHub Actions for free.

GitHub Action Workflow

  1. Take the Kubernetes Nginx manifest and commit it to a repository in GitHub. This will ensure that GitHub Actions can utilize it with Datree.

  2. Under the repository, click Actions..

  1. Under Actions, you'll see several workflow options. Instead of choosing a pre-made workflow, select the option to create one yourself.

  1. You'll be brought to a sample workflow. Delete everything after line 26 so you can add Datree.

  1. Use the run command in GitHub Actions to run Datree. The two commands will be:
  • curl [https://get.datree.io](https://get.datree.io/) | /bin/bash
  • datree test ~/.datree/k8s-demo.yaml

Once the pipeline is configured, you'll need to set up your account token, which you can do by going to Settings --> Secrets in your GitHub repository. Then, you can all upon the secret as an environment variable.

For more information on account tokens in Datree, please visit: https://hub.datree.io/account-token

Congratulations! You can now run a CI pipeline to test your Kubernetes manifest!

Learn More

If you'd like to learn more about Datree, feel free to check out the Git repo and documentation below!

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .