Deploying Helm Charts to a Kubernetes server from Jenkins

Question

I would like to be able to automate deployments to my Kubernetes cluster using Helm charts executed by Jenkins (as part of the build cycle). The Jenkins machine is on a separate network to the Kubernetes cluster (rather than part of it as documented in numerous blogs).

I have a chart repo hosted inside a private GitHub account. I followed the process here: https://hackernoon.com/using-a-private-github-repo-as-helm-chart-repo-https-access-95629b2af27c and was able to add it as a repo in Helm on an Azure server using a command of the format:

helm repo add sample 'https://[email protected]/kmzfs/helm-repo-in-github/master/'

I've been trying to get the ElasticBox Kubernetes CI/CD (v1.3) plugin inside Jenkins to connect to this chart repo, but whenever I press "Test Connection", I get a 400 Bad Request error. I have tried to enter the details in a variety of ways:

1. Using the same format (and token) as above and no credentials
2. Using the private token (same as in the query above) in the credentials, and the url of https://raw.githubusercontent.com/kmzfs/helm-repo-in-github/master/
3. Using my username and password in the credentials, and the url of https://raw.githubusercontent.com/kmzfs/helm-repo-in-github/master/

I have this plugin to connect to the Kubernetes Cloud and it can connect to the repository at https://github.com/helm/charts and deploy a RabbitMQ container.

Is it possible to get this plugin to connect to a private Github repository as a chart repository, and if so, how do I go about doing so?

If not, is there an alternative means of deploying Helm charts (in a private repo) from Jenkins? I couldn't find any other plugins that used Helm.

Thanks Duncan

Answer 1

What we use in our CI is completely skip anyfunky Jenkins plugins and just go for the native tooling. We bake kubectl/helm into the jenkins/worker image provide credentials to them so they can speak to the cluster and then take the private Helm chart not from published charts, but directly from private git repo holding that chart. And then we simply run helm against this localy cloned chart with a usual script step.

Example of kube config part defining the ca cert (related to comment below):

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: <base64 ca cert>
    server: https://cluster_api_url
  name: mycluster

Answer 2

We're working on an open source project called Jenkins X which is a proposed sub project of the Jenkins foundation aimed at automating CI/CD on Kubernetes using Jenkins and GitOps for promotion.

We worked around some of the issues you've been having by running the Jenkins pipelines inside the kubernetes cluster; so there's no need to authenticate with the kubernetes cluster - it just reuses the existing RBAC.

When you merge a change to the master branch, Jenkins X creates a new semantically versioned distribution of your app (pom.xml, jar, docker image, helm chart). The pipeline then automates the generation of Pull Requests to promote your application through all of the Environments via GitOps.

Here's a demo of how to automate CI/CD with multiple environments on Kubernetes using GitOps for promotion between environments and Preview Environments on Pull Requests - using Spring Boot and nodejs apps (but we support many languages + frameworks).