Helm for Container Deployments
DeployHub supports Helm in two ways:
- Stores the Helm chart repository and version
- Can be called by the DeployHub internal deployment engine for performing container deployments.
Storing Helm Chart Repository and Version
DeployHub integrates with Helm using the CI/CD Command Line Interface (CLI). For every Component Version, the CLI gathers and stores the
| Access | Description |
|---|---|
| Chart | Helm Chart for the Component |
| ChartNamespace | Name space for the Component to be deployed to |
| ChartRepo | Helm Chart Repo Name |
| ChartRepoUrl | Helm Chart Repo Url |
| ChartVersion | Helm Chart version |
These values are displayed for every Component Version and viewable from the Component Detail dashboard.
Using Helm with the DeployHub Internal Engine
Helm is called to replace the DeployHub default processing engine for performing container deployments. When DeployHub executes the release process, it will call the Helm Chart you have defined as your Custom Action at the Component level. DeployHub includes the version of the Helm chart as part of its overall configuration data.
Helm and Key Value Pairs
In order to support a consistent Helm deployment across Cluster Endpoints and Environments (Dev, Test, Prod) Key value pair substitution is performed. When a Helm chart is used, DeployHub will pull your Helm Chart in the .tgz format from either a public or private Chart Museum. It then expands it out into a separate directory location where Helm is executed. This location is defined by the DeployHub Endpoint which you define (see “Connecting a DeployHub Endpoint to your Kubernetes Cluster through Helm” below).
DeployHub will then create an override values file which contains all the specific key value pairs defined at the Endpoint, Environment, Component or Application in this order of precedence. For example, if the same key value pairs are defined at the Endpoints as well as the Application, the Endpoint key values are used.
The override values file passes the Key value definitions Helm ‘upgrade’ command. This process allows a single Helm chart to be reused across all deployments, supporting the needed key value pairs for each deployment.
If you would like to create a hermetic Helm Chart stored in the DeployHub database, use the following key value:
helmcapture=Y
This must be defined at any level, i.e., Endpoint, Environment, Component or Application.
Connecting a DeployHub Endpoint to your Kubernetes Cluster through Helm
DeployHub’ deployment engine comes pre-installed with Helm. For this reason you should use the deployment engine as the “localhost” Endpoint for your deployments. This Helm install on the “localhost” Endpoint needs to know how to connect to your Kubernetes Cluster.
Mount your “.kube/config” file to the DeployHub deployment engine Docker container to provide the connection. The additional parameter to the docker run command for the DeployHub container exposes the Kubernetes config file to the Helm install in DeployHub. The following is an example of the additional parameter:
-v ~/.kube:/home/omreleng/.kube:Z
For more information on starting the DeployHub Container see:
Connection to a Cloud Kubernetes Cluster
In order to connect to Kubernetes cluster running on a cloud provider, an authentication between DeployHub and the cloud provider must be made. Each cloud provider has a different set of parameters used to authenticate. Once authenticated, DeployHub will execute Helm in the same across all the cloud providers enabling reuse of the Helm Charts without the need to update them.
Connecting to a Google Kubernetes Cluster
| Key | Value | Command |
|---|---|---|
| gcloud.compute.zone | compute zone for the cluster | gcloud config set compute/zone |
| gcloud.container.cluster | cluster name | gcloud config set container/cluster and gcloud container clusters get-credentials |
| gcloud.core.account | account name | gcloud config set core/account |
| gcloud.core.disable_usage_reporting | disable reporting | gcloud config set core/disable_usage_reporting <disable_usage_reporting> |
| gcloud.core.project | project name | gcloud config set core/project |
| gcloud.oauth.account | service account name | gcloud auth activate-service-account |
| gcloud.oauth.keyfile | key file for service account | gcloud auth activate-service-account –key-file= |
Connecting to a Amazon Kubernetes Cluster
| Key | Value | Command |
|---|---|---|
| eks.aws_access_key_id | access key ID | aws –profile default configure set aws_access_key_id <key_id> |
| eks.aws_secret_access_key | secret key | aws –profile default configure set aws_secret_access_key <access_key> |
| eks.region | region the cluster is running in | aws eks –region |
| eks.cluster | cluster name | aws eks –region |
| eks.optional | additional options | aws eks –region |
Connecting to a Azure Kubernetes Cluster
| Key | Value | Command |
|---|---|---|
| aks.serviceprincipal | service principal | az login –service-principal -u |
| aks.certificate | certificate for the service principal | az login –service-principal -u |
| aks.tenant | tenant for the service principal | az login –service-principal -u |
| aks.resourcegroup | resource group for the cluster | az aks get-credentials –resource-group |
| aks.cluster | cluster name | az aks get-credentials –resource-group |
Using an existing context
| Key | Value | Command |
|---|---|---|
| kubectl_context | context name | kubectl config use-context <kubectl_context> |
Additional Helm Key/Values
| Key | Description |
|---|---|
| helm_exe | use helm2 for Helm V2 executable. Default is Helm V3 |
| helmrepo.url | url to the chart repo (from Component Definition) |
| helmrepo.username or helmrepouser | user name used to login into the repo with |
| helmrepo.password or helmrepopass | password user to login into the repo with |
| chart | chart to use (from Component Definition) |
| chartversion | version of the chart. Default latest (from Component Definition) |
| chartnamespace | namespace to use for the deployment (from Component Definition) |
| helmopts | additional options for the helm upgrade |
| helmtemplateopts | additional options for the helm template |
| helmcapture | y/n for uploading a hermetic version of the chart and values to DeployHub stored by deploy log # |
Helm and Custom Actions
Helm is called as a DeployHub Custom Action. To use Helm, you will need to import two Helm files as DeployHub Procedures and define them to your Custom Action. This Helm Custom Action can then be assigned to your Container Components. See Procedures and Functions and Customize Actions to learn more. The following steps will create your Helm Custom Action.
Step 1 - Download and Import the Helm scripts as Procedures
Download the the most current DeployHub Helm Procedures from the DeployHub Git Repo. 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.
Step 2 - Create your Procedures
Once downloaded, you will need to Import the scripts into DeployHub as Procedures. To import these Procedures navigate to the Func/Procs Menu option on the left hand side of the DeployHub Main Menu panel. This will take you to the Functions and Procedures List View. From the Functions and Procedures List View select the Import option. The Import will bring you to your operating system “file open” dialog box for selecting the WriteEnv2Toml.re and HelmUpgrade.re files.
Next, select your “Global,” or highest level, Domain and upload the Procedure into DeployHub. If you select a lower level Sub-Domain you will restrict access. By defining it to your highest level Domain, all Users will be able to see the Procedures. Once you have both imported, you are now ready to create your Action.
Step 3 - Create your Action for Your Helm Procedures
Once you have imported your WriteEnv2Toml.re and HelmUpgrade.re files as Procedures, you can define your Action. Navigate to the Actions list view from the Actions menu option on the left hand side of the DeployHub Main Menu panel.
Use the +Add option to create a new Action for you Procedure. In the “Full Domain” field select your “Global” Domain. If you select a lower level Sub-Domain you will restrict access to this Custom Action. By defining it to your highest level Domain, all Users will be able to execute the process regardless of their Sub-Domain.
Name the new Action HelmChart (no spaces).
Now we are going to customize this Action. On the right hand side, you will see a list of Functions and Procedures you can choose from. Navigate to your Domain to find the WriteEnv2Toml.re and HelmUpgrade.re imported Procedures. Drag them onto the area under “Start”. The order should be WriteEnv2Toml, HelmUpgrade.
No Parameter fields are required for WriteEnv2File.
When you drag the HelmUpgrade Procedure onto the area under “Start” a pop-up dialog box will open for you to complete the following parameters:
| Field | Value | Description |
|---|---|---|
| Title | Not Required | Name of the step in your deployment workflow. |
| Summary | Not Required | Enter a summary of this step. |
| 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 release |
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 at the Action level.
Assign the Helm Chart Action to a Component
Create your new Component from the Component Dashboard. See the Components chapter. For each container Component you will need to define the variable values. Values are specified when you create a new container Component. 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.
Storing and Retrieving a Hermetic Helm Chart
In order to create an ‘airtight’ Helm deployment, DeployHub takes the generated Helm overrides file created during a Helm deployment and executes the Helm template command to find the container images that were referenced. All container image digests are captured and stored in the DeployHub database along with the Helm Chart and all key values used in a specific deployment. To turn on this option, the following key value pair must be defined at any level, i.e., Endpoint, Environment, Component or Application.
helmcapture=Y
Once stored in the DeployHub database, you can retrieve the hermetic Helm Chart, key value pairs and all container digests to repeat the exact deployment utilizing Helm manually.
Retrieving and Running the Helm Chart Manually
To re-execute a Helm deployment manually, you will retrieve all captured data in a zip file (Helm Chart, all container digest, and key values ). To retrieve the data and generate a zip file, execute the following curl command if using the SaaS:
curl "https://console.deployhub.com/dmadminweb/API/helmchart/<DeploymentNumber>?format=zip"-o Helmchart.zip
where: Deployment Number is the Number of the Deployment displayed in the DeployHub dashboard for the Application.
Helmchart.zip is the name of the zip file you want to create.
If you are using an on premise version use the following command:
curl "http://<myDeployHub>/dmadminweb/API/helmchart/<DeploymentNumber>?format=zip"-o Helmchart.zip
where: myDeployHub is your on premise DeployHub Server.
Deployment Number is the Number of the Deployment displayed in the DeployHub dashboard for the Application.
Helmchart.zip is the name of the zip file you want to create.
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.