Shipwright is an extensible framework for building container images on Kubernetes.
Shipwright supports popular tools such as Kaniko, Cloud Native Buildpacks, Buildah, and more!
Shipwright is based around four elements for each build:
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
Shipwright’s Build API consists of four core CustomResourceDefinitions (CRDs):
Build- defines what to build, and where the application should be delivered.
ClusterBuildStrategy- defines how to build an application for an image building tool.
BuildRun- invokes the build. You create a
BuildRunto tell Shipwright to start building your application.
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.
ClusterBuildStrategy are related APIs to define how a given tool should be
used to assemble an application. They are distinguished by their scope -
are namespace scoped, whereas
ClusterBuildStrategy objects are cluster scoped.
The spec of a
ClusterBuildStrategy 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:
# this is a fragment of a manifest 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
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
BuildRun for more details.