15. Source-to-Image Workflow¶

15.1. Context and Problem Statement¶

We want to have a Source-to-Image workflow to import services based on a GitHub repository. It should run inside our Kubernetes cluster, however currently Kubernetes doesn’t have a resource build-in that is able to build container images. Therefore another technology is required.

15.2. Decision Drivers¶

MUST run on our Kubernetes cluster
MUST run completely in userspace (no root access required)
MUST be sufficient to provide a single URL to a GitHub repository (with included Dockerfile)
SHOULD be independent of any cloud service provider

15.3. Considered Options¶

Gitkube
Google Cloud Build
Azure Container Registry Tasks (ACR Tasks)
OpenShift Source-to-Image (S2I)
Knative Build

15.4. Decision Outcome¶

Chosen option: Knative Build, because it meets all of our criterion decision drivers. It allows us to implement a Source-to-Image workflow on our Kubernetes cluster independently to any cloud service provider.

15.4.1. Positive Consequences¶

By using Knative Build we have the choice to use different kinds of Builders, follow-up decision is required: Building OCI images

15.4.2. Negative consequences¶

Nothing known

15.5. Pros and Cons of the Options¶

15.5.1. Gitkube¶

GitHub: Gitkube

Good, because it is easy to use (only git and kubectl are required)
Good, because it is designed to build and deploy images to Kubernetes
Bad, because it uses Docker-in-Docker approach (see Building OCI Images)
Bad, because it is build for a different purpose: Helping developers to trigger the build and deployment of an image by using git push

15.5.2. Google Cloud Build¶

Cloud Build documentation

Good, because it is easy to use, nothing has to be installed (only a call to the Cloud Build API is required)
Good, because it is a managed service therefore it doesn’t consume our own resources
Good, because it allows us to use different Builder technologies (see Building OCI Images)
Bad, because we depend on the continuity of a third-party service (Google Cloud Build)
Bad, because it runs only on Google Cloud, that forces vendor lock-in
Bad, because it leads to additional costs (first 120 builds-minutes per day are free, see Pricing

15.5.3. Azure Container Registry Tasks (ACR Tasks)¶

Tutorial: Automate container image builds with Azure Container Registry Tasks

Good, because it is a managed service therefore it doesn’t consume our own resources
Good, because we already run on the Azure Cloud
Bad, because it uses the Docker daemon internally, no other Builders can be used (see Building OCI Images)
Bad, because there is no public API available, only usable with the Azure CLI
Bad, because we depend on the continuity of a third-party service (ACR Tasks)
Bad, because it runs only on Azure, that forces vendor lock-in
Bad, because it leads to additional costs (100 minutes are included for free per month, see Pricing calculator

15.5.4. OpenShift Source-to-Image (S2I)¶

GitHub: Source-To-Image (S2I)

Good, because it is the way to go for creating a Source-to-Image workflow on a OpenShift cluster
Bad, because it is designed for the OpenShift Container Platform (additional effort is required to use it on plain Kubernetes)
Bad, because it uses the Docker daemon internally (in future Buildah), no other Builders can be used (see Building OCI Images)

15.5.5. Knative Build¶

GitHub: Knative Build

Good, because it has the backing of industry giants (Google, Red Hat, IBM, SAP)
Good, because it is designed for Kubernetes
Good, because it provides a standard, portable, reusable, and performance optimized method for defining and running on-cluster container image builds
Good, because it allows us to use different Builder technologies (see Building OCI Images)
Good, because Knative Build consumes little resources (2 pods a ~11 MB).
Bad, because it is still work-in-progress