This is part 2 of a series on serverless applications with Knative. Part 1 is here, Part 3 is here and if you are interested in a deep dive tutorial then its here Knative Tutorial

Introduction

In the Part-1 of Knative Serving blog series, you were introduced on how to build and deploy your first serverless service using Knative Serving. In this blog you will be introduced to another Knative component called Knative Build.

What is Knative Build ?

Knative Build is a way to do an on-cluster(Kubernetes) build of container images from your source code i.e. source-to-image, the built container image can then be used in other Kubernetes resources like Knative serving service.

Why Knative Build ?

Kubernetes native (using Custom Resources Definitions) way to define a set of  reusable steps that can run on-cluster builds from application sources to produce container images. These container images are designed to be optimised in size and have better runtime performance. Knative Build is not a CI/CD solution but is designed to provide building blocks to integrate with your existing CI/CD solutions.

Components Overview

Knative Build has two main components, Build and BuildTemplate, both defined via Custom Resources Definitions(CRD):

  • Build( )

A build is a sequential set of instructions called “step”,  that defines the process of how to build your sources into a container image. Each build step will be run using another arbitrary container image called .

The of the build is usually an external data source mounted as a Kubernetes volume. Currently, the following sources are supported:

  • Git
  • Google Cloud Storage
  • An arbitrary container image

As the steps of the build are sequential, the output from the previous steps are available for the subsequent steps. In a build you can also define environment variables that can be used inside the build step, as well as pass arguments to the image; e.g. if you are running a npm based builder and the npm command needs parameters to run,  in such cases you can pass arguments builder run command using the arguments. The later part of this post covers these in much more detail.

  • BuildTemplate( )

The build steps are usually defined inline within the build spec, or they can be defined via reusable build steps called BuildTemplate.

BuildTemplates provides an option for the Build authors to define the parameters that can then be used in build steps. The parameters help Build to override or define values to the parameters in the respective Build definition.

The Build and BuildTemplate can also make use of a ServiceAccount object to define the secrets to pass the credentials—GitHub tokens, user credentials, SSH-keys—to the build steps to help make use of them where they might be needed.

Setup

In order to be able to run the demo code in this post, you will need a Minishift instance running with Knative Serving and Knative Build.

For this blog, I will be using OKD, the community distribution of Kubernetes that powers Red Hat OpenShift. To run OKD locally we can use Minishift, a single node OKD cluster that can be used for development purposes.

These instructions explain how to install and configure Knative Serving on Minishift. Once you have Knative Serving up, add the Knative Build components by following the instructions from here.

Application Overview

The demo application we will be building is a greeter application built using Spring Boot. You can find the sources of the application in the GitHub repository.

Git clone the resources using the command:

<span>git clone https://github.com/workspace7/knative-build-blogs</span>

All the sources for the examples shown in this blog are available in the directory “part-1” located in the root of the source repository, for convenience we will refer to this directory as $PROJECT_HOME in rest of this post.

The application will use Buildah to build the java application container images. Buildah allows you to build container images without the need of a Docker daemon. The images built by Buildah are OCI compliant.

Increase max user namespace

The user namespace values on RHEL 7 / Centos 7 are set to 0 by default. The value needs to be updated to enable buildah container builds to pass. For this demo we will be setting max_user_namespaces to a value of 15000.

minishift ssh

sudo -i

echo 15000 > /proc/sys/user/max_user_namespaces

Skip Tag to Digest (optional)

In the following section we will see what is a image digest,  how it is used by Kubernetes deployment and how you can skip the resolution of image to digest in Knative-serving:-

Docker images wit v2 or later format has content addressable identifier called digest. The digest remains unchanged as long the underlying image content remains unchanged.

Source: https://docs.docker.com/engine/reference/commandline/images/#list-image-digests

Let say you have a deployment like the following (note that resource definition have been trimmed for brevity):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloworld
spec:
 template:
   spec:
      containers:
- name: my-container
image:

When you deploy this application in Kubernetes, the deployment will look like:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloworld
spec:
 template:
   spec:
      containers:
- name: my-container
     image: >-
gcr.io/knative-samples/helloworld-go@
98af362ceca8191277206b3b3854220ce125924b28a1166126296982e33882d0>

 

   98af362ceca8191277206b3b3854220ce125924b28a1166126296982e33882d0.>

   

 5000>