 All right, hey everybody welcome to episode seven of chat loop back off today is April 4th. Wow, it's April already. It's pretty crazy My name is Jeremy Rickard. I'll be the host today I'm happy to be back to learn some more things about the cloud native landscape with you If you haven't tuned in before this is a program that dives into the realms of the cloud native landscape takes a look at projects and Kind of walks through the learning process of the host to better understand some of those projects It's been a few weeks since we've done one of these and I'm pretty excited to be back If you if we haven't met before It's a pleasure to meet you. My name is Jeremy again I'm a chair for Sig release in Kubernetes. I'm also on the code of conduct committee. So you may have seen me in a few other places It's it's spring here again kind of crazy I was thinking about the last episode we did of this show that I got to host and We were expecting a blizzard in Colorado and it delivered my kids had no school And then they were on break for a little bit and now we've totally pivoted and it's like 65 Fahrenheit here It's super super nice Can't believe how quickly time is passing If you've never turned into the stream before welcome again This is a live stream that's a symbol or similar kind of a sibling show to chat a clash loop back off Which you may have seen at Cube Cup In that it's an event kind of competition style where it's two competitors or two people from the community are pitted together To solve some sort of technical challenge that's been decided and not told to them ahead of time So it's it's kind of a laid-back Maybe experience for for folks definitely for the audience and it's meant to be a good time Where hopefully everybody can learn a little bit together. I was super bummed to miss the the instance in Paris I got to do it in Chicago and it was super fun I hear there were really great competitors and the challenges were really cool So hopefully I'll get a chance to do it again in Salt Lake City Coming up in a few months. That'll be really great This stream is a little different than that It's again more focused on the host kind of going through a topic and understanding it a little bit better Learning about some project in the cloud native ecosystem I haven't done any in-depth research on this project before I think that's a key thing to understand as we dive into this I'm gonna come into this pretty fresh without really having much background on the project I know generally what it does, but I haven't looked at how to install it and I don't have it on my machine today So as we go through that if you have questions Feel free to ask them in the chat and I'll try to keep up with some of those If you see me get stuck with something definitely chime in and offer your feedback If you use the project in the past, that would be really great to have some Some sharing of knowledge between us and the and the audience Today, we're gonna learn about build packs, which is a CNCF incubating project And it's it's identified the the purpose of the project is really to think about how we build cloud native applications Generally, you know, you're gonna take your application You're gonna result in the result will be a couple of container a container or multiple containers that The package your application up and make them ready to go Without having to use Docker directly. I think that's the the keep the key point of it from what I understand During this live stream again, if you have questions, feel free to drop them in chat If you have suggestions that can help me get unblocked totally speak up that that being said This is an official live stream of the CNCF and it is subject to the CNCF code of conduct So please don't add anything to the chat that would violate the code of conduct and please really just respect Your fellow participants and me the presenter this video will be put on the YouTube Afterwards so folks that aren't able to attend today will be able to join us asynchronously Before we get going I thought we could highlight some news from the the cloud native World it's been a few weeks. So we have a few topics to look at. I'm gonna go ahead and share my screen We can take a look at a couple of different different items we're gonna share this one and Should be good. Okay, cool. So first up This was announced during cube con. I thought it was pretty cool It's a project called spin cube and it's a way for you to to deploy web assembly modules or workloads into your existing Kubernetes clusters And I think that's a pretty cool way to be able to get started You know learning this kind of new paradigm of how we're gonna package applications and workloads Outside of traditional Docker containers. There've been a few other ways of doing some, you know Non-traditional workloads inside of Kubernetes, but I think this one's a pretty seems like a pretty cool way I've seen a lot of chatter about this. I'm really excited to take a look at this and myself some point in the future and I did see that the The firm down folks plan to donate this to the CNCF and they have applied or will be applying to make this a Incubating project or sorry a sandbox project Within the CNCF. So if that gets accepted, I think this would be a really cool project to take a look at Really relevant to a lot of changes that are happening in the ecosystem At some point on a later stream, so hopefully knock on where that happens Another interesting thing that happened during cube con so some folks may have missed it But at this point it's been pretty pretty well out there that Redis has adopted a new dual source license Caused a lot of concerns and a lot of frustrations to be voiced on social media In other places and it seems like an outcome of that is that there's been a fork of this project called Valky that is also being donated to the Linux Foundation In order to continue developing What was Redis? 7.24 under a License that is more amenable to open-source consumption by it by everybody So this will be an interesting one to kind of take a look at going forward Looks like it's got a pretty big backing from AWS and Google Oracle Ericsson snaps and end users It'll be really interesting to see how this this project kind of unfolds going forward All right Last time if you were here again, I mentioned Kubernetes 130 is coming out really soon And I'm gonna mention it again because we're so close now We are just about two weeks away from Kubernetes 120 being released or sorry 130 being released You can see the the release date for that. It's gonna be Wednesday 17th of April. I think this is super cool. I was the release lead for Kubernetes 120 So we're now 10 releases away from Kubernetes 120 once this comes out And it's super exciting to see all the changes that go into all these releases and and get an opportunity to take a look at all The things that are coming this time around there's been a sneak peek I'm gonna just share this link and I'm gonna share all these as notes in the the show notes later on So folks can take a look at them if they want But I think this is pretty cool. It's got a couple of big changes that are either Graduating or will be new things to take a look at inside of Kubernetes 130 Couple of cool things that really stuck out to me were sell the common expression language for mission control That's gonna be a feature that you'll be able to rely on inside of 130 going forward. That's that's pretty cool I think the the swap support is also one that's been interesting to see Kind of evolve over time This is still gonna be in beta It'll be available for folks to try out, but it seems like a pretty pretty interesting change There's blog posts you can take a look at for that one. I'm not sure if there's one for the sell policies yet But you can check out the caps here caps are Kubernetes enhancement proposals They're pretty cool You can click through to them and you can see all of the information about what's gonna go on Inside of that change. It's really cool You can see all the work that's gone into it and this one Definitely you can see has had a lot of PRs and a lot of work that's gone into it So it'll be really really cool to see this graduate to a stable feature in 130 Speaking of those releases. I think a lot of people probably don't Try out the earlier releases if you're not aware Kubernetes does alpha releases. It does beta releases. It does Our release Canada releases so you can kind of see some of these throughout the timeline You know, we there was an alpha alpha 3 release back in February Beta release in March the very first alpha release was was back in January So you could have tried out some of these things over time And I think that's a really good way to give back to the project if you're able to you can, you know Be pretty assured that these release candidates are pretty close to where you're gonna want to be able to try them out this is the point at which the branches get created and We are really really restrictive on what things are gonna get merged into the project at that point So you have some pretty good assurances that those things will be ready to go and we do build Containers and packages for all of those things. So they're they're pretty pretty readily Available to try out and dims if you're not familiar with dims a great person to follow on on different social media platforms He put out a call for folks to test out the release candidates back when we did the RC zero a few weeks ago March 28 This thread I don't I'm not logged into what used to be called Twitter So I can't actually access the whole thread But there was a bunch of good information in this this this tweet The replies to this tweet that shows you how you could take advantage of some of these releases and try them out before the dot Zero comes out in two weeks So you're able to open bugs or provide feedback and get some of those changes into the dot zero release before it comes out For Cooper studies, I think we've we've seen a lot of work go into making these releases more and more stable over time and trying to eliminate any bugs that go into them, but you know any any Extra help that folks can have by taking a look at some of these things and putting extra eyes on things is super super useful And making some of those releases a little bit more stable and kind of on that topic The last little piece of information that I wanted to share news-wise is that Jordan Liggett has been doing Liggett if you've seen on GitHub has been doing a bunch of analysis on regressions per minor releases This is some work. We've been doing as part of the LTS working group another thing that I've been working on in Kubernetes Kind of looking at how stable are these releases, you know, when you're gonna go from a minor 125 to 126 for example What kind of issues can you expect in terms of regressions? What and what can you see from patch release to patch release? So maybe going from 128 dot three to 128 dot four how many how many your regressions are there and I think There's a lot of a lot of detail inside of this again We'll share the link as part of the show notes You have to be part of the Kubernetes dev mailing list to access this, but that's a pretty easy pretty easy thing to get There's a lot of detail that goes into this and links to a whole bunch of different information If you want to kind of drill down into things, but I think some really cool information that kind of came out of this is that we are Looking at probably the least number of regressions that have come in Most recent releases. So kind of common concern that we've heard from folks in the past is that there are a lot of regressions and upgrading from patch release to patch release is something that's not really safe or stable to do and That's actually not true based on the data that we're seeing as part of this this regression analysis So I think it's really cool data Lots of cool stuff to take a look at would encourage folks to to take a look through that if they have the interest Okay, so with all of that out of the way, we are going to dive into Cloud native build packs. So I'm gonna close those other tabs to get them out of the way for now And I'm going to jump back over to this other screen so that I can take a look at any comments or questions that come in but without further ado, let's dive into cloud native build packs and I think you can see a bunch of really cool information right out of the box about, you know What's the what's the use case? What's the value prop for using something like build packs? We see Compliance, I think that's something that a lot of people in the enterprise world are interested in Performing upgrades with minimal effort intervention. That sounds like something that anybody would be interested in a balance between app devs and operators I think that that line kind of blurs from place to place But it's a it's a cool one to keep in mind But really, I think the mission statement here seems to be transforming your application source code into images It can run on any cloud without having to necessarily use, you know, under lower level Docker technologies directly So let's let's let's go through this documentation See if we can get to a point where there's some good quick start or how to and then we'll we'll dive in and try some of this out So what does cloud native build packs do? Transforms your application source code into container images. We said that before you can Concentrate the knowledge of the container build best practices within a specialized team instead of having app developers across the Organization individually maintain their own Docker files. That's a pretty Pretty attractive kind of thing to do when you get to a really really large organization In my day job today we're doing a bunch of things to try to standardize folks and really apply security best practices across things and it's It's difficult because it's kind of like the Wild West and there are so many different ways So many different teams have been doing different things Okay, so this makes it easier to know what's inside the application images and for security compliance requirements and perform upgrades Yeah, that sounds sounds super cool Build packs were first conceived by Heroku in 2011. That's that's a long time ago since then they've been adopted by cloud foundry and Platforms as a service like Google App Engine get lab K native deus Dooku and dry. I don't know the last two But I'm pretty familiar with these other ones and I've definitely seen them being used inside of K native Cloud native build packs were initiated by pivotal and Heroku in January of 2018 and Join the CNCF in October of 2018. So they've been in the CNCF for quite a while. It's we're in 2024 now So that's that's pretty far away The project aims to unify the build pack ecosystems with platform to build contracts It's well-defined and incorporates learnings from maintaining production grade build packs for years above pivotal and Heroku Cloud native build packs embrace Yeah, sure. I can increase the font size for sure Let me know if that's any better Hello, okay. I'm gonna assume that that's big enough and we'll go from there Left off right here. So cloud native build packs embrace modern container standards such as the OCI image format That's pretty cool and takes advantage of the latest capabilities of these standards such as cross block cross Repository blob money and image layer rebasing on Docker v2 APIs. That seems pretty cool Looks like we're gonna jump right into a tutorial now and we're gonna start by probably installing the pack CLI So I'm gonna jump into the tutorial and we'll kind of work from there as we go I'll try to To maybe make some some callbacks to or if they don't show it callbacks to like how you might do this with with Docker files or with other Tools in space because there's actually a bunch of tools in the space that are doing, you know code to to image kind of Okay, so in this tutorial, we're gonna use pack Pack uses Docker or a Docker compatible daemon. So I do have Docker already Looks like you can use it with podman. I do not have podband installed. So we're gonna use Docker I don't have pack installed though. So we're gonna go ahead and install pack and I'm gonna use homebrew to do this Cuz I'm on a Mac and that seems like a good thing to do All right Okay, go start out here We're gonna brew install bill packs tap pack. Well, that's running Jump back over here Cool, they have auto completion for ZSH that'll work for me. We'll do some of that when we get there It looks like you're able to run this in a container, which is pretty cool So without having to install anything you can just run it that way You can manually install it you can do every everyone's favorite thing of curling and then Passing it to a shell. That seems like a the great thing to do Looks like there are wicks and windows Installation steps for this so looks like you're pretty much covered no matter what's What dev OS you're running on your your local machine. So that's pretty cool Okay, let's see how this is going Still still installing a couple things Okay, I'm gonna jump back to that previous page. Actually, let's see if there's anything we need to do in here I think this is the only thing that I really care about I'm gonna add that to my ZSH RC file Actually, it's not installed yet. Okay, it is installed now. So I should be able to do this. All right. So that's running. Let's go back to the tutorial Okay bill pack base camp before we sit out you know the basics of bill packs and how they work So what is a bill pack a bill pack is something you've probably used without knowing it as they're currently being used in many cloud platforms That said well bill packs are often behind the scene detail. They're at the heart of transforming your source code into a runable app Okay auto detection sounds cool This is enables them to be transparent. Okay So it's gonna look at your source code to try to determine what kind of base image you're gonna look for What things need to go into the application and how to build it probably so that's that's pretty cool What is a builder? It's an image that contains all the components necessary to execute your build a builder image is created by taking a build image and adding a Life cycle bill packs and files that configure the aspects of the build including the build pack detection order and the locations of the images. Okay, so they've got a Tutorial we can work through here. It looks like it's a simple Java app. That's what I have in mind too So we'll just use theirs instead of starting from scratch. That seems like a pretty good thing to do So I'm gonna go back over to this terminal window Clear and then we're gonna clone that. All right So we've got our samples directory here now I'm gonna bring up a VS code window just in case we need that Cool. Got a bunch of stuff in here. We have a a Docker file for Git pod but not a regular Docker file. So I do expect that because of we're we're using Build packs instead of straight up Docker files Click we've got a couple different directories in here with some application stuff And some basic images a couple different Stacks, so if you want to customize it looks like you can do different different base images. That's cool builders Yep sample builders that use the base images in this repo. That's cool. And bill packs Okay, we've got a whole bunch of different ones. This repo is laid out pretty nicely So shout out to the the bill packs people for including nice Directory level read me files. That's pretty cool. Okay So we've got that clone. Let's go back to the tutorial So we want to go into the Java apps sub directory So samples apps Java Maven and then we want to build the app using build pack. Okay, so let's give that a shot So we're gonna go to this directory Oh, I'm already in samples. So I'm gonna do CD apps Java Maven and then oops we want to Run the pack CLI Before we do that, let's just run the pack CLI without anything See what we're working with here. So we've got that in CLI installed It's a CLI for building apps using cloud native build packs. Oh, you're not seeing my terminal. Okay, hold on Sorry about that. I was only sharing a window. Sorry. That was my bad Thank you for calling that out. Is the terminal coming through now? I Think I see it in the the preview window. So I think we're good now Okay, cool so just Yeah, thank you for confirming So all I've done so far since we couldn't see the terminal before is I've cloned this repo with the get clone command and then I have changed into this Samples apps Java Maven directory. So inside of here, we've got a Basic Java application that uses Maven to do the builds. So the the pom.xml Has a bunch of Java specific things about how to build which plugins it's going to use This is a spring boot application. So it's going to use a bunch of those things under source We've got our Java directory resources and Some properties files. I think the one thing to notice inside of this is that we don't have a Docker file So there's there's definitely none of that We're going to use Bill gets the build packs to do that. So that'll be really cool The last thing I was showing before we noticed that the terminal wasn't there was the Paxiola is installed It's got a whole bunch of different commands. We'll see how many of these we get through I think the first one we're going to look at is build so generating an app from source code That's probably the thing that folks are going to be most immediately interested in So we're I think we're going to dive into that one if we go back to the docs for a second We're going to run pack build which is going to be that command right there So let's do pack build And see what it gives us as options You can specify the builder you want to use you can specify build packs the registry So there's a lot of customization that you can do inside of this. I think we're going to Start off with a little less customization and go with just the the recommended basic thing here Hello in Paris. Nice to see you Okay, so we're going to use the pack command We're going to do pack build my app and I think we're going to specify the builder here Which is going to be the simple builder jammy. So let's run this And there's a note below if this is your first time running pack build you'll notice the build might take longer than usual It's going to cache things for us. So this is the first time I've run this So this is going to probably take a little bit of time. So we'll do some more exploring while that's running But let's give it a shot see what happens Okay, so that looks like a docker build happening behind the scenes. Oh Could not get decompression stream fork X that looks like it is a Mac M1 problem, let's go back to See if there's any information that might help us debug this if anybody has used build packs on An M1 Mac and has run into a similar issue Please feel free to share it in the chat and you can get us kind of unblocked a little bit I would guess that Because this is not an An Intel processors it's not an x86 that's probably what's coming into the issue here. I wonder if So we're going to use this tool called or us And we're going to look inside of this direct this repo and see if there's anything that is arm-specific that might help us out Okay, so we've got an alpine bionic jammy Nano server There has to be a command that helps you list the available builders you may use yeah, let's let's check that I think there was a pack builders Command here Okay, we've got some suggested ones from Pakato from heroku and from Google Let's Let's try this at the different time a different builder Actually, let's try the Google one first. That's an older version of Ubuntu, but we'll see if that works for us This is a pretty cool thing. I definitely think that if I was running this In my environment, I would probably want to host those build packs or those builders In a repo that I control a registry that I controlled just for more supply chain Security assurances so it's cool that you can specify different ones and override that Keep your fingers crossed and see if this one builds for us Nope Let's Let's take a look at the manifest for that See if it has a Yeah, this is an AMD 64 image. I would guess not Not for arm. Okay. Let's try the Pakato one and see Okay, we'll just try it with this one and see if that works Yeah, it doesn't look like these are multi-arch images that may be maybe a problem for my M1 Mac, it's just a regular manifest. Okay, so we give that try but I think we're gonna run into the same problem so might need to go to the Docs again and try to find some more info on how we use it with a non-amd 64 machine First thing I would probably do for that is to find their github repo All right. Well, it looks like there is an issue on an M2 Mac with pod man not using pod man. So hopefully not that That probably is not my issue because We're not getting that far. Okay. Let's take a look at the Pack build command and see if there's anything that allows us to specify the format we want to use I don't think it's not a multi-arch image. So I don't think that'll matter, but all right. Let's try Google search and our error is I wonder if I need to enable Rosetta again. No, it doesn't seem like it could be a broken Let's try just running one of these images and see what happens. What version of Docker. Do I have? 427.1 Is it related with your current build kit builder instance? Docker build xls to see which builder. It's good. Good idea. I am using the default one From Docker, let's just make another one And switch to a new build kit and see if that does anything. Well, that's going This seems like my My Mac is not Doing correct things. I would not expect this error to come through Just trying to a good book instance Yeah, it's possible to increase the terminal size. There we go. Let's try that. Okay Let's see if I can just run just a rate. Maybe my Docker needs to be restarted I spilled engine next wrong. That's why yeah, something's wrong with my Me restart Docker Sorry for The technical difficulties Let's try to use the desktop Linux use not user If anybody has any other suggestions, feel free to throw them into the chat Let's verify if I can make another kind cluster. I have one running. So should be okay, but let's let's give it a shot Well, let's run in. I'm going to make sure that Yeah, that has a RM 64 Linux instance, I should have been able to run that. Yeah, I've not seen that error before either Which is unfortunate But it is failing to create a kind cluster now to which is like like all of the Binary formats are incorrect That is super weird Let's see if anybody has Solved this for us on the internet already And this is a mini cube issue. Yeah, that's super weird. I can't do anything with With Docker here. Let me force quit it right again Tom in the chat says this is a life of running clusters on the M1 Even if it's not the root cause it's always in the back of your head. That is true I've had pretty good luck with with Docker on this M1 so far but not not now I guess Now it's Not being so nice It's actually starting my Mac is not Not being very happy today. Yes. Docker is running according to This but I don't think it is running correctly. Yeah, it's not showing up here Super super strange. Oh Well, we are running out of time. So let's just take a look at some more of the Documentation for build packs since we're not able I'm not able to get it to to run on my Mac Definitely doesn't seem like it's a problem with with build packs. Definitely seems like it's a problem with with Jeremy's installation of Docker for some reason or Jeremy's computer Which is Unfortunate apologize for that Okay, so what this will end up doing is building us a new container We see here when we do a Docker run here It's gonna use This as the tag. So let's go take a look at the commit The pack command for a second Look at the help screen. So when you run this Test image is gonna be I think the name of the the image you want to build It does look like you can specify other tags So essentially when this is running, it's gonna generate something like my app latest You're not specifying a tag right here. So it does look like you can override that here You can specify additional tags to push the output image to I'm curious if it does push directly to Oops if it pushes directly to your your registry by default No, I think it goes to the Damon by default you have to use this publish flag to make it go to the actual The registry Okay, that's cool. That's bum output there. It'll generate an S bomb for you Omitting this flag will yield no S bomb content So if you want to generate an S bomb for that, that's a really cool feature built into this that it'll generate a Software build materials for you by default if you if you provide this output directory That's that's a really nice feature that's built into that That we didn't get a chance to take a look at Okay, back to the docs. Oh Really cool windows builds are are something that you can support. What's what's that look like for Linux containers? That's pretty Pretty neat. Looks like it's pretty similar. We are gonna run Pack build and really just specify a different builder to go along with that. That's that's pretty cool Building a custom environments build for the arm architecture. This is useful information My Mac should with Rosetta and running. Let me run AMD 64 images and build AMD 64 images like I've done that before for today But it's pretty cool that they've got documentation for building arm-specific images here as well I will try this out later on and Make sure that I can Get that to work. I think the other interesting one here is using pod man I think we're starting to see a lot of folks migrate away from from Docker to other alternatives Pod man is one that people seem to be really into Lima is another one. That's kind of kind of interesting. I would be interesting to see how that would work with this. I Wonder if I install I don't probably don't have time to install pod man to do this for this this live stream But there is really good documentation here looks like for for switching over to use pod man Instead of using Docker Directly, that's that's pretty cool Understand the build outputs. Let's take a look at that the S bomb piece is interesting to me. So let's take a look at that So They will generate Sift or Cyclone DX or SBDX. That's cool The S bomb can also be downloaded. It looks like after build time. So you can specify that command With pack build, but also you can use pack S bomb later on to do that. That's that's great That's a really good information here. So definitely I would recommend checking this out on Your own make sure you got a working Docker instance Since it's not not being too happy for me today but There's a bunch of really useful information here starting with the tutorial I think is useful I think this concepts page has a lot of really specific information That will be useful As you're kind of walking through this journey Builders are OCI images that contain combination of build packs and build time based images What happens during a build? Let's let's read that one real quick Well, we've got a few minutes left So build is the process of executing one or more build packs against an application source code to produce a runnable OCI image So the builder image has one or more build packs inside of it And it takes your app and then produces your app image So these layers can come from multiple build packs. It looks like so you can specify multiple of those The runtime image which is going to be that base image and then your application itself is there. Oh Rebase that's kind of cool. So rebase allows you to Rapidly update an image without when it's runtime based images change So if you're maybe basing on Ubuntu 2204 and a new version comes out It looks like that allows you to do that pretty pretty easily and there's a pack rebase command that does that so See what that looks like Yeah, that's pretty cool. It'll perform the rebase operation. You can skip validating probably not a good idea But you can actually have it published directly for you afterwards. That's a pretty great Feature as well All right, well, I'm gonna end it here since I'm not able to get this to run on my my local machine I apologize for the inconvenience Maybe we can do round two of this as another Livestream after we get my technical issues figured out. Thanks for joining me today again Apologies for the technical difficulties. I hope to see you