Building Container Images the Modern Way - Adrian Mouat, Chainguard

Рет қаралды 24,776

CNCF [Cloud Native Computing Foundation]

Күн бұрын

Don't miss out! Join us at our next Flagship Conference: KubeCon + CloudNativeCon North America in Salt Lake City from November 12 - 15, 2024. Connect with our current graduated, incubating, and sandbox projects as the community gathers to further the education and advancement of cloud native computing. Learn more at kubecon.io
Building Container Images the Modern Way - Adrian Mouat, Chainguard
Are you still building images like it's 2015? This talk will get you up-to-speed with modern build technology and techniques and building images in seconds rather than minutes. This can make an enormous difference in CI/CD where a small improvement can reduce costs and speed up delivery. We'll start by taking a look at what an OCI container image is, before delving into the different options for assembling them. After understanding why things are the way they are, we'll dive into some of the options for achieving vastly faster build times and smaller images. We'll also look at supply chain concerns such as SLSA, SBOMs and attestations. We'll explore buildkit, buildpacks, Dagger, ko, Apko, Rockcraft and Nix amongst other technologies. Come along and learn how to move beyond the plain Dockerfile!

Пікірлер: 16

@joebowbeer 7 ай бұрын

02:51 Image Builder Goals 05:32 Distroless Multistage Docker Build 08:08 KO (golang) 13:31 Bazel (summary) 17:13 Apko (summary) 18:33 Canonical Chiselled Containers 21:26 Buildpacks 24:18 Buildkit and Dagger 28:42 Nix 30:47 OK, So What Do You Recommend?

@jpetazzo 8 ай бұрын

That's a great review! A couple of additional comments/ideas on that topic: - Bazel is incredibly complex, and I've been told multiple times (by folks using it) that maintaining a non-trivial Bazel build could easily require a full time expert, and that it would be very difficult to turn it into a self-service thing (i.e. even small trivial changes often require the intervention of the expert). As a datapoint, Kubernetes itself used to be built with Bazel, but the Bazel build infrastructure was removed because the Kubernetes maintainers couldn't maintain it anymore. - the good old "docker build" actually uses newer BuildKit features. For instance, stuff like "RUN --mount=type=cache,path=/var/cache/apt ..." lets you have persistent cache across builds, that doesn't end up in the final image. That's just one example, there are many other hidden gems (that we typically don't find in tutorials that have been written literally a decade ago :))

@AdrianMouat 8 ай бұрын

Thanks @jpetazzo! And good point about docker build

@georgegeorgiev1716 24 күн бұрын

The issue with obtaining different SHAs is not a problem with Bazel itself. Bazel is a build system, not a build tool-it orchestrates the tooling executed according to the rules defined for Bazel. Therefore, the comments around minute 10 are directed at rules_oci, not Bazel. The presenter receives different SHAs because they haven't set up a remote or disk cache. If a cache were configured, the same file would be retrieved every time. Despite all that, I don’t understand why having a different SHA would matter as long as the file is semantically correct.

@AdrianMouat 13 күн бұрын

Thanks George. I knew it was something I was doing wrong, I just couldn't figure it out in the time I had. A matching SHA *proves* the file is the same -- it's mainly a security thing but it also has nice properties for debugging etc.

@palark 8 ай бұрын

A fantastic overview, thank you for making it! Sad that werf is missing, though. It uses buildah under the hood to build images, yet brings lots of great features on top of it (such as distributed cache, making it a self-hosted substitute for Docker Build Cloud or Dagger Cloud) and aims to cover other CI/CD steps as well.

@maltepoll 8 ай бұрын

Nix and Bazel are both great solutions for building container images - especially if you have more complex requirements. Either your project is trivial (single, statically linked Go binary) which allows you to package it up nicely with any tool under the sun (including Dockerfiles) reproducibly, or you need a real build system and will not be happy with Ko.