Go is an increasingly popular programming language, and frequently chosen for developing command-line utilities. Many tools used with Kubernetes and Red Hat OpenShift are written in Go, including the command-line interfaces (CLIs) for Tekton (tkn
), OpenShift (oc
), and Kubernetes (kubectl
). Also, developers can compile Go to a single executable for a broad range of operating systems. As a result, it's easy to develop and desk-test applications before putting them into containers and running those containers in OpenShift.
In a meta sort of way, this is an article about a tutorial, where I show you how to build and deliver a small Go RESTful service using OpenShift Pipelines. You could just jump to the tutorial now, but I suggest reading this article first. I'll quickly introduce the working environment for the tutorial, and I'll explain my logic for setting up the tutorial the way that I did.
What's included in the OpenShift Pipelines Workshop tutorial
The OpenShift Pipelines Workshop tutorial includes two GitHub repositories. One repository contains the tutorial and two YAML files that you will use for the example application. The other repository contains the Go service that you will build. The tutorial also references the OpenShift Pipelines Catalog, an open source library of reusable pipeline assets. This catalog is an excellent example of the open source world and how it produces valuable community-wide solutions.
In the tutorial repository, you'll find two YAML files: qotd-pipeline.yaml
and sub.yaml
. The sub
file creates the OpenShift Pipelines Operator, while qotd-pipeline
defines the pipeline to be used.
In the source code repository, you'll find the Go code for the service. You'll find a Dockerfile that you can use to create an image. You will also find three YAML files in the /k8s
directory. Those files define the DeploymentConfig
, Service
, and Route
that you will create. Keeping those artifacts in the same repo as the source code makes sense, and it puts all the related pieces in one, easily accessible spot.
The build environment
OpenShift Pipelines relies on Tekton, which is Knative's container-based build component. Tekton uses tasks to get work done, such as building the Linux Open Container Initiative (OCI)-compliant image. In this case, I call the image "OCI-compliant" because we don't use the docker
command to build anything. Instead, we'll use the open source buildah
system. The buildah
task is contained in the aforementioned OpenShift Pipelines Catalog and is included when you install the OpenShift Pipelines Operator. This is one of several cluster-wide tasks we'll use for this project. You can see a list of all the tasks by running tkn clustertask ls
.
About OCI: Open Container Initiative (OCI) is an open governance structure for creating open industry standards around container formats and runtimes. OCI says, "build an image according to these standards, and it'll run as promised."
What's great about buildah
buildah
puts you in control of what gets built and how it's built. As an example, I have a Dockerfile in my source code, and I can use that to build and desk-test code on my local machine, regardless of the operating system I am using. When I move everything to OpenShift and use the pipeline, I can use the same Dockerfile to perform the build. I can rest assured (no pun intended) that the created executable and image will match what's on my machine. No more, "but it worked on my machine." Using buildah
, I can deploy my code at 4:59 p.m. Friday and go home without another worry. (I added that last sentence just to get the folks in Operations riled up.)
Conclusion
This quick article has been an introduction to my longer tutorial. Now you know where to find the components you need and why I put them there. It's time to head over to the GitHub workshop and get started with the tutorial!
Last updated: June 26, 2020