We'll almost never install a Chart as we did. Even though the default values do often make a lot of sense, there is always something we need to tweak to make an application behave as we expect.
What if we do not want the Jenkins tag predefined in the Chart? What if for some reason we want to deploy Jenkins 2.112-alpine?
There must be a sensible way to change the tag of the stable/jenkins Chart.
Helm allows us to modify installation through variables. All we need to do is to find out which variables are available.
Besides visiting project's documentation, we can retrieve the available values through the command that follows.
1 helm inspect values stable/jenkins
The output, limited to the relevant parts, is as follows.
... Master: Name: jenkins-master Image: "jenkins/jenkins" ImageTag: "lts" ...
We can see that within the Master section there is a variable ImageTag. The name of the variable should be, in this case, sufficiently self-explanatory. If we need more information, we can always inspect the chart.
1 helm inspect stable/jenkins
I encourage you to read the whole output at some later moment. For now, we care only about the ImageTag.
The output, limited to the relevant parts, is as follows.
... | Parameter | Description | Default | | ----------------- | ---------------- | ------- | ... | Master.ImageTag | Master image tag | lts | ...
That did not provide much more info. Still, we do not really need more than that. We can assume that Master.ImageTag will allow us to replace the default value lts with 2.112-alpine.
If we go through the documentation, we'll discover that one of the ways to overwrite the default values is through the --set argument. Let's give it a try.
1 helm install stable/jenkins 2 --name jenkins 3 --namespace jenkins 4 --set Master.ImageTag=2.112-alpine
We still need to change the jenkins Service type to NodePort. Since this is specific to minikube, I did not want to include it in the command we just executed. Instead, we'll run the same command as before. Please execute the command that follows.
helm upgrade jenkins stable/jenkins --set Master.ServiceType=NodePort --reuse-values
We still did not go through the upgrade process. For now, just note that we changed the Service type to NodePort.
Alternatively, you can delete the Chart and install it again but, this time, the --set Master.ServiceType=NodePort argument needs to be added to helm install.
The Route we created earlier still exists, so we do not need to create it again.
The output of the helm install command is almost the same as when we executed it the first time, so there's probably no need to go through it again. Instead, we'll wait until jenkins rolls out.
1 kubectl -n jenkins 2 rollout status deployment jenkins
Now that the Deployment rolled out, we are almost ready to test whether the change of the variable had any effect. First, we need to get the Jenkins address. We'll retrieve it in the same way as before, so there's no need to lengthy explanation.
1 ADDR=$(kubectl -n jenkins
2 get svc jenkins
3 -o jsonpath="{.status.loadBalancer.ingress[0].hostname}"):8080
As a reminder, the command to retrieve the address from minikube is as follows.
ADDR=$(minikube ip):$(kubectl -n jenkins get svc jenkins -o jsonpath="{.spec.ports[0].nodePort}")
As a reminder, the command to retrieve the address from GKE is as follows.
ADDR=$(kubectl -n jenkins get svc jenkins -o jsonpath="{.status.loadBalancer.ingress[0].ip}"):8080
As a reminder, the command to retrieve the address from the OpenShift route is as follows.
ADDR=$(oc -n jenkins get route jenkins -o jsonpath="{.status.ingress[0].host}")
As a precaution, please output the ADDR variable and check whether the address looks correct.
1 echo $ADDR
Now we can open Jenkins UI.
1 open "http://$ADDR"
This time there is no need even to log in. All we need to do is to check whether changing the tag worked. Please observe the version in the bottom-right corner of the screen. It should be Jenkins ver. 2.112.
Let's imagine that some time passed and we decided to upgrade our Jenkins from 2.112 to 2.116. We go through the documentation and discover that there is the upgrade command we can leverage.
1 helm upgrade jenkins stable/jenkins 2 --set Master.ImageTag=2.116-alpine 3 --reuse-values
This time we did not specify the Namespace, but we did set the --reuse-values argument. With it, the upgrade will maintain all the values used the last time we installed or upgraded the Chart. The result is an upgrade of the Kubernetes resources so that they comply with our desire to change the tag, and leave everything else intact.
The output of the upgrade command, limited to the first few lines, is as follows.
Release "jenkins" has been upgraded. Happy Helming! LAST DEPLOYED: Thu May 24 12:51:03 2018 NAMESPACE: jenkins STATUS: DEPLOYED ...
We can see that the release was upgraded.
To be on the safe side, we'll describe the jenkins Deployment and confirm that the image is indeed 2.116-alpine.
1 kubectl -n jenkins 2 describe deployment jenkins
The output, limited to the relevant parts, is as follows.
Name: jenkins
Namespace: jenkins
...
Pod Template:
...
Containers:
jenkins:
Image: jenkins/jenkins:2.116-alpine
...
The image was indeed updated to the tag 2.116-alpine.
To satisfy my paranoid nature, we'll also open Jenkins UI and confirm the version there. But, before we do that, we need to wait until the update rolls out.
1 kubectl -n jenkins 2 rollout status deployment jenkins
Now we can open Jenkins UI.
1 open "http://$ADDR"
Please note the version in the bottom-right corner of the screen. It should say Jenkins ver. 2.116.