Serverless Computing Tutorial: Deploying to Knative (Part 3)
Articles,  Blog

Serverless Computing Tutorial: Deploying to Knative (Part 3)

The following is a Coderland presentation about our newest attraction, The Compile Driver. Hello! This is Doug Tidwell for Coderland. In this video, we’ll take a look at Knative itself. We’ll cover the three parts of Knative, we’ll talk about how to install it on Minishift, and we’ll deploy our image processing code as a serverless function. With all that done, we’ll talk about ways to invoke the code from the command line and from the React front end we looked at in the previous video. So let’s talk a little bit about Knative. It has three components. Knative Build, as you would expect, builds and packages your code, Knative Eventing lets you define events that should trigger your code, and Knative Serving manages your functions, including scaling them to zero whenever they’re not being used. To keep it simple, we’ll focus on Knative Serving here. We’ve already built the code for you, so you don’t have to worry about Knative Build, and instead of setting up events, we’ll simply call the serverless function when we need it. We’ll cover the other parts of Knative some other time. We’re assuming you’ve been through the first video and have the cloned repos installed on your machine. If not, you can find the image manipulation code at this URL [ And Don Schenck’s React front end here: [] Now, let’s move on to the install. In this video, we’ll use Minishift, a single-node version of OpenShift, Red Hat’s Kubernetes distribution. The simplest way to get it is to install the CDK, the Red Hat Container Development Kit, available, again, at the URL [] on your screen. You can, of course, get a copy of the CDK if you’re a member of the Red Hat Developer Program (if you’re not, you should be, it’s free) Once you’ve got the CDK installed, it’s time to get started. The overview of what you’ll do now used to be 1. Starting a Kubernetes cluster, 2. Starting Istio, then 3. Installing Knative, and finally D. Installing your code. But that process is SO two weeks ago. Our good friend Kamesh Sampath has an awesome Knative tutorial that we’ll be leaning on throughout this video. The tutorial is at this URL [] and we cannot praise it highly enough. Go ahead and open that URL in a second browser tab so you can follow along. And we really, really hope you’re following along. Click the Setup link in the tutorial and make sure you have all of the prerequisites installed. Now clone the knative-tutorial repo [] With that done, set the TUTORIAL_HOME environment variable and switch to $TUTORIAL_HOME/work. Now clone the knative-operators repo from the work directory. Before you run the magic script that makes your life easy, take out one line. I’ll edit it with nano, but obviously use whatever editor you like. I’m deleting the openshift-version setting. As of mid-February 2019, if you’re using the latest CDK, you’ve got version 3.11.43. Even better, the CDK makes sure everything is in sync, so you can just delete this line. Save the file, exit your text editor, and run it. Our sincere apologies if you enjoy typing dozens and dozens of commands and configuration statements, but Kamesh’s wonderful script does all the work for you. That’s great news for those of us who like our installations to be automatic and painless. But make no mistake, the script takes a while. It does a massive amount of work for you, and it’s at least one order of magnitude faster than doing things yourself. Once the script is finished, run the three commands you should always run after minishift starts. eval $(minishift oc-env) eval $(minishift docker-env) and oc login -u admin -p admin. That sets up the oc command, the Docker environment, and logs you in. This takes us to the moment you’ve possibly been waiting for: Step D: Deploying your serverless code. The commands you’ll need are currently in the Configure OpenShift project section in part 1 of Kamesh’s tutorial. Start with oc new-project knativetutorial, then the two policy commands you see here. Once you run those, you’re all set to deploy your code. Switch to the image-overlay repo you cloned on your machine earlier. It contains a file called service.yaml that tells Knative how to deploy your code. The YAML file gives your service a name, and most importantly, has the URL of the container image for your serverless code. Now take a deep breath and type oc apply -n knativetutorial -f service.yaml. Let’s go to the console to see what we just deployed. Type minishift console and it will pop up in your default browser. When you see this panel, enter admin as your username and password and you should see the service you just deployed. There are running pods associated with the service. I took my time opening the console, so as you can see, Knative is already terminating the service’s pods because no one invoked the service. The number of pods will soon drop to zero. When we invoke it later, the system will start a pod for us. Or multiple pods, depending on the demand on the serverless function. Your service is finally deployed, so let’s invoke it. As with anything managed by Istio, we need to get the IP address and port number for the ingress gateway. We’ll send our requests to that address and Istio will figure out how to route our request to the right service… …with a complication that we’ll talk about in a minute. Stand back from the screen, because here comes the command to get the address. First, we get the IP address of the minishift cluster. That’s pretty simple. The hard part is getting the port number. This part of the command uses JSON to extract it, then we wrap things up with /overlayImage. Cut and paste this from the tutorial unless you really enjoy typing. Here’s what the IP address of the endpoint looks like on my system, your mileage, of course, may vary. The aforementioned complication here is that Knative uses the HTTP Host header to route the request to our service. Type oc -n knativetutorial get to see the domains of your services. As you can see here, the domain is the name of the service, then the namespace, then That tells Istio which service in which namespace should handle the request. The value of that domain has to be the value of the Host header when you invoke the service. Unless you change the configuration of the cluster, which we’re not going to do here. So now that we have all the pieces of the puzzle, let’s use curl to invoke the service. Here’s the delightfully simple command. We use -X to make this a POST, we set the Host header with the domain of the service, We specify that we’re sending and receiving JSON, and we pass in the file sampleInput.txt as the data. Finally, we have the actual URL. Hit enter and within a few seconds you should get a screen full of JSON, including a bunch of base64 encoded data. If there are no pods running when you invoke the service, you may have to try it again, but everything should work. Obviously you’ll want to redirect that output to a file, extract the image data, and decode it to see the updated photo just as we did in the first video. You can also edit the curltest shell script or curltest.cmd to change the URL of the service and add the Host header. That will save you a lot of typing. Although you’re no doubt thrilled that you invoked your service from the command line, you’d probably like to use Don’s React interface to work with the service as well. And that’s where things get complicated. Actually, that’s where things get MORE complicated. The problem is that Don’s code uses an XMLHttpRequest (an XHR) to access the remote function and update the image. But an XHR isn’t allowed to set the value of the Host header. To get around this problem I wrote a proxy that CAN change the Host header. Don’s code can call my proxy, which fixes the header and calls the function in Knative. Look! Another URL on your screen! This is the address of the repo for my proxy. So we’ll point Don’s code to the proxy. When Don’s code calls the proxy, the proxy fixes the Host header and sends the data to Knative. The results are sent back to Don’s code. Obviously that means you have to configure Don’s code and the proxy to use the correct values. To do that, go to the terminal where you’re running Don’s code and set the variable REACT_APP_OVERLAY_URL to http:// localhost:8888/overlayImage. Now create a new terminal and switch to the directory with the Knative proxy (knative-proxy). Set the variable PROXY_URL to the IP address you discovered earlier (again, with /overlayImage), and set the variable PROXY_HOST to the value of the service’s domain. npm install, then npm start, and the proxy is up and running. Now, switch to the terminal where you’re running Don’s code. Restart it and reload the browser if you need to. Click the “Take picture” button and everything should work. An updated image from a serverless function managed by Knative just popped up on your screen. How cool is that? You’ll see a message in the proxy’s window that indicates Don’s code has called the proxy successfully. If you get any errors, just reload the web page and try it again. As we were building the Compile Driver, we had high hopes to replace the proxy with an Istio wildcard routing rul and some Kubernatorial magic, but for reasons we couldn’t discern, I wasn’t able to get it to work. So we’re going with the proxy even though it’s a hack. We’re all programmers here, after all, and as you know, your kludge that works beats my elegant architecture that doesn’t. Watch this space, We’ll post a new video if…WHEN… we get the non-proxy version working. And with that, we’ll bring our discussion of the Compile Driver to a close. The image manipulation code is deployed as a serverless function that scales to zero when it’s not being used. When we need it, though, Knative fires up a pod and we can use it. We encourage you to do more exploring with Knative. Kamesh’s tutorial is a fantastic resource that’s always being improved and expanded, and watch for more serverless content here at the Red Hat Developer Program as well. We appreciate you playing along here, we hope this has been useful. We’re always expanding Coderland, so please, let us hear from you. [address [email protected] appears on screen] We look forward to your comments, suggestions, and PRs. Thanks so much for watching. For Coderland, this is Doug Tidwell saying “May all your bugs be shallow.” Cheers.


Leave a Reply

Your email address will not be published. Required fields are marked *