Upgrading Charts

We are about to install the go-demo-3 Chart. You should already be familiar with the commands, so you can consider this as an exercise that aims to solidify what you already learned. There will be one difference when compared to the commands we executed earlier. It'll prove to be a simple, and yet an important one for our continuous deployment processes.

We'll start by inspecting the values.

 1  helm inspect values helm/go-demo-3

The output is as follows.

replicaCount: 3
dbReplicaCount: 3
image:
  tag: latest
  dbTag: 3.3
ingress:
  enabled: true
  host: acme.com
route:
  enabled: true
service:
  # Change to NodePort if ingress.enable=false
  type: ClusterIP
rbac:
  enabled: true
resources:
  limits:
    cpu: 0.2
    memory: 20Mi
  requests:
    cpu: 0.1
    memory: 10Mi
dbResources:
  limits:
    memory: "200Mi"
    cpu: 0.2
  requests:
    memory: "100Mi"
    cpu: 0.1
dbPersistence:
  ## If defined, storageClassName: <storageClass>
  ## If set to "-", storageClassName: "", which disables dynamic provisioning
  ## If undefined (the default) or set to null, no storageClassName spec is
  ##   set, choosing the default provisioner.  (gp2 on AWS, standard on
  ##   GKE, AWS & OpenStack)
  ##
  # storageClass: "-"
  accessMode: ReadWriteOnce
  size: 2Gi

We are almost ready to install the application. The only thing we're missing is the host we'll use for the application.

You'll find two commands as follows. Please execute only one of those depending on your Kubernetes flavor.

If you are NOT using minishift, please execute the command that follows.

 1  HOST="go-demo-3.$LB_IP.nip.io"

If you are using minishift, you can retrieve the host with the command that follows.

 1  HOST="go-demo-3-go-demo-3.$(minishift ip).nip.io"

No matter how you retrieved the host, we'll output it so that we can confirm that it looks OK.

 1  echo $HOST

In my case, the output is as follows.

 1  go-demo-3.192.168.99.100.nip.io

Now we are finally ready to install the Chart.

However, we won't use helm install as before. We'll use upgrade instead.

 1  helm upgrade -i 
 2     go-demo-3 helm/go-demo-3 
 3     --namespace go-demo-3 
 4     --set image.tag=1.0 
 5     --set ingress.host=$HOST 
 6     --reuse-values

The reason we are using helm upgrade this time lies in the fact that we are practicing the commands we hope to use inside our CDP processes. Given that we want to use the same process no matter whether it's the first release (install) or those that follow (upgrade). It would be silly to have if/else statements that would determine whether it is the first release and thus execute the install, or to go with an upgrade. We are going with a much simpler solution. We will always upgrade the chart. The trick is in the -i argument that can be translated to "install unless a release by the same name doesn't already exist."

The next two arguments are the name of the Chart (go-demo-3) and the path to the Chart (helm/go-demo-3). By using the path to the directory with the Chart, we are experiencing yet another way to supply the Chart files. In the next chapter will switch to using tgz packages.

The rest of the arguments are making sure that the correct tag is used (1.0), that Ingress is using the desired host, and that the values that might have been used in the previous upgrades are still the same (--reuse-values).

If this command is used in the continuous deployment processes, we would need to set the tag explicitly through the --set argument to ensure that the correct image is used. The host, on the other hand, is static and unlikely to change often (if ever). We would be better of defining it in values.yaml. However, since I could not predict what will be your host, we had to define it as the --set argument.

Please note that minishift does not support Ingress (at least not by default). So, it was created, but it has no effect. I thought that it is a better option than to use different commands for OpenShift than for the rest of the flavors. If minishift is your choice, feel free to add --set ingress.enable=false to the previous command.

The output of the upgrade is the same as if we executed install (resources are removed for brevity).

NAME:   go-demo-3
LAST DEPLOYED: Fri May 25 14:40:31 2018
NAMESPACE: go-demo-3
STATUS: DEPLOYED
    
...
    
NOTES:
1. Wait until the application is rolled out:
   kubectl -n go-demo-3 rollout status deployment go-demo-3
    
2. Test the application by running these commands:
   curl http://go-demo-3.18.222.53.124.nip.io/demo/hello
A note to minishift users
We'll need to create a Route separately from the Helm Chart, just as we did with Jenkins. Please execute the command that follows.
oc -n go-demo-3 create route edge --service go-demo-3 --insecure-policy Allow

We'll wait until the deployment rolls out before proceeding.

 1  kubectl -n go-demo-3 
 2    rollout status deployment go-demo-3

The output is as follows.

Waiting for rollout to finish: 0 of 3 updated replicas are available...
Waiting for rollout to finish: 1 of 3 updated replicas are available...
Waiting for rollout to finish: 2 of 3 updated replicas are available...
deployment "go-demo-3" successfully rolled out

Now we can confirm that the application is indeed working by sending a curl request.

 1  curl http://$HOST/demo/hello

The output should display the familiar hello, world! message, thus confirming that the application is indeed running and that it is accessible through the host we defined in Ingress (or route in case of minishift).

Let's imagine that some time passed since we installed the first release, that someone pushed a change to the master branch, that we already run all our tests, that we built a new image, and that we pushed it to Docker Hub. In that hypothetical situation, our next step would be to execute another helm upgrade.

 1  helm upgrade -i 
 2     go-demo-3 helm/go-demo-3 
 3     --namespace go-demo-3 
 4     --set image.tag=2.0 
 5     --reuse-values

When compared with the previous command, the difference is in the tag. This time we set it to 2.0. We also removed --set ingress.host=$HOST argument. Since we have --reuse-values, all those used in the previous release will be maintained.

There's probably no need to further validations (for example, wait for it to roll out and send a curl request). All that's left is to remove the chart and delete the Namespace. We're done with the hands-on exercises.

 1  helm delete go-demo-3 --purge 
2
3 kubectl delete ns go-demo-3
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset