cilium / image-tools Goto Github PK

Dockerfiles for cilium-runtime and cilium-builder dependencies

License: Other

Makefile 5.28% Dockerfile 26.58% Shell 62.09% Go 5.99% C 0.06%

image-tools's Introduction

Cilium Dependency Packaging

This repository contains build definitions for a number of images that are components of the official and development images of Cilium.

The builds are currently hosted in GitHub Actions, but can be ported to any other container-based CI system.

Portability between CI systems and ability to run locally is critical, that's why some of these images are preferred over pre-packaged GitHub Actions. Also, pre-package action often download dependencies on-the-fly, potentially increasing build times and causing flakiness. Registry is a network resource, which could be unreliable at times, however it can be mirrored easily, unlike GitHub releases. Some of the image do depend on GitHub releases or other HTTP blob storage providers, but there is no easy way around that, as the only alternative would be to build all of the dependencies from source, which is not feasible.

Images

`images/maker`

This image consists of core tools used for building all other images, which include bash, make and docker (with buildx) and crane. This image enables using latest BuildKit features without depending on whatever Docker daemon/client CI host provides. Since buildx runs a BuildKit daemon inside a container, it's largely independent of what version of Docker daemon it runs on.

This image also includes a secure credentials helper - docker-credential-env, which prevents having to use docker login which stores a plain text token in ${DOCKER_CONFIG}/config.json.

`images/compiler`

This image consists of compilers and libraries needed to build other images for amd64 and arm64.

It also includes multiple Bazel version to enable building different version of Istio and Envoy.

`images/bpftool`

This image builds bpftool binary for amd64 and arm64 using a cross-compiler. The resulting image has only one file - /bin/bpftool, it is a proper multi-platform image. The binary is dynamically linked to Ubuntu 20.04 glibc and other dependencies.

This image uses a recent version of bpftool from bpf-next Linux kernel tree.

`images/llvm`

This image builds llc and clang binaries for amd64 and arm64 using a cross-compiler. The resulting image has only two files - /bin/llc and /bin/clang, it is a proper multi-platform image. The binaries are dynamically linked to Ubuntu 20.04 glibc and other dependencies.

This image is a custom BPF-only distribution of LLVM.

`images/checkpatch`

This image packages the checkpatch.pl script used to check format and consistency for the patches submitted for inclusion to the Linux kernel, along with related files and a wrapper script.

While the script itself is directly copied from the upstream version in the kernel repository, a number of patches are applied before the script is run. These patch mostly address a number of false positives for Cilium's code base.

`images/tester`

This image contains a simple Go program, which is a minimal version of container-structure-test. It's adapted to run inside a container build context more easily than the original container-structure-tests.

Here is how testing is accomplished in the llvm image:

Usage

Making changes

All images get automatic tags based on the latest commit of the image directory. Tags used to be based on unique git tree object hash, but due to setting up renovate to automatically update images, and the inability to order sha1 values by time, the new tagging system uses a combination of the timestamp and the short sha1 of the latest commit for the image directory, using the git log command with the image directory as a path parameter.

As the result of this, following stands:

image build definitions can be obtained with git show <tag>
image build is defined by the last commit that modified the image directory
when changes are committed to image directory, new tag is generated
- if there is a new tag, image is rebuilt and pushed with that new tag

This does not cater for reproducible builds, however it serves as basis for reliable builds, especially when following rules are also applied to any build definitions:

