Integrate Helm Into Your Microservice Releases
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).
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 |
Further Reading:
- Microservice Supply Chain
- Microservice Versioning Management
- Simplifying Microservice Applications
- Domain-Driven Design for Microservices
- Ship Microservices Safely – Know Your Blast Radius
- Improve Your Incident Response
- Microservice Configuration Management
- Database Updates Pushed Across Your CD Pipeline
- Building Microservice Pipeline
- Microservices Continuous Integration
- DeployHub Microservice Dashboard