We’re giving away 1,500 more DJI Tello drones. Enter to win ›
Doug Tidwell | Published February 27, 2018
This tutorial shows you how to use Kubernetes secrets to deliver credentials to your application. When you’re done, you’ll be able to deploy far more complicated apps to your cluster. Your apps will be able to access the full power of the IBM Cloud catalog, allowing you to extend your Kubernatorial dominance.
Here’s what you’ll do in this tutorial:
Along the way you’ll also take a look at the Kubernetes dashboard.
As always, we hope you’ll follow along with the exercises here. The goal is for this tutorial to stand on its own, but you can find background on the concepts presented here in the following videos:
You’ll need to have all of these things created, installed, configured, and running by the end of this section:
It’s entirely possible you have all of these things already. However, we include some basic instructions here if you need them. The starting point is the Rameses II chatbot app built in the chatbot videos mentioned above. If you have some other app that uses an IBM Cloud service that requires credentials, by all means use your app instead.
The first step is to clone the github repo at https://github.com/IBM/conversation-simple-k8s:
At a command line, type the following commands:
git clone https://github.com/IBM/conversation-simple-k8s
This code is based on the conversation-simple app built by the Watson conversation team, with a Dockerfile and some YAML and JSON files added for convenience.
Many thanks to the Watson team for developing, sharing, and maintaining this app.
To create an instance of the Watson conversation service, go to the IBM Cloud catalog (visit cloud.ibm.com and click “Catalog” at the top of the page). Type conversation in the search bar. You’ll see the Conversation service in the Watson section:
Click the catalog item to get started. On the next panel you’ll see the name of the new service at the top. You can take the existing name (which will be something like Conversation-n1) or type in something more memorable. Scroll down to the Pricing Plans section and make sure the Lite plan (a.k.a. the “free” plan) is selected:
Click Create to create your new conversation service. When the service is created, click the Launch tool button to open the workspace:
(Notice that the conversation service is named dwtv-convo instead of the far less memorable Conversation-n1.)
You’ll see the Workspaces panel:
Now import all of the intents, entities, and dialogs for the chatbot from the file RoyalValet.json in the repo you cloned earlier. In your workspace, click the Import icon:
Select the file from your machine, make sure the Import Everything radio button is checked, then click Import:
This adds to your workspace a complete chatbot named Royal Valet.
You’ve probably done most of these already, but make sure you go through the following steps:
bx plugin install container-registry -r "IBM Cloud"
bx plugin install container-service -r "IBM Cloud"
bx cr login
bx cr namespace-add [name]
The repo you cloned has a Dockerfile (and a .dockerignore file too, for that matter) to make it easy to create a Docker image from the code. First, make sure the Docker runtime is running on your machine. How you do that depends on your platform, so see the Docker documentation if you need details.
With Docker running, type the following command in the conversation-simple-k8s directory:
-t registry.ng.bluemix.net/[your namespace]/conversation:v1
Note that the ng part of the registry name will be different depending IBM Cloud data center you’re using. For example, if your cluster is in Germany, that part of the registry name will be eu-de. (Keep that in mind whenever you see ng in the rest of this article.) The namespace here is the namespace you created with the bx cr namespace-add command earlier.
bx cr namespace-add
Finally, be sure to include the period at the end of the command; that tells Docker to look for the Dockerfile in the current directory. The start of the build looks like this:
When the build finishes, run the following command to push it into your container registry in the IBM Cloud:
You’ll see something like this:
Now your Docker image is built and uploaded to the IBM Cloud. The next step is to create a Kubernetes cluster for your image.
To use a Kubernetes secret, of course, you’ll need a Kubernetes cluster. That’s what you’ll create now. From the IBM Cloud console, go to the menu in the upper left-hand corner and click Containers:
Next, click the Create cluster button in the middle of the page:
Finally, give your cluster a name (in the example below, the cluster is named “Mailbag”) and make sure you’ve checked the Lite plan (a.k.a. the “free” plan), then click the Create Cluster button on the right-hand side of the panel:
It will take several minutes for the cluster to be provisioned and started. While that’s happening, feel free to stand up and stretch, get a cup of coffee, or visit with your neighbors. When the cluster is up and running, you’ll see it in your IBM Cloud dashboard:
The last bit of setup work is to configure the kubectl command to point to your Kubernetes cluster in the IBM Cloud. Once configured, anytime you use kubectl, it interacts with your cluster. Run the following two commands to set everything up:
bx cs cluster-config Mailbag
These two commands look like this on Linux or the Mac:
Notice that the export command is merely a cut and paste of the output of the bx cs cluster-config command. Also, be aware that this only configures kubectl for the current command line. If you switch to another window, you’ll need to configure kubectl in that window as well.
bx cs cluster-config
Okay, enough setup already. Hopefully you had most of those steps done already or knew how to do them without much trouble. Your next task is to create the YAML file for your credentials. Open the file convo-secret.yaml from the repo you cloned:
The trick here, as you probably guessed, is to fill in the WORKSPACE_ID, CONVERSATION_USERNAME, and CONVERSATION_PASSWORD values correctly. However, there’s one complication: Those values have to be base64-encoded. And of course, you have to get the values before you can encode them.
To get the WORKSPACE_ID, go back to the conversation workspace, click the three dots icon on the tile for your chatbot, and select View details:
The tile shows you the workspace ID:
Click the copy icon to put the value on the clipboard, then use a base64 encoding tool to convert the value. On Linux and the Mac, the command looks like this:
echo -n “c37281df-ea7e-3821-dd7f-c2758fab490c” | base64echo -n "c37281df-ea7e-3821-dd7f-c2758fab490c" | base64
echo -n "c37281df-ea7e-3821-dd7f-c2758fab490c" | base64
This returns the value you need for the convo-secret.yaml file:
In this example (which is not a valid workspace ID), you would paste the value YzM3MjgxZGYtZWE3ZS0zODIxLWRkN2YtYzI3NThmYWI0OTBj into the convo-secret.yaml file.
Two things to keep in mind: First of all, the -n-n parameter of the echo command is required. This stops echo from adding a newline to the end of the text in double quotes. If you omit this parameter, the encoded value won’t work. Second, if you’re on Windows, use one of the base64 encoding tools that are available on the web. Windows includes certutil, a tool that can do base64 encoding — but it won’t work because it always adds a newline.
That takes care of the first credential you need. Now it’s time to get the CONVERSATION_USERNAME and CONVERSATION_PASSWORD values from the conversation service. Go to the dashboard at cloud.ibm.com, find your conversation service in the list, and click it to open the service’s management page. Click the Service credentials tab on the left:
You should see a list of credentials. If you don’t have any credentials, click the New credential button to create one. Next, click View credentials to see the values you need:
Now take those two values, base64 encode them, and paste the encoded values into the YAML file. The final version of convo-secret.yaml should look something like this:
With the credentials filled in, it’s time to create the secret.
Type kubectl create -f convo-secret.yaml at the command line.
kubectl create -f convo-secret.yaml
Wait, that was a whole section? That’s all it takes to create the secret?
Well, yes. In retrospect, your author should have put more thought into the outline. But let’s press on.
When you’re working with Kubernetes, the Kubernetes dashboard is an extremely useful tool for figuring out what’s going on in your cluster. (It is also extremely useful for figuring out what’s going wrong in your cluster.) To start it, type:
With the proxy running, open localhost:8001/ui in your browser. You’ll most likely see this login prompt:
Go to the command line and type kubectl config view to get the token you need to log in. The YAML output contains a field named id-token:
kubectl config view
Copy the value of the token to the clipboard. In your browser, click the Token radio button, paste in the token, and click SIGN IN:
After you log in, you’ll see a dashboard that looks something like this:
If you scroll to the bottom of the list on the left and click Secrets, you’ll see a list of secrets. Click on the name of the secret you just created:
You can find the details of the deployments, pods, services, and lots of other things inside your cluster. Get to know the dashboard. The dashboard is your friend.
Continuing its tradition of usefulness, the repo you cloned has a file called convo-deployment.yaml which already has most of the YAML you need. Open it in your favorite editor:
This defines the Kubernetes deployment that you’ll use to deploy your Docker image. There are a couple of things worth noting here. First of all, this file creates a new deployment named convo and a new container named convo-container, and it is based on the Docker image registry.ng.bluemix.net/mailbag/conversation:v1. You’ll need to change that image name appropriately: ng should be different if you’re not using the US South data center, and mailbag should be replaced with your namespace.
The second thing is that your container exposes port 3000. The node app inside the Docker image listens on this port. If your code does things differently, you’ll need to change this value.
Finally, the env section of the file defines three environment variables that will be available to your app when it starts. The syntax here is pretty straightforward. There are three environment variables (named WORKSPACE_ID, CONVERSATION_USERNAME, and CONVERSATION_PASSWORD, as you’d expect), each one gets its value from a Kubernetes secret named convo-secret and each one is mapped to a particular key in the secret.
You’re almost there! The first thing to do, as you would expect, is to tell kubectl to process the file you just updated:
kubectl create -f convo-deployment
The rest of the work of deploying and exposing your code is done exactly the same way for any app, whether it uses credentials or not. You’ve set up the Kubernetes secret, so deployment is straightforward. Type this exhausting command:
kubectl expose deployment convo --type=NodePort --port=3000
This creates a new service (cleverly named convo-service) that your users can use to access your code. The name convo here is the name of the deployment from the YAML file, and 3000 is your app’s port number. We won’t cover what a NodePort is here; suffice to say, it’s your only option with a free cluster in an IBM Cloud Lite account.
When Kubernetes creates your service, it creates a proxy that assigns a randomly generated port number to your app. To find that port number, use kubectl describe service convo-service:
kubectl describe service convo-service
In this example, Kubernetes has exposed port 31361 to the world, and anything that comes in on that port will be passed on to the service on port 3000. The last thing you need to know is the IP address of the cluster itself. Kubernetes doesn’t know anything about the outside world, so you have to use the bx command for that. bx cs workers Mailbag gives you the information you want:
bx cs workers Mailbag
The IP address of the cluster is 126.96.36.199. If you open your browser to http://188.8.131.52:31361, you should see your app:
Using Kubernetes secrets allows you to set up the environment variables your code needs before it starts. Secrets are elegant, straightforward, and easy to create and manage (except for the base64 part, anyway). Now you’re ready to load up your Kubernetes clusters with apps that use any number or combination of services from the IBM Cloud platform. Have fun!
Make sense of Kubernetes with these step-by-step instructions on how to deploy a Flask application to the IBM Cloud Kubernetes…
Back to top