Generating CDA Entities from Helm Charts

As an Application Developer, you use the helm2rm tool to easily include CDA in your CI/CD toolchain. You can adopt new technologies faster while keeping full control and visibility, since you work with end-to-end pipelines which can include even mainframe for the backend that applications like Docker need.

helm2rm parses a Helm Chart, retrieves the information on what is going to be deployed and autogenerates the necessary configuration in CDA for a full Application, so that you only need to provide credentials to the target cluster and can start with the deployment immediately.

This page includes the following:

Scenario

Image showing roles, repositories and components

  1. An Application Developer commits and pushes code into a remote repository with a version control system (for example, GIT). The commit triggers a new build job in Jenkins, which in turn:

    • Builds a Docker image and sends it to a Docker registry.
    • Packs a Helm chart and sends it to a Helm repository.
    • Executes the helm2rm cli tool to create or update an Application in CDA.

      Image showing components, packages and workflows

      Note: a Profile must be created in CDA.

    The Application Developer can continue working with the toolchain he/she is familiar with.

  2. Then, the Operator can trigger a deployment via:

    • CDA REST API (to trigger an auto-deployment)
    • CDA user interface, by triggering the Application deployment to a Kubernetes cluster target.

    The deployment execution fetches the Helm Charts to get an image.

  3. Finally, the new version of the Application is ready to be used in the target Kubernetes cluster.

Component Synchronization

helm2rm synchronizes Helm_Charts with CDA and creates the following entities:

  • Helm Chart > CDA Component (Type: Helm Chart)

    Note: Chart variables are represented by properties of the virtual Component in CDA

  • Docker Container > CDA nested Component (Type: Helm Chart Container). For more information, see:Working with Nested Components

    The nested Components cannot deployed individually. They are used to provide visibility on which containers and which versions would be deployed if you execute the Helm Chart. They cannot be mapped to Targets either.

  • Chart version > CDA Package
  • Container version > CDA Artifact

    Note: the Artifact name corresponds to the image tag name.

  • Artifact Source of type Void
  • Workflows

Prerequisites

The following components must be installed:

Folder Structure

The helm2rm tool contains the following folders:

Using the helm2rm Tool

To use the helm2rm tool, choose one of the following options:

  • Download and install Helm locally.
  • Run the helm executable stored in the /helm folder.

Note: see helmExecutablePath 

See also: