Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multi-platform support #711

Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion .github/workflows/nightly.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -29,7 +29,7 @@ jobs:
- name: Install Ko
run: |
echo '::group:: install ko'
curl -L https://github.com/google/ko/releases/download/v0.8.0/ko_0.8.0_Linux_x86_64.tar.gz | tar xzf - ko
curl -L https://github.com/google/ko/releases/download/v0.8.1/ko_0.8.1_Linux_x86_64.tar.gz | tar xzf - ko
chmod +x ./ko
sudo mv ko /usr/local/bin
echo '::endgroup::'
Expand Down
2 changes: 1 addition & 1 deletion .github/workflows/release.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -46,7 +46,7 @@ jobs:
- name: Install Ko
run: |
echo '::group:: install ko'
curl -L https://github.com/google/ko/releases/download/v0.8.0/ko_0.8.0_Linux_x86_64.tar.gz | tar xzf - ko
curl -L https://github.com/google/ko/releases/download/v0.8.1/ko_0.8.1_Linux_x86_64.tar.gz | tar xzf - ko
chmod +x ./ko
sudo mv ko /usr/local/bin
echo '::endgroup::'
Expand Down
9 changes: 5 additions & 4 deletions Makefile
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,8 @@ CONTROLLER = $(OUTPUT_DIR)/bin/shipwright-build-controller
# golang cache directory path
GOCACHE ?= $(shell echo ${PWD})/$(OUTPUT_DIR)/gocache
# golang target architecture
GOARCH ?= amd64
GO_OS ?= $(shell uname | tr '[:upper:]' '[:lower:]')
GO_ARCH ?= $(shell uname -m | sed -e 's/x86_64/amd64/' -e 's/aarch64/arm64/')
# golang global flags
GO_FLAGS ?= -v -mod=vendor -ldflags=-w

Expand Down Expand Up @@ -232,18 +233,18 @@ test-e2e-kind-with-prereq-install: ginkgo install-controller-kind install-strate
.PHONY: install install-apis install-controller install-strategies

install:
KO_DOCKER_REPO="$(IMAGE_HOST)/$(IMAGE)" GOFLAGS="$(GO_FLAGS)" ko apply --bare -R -f deploy/
GOOS=$(GO_OS) GOARCH=$(GO_ARCH) KO_DOCKER_REPO="$(IMAGE_HOST)/$(IMAGE)" GOFLAGS="$(GO_FLAGS)" ko apply --bare -R -f deploy/

install-with-pprof:
GOFLAGS="$(GO_FLAGS) -tags=pprof_enabled" ko apply -R -f deploy/
GOOS=$(GO_OS) GOARCH=$(GO_ARCH) GOFLAGS="$(GO_FLAGS) -tags=pprof_enabled" ko apply -R -f deploy/

install-apis:
kubectl apply -f deploy/crds/
# Wait for the CRD type to be established; this can take a second or two.
kubectl wait --timeout=10s --for condition=established crd/clusterbuildstrategies.shipwright.io

install-controller: install-apis
KO_DOCKER_REPO="$(IMAGE_HOST)/$(IMAGE)" GOFLAGS="$(GO_FLAGS)" ko apply --bare -f deploy/
GOOS=$(GO_OS) GOARCH=$(GO_ARCH) KO_DOCKER_REPO="$(IMAGE_HOST)/$(IMAGE)" GOFLAGS="$(GO_FLAGS)" ko apply --bare -f deploy/

