 Hello, welcome to cube con cloud native con I was fortunate to have been asked to give a lightning talk at the very first cloud native day And it's an honor to be with you here in Valencia today in this lightning talk We would be discussing how to scale container builds with software supply chains with the build packs flux and cartographer projects So build packs is a CNCF incubating project and it's designed to simply go from source code to a running container There are no docker files required to build the container image. So all that complexity just melts away It seems like also every day in the news we hear something about a software bill of materials or an S-bomb how it's either required Or helpful build packs also creates an S-bomb natively as part of the build process The build pack spec is involved with a logical mapping of layers to components So it makes it easy to do rebasing. So this is really good for incremental builds Which results in minimal data transfer when a full rebuild is not required Build packs API supports a wide variety of S-bomb formats including sift spdx and cyclone DX the S-bomb is created at build time Which is nice because the user doesn't have to go back to scan the container to try to figure out what packages are in the container There's also a lot of really nice Metadata in the S-bomb also including what processes are available What run image was used to create the app image and as well as what build pack was used to create the app image The rebasing capability in Build packs is key because large organizations could have hundreds of apps that use a common base OS layer And if one package in that base OS layer changes that means all the applications need to be rebuilt Say all these applications use logging and say there's a base logging package say log for J That means every time The update happens of the base package the image needs to be rebuilt But build packs can make that easy because build pack images are built are composed of layers and the app images can all share a Common runtime layer so in our example when that base OS layer is updated and all the application images are affected Build packs can upload a single patch copy of the OS packages and the environment to the container registry So this rebasing can happen very very quickly this can happen in the order of milliseconds And then a tool like k-pack can automate the run of the build pack builds and then a supply chain like cartographer can then Deploy the app images at scale So cartographer is a Kubernetes native supply chain It's designed to be very efficient you write your Kubernetes resources once and then reuse them as templates So it minimizes the YAML developers and operators need to use and it gets us away from that wall of YAML burden or impediment It defines all the steps for an apps to reach the path to production So it's really good at automating best practices and a shift left methodology It's designed to work with any Kubernetes object in any Kubernetes object That is applied to the cluster can be used in the supply chain It's also designed to work with existing tools like CICD pipelines So Cartographer is based on choreography, which is more flexible than linear orchestration with linear orchestration Typically a phase say a pipeline run happens it goes deep and then everything waits till they end of that phase or that pipeline run Choreography is essentially a graph. It has an event broker So anything can trigger an event in the supply chain. It's based on a Kubernetes API So it's essentially looking at Kubernetes objects a status and updating the spec field So in our example where the base OS layer changed then build pack can trigger the container releases automatically So all that happens without a code commit from the developer in addition to Choreography you can also have an automatic run of the supply chain when the developer commits code to the repository Flux is a CNCF incubating project. It has a git watcher. So when the developer Hits commit and commits to git then the supply chain runs. So it's based on the GitOps philosophy So you have a nice declarative state You have all the rich archiving and revision history and the single source of truth of git So Scaling container builds build pack with the rebasing is very powerful Flex is the git watcher and then the supply chain choreographer ties it all together for more information on build packs Check out the session on Thursday Check out the session on Friday for flux and flagger and for more information on cartographer Please join us on Twitter feed as well as join us in the community meetings and the open hours that occur every week So thank you for your interest in scaling container builds with supply chains