Fixing the Auto-Generated Helm Chart

Even though the code of the application is small, I will save you from going through it. Instead, I’ll let you know right away what’s missing and what parts of the chart need to be added or modified.

Adding DB environment variable#

First of all, the application requires an environment variable called DB. The code is using it to obtain the address of the database. That brings us to the first thing missing in the chart generated by Jenkins X; there is no definition for MongoDB.

The first step is to open charts/go-demo-6/templates/deployment.yaml in your favorite editor. That’s where the Deployment for the application is defined, and that’s where we need to add the variable.

Please locate the code that follows.

Now, add the env section with the name set to DB and the value {{ template "fullname" . }}-db. The final version of the snippet listed above should be as follows.

Save the file.

Adding MongoDB to the Helm chart#

Next, we need to add MongoDB to the Helm chart that was created for us. Now, we could start writing Helm templates for the MongoDB StatefulSet and a Service. We could spend time trying to figure out how to replicate data between its replicas, and probably a few other things that might not be obvious from the start. However, we should know better. We should know that there is already a Helm chart that does that and more. There are quite a few charts we could use, but we’ll go with mongodb from the stable channel.

So, how can we add MongoDB chart to the one we already have? The answer is dependencies. We can make our application depend on MongoDB charts by creating a requirements.yaml file.

The only things worth noting in that file are alias and condition.

• The former (alias) is set to the value that will create a Service with the same name as the environment variable DB that we just added to deployment.yaml.
• The latter (condition) will allow us to disable this dependency. We’ll see later why we might want to do that.

There’s only one more thing missing. We should probably customize the MongoDB chart to fit our use case. I won’t go through all the values we could set. You can explore them yourself by executing helm inspect values stable/mongodb or by visiting project README. Instead, we’ll define only one, mostly as an exercise on how to define values for the dependencies.

Defining values for the dependencies#

So, let’s add some new entries to values.yaml.

We set only replicaSet.enabled to true. The important thing to note is that it is nested inside go-demo-6-db. That way, Helm will know that the variable is not meant for our application (go-demo-6), but for the dependency called (aliased) go-demo-6-db.

Now, that we know how to add dependencies to our applications, we should push the changes to GitHub, and check whether that solved our issue.

Monitor the build activities#

Next, we need to wait until the new release is deployed to the staging environment. We’ll monitor the activity of the new build and wait until its finished.

The output, limited to the new build, is as follows:

The Promoted step is the last one in that build. Once we reach it, we can stop monitoring the activity by pressing ctrl+c.

Inspect Pods#

Let’s see whether we got the Pods that belong to the database and, more importantly, whether the application is indeed running.

The output is as follows:

⚠️ Please note that it might take a minute or two after the application pipeline activity is finished for the application to be deployed to the staging environment. If the output listed above does not match what you see on the screen, you might need to wait for a few moments and re-run the previous command.

The good news is that the database is indeed running. The bad news is that the application is still not operational. In my case, it has already restarted five times, and 0 containers are available.

Describe pods#

Given that the problem is this time probably not related to the database, the logical course of action is to describe the Pod and see whether we can get a clue about the issue from the events.

The output, limited to the message of the events, is as follows.

This time, liveness and readiness probes are failing. Either the application inside that Pod is not responding to the probes, or there’s some other problem we have yet to discover.

Now, unless you went through the code, you cannot know that the application does not respond to requests on the root path. If we take a look at the Pod definition, we’ll see that probePath is set to /. Jenkins X could not know which path could be used for the probe of our application. So, it set it to the only sensible default it could, and that’s /.

Modifying the probePath entry#

We’ll have to modify the probePath entry. There is already a variable that allows us to do that instead of fiddling with the Deployment template.

If you go through the values, you’ll notice that one of them is probePath and that it is set to /.

Please edit the charts/go-demo-6/values.yaml file by changing probePath: / entry to probePath: /demo/hello?health=true. Feel free to use your favorite editor for that and make sure to save the changes once you’re done. Next, we’ll push the changes to GitHub.

Now we have another round of waiting until the activity of the new build is finished.

Once the new build is finished, we can stop watching the activity by pressing ctrl+c. You’ll know it is done when you see the Promoted entry in the Succeeded status or simply when there are no Pending and Running steps.

Final checks for the application#

What do you think? Is our application finally up-and-running? Let’s check it out.

The output is as follows:

To be on the safe side, we’ll send a request to the application. If we are greeted back, we’ll know that it’s working as expected.

The output shows hello, world, thus confirming that the application is up-and-running and that we can reach it.

Before we proceed, we’ll go out of the go-demo-6 directory.

In the next lesson, we will discuss the reasoning behind all the work we just did.