Helm and DeployHub for Microservice Releases

Helm

Integrate Helm Into Your DeployHub Release

Helm helps with the process of creating your container image. It is an agentless solution that can be called via a DeployHub ‘Custom Action.’ Helm provides a broad set of pre-defined Helm “Charts.” A Helm Chart is a reusable script that simplifies the creation of your container image. When DeployHub executes the release process, it will call the Helm Chart you have defined as your Custom Action.  What DeployHub offers is the versioning around what was released, including the version of the Helm Chart.  DeployHub tracks all of the configuration of your release and tracks all changes to the configuration, including Helm.

Helm is called by DeployHub using  ”Custom Action.” A Custom Action can replace the usual DeployHub deployment engine processing by calling an external script that performs its own deployment activities. Custom Actions can be used when you want an external tool to perform the delivery step of the deployment process. This will be the case for Helm.

Importing the DeployHub Helm Procedures

To use Helm, you will need to import the most current DeployHub Helm Procedures from GitHub. There will be two:

• WriteEnv2Toml.re – This Procedure takes all the attributes from DeployHub Environments, Applications, Endpoints and Components and writes them to a file readable by the Helm Procedure.
• HelmUpgrade.re – This Procedure performs a Helm upgrade/install of the Helm Chart.

Download them from:
https://github.com/DeployHubProject/DeployHub-Pro/tree/master/procedures

Once downloaded, you will need to import them into DeployHub as Procedures. To import these Procedures first login into DeployHub and select the Flows menu.  Navigate to the Function & Procedures tab. Select your Domain, such as ‘Global Domain,’ and right click for the Menu. Choose “Import a Function or Procedure into this Domain”. Upload the two Procedures one at a time into the DeployHub database.

Creating a Custom Action for Helm

Once you have imported your Helm Procedures, you can define your Custom Action. Change to the Workflow tab on the right pane. Select your Domain and right click. This will give you the option to create a “New Action in this Domain.”

Name the new Action “HelmChart” (no spaces).

 

New DeployHub Action

 

Now we are going to customize this Action. Go to the Workflow tab. You will see the ‘Activity Hub’ on the Right hand side of your screen. Navigate to your Domain to find the two Procedures. Drag them onto the area under Start. This will bring up the Dialog box to enter the parameters. No fields are required for WriteEnv2Toml.

 

Repeat the process for the HelmUpgrade Procedure and fill in the fields as follows:

Title: Not Required
Summary: Not Required
RspFile: $RspFile (The results from the WriteEnv2Toml.re Procedure)
Chart: $(Chart) (The Helm Chart to be used during the deployment)
Release Name: $(component.name) (The name of the Component)

At this point the Action is ready to be used by anyone with access (based on Domain and security options). Each Component that uses the Action will need to define specific values. Because this new Action is reusable, no Component variables are defined.

Assign the HelmChart Action to a Docker Component

For each Docker Component, you will need to define the variable values. Values are specified when you create a new Docker Component. These values will override those defined at the Application or Environment level. The values from DeployHub will be passed along to Helm’s values.yml file at execution time.

Docker component items have the following attributes, none of which are required:

 

BuildId The build ID from the build system such as Quay or DockerHub
BuildUrl Build URL for the build system
Chart Helm chart for the component
Chart Version Version of the Helm chart
Chart Name Space Namespace for the Helm chart to deploy to
Operator Kubernetes Operator
DockerBuildDate Timestamp for the Docker Build
DockerSha SHA for the Docker Image
DockerRepo URL for the Docker Registry
GitCommit Git Commit that triggered the Build
GitRepo Git Repo Name
GitTag Git Tag such as ‘Master’ or ‘v1.5.0’
GitUrl URL to the Git Repository
BuildNumber Build Job Number for CI/CD
Build Job Build Job name for CI/CD
ComponentType Name of the Component Type
ChangeRequestDS Name of the Change Request Datasource
Category Name of the Components Category
AlwaysDeploy Y/N
DeploySequentially Y/N
BaseDirectory Base Directory for the Component
PreAction Name of the Pre-Action
PostAction Name of the Post-Action
CustomAction Name of the Custom-Action
Summary Component Summary or Description

 

More Information

 

Leave a Reply