install-controller-kind: install-apis
KO_DOCKER_REPO=kind.local GOFLAGS="$(GO_FLAGS)" ko apply -f deploy/
Expand Down
13 changes: 13 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -146,6 +146,19 @@ To find out more on what's the best strategy or what else can Shipwright do for
| [Kubernetes](https://kubernetes.io/) | v1.17.\*, v1.18.\*, v1.19.\* |
| [Tekton](https://tekton.dev) | v0.19.0, v0.20.\*, v0.21.0 |

### Platform support

We are building container images of the Shipwright Build controller for all platforms supported by the base image that we are using which is [registry.access.redhat.com/ubi8/ubi-minimal](https://catalog.redhat.com/software/containers/ubi8/ubi-minimal/5c359a62bed8bd75a2c3fba8). Those are:

- linux/amd64
- linux/arm64
- linux/ppc64le
- linux/s390x

All these platforms are also supported by our Tekton Pipelines dependency. Our own tests as part of our CI pipeline are all only running on and testing the linux/amd64 platform.

Our sample build strategies are all functional on linux/amd64. Their support on other platforms relies on the tools being used there to be available for other platforms. For detailed information, please see [Available ClusterBuildStrategies](docs/buildstrategies.md#available-clusterbuildstrategies).

## Want to get involved?

### Community meetings
Expand Down
27 changes: 17 additions & 10 deletions docs/buildstrategies.md
Original file line number Diff line number Diff line change
Expand Up @@ -13,7 +13,6 @@ SPDX-License-Identifier: Apache-2.0
- [Installing Buildah Strategy](#installing-buildah-strategy)
- [Buildpacks v3](#buildpacks-v3)
- [Installing Buildpacks v3 Strategy](#installing-buildpacks-v3-strategy)
- [Try it](#try-it)
- [Kaniko](#kaniko)
- [Installing Kaniko Strategy](#installing-kaniko-strategy)
- [BuildKit](#buildkit)
Expand All @@ -39,26 +38,32 @@ A `ClusterBuildStrategy` is available cluster-wide, while a `BuildStrategy` is a

## Available ClusterBuildStrategies

Well-known strategies can be boostrapped from [here](../samples/buildstrategy). The current supported Cluster BuildStrategy are:
Well-known strategies can be bootstrapped from [here](../samples/buildstrategy). The currently supported Cluster BuildStrategy are:

- [buildah](../samples/buildstrategy/buildah/buildstrategy_buildah_cr.yaml)
- [buildpacks-v3-heroku](../samples/buildstrategy/buildpacks-v3/buildstrategy_buildpacks-v3-heroku_cr.yaml)
- [buildpacks-v3](../samples/buildstrategy/buildpacks-v3/buildstrategy_buildpacks-v3_cr.yaml)
- [kaniko](../samples/buildstrategy/kaniko/buildstrategy_kaniko_cr.yaml)
- [source-to-image](../samples/buildstrategy/source-to-image/buildstrategy_source-to-image_cr.yaml)
| Name | Supported platforms |
| ---- | ------------------- |
| [buildah](../samples/buildstrategy/buildah/buildstrategy_buildah_cr.yaml) | linux/amd64 only |
| [BuildKit](../samples/buildstrategy/buildkit/buildstrategy_buildkit_cr.yaml) | all |
| [buildpacks-v3-heroku](../samples/buildstrategy/buildpacks-v3/buildstrategy_buildpacks-v3-heroku_cr.yaml) | linux/amd64 only |
| [buildpacks-v3](../samples/buildstrategy/buildpacks-v3/buildstrategy_buildpacks-v3_cr.yaml) | linux/amd64 only |
| [kaniko](../samples/buildstrategy/kaniko/buildstrategy_kaniko_cr.yaml) | all |
| [ko](../samples/buildstrategy/ko/buildstrategy_ko_cr.yaml) | all |
| [source-to-image](../samples/buildstrategy/source-to-image/buildstrategy_source-to-image_cr.yaml) | linux/amd64 only |

## Available BuildStrategies

The current supported namespaces BuildStrategy are:

- [buildpacks-v3-heroku](../samples/buildstrategy/buildpacks-v3/buildstrategy_buildpacks-v3-heroku_namespaced_cr.yaml)
- [buildpacks-v3](../samples/buildstrategy/buildpacks-v3/buildstrategy_buildpacks-v3_namespaced_cr.yaml)
| Name | Supported platforms |
| ---- | ------------------- |
| [buildpacks-v3-heroku](../samples/buildstrategy/buildpacks-v3/buildstrategy_buildpacks-v3-heroku_namespaced_cr.yaml) | linux/amd64 only |
| [buildpacks-v3](../samples/buildstrategy/buildpacks-v3/buildstrategy_buildpacks-v3_namespaced_cr.yaml) | linux/amd64 only |

---

## Buildah

The `buildah` ClusterBuildStrategy consists of using [`buildah`](https://github.com/containers/buildah) to build and push a container image, out of a `Dockerfile`. The `Dockerfile` should be specified on the `Build` resource. Also, instead of the `spec.dockerfile`, the `spec.builderImage` can be used with `quay.io/buildah/stable` as the value when defining the `Build` resource.
The `buildah` ClusterBuildStrategy consists of using [`buildah`](https://github.com/containers/buildah) to build and push a container image, out of a `Dockerfile`. The `Dockerfile` should be specified on the `Build` resource.

### Installing Buildah Strategy

Expand Down Expand Up @@ -152,6 +157,8 @@ kubectl apply -f samples/buildstrategy/ko/buildstrategy_ko_cr.yaml

**Note**: The build strategy currently uses the `spec.contextDir` of the Build in a different way than this property is designed for: the Git repository must be a Go module with the go.mod file at the root. The `contextDir` specifies the path to the main package. You can check the [example](../samples/build/build_ko_cr.yaml) which is set up to build the Shipwright Build controller. This behavior will eventually be corrected once [Exhaustive list of generalized Build API/CRD attributes #184](https://github.com/shipwright-io/build/issues/184) / [Custom attributes from the Build CR could be used as parameters while defining a BuildStrategy #537](https://github.com/shipwright-io/build/issues/537) are done.

**Note**: The build strategy is setup to build for the platform that your Kubernetes cluster is running. Exposing the platform configuration to the Build requires the same features mentioned on the previous note.

## Source to Image

This BuildStrategy is composed by [`source-to-image`][s2i] and [`kaniko`][kaniko] in order to generate a `Dockerfile` and prepare the application to be built later on with a builder.
Expand Down
4 changes: 2 additions & 2 deletions hack/release.sh
Original file line number Diff line number Diff line change
Expand Up @@ -13,5 +13,5 @@ echo "Building container image"

# Using defaults, this pushes to:
# quay.io/shipwright/shipwright-build-controller:latest
KO_DOCKER_REPO="$IMAGE_HOST/$IMAGE" GOFLAGS="${GO_FLAGS}" ko resolve -t "$TAG" --bare -R -f deploy/ > release.yaml
KO_DOCKER_REPO="$IMAGE_HOST/$IMAGE" GOFLAGS="${GO_FLAGS} -tags=pprof_enabled" ko resolve -t "$TAG-debug" --bare -R -f deploy/ > release-debug.yaml
KO_DOCKER_REPO="$IMAGE_HOST/$IMAGE" GOFLAGS="${GO_FLAGS}" ko resolve -t "$TAG" --bare --platform=all -R -f deploy/ > release.yaml
KO_DOCKER_REPO="$IMAGE_HOST/$IMAGE" GOFLAGS="${GO_FLAGS} -tags=pprof_enabled" ko resolve -t "$TAG-debug" --bare --platform=all -R -f deploy/ > release-debug.yaml
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For reference - ko inspects the manifest list of the base image, and then does a golang build for each platform in the manifest [1]. I assume this also means ko resolve will push a manifest list.

[1] https://github.com/google/ko#multi-platform-images

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

14 changes: 11 additions & 3 deletions samples/buildstrategy/ko/buildstrategy_ko_cr.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -72,14 +72,22 @@ spec:

# Download ko
pushd /tmp > /dev/null
curl -f -s -L https://github.com/google/ko/releases/download/v0.8.1/ko_0.8.1_Linux_x86_64.tar.gz | tar xzf - ko
curl -f -s -L https://github.com/google/ko/releases/download/v0.8.1/ko_0.8.1_$(uname)_$(uname -m | sed 's/aarch64/arm64/').tar.gz | tar xzf - ko
popd > /dev/null

# Run ko

# Select the platform to build based on the architecture that the cluster runs.
# Once there is parameter support in Shipwright, we should expose this setting there.
PLATFORM="$(uname | tr '[:upper:]' '[:lower:]')/$(uname -m | sed -e 's/x86_64/amd64/' -e 's/aarch64/arm64/')"

export GOROOT=$(go env GOROOT)
export KO_DOCKER_REPO="${REPO}"

if [ "${TAG}" == "" ]; then
GOROOT=$(go env GOROOT) KO_DOCKER_REPO="${REPO}" /tmp/ko publish "./$(build.source.contextDir)" --bare --oci-layout-path=/workspace/output/image
/tmp/ko publish "./$(build.source.contextDir)" --bare --oci-layout-path=/workspace/output/image --platform="${PLATFORM}"
else
GOROOT=$(go env GOROOT) KO_DOCKER_REPO="${REPO}" /tmp/ko publish "./$(build.source.contextDir)" --bare --oci-layout-path=/workspace/output/image --tags="${TAG}"
/tmp/ko publish "./$(build.source.contextDir)" --bare --oci-layout-path=/workspace/output/image --platform="${PLATFORM}" --tags="${TAG}"
fi
resources:
limits:
Expand Down