 Hi, this is your something part here and welcome to another episode of TFR Let's see a demo and today we have with us once again Ram anger chief evangelists at Cloud Foundry Foundation and Timothée Isner member of technical staff at VMware Ram Timothy is great to have you both on the show Yeah, and today we are going to talk about build packs pocket a project and also see a demo But I would love to start with some of the basic which is Ram We have talked about a couple of times, but it's always good to remind What are build packs and what is cloud native aspect of it? So build packs are a bunch of scripts that help build your containers The cloud native aspect of it has been something that the community has been working on for about five years now And it's an evolution of build packs as a build tool from the days of Heroku and Pivotal about a decade ago In and it's bringing it into this new without containers and Kubernetes and the alternative right now Let's talk about the packet of project and once again how it's associated with the cloud native landscape and build packs the cloud native build pack specification kind of lays out What a bit how a build pack should behave And uh, paquito build packs the project Serves as an implementation of that specification so a concrete Suite of scripts that that implement that all follow the specification so that anyone who wants to use Who wants to? conform to the cnb spec can trust that it will function exactly as outlined there excellent. Thank you What does it mean for docker? So there's no fear of Conflicting docker or not wanting docker or removing docker from the scene so to say we will see this during the demo but paquito essentially Outputs an OCI compatible container image which can piggyback onto any existing docker based workflow that you have right now That being said there's also like some parts of the entire cloud native build pack Specification that makes use of docker in order to create things like stacks and so There's very much a lot, you know a good amount of interplay that's happening between And cloud native build packs and docker if you look at the whole cloud native constituents user base It's like they're big players and then also small players startups if you look at build packs Who reaps the benefit of build pack the most is it like big enterprises or also small teams and startups as well I'd say there are The benefits of both, um, I think Perhaps for for larger build for larger businesses that are maybe out of the the startup phase the benefits are Numerous because there's this aspect of rebasing. There's it makes operators lives much easier You can you don't have to mess around with docker files at scale And so that that's a really good prospect for a large company, but on the on the opposing side for smaller companies It's easier to get to lay a foundation with build packs because you don't have to redo any infrastructure that's already been Um, that's already been established. So and but it's not hard to do either of those things So I think there's there's benefits for both. Um, and it's kind of hard to to To declare a winner as far as who benefits the most between those two spaces I think So what I wanted to add to that is if you look at the list of paketo adopters On the one hand, you see this massive software engineering companies like bloomberg like ing and who have lots of compliance and security and all of these picky operational Requirements that are way up the maturity ladder and on the other hand, you also have a lot of Companies that are coming up with platforms like fly.io and railway dot app And and you know folks in the middle of the like digital ocean app platform consumes Build packs and so you see a wide spectrum of people Coming and using build packs and expecting some advantage out of it and that makes for a very vibrant community So so it's very heartening to see This project impacting companies of you know all shapes and sizes One more thing I want to ask is that if you look at large enterprises, of course, they have all the resources But it's small startups. They do sometimes, you know, especially when it comes to all these more technologies Can you talk about what are the benefits of build packs that are there for smaller teams and startups? I think for for smaller teams and startups you benefit from a Quick iteration. So you're able to get open running very quickly paketo and build packs in general They detect what's needed from your source code and and adapt to changes in your source code as well So that's a very good benefit for someone Starting up on trying to move quickly. I think as well you kind of get security baked in At the outset of the development process So you don't have to it's not an afterthought as you begin to grow You you get that from the from the outset. I think that's a really strong component for for startups as well Perfect. Thank you so much now. It's time to see some action. Uh, and You you have prepared a demo. So let's see the demo right now What we are going to demonstrate is how to use build packs in the most basic form We'll build into some of the more Intermediate features during the demo But first what we are going to do is kick off a build with what is known as the pack command So pack basically is a cli that consumes the cloud native build packs What you're seeing right now is pack consuming paketo builders which is an implementation of the cloud native build packs and Pack is going to make use of the paketo build packs in order to create A container image of a node js So what kicks off is a build pack life cycle so In the output you can see a bunch of different phases called detect Analyze And then later on export. So these are the phases that the build packs actually go through And help us go from a source code to a container image If you want to walk us through a few details of the build process itself in the detection phase uh, the life cycle runs the detect binary that's included in a suite of build packs and um Try us to figure out what it is that your Applicate your application image will need given the source code Uh, and it decides which build packs are going to participate in the build process through that Through that our detection phase Uh, this all happens It in parallel and then a build plan is generated by the end of the detection phase Which contains all of the build packs And their requirements and the things that they provide to the build Uh, which have to there have to has to be Uh requirement met by a provision for the build pack to participate in each case Uh, one of the newer features we've added you can see here is A description of what a build pack May not have found and why it isn't participating in a build in this case It's the node run script build pack Which would need to have scripts in a package json file to participate and since it could not find any scripts it decided Not to participate in the build here And you can see that the node engine npm install node start and npm start build packs have been chosen to participate As well as the CA certificate build pack some of the other interesting parts While examining this output is you can see a line that says Generating s-bomb so s-bombs are software bill of materials and They're a big deal right now with the executive order from the current administration and With all of the talk about supply chain security Ain't nobody going to say no to an automatically generated s-bomb. So Build packs are capable of automatically generating these s-bombs and making them available And then if you scroll down further, there's configurations for what the Run command is like you don't have to necessarily Specify an entry point dot s-h and keep those maintained and things like that Build packs are fully capable of detecting all of these based on the files that are a part of the source itself and Including them as part of the final container difference. So in the last part of the output We see that you know the image has been built and an oci container built the name That we specified has been actually exported from this process In the next part of the demo, we're going to see The use of a command known as pack inspect as is the pack cli way of basically showcasing what's inside the actual image so you can see that the image contains A bunch of build packs that were actually used in order to create it and you can see what Processes are used to start it to run it etc. There's also information about the base image, which is What is used as sort of boilerplate in order to construct the app layers above Now you can also make use of a docker inspect on the same image So remember when I said you can make use of existing like docker commands and Existing docker workflows in order to effectively generate like The same kind of experience for app developers So this is just a quick demonstration of if you have like a docker inspect command somewhere in your developer's workflow It will work fine if you have a docker run command in order to start images and stuff like that That will also work. So just a quick demonstration of how Build packs based images. I have a good interplay with docker based workflows Tim for the last part of the demo, do you quickly want to show how the s-bomb stuff works? Sure, so in order to To consume or to see the s-bomb we're going to do a pack s-bomb download And specify the output folder Dash o and a path All right, and here now if we look at the layers directory In s-bomb and launch We'll see that there's s-bomb generated for Each layer that is Crucial in the building of the application image. So for each build pack There's a separate layer s-bomb Or a separate set of layer s-bombs generated So we can look at for example the npm install s-bomb in and the launch modules is what's generated by The npm install build pack. So your node modules in this case And we can even Take a look at An example here For this example, I'll just load up Maybe the shift of the three options that we have What I want to point out there is we're not picking favorites among s-bomb formats. So All of the different Format are available and depending on what the security or compliance team uses Chooses to consume They're free to you know, pick whichever format they want to implement it. So at the moment Images been using paketo build packs output Has come in all three forms Rom Tim, thank you so much for of course talking about build packs paketo and also this great demo here Before we wrap this up rom if you have any words to leave our audience with Yeah, so what we're seeing with build packs, you know harks backs to the glory days of heroku not that they're not relevant anymore, but The entire experience is inspired heavily by that developer workflow of you know come with your source code And leave with like an immutable artifact So right now, you know world is You know software is eating the world and containers are Software world essentially and so the ability to produce oci based containers is a big win for us And so the big thing That I want to leave our viewers with is paketo being an open source project Which borrows from the upstream cloud native build pack, which is also a cncf owned open source project Is always looking for more contributors and adopters and maintenance. So if folks who are looking at this want to enable A great platform for their developers and software engineering teams that they managed Go ahead and do it But if you're also willing to come back and work with us in Different areas then, you know, you're most welcome to do so and we welcome all kinds of contributors into the community Rom Tim, thank you so much for joining me today. And as is all I would love to chat with you again soon. Thank you