 John Waliki is coming in at 15. Ah-ha, here he is, welcome. Yeah. All right. Thank you, Matteo. That was fantastic. I'm really delighted to be here, Ryan. Thank you. Yeah. Thank you, John. Have fun now. Oh, of course, Zoe. Ryan, I'm like a live demo guy all the time, and that's what you're going to see. Excellent. That sounds great. I was especially interested in your topic. I know there's a lot in there, but this sounded like a really fun thing that I would maybe want to reproduce after the fact and try out as well. So I'm really excited. This sounded like a really fun topic. Yeah, absolutely. I think we're just about ready to go. If you're ready, you want to... Hang on, hang on. What I'm going to do is, during our little talk, Ryan, I'm going to... Since I can't see the live chat anymore because we're in the backstage, I just sent you some links. I was wondering if you could drop them into the chat for our audience. They want to follow along with some of our links here, okay? Yeah, you bet, definitely. All right, well, let's do it. All right, so we're going to pray to the demo gods like Matteo suggested, and we are going to roll here. Let me do a quick introduction. So my name is John Wallachy and we're going to talk today about containerizing and deploying your Node.js applications using some best practices. At the end, we're going to deploy our containers to IBM Cloud Code Engine, and I'll sort of take you through that as well. If you're joining us just now, Ryan's been running the track today. We're in the JavaScript track and Matteo and Lucas and I and later, after me, we've got Ganesh coming up and just awesome presenters. I'm really humbled and delighted to be here with them. We're going to cover a couple of topics and just a little bit of background and why you're going to want to spend the next 30 minutes with me. I'm an IBM developer advocate, sort of a senior developer. I love to teach, I love to speak at conferences and mentor at hackathons and run workshops and tutorials and now tons of live streams. This is sort of second nature. We're eager to get out on the trade show floors and at the conferences. And next week, hopefully I'll see some of you at Open Source Summit in Seattle. So look for me there in the IBM booth. So that's what I do and senior IBMer, I do a lot of different. So I'm an IoT guy and Node.js application developer forever and ever. Other roles in IBM, sort of really fun leading the Linux efforts. And so great partnership with Red Hat for two decades plus now. But what we're going to spend the rest of our time talking about is how to build Node.js containers. And I'm going to spend a couple of minutes. My one slide guys, I promised that there was going to be no slides and I just got one because I just want to introduce the topics. So what makes a good container? Where and why would you want to build containers that are trusted and secure and small and production ready? Well, let's unpack those because they're really important. First number one, you want to start with a trusted base image. You can go to Docker Hub and peruse through all the containers that are out there and maybe pick one that you want to build on top of. But let's be honest, Ivan from Moscow doesn't have your best interests in mind. So maybe you shouldn't select his image as your base. What you want to do is select an image, a base image that has got a pedigree and is supported and it's being scanned and actively maintained. Sort of that, you want to build from recent images that have got all this CEVs applied that have the right set of infrastructure and rigor underneath them. So we're all very passionate and very worried now about our software supply chains and the software bill of materials. And starting from a trusted image really gives you that security that you know you're going to really require especially as you get to production. You want to know what your application is running on top of. And so number one, let's start with a trusted base image and I'm going to introduce you to what's called universal base images from Red Hat. They're free and I've been building with them for now a couple of, you know, two years starting to get good at it and though I rarely call myself an expert. Number two, secure. So you can throw a kitchen sink into a container and call it done. It works, but it's got an entire vast attack surface and a secure container is going to be really tight. Sort of that you understand and you know exactly why every package is in your container. Anything more is a vulnerability waiting to happen. So just, oh, I always think of is how do I make this container as tight and small? I gonna install only what I need for the particular workload and then nothing else because you want to make sure that, well, because, you know, CVs are gonna happen, right? Versions are gonna happen. And it's software and we're all sort of building on top of other shoulders, other giants and we make mistakes. So the smallest attack surface possible is gonna make your container hopefully as you get to production that much more secure. Now, as you start to prune and really call it your image, you obviously it's gonna get smaller and maybe it gets big and then it gets smaller over time. I very often developers will collaborate and they'll give me an enormous Docker file and we'll prune it down and we'll get it smaller and smaller. And I'm gonna show you how we can do that in the next couple of minutes. We're gonna start with a pretty big container and then a little bit smaller container and then like as well as we can get it for the particular workload. And then we wanna make sure we're production ready. When we go pick on our image, do we need all the docs? Do we need all of the extras that are sort of delivered inside of our image? No, right? What we really want is the production harness, the test infrastructure. And you'll see me in the next couple of minutes that I build almost everything from a make file, local and then GitHub actions and then a variety of Tecton pipelines and so forth as we get to production ready, OpenShift clusters and Kubernetes cluster. So we wanna make sure that we can push our containers through the pipeline and we get consistent results out of, right? We want repeatable results. We don't want, oh, today it looked like it worked and then tomorrow it doesn't quite work because we chose poorly. So we wanna think through how we get to production ready pipelines and so I write make files and then I write GitHub actions and I write Tecton pipelines and I pay attention to those things. So those are sort of the four big lessons, the four big takeaways for John, all right? Let's go and so I'm not the only one that's thinking about this and I wanna mic X IBM colleagues and now a Red Hatter excited for him and he's leaving the node application to stack. He's actually part of the OpenJS as well. He sits as a community member on the OpenJS technical committee, but Michael Dawson.