all FROM statements use digests (use scripts/get-image-digest.sh)
any system packages are installed in a separate image that is references by a digests (that's how images/compilers is designed)
- pining system packages can be quite laborious, especially because most of the time what you want is newer than what the distribution offers, so what's much easier to let the package manager get the latest and then pin down the result by digest, so every time there is a change in underlying system packages, that is explicitly recorded by change of digest in each image that uses the base image

Be sure to use make lint, which will run shellcheck and hadolint.

For details of how this works, see the following:

Building Locally

One should be able to build images locally as long as they have Docker installed with buildx plug-in.

Updating `images/{maker,compilers}`

When you have dependencies that need to be added to these images before using them in one of the other images, e.g. if you need to add a system library in compilers image that will be used for compiling something else, you should make a PR to update compilers first. However, that's only required for full integration, and you can build images locally if you prefer, you can also push them to your own Docker Hub account or any other registry.

When changes to these images are merged into master, builds should run and push new images to each of the registries. Once new images are out, renovatebot will open a PR to update all dependent images.

image-tools's People

Contributors

Stargazers

Watchers

image-tools's Issues

consider pining all packages

informative image labels

We should consider using labels to store basic info about images.

build images on PRs

This should be doable with GitHub registry, but one major hurdle is that certain images take hours to build, like LLVM.

Unknown flag: --builder with docker buildx

I'm getting an unknown flag: --builder if I try to build an image with the latest version. I'm using the Buildx plugin included in the Docker CLI, after enabling experimental features as per the documentation.

$ docker --version
Docker version 19.03.12, build 48a66213fe
$ PUSH=true REGISTRIES=docker.io/pchaigno make llvm-image 
PUSH=true EXPORT=false TEST=true scripts/build-image.sh cilium-llvm images/llvm linux/amd64 "$(cat .buildx_builder)" docker.io/pchaigno
will build cilium-llvm:76897177401ee8c204b160bfb154bcc67409b885-wip as it has wip suffix
building cilium-llvm:76897177401ee8c204b160bfb154bcc67409b885-wip
+ run_buildx
+ build_args=("--platform=${platform}" "--builder=${builder}" "--file=${image_dir}/Dockerfile")
+ '[' false = false ']'
+ build_args+=("${image_dir}")
+ '[' true = true ']'
+ docker buildx build --target=test --platform=linux/amd64 --builder= --file=images/llvm/Dockerfile images/llvm
unknown flag: --builder
See 'docker buildx build --help'.
+ exit 1
make: *** [Makefile:53: llvm-image] Error 1

If I remove that flag as follows, everything works fine.

diff --git a/scripts/build-image.sh b/scripts/build-image.sh
index 0504afa..fa16228 100755
--- a/scripts/build-image.sh
+++ b/scripts/build-image.sh
@@ -114,7 +114,6 @@ do_test="${TEST:-false}"
 run_buildx() {
   build_args=(
     "--platform=${platform}"
-    "--builder=${builder}"
     "--file=${image_dir}/Dockerfile"
   )
   if [ "${with_root_context}" = "false" ] ; then

Should I be using a different Docker version?

rename repo to image-tools

@aanm as we discussed earlier, could you please rename this repo?

Bug: renovate is unable to track image updates (unsupported/unversioned value)

Renovate is unable to track image updates. The startup-script image uses sha256 digests that seem unsupported. Versioning needs to be amended for renovate to take care of automatic updates.

Details

Mar 26th: Image update scripts were replaced by renovate

Note the intention to switch to pinned digests
Note tracking package names (line 102 of renovate.json5)

Mar 26th: Alpine image needed manual update
June 26th: Alpine image needed manual update
nodeinit image also needed manual update in cilium/cilium repo

When running LOG_LEVEL=debug renovate --platform=local on a local copy of the repository,

DEBUG: Dependency quay.io/cilium/image-compilers has unsupported/unversioned value 5569a29cea6b3ad50aeb03102aaf3dc03841197c (versioning=docker) (repository=local)
DEBUG: Dependency quay.io/cilium/image-tester has unsupported/unversioned value dd09c8d3ef349a909fbcdc99279516baef153f22 (versioning=docker) (repository=local)
DEBUG: Dependency quay.io/cilium/image-tester has unsupported/unversioned value dd09c8d3ef349a909fbcdc99279516baef153f22 (versioning=docker) (repository=local)
DEBUG: Dependency quay.io/cilium/image-compilers has unsupported/unversioned value 5569a29cea6b3ad50aeb03102aaf3dc03841197c (versioning=docker) (repository=local)
DEBUG: Dependency quay.io/cilium/image-tester has unsupported/unversioned value dd09c8d3ef349a909fbcdc99279516baef153f22 (versioning=docker) (repository=local)
DEBUG: Dependency gcr.io/go-containerregistry/crane has unsupported/unversioned value latest (versioning=docker) (repository=local)

Note: the repetition of debug messages is because multiple Dockerfiles contain the same images (e.g. images bpftool, compilers and llvm).

According to the docker versioning documentation for renovate,

Are commit hashes supported?
No, Renovate ignores Docker image tags that look like a Git commit hash.

References

Failed to pull images for linux/arm/v7

I am having the below issue, not sure if it is or will be supported.

Thanks

  Normal   Scheduled  <unknown>            default-scheduler  Successfully assigned kube-system/cilium-node-init-v9f9m to ubuntu4g
  Normal   Pulling    16s (x3 over 2m25s)  kubelet, ubuntu4g  Pulling image "docker.io/cilium/startup-script:af2a99046eca96c0138551393b21a5c044c7fe79"
  Warning  Failed     12s (x3 over 57s)    kubelet, ubuntu4g  Failed to pull image "docker.io/cilium/startup-script:af2a99046eca96c0138551393b21a5c044c7fe79": rpc error: code = Unknown desc = no matching manifest for linux/arm/v7 in the manifest list entries
  Warning  Failed     12s (x3 over 57s)    kubelet, ubuntu4g  Error: ErrImagePull
  Normal   BackOff    1s (x3 over 56s)     kubelet, ubuntu4g  Back-off pulling image "docker.io/cilium/startup-script:af2a99046eca96c0138551393b21a5c044c7fe79"

image testing

Validate binaries path, architecture, versions etc. We could use https://github.com/GoogleContainerTools/container-structure-test for this.

Add bazel to compilers image

So that it can be used to cross-compile Envoy.

push to quay.io as well as docker.io

turn `build-image.sh` into a high-level tool

Use-cases:

There are many ways of building a Docker image, it would be beneficial to Cilium project to provide consistent and reliable method for building image on release as well as for testing, this method should cater for multi-platform builds as well.

Building an image involves a series of base images, it's desirable to reference the by digest for maximum reproducibility. Digests are hard to manage manually, furthermore - digests are simply not human friendly. It would be very helpful to have a human friendly source for mapping digests to sources in git and general information like the build date and description of key facts about images (e.g. software versions).

Requirements:

make it usable in Cilium repo
ensure it serves a human-friendly layer on top of automatic git-based tags and image digests
make sure it easy to use and very simple to maintain

include core shared libraries in all images

At the moment output binaries are included and core shared libraries (e.g. ld-linux-x86-64.so.2, libc.so.6, etc) are expected to be present in downstream image. It would be helpful if any of the images could be used in stand-alone fashion, at very least in order to enable validation.

validate build logic on PR

Right now there is a shellcheck and hadolint, but still plenty of room for bugs. It would be nice to enable quick end-to-end validation without building all the images. Perhaps it would be easier to accomplish as part of Go rewrite (#10).

missing iproute2 build dockerfile

I want build cilium 1.12.7 image by myself, but I can't found iproute2 dockerfile.

image signing

It would help to sign our images to protect the supply chain.

lookup commit ID based on tree hash

We need to find a way of finding which commit hash a given tree hash belongs to.

automate updating `FROM` statements with new digests

Right now we have make update-compilers-images, for example. This works inside this repo, but wouldn't be easily portable to e.g. Cilium repo. It's also manual right now, making it automatic would minimise level of human interaction needed.

use full image names

Instead of ubuntu, alpine and golang, full names should be used, namely docker.io/library/{ubuntu,golang,alpine}.

test out GitHub registry

It would be nice if PR from external contributors pushed images to contributor's own registry, that way we could avoid having to enable external contributors to push to a shared registry somehow. Seems like GitHub registry should allow this use-case.

Arm64: clang error - unable to create target: No available targets are compatible with triple "bpf"

root@9f9ac1aba371:/cni# clang -O2 -target bpf -c xdp.c -o xdp.o
error: unable to create target: 'No available targets are compatible with triple "bpf"'
1 error generated.
root@9f9ac1aba371:/cni# cat xdp.c
int main()
{
   return 0;
}

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Rate-Limited

These updates are currently rate-limited. Click on a checkbox below to force their creation now.

chore(deps): update docker.io/library/ubuntu:24.04 docker digest to 8a37d68

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

Detected dependencies

dockerfile

images/bpftool/Dockerfile

docker/dockerfile 1.1-experimental

quay.io/cilium/image-compilers 5569a29cea6b3ad50aeb03102aaf3dc03841197c@sha256:b15dbedb7c49816c74a765e2f6ecdb9359763b8e4e4328d794f48b9cefae9804

docker.io/library/ubuntu 24.04@sha256:2e863c44b718727c860746568e1d54afd13b2fa71b160f5cd9058fc436217b30

quay.io/cilium/image-tester dd09c8d3ef349a909fbcdc99279516baef153f22@sha256:c056d064cb47c97acd607343db5457e1d49d9338d6d8a87e93e23cc93f052c73

images/ca-certificates/Dockerfile

docker.io/library/alpine 3.20.1@sha256:b89d9c93e9ed3597455c90a0b88a8bbb5cb7188438f70953fede212a0c4394e0

images/checkpatch/Dockerfile

docker/dockerfile 1.1-experimental

docker.io/library/alpine 3.20.1@sha256:b89d9c93e9ed3597455c90a0b88a8bbb5cb7188438f70953fede212a0c4394e0

images/compilers/Dockerfile

docker.io/library/ubuntu 24.04@sha256:2e863c44b718727c860746568e1d54afd13b2fa71b160f5cd9058fc436217b30

quay.io/cilium/image-tester dd09c8d3ef349a909fbcdc99279516baef153f22@sha256:c056d064cb47c97acd607343db5457e1d49d9338d6d8a87e93e23cc93f052c73

images/iptables/Dockerfile

docker.io/library/ubuntu 24.04@sha256:2e863c44b718727c860746568e1d54afd13b2fa71b160f5cd9058fc436217b30

images/llvm/Dockerfile

quay.io/cilium/image-compilers 5569a29cea6b3ad50aeb03102aaf3dc03841197c@sha256:b15dbedb7c49816c74a765e2f6ecdb9359763b8e4e4328d794f48b9cefae9804

docker.io/library/ubuntu 24.04@sha256:2e863c44b718727c860746568e1d54afd13b2fa71b160f5cd9058fc436217b30

quay.io/cilium/image-tester dd09c8d3ef349a909fbcdc99279516baef153f22@sha256:c056d064cb47c97acd607343db5457e1d49d9338d6d8a87e93e23cc93f052c73

images/maker/Dockerfile

docker/dockerfile 1.1-experimental

docker.io/library/docker 26.0.0-dind@sha256:016c45d9e31461802186e8e9aaa394f35e173a8ce913ea7195a672cdc97102f2

gcr.io/go-containerregistry/crane latest@sha256:30621571a135ddef3f371b3efd000cd76c13f81cb9d5513d105e024dcb30a352

docker.io/library/golang 1.22.1@sha256:0b55ab82ac2a54a6f8f85ec8b943b9e470c39e32c109b766bbc1b801f3fa8d3b

docker.io/library/alpine 3.20.1@sha256:b89d9c93e9ed3597455c90a0b88a8bbb5cb7188438f70953fede212a0c4394e0

images/network-perf/Dockerfile

registry.access.redhat.com/ubi8/ubi undefined

images/startup-script/Dockerfile

docker.io/library/alpine 3.20.1@sha256:b89d9c93e9ed3597455c90a0b88a8bbb5cb7188438f70953fede212a0c4394e0

docker.io/library/alpine 3.20.1@sha256:b89d9c93e9ed3597455c90a0b88a8bbb5cb7188438f70953fede212a0c4394e0

images/tester/Dockerfile

docker/dockerfile 1.1-experimental

docker.io/library/golang 1.22.1@sha256:0b55ab82ac2a54a6f8f85ec8b943b9e470c39e32c109b766bbc1b801f3fa8d3b

docker.io/library/alpine 3.20.1@sha256:b89d9c93e9ed3597455c90a0b88a8bbb5cb7188438f70953fede212a0c4394e0

github-actions

.github/workflows/images.yaml

actions/checkout v4.1.1@b4ffde65f46336ab88eb53be808477a3936bae11

.github/workflows/pr-checks.yaml

actions/checkout v4.1.1@b4ffde65f46336ab88eb53be808477a3936bae11

ubuntu 22.04

gomod

images/tester/cst/go.mod

go 1.22

github.com/GoogleContainerTools/container-structure-test v1.17.0

Check this box to trigger a request for Renovate to run again on this repository

consider using cache

buildx offers advanced cache export/import options, we could use those and save cache either in the registry or in GitHub Actions.

use buildx bake

Before rewriting the shell wrappers in Go (#10), we should switch to buildx bake, which has a more high-level interface.

Some relevant docs here: