What is Shipwright? Which problems does this project try to solve?
In Part 1 of this series, we looked back at the history of delivering software applications, and how that has changed in the age of Kubernetes and cloud-native development.
In this post, we’ll introduce Shipwright and the Build APIs that make it simple to build container images on Kubernetes.
Recall in Part 1, developers who moved from VM-based deployments to Kubernetes needed to shift their unit of delivery from binaries to container images. Teams adopted various tools to accomplish this task, ranging from Docker/Moby to Cloud-Native Buildpacks. New cloud-native applications like Jenkins-X and Tekton have emerged to deliver these container images on Kubernetes. Jenkins - the predecessor to Jenkins-X - has continued to play a prominent role in automating the building and testing of applications.
Building a container image on Kubernetes is not a simple feat. There are a wide variety of tools available, some which require knowledge on how to write a Dockerfile, others which do not or are tailored for specific programming languages. For CI/CD platforms like Tekton, setting up a build pipeline requires extensive configuration and customization. These are burdens that are difficult to overcome for many development teams.
With Shipwright, we want to create an open and flexible framework that allows teams to easily build container images on Kubernetes. Much of the work has been inspired by OpenShift/okd, which provides its own API for building images. At the heart of every build are the following core components:
Developers who use docker are familiar with this process:
$ docker build -t registry.mycompany.com/myorg/myapp:latest .
$ docker push registry.mycompany.com/myorg/myapp:latest
The Build API consists of four core Custom Resource Definitions (CRDs):
BuildStrategy
and ClusterBuildStrategy
- defines how to build an application for an image
building tool.Build
- defines what to build, and where the application should be delivered.BuildRun
- invokes the build, telling the Kubernetes cluster when to build your application.BuildStrategy
and ClusterBuildStrategy
are related APIs to define how a given tool should be
used to assemble an application. They are distinguished by their scope - BuildStrategy
objects
are namespace scoped, whereas ClusterBuildStrategy
objects are cluster scoped.
The spec consists of a buildSteps
object, which look and feel like Kubernetes Container
specifications. Below is an example spec for Kaniko, which can build an image from a
Dockerfile within a container:
spec:
buildSteps:
- name: build-and-push
image: gcr.io/kaniko-project/executor:v1.3.0
workingDir: /workspace/source
securityContext:
runAsUser: 0
capabilities:
add:
- CHOWN
- DAC_OVERRIDE
- FOWNER
- SETGID
- SETUID
- SETFCAP
env:
- name: DOCKER_CONFIG
value: /tekton/home/.docker
command:
- /kaniko/executor
args:
- --skip-tls-verify=true
- --dockerfile=$(build.dockerfile)
- --context=/workspace/source/$(build.source.contextDir)
- --destination=$(build.output.image)
- --oci-layout-path=/workspace/output/image
- --snapshotMode=redo
resources:
limits:
cpu: 500m
memory: 1Gi
requests:
cpu: 250m
memory: 65Mi
The Build
object provides a playbook on how to assemble your specific application. The simplest
build consists of a git source, a build strategy, and an output image:
apiVersion: build.dev/v1alpha1
kind: Build
metadata:
name: kaniko-golang-build
annotations:
build.build.dev/build-run-deletion: "true"
spec:
source:
url: https://github.com/sbose78/taxi
strategy:
name: kaniko
kind: ClusterBuildStrategy
output:
image: registry.mycompany.com/my-org/taxi-app:latest
Builds can be extended to push to private registries, use a different Dockerfile, and more. Read the docs for a deeper dive on what is possible.
Each BuildRun
object invokes a build on your cluster. You can think of these as a Kubernetes
Jobs
or Tekton TaskRuns
- they represent a workload on your cluster, ultimately resulting in a
running Pod
.
A BuildRun
invocation can be very simple and concise:
apiVersion: build.dev/v1alpha1
kind: BuildRun
metadata:
name: kaniko-golang-buildrun
spec:
buildRef:
name: kaniko-golang-build
As the build runs, the status of the BuildRun
object is updated with the current progress. Work
is in progress to standardize this status reporting with status conditions.
You may have noticed that the Kaniko build strategy above references two directories in the build step:
/tekton/home
/workspace
Where do these directories come from? Shipwright is built on top of Tekton,
taking advantage of its features to simpify CI/CD workloads. Among the things that Tekton provides
is a Linux user $HOME
directory (/tekton/home
) and a workspace where the application can be
assembled (/workspace
).
Shipwright can be installed in one of two ways:
If your cluster has Operator Lifecycle Manager installed, option 2 is the recommened approach. OLM will take care of installing Tekton as well as Shipwright.
The samples contain build strategies for container-based image build tools like Kaniko, Buildah, Source-to-Image and Cloud-Native Buildpacks.