 All right. Hello everyone and welcome to Cloud Native Live where we dive into the code behind Cloud Native. I am Itai Shakuri and I'm Director of Open Source at Aqua Security. I'm also a CNCF Cloud Native Ambassador and will be hosting today's show. So this is Cloud Native Live. Every week we bring a new set of presenters to showcase how to work with Cloud Native technologies. They will build things, they will break things and they will answer your questions. So join us every Wednesday at 11 a.m. Eastern time. This week we have Meti Straton here to talk with us about Pulumi. He will introduce himself in a second, just a quick disclaimer that this is an official live stream of the CNCF and as such is subject to the CNCF Code of Conduct. Please don't add anything to the chat or questions that will be in violation of that Code of Conduct. Basically just be respectful of your fellow participants and presenters. So Meti, would you like to introduce yourself? Sure, yeah. My name is Meti Straton. I'm a Staff Developer Advocate at Pulumi. I've been here for a couple of months. So we'll see how expert I can just be. I've been in the DevOps space for a long time. I host a podcast called The Rest of DevOps and run DevOps days. I'm excited to do a little exploring about Pulumi and what we can do to play around and have some fun with Kubernetes with it. Cool, yeah. I've been looking a little bit before this show about Pulumi. It sounds very, very interesting. So I'm happy to hear a general overview first about what is Pulumi. Absolutely. So the real way to think about this and I've been in the config is code and the info code space for a long time and what resonates to me is we've talked about infrastructure as code, but what we've really been doing is building infrastructure with code. And a lot of what we can do with Pulumi is that and there's also other capabilities that I'm not really going to go into today where you can actually treat your entire infrastructure as an API rather than being something you run commands against, but you can actually embed if you're building, for example, like a dev portal or something as a platform team, and you want people to be able to manipulate Kubernetes but not have to run Pulumi at the CLI. It's very easy in whatever programming language you're using for your portal to just consume the libraries and then it all happens there. So there's a tutorial we do where basically go ahead and do pod deployments by clicking on a button in a Python web app. But the thing that's really powerful with Pulumi and among other things is that all of your Pulumi programs, which is the thing you're going to write to reason about your cloud infrastructure, whether it's Kubernetes or AWS or GCP or whatnot, you're writing it in the programming language of your choice. So you can write Pulumi code in JavaScript and TypeScript, which is what I'm going to be doing today. You can write it in Python. You can write it in .NET or you can write it in Go. And the reason that that's, there's a couple of reasons that that resonates to me and again kind of coming from the background of working with Chef where you had the goodness of being able to write in Ruby, but the problem was if you didn't like Ruby, you probably weren't going to like Chef too much. And the goodness of this is among other lines like, hey, if you already know one of those programming languages, cool, you don't have to learn a new language. But because it's expressed that way, everything available to that language is available to you as you build your Pulumi code. Things like, you know, as simple as just autocomplete stuff in your IDE, but testing tools, all that good stuff. One of the funny things when I started, because the first thing when I try to learn something new, the first thing I do is try to figure out if I can write a plugin for an IDE for it. And I was like, I wonder if there's a Pulumi plugin. Well, of course, actually, there's not because you don't need it because Pulumi is just TypeScript or it's just Go. And you'll see that as I kind of go through this stuff where we're getting that stuff for free. And the last sort of thing I think about is there's a couple of different types of reasons you might be thinking about Pulumi. It could be if you're like me and you spent your life in ops, and you're maybe on a platform team, this is a way to be able to provide these resources in an automated and trackable way and the way that makes sense to you. But also if you're a software engineer that doesn't really know cloud infrastructure that well, but you know you need to get stuff there, this is giving that window to the cloud to that ability to create that, get the stuff that you need and where that goes. That's the stuff that I think is cool about it. Yeah, and I really like the kind of thought provoking statement that you opened with that we were building infrastructure as code, but we were actually building infrastructure with code because like most of the other ISE tools are either something like YAML or JSON or something like that, which is more like a data structure language, not really a code language. Maybe we turned it into a code language without realizing that. But yeah, definitely interesting direction. And do I understand it correctly if I say that it's like the missing, so we have, we're used to working with different systems providers, clouds, or services. Some of them provides us good SDKs to work with software development kits in the languages that we like. Some of them are better than others. Some of them has better coverage than others. Is this like the universal SDK? That's the intent because there's a couple different ways that you can consume providers with Pulumi. There's the ability you can absolutely wrap an existing Terraform provider. So if there's not a native Pulumi provider, but there is a Terraform provider, there's those bridges. But where it gets powerful is what we call the native providers, where we're talking directly to the APIs from that platform. And so as long as that, as soon as that's available in that API, it's available in Pulumi. We don't have to update Pulumi to support something new in Azure, or as long as it's in that API, because then you get it kind of for free with the native provider. So it gives you that ability. And there's a couple interesting things to me, like again, coming back from this sort of background with Chef and everything. There are certain things that people wanted to do with Chef that I realized you can do with Pulumi. And it's because we're reasoning about cloud infrastructure. So back in my Chef days, one of the things people always wanted is they said, hey, I've got my Apache server here. Can I just point Chef to it and generate the cookbook that will make it look like that? And we said, well, no, because there's hundreds of thousands of configuration things that could possibly exist on a Linux operating system, plus Apache, plus whatever. There's no way for us to know all the things that might have a configuration. Well, then you go and you start talking about things like, because when you're reasoning against an API versus that, all that stuff is consumable. So you absolutely can point Pulumi to your Fargate cluster, to your Kubernetes cluster that exists and say, generate the Pulumi code that will make this happen. And that actually can happen. And it's because we're reasoning about everything at an API level. And that's just as the world has changed, right? Linux servers weren't meant to be reason about like APIs. They're just a bunch of files, right? Right. All right, cool. So maybe you have a slide or you want to jump into demo? I'll just go ahead into the demo. So I'm just going to talk a little bit about what I want to do. We're going to kind of play a little fast and loose and figure out what's interesting. But there's a few things I thought would be pretty cool. I had kind of thought about running this on Minicube on my machine, but I also have Apple Silicon and I haven't had a good experience yet, making sure that's 100% good. So the Kubernetes cluster that we're going to do is we're going to use Pulumi to spin up an EKS cluster in Amazon. You could do this with AKS. You could do this with however you wanted to. That's just how I'm choosing to do that, to kind of show the ideas. The other thing is like I said, you can write Pulumi code in TypeScript or Python or Go or C-Sharp and .NET. I'm going to be using TypeScript because that's where my examples were. I also usually, I actually like to write Pulumi code in Go, but I had a couple things I wanted to steal from that I'd done before that were in TypeScript. So that's where we'll go. But all of this stuff is available in all the other languages. So I'm going to go ahead and we're going to get an EKS cluster up. I already have another EKS cluster sitting in the wings because it takes about 16 or 17 minutes for that cluster to come up. And I didn't think you all wanted to sit here and just listen, but we might even take that time and kind of talk a little bit. And then just sort of going to show how you can do some simple deployments like just getting some pods up and then stepping through how we can deploy with a Helm chart and then even creating kind of a little bit more of a complicated deployment to see where those things go. And then sort of talk about like as questions come up and ideas about how you can use this stuff to connect things a bit more. But yeah, we can go ahead and get started. The one thing I'm, give a quick background before I bring up my code, then I think I'll just go ahead and do it this way. There we go. Okay. So Pulumi is an open source project. Pulumi itself doesn't cost you a dime. Go ahead, use it, knock yourself out. What Pulumi needs is it needs a backend, a place where it stores state. And you can, the preferred way is through the Pulumi service, Pulumi.com. And for individuals, stuff like this doesn't have any cost to it. The paid offering is if you're creating teams and organizations and doing things with needing a lot more. That being said, you can use S3 as a backend. You can use almost anything. But you'll have probably a little bit of a better experience using Pulumi.com. So explain what you meant by storing the state. What is this state? Absolutely. So the thing to remember is Pulumi, the service, the Pulumi.com, it doesn't actually talk to any of the cloud providers are doing any of that stuff. So we don't talk to the cloud provider on your behalf on our SaaS. But what happens if I'm going to do a deployment, for example, I'm going to say spin up this cluster, which we're doing. Pulumi has to know the state that the cluster is in so that it is able to, when you run to say, do I need to do anything? I need to understand what's happening. And so that has to be stored somewhere. There has to be a way for Pulumi when I run my Pulumi program to say, well, Maddie, you asked for this. But this is the current state of the thing you want. And this is the change I'm going to make. And then also, and that lets us, in addition to, so it's just sort of the common central structure to reason about your infrastructure. And I guess you can store that as a state file, wherever you want. It's just a, works out a little bit better if you can use the service, because you get to see a little bit more. Put it this way, if you're not going to use the service and you throw it in S3 or something like that, you probably going to have to build some stuff around it to show you this stuff. So the idea- And this service is also free, right? Yes. The only place where you're going to start running into the cost is if you want to create, like, Arbat, who has rights to what stack, who's doing that. If you're doing larger collaboration type features is where the paid offering comes. But I mean, for me, just right now, I just rocked this thing. It's totally free. When I started, I was like, oh, do I have to get some kind of special key for my Pulumi account? And everybody who works at Pulumi is like, we just use a free one. It's fine. It's totally good. And the idea, you'll see a little bit, I've got a couple in here, and we're going to create these projects. The thing with a project, for example, we can go look, I don't want to kind of give things every way, but this is the cluster that, this is what the output is going to look a little bit like when we go, and we can see just it's showing me the activity, the things that happen. We'll go through this when I build it up. But this also lets me know all of the resources that this particular Pulumi project has created. And the thing that's important to think about is you have, when you think about how you organize your Pulumi projects and your way you reason about Pulumi, and there's lots of different ways to do it depending on how your team works. But fundamentally, I've got a Pulumi program that's like a project, probably maps to a Git repo. And then within a project, you have stacks, which to me, I always reason about them as like environments, but they're really different instances of this type of program that might have things different about them. So we're going to just be using a stack that I call dev for the stuff we're building, but you might have a dev stack, you might have prod stack, and, or you might break them up based on like availability zones or something, because those are all different configuration parameters, you might pass into that. So you can use the same Pulumi code. I like to think about them as environments, which may or may not be the right way to talk about it in Pulumi speak, but it's what made sense to me, what makes sense to me. So it's like a template that I could instantiate more of? Absolutely right. Like so for example, like let's say I've got this, you know, workshop class, this cluster that we're going to build this EKS cluster. And then I know this is maybe not a great example, but for some reason, my development cluster that I like to build is in US West too. But we run prod in US East because we don't like ourselves, I guess, I don't know. So what I could do is my program does that, but you'll see when we kind of pull in, there's places we can pull in from the config and every stack has its own sub config. So then I can say in the part one, maybe I'm going to say where's the availability zone or maybe even the size, right? How many replicas do I need for this application? Maybe in tests, I only need one or two, but prod we know we run 100. So those are all variables that can be set at the stack level and stacks can actually output to each other as well. We're not going to really go into that today. But if I have a stack, it can maybe again, if you're thinking about how things move along through your workflow, maybe something outputs from an earlier stack and then that has to get consumed by a later one. So there's a lot of ways we can reason about this, about this data. Nice. I'm going to go ahead and sorry, I kept the, if I want to change my windows, y'all don't want me sharing my whole screen because it's a 49-inch monitor. So I have to go window by window. So a couple of things I'm not going to, I'm going to explain through, but not going to show because it's boring to watch me do. So the thing is for this whole work, you need the Pulumi command line tool, right? So you can just sort of see there it is. It's all with homebrew. Easy enough. It's a simple little CLI. And then you will, in this case, what I've already done is I've already offed, excuse me, Pulumi to the Pulumi service. And there's a step. There's Pulumi login. You go through. It's just like every other type of thing you've done like this, which says that way it stores your credential and knows that when I'm running Pulumi, it should talk to, it should use my account to talk to the Pulumi service. So we've already sort of got that, got that started. And what we're going to do is we're going to start and create a Pulumi program that's going to spin up a EKS cluster for us on Amazon, which we could then use for a lot of the other stuff that we're going to do. So you mentioned that you've authenticated this CLI with the Pulumi service. What about authenticated with your AWS account? So that uses my normal AWS CLI config, right? So, you know, you could use environment variables, use whatever is the way that you would manipulate AWS. So you could use an environment, you know, use an AWS profile. So what you can do is I could say, for example, Pulumi config set, I can set the config as you'll see when we set, we're going to set a couple parameters in the config. And one of the things I could do in there is say what AWS profile to use. So that could even be interesting at a stack level as well, right? Like maybe I have a stack for dev that uses a different AWS profile. And so in the stack config, I can say use this AWS profile, but in production use this AWS profile. So Pulumi relies on this tooling that AWS or the other cloud provider provides, or it's just a convention of how to set it. It's a convention of how that goes, right? So I could like, we are talking about, are you not seeing my screen? Actually, no, we're not. I thought we're just still now we did. Oh, I guess I have to have focus on. Oh, that's why I clicked on something. Oh, this is going to be fantastic. Okay, well, we'll do our best. I apologize if it pops back and forth as we didn't miss much. Yeah, yeah, that was a to the empty VS code screen. So the, yeah, it follows it's the company because it's talking to the APIs the way that the API wants to be talked to. So you'll see, for example, when we go to the part where we're manipulating the cluster, Pulumi doesn't use kubectl, but it uses kubectl config. Yeah, right. So, and there's various ways you can get that access that that's the format of that that it consumes, but you don't need to have the AWS CLI installed to do that. But the convention of where the credential comes from. So cool. Okay. So we're going to go ahead and create our first Pulumi program here. So we're just going to call this Maddy cluster. Maddy cluster because yeah, let me see if I can make that a little bigger for you. Is that better? I think so. Okay, so and then, okay, so very exciting, we created a directory. But what we're going to do now is that we're going to say Pulumi new and then you can either create a blank one. Like in this case, we're just doing an empty TypeScript program. You'll see later that there are templates for for different things. So if I if I wanted to create that that will pre create get kind of a getting started piece, but we're going to start from scratch here. So we're going to say we're going to create a new TypeScript. And it's going to say so it's creating the stack for me on the Pulumi service. And then it kind of set up the the beginnings that we need to have here. Right. So it's a TypeScript program. So we've got our package JSON. And it's go ahead and it says, okay, I know that I need Pulumi. And it gives me and we can see that index.ts is our main program, which is not really doing anything terribly interesting right now. So we've gone ahead and initialized it. We started it. And we can see that we're importing the Pulumi library. But let's actually do something interesting here. So far, it's a regular TypeScript application that I could have just set up myself, you're just helping me with the skeleton for that. Exactly what this did. And also because it the Pulumi YAML is telling it the name of the Pulumi project that's connected to that. So like you could have done all that. But if you don't do the Pulumi new, you would have to go and then create that project on the Pulumi side. So this takes care of, you can say it's creating the stack. And then but then it's also, like I said, preconfiguring the things that we know we normally need. But you don't necessarily have to follow this in this way. The other thing, a little more advanced way to think about it is right now, you're seeing that I've got the Pulumi program kind of by itself. It's possible and sometimes the right pattern. If you want the info code to live with the application. So you might have in your repo for your application, you might have a subdirectory called infra that contains your actual Pulumi program. So it doesn't have to be at the root like this. And a lot of this, a lot of how you organize your repositories and how you go about this really maps to how your organization works and how you reason about things. So we've got our our initial piece, we could do a Pulumi up, but it wouldn't do anything interesting. But we want to go ahead and get in the AWS packages that we need because we're going to be talking to AKS or EKS, sorry, Amazon people. I'm going to go ahead and clear my screen here. So we're going to do a, yeah, sorry, I see the question. I'm a Python developer. Absolutely. You can write Pulumi and Python. Lots of people like to write Pulumi and Python. I am not that people. Python is my third preferred language. I'm not making a judgment. It's just more of where I'm comfortable. So I usually write and go or in TypeScript. But all the things I'm doing here, you would be able to do in Python. And one of the things that's really important is we have this idea of Pulumi packages, of which the other AWS package I'm about to add is an example. So there'll be packages for cloud providers and Kubernetes and things. But you also could have a package for, say, page duty. There is a package for page duty. But what's cool with this idea of multi-language packages is you might create this package that either you want the community to use or within your organization and you're like, okay, well, the thing is, because if normally if I want to write this package, I have to write the SDK for it in each of the languages I wanted it to support. So let's say I know go. And I'm like, okay, I'm going to write a package for page duty. Well, I'm going to write it and go. And that's cool for anybody who wants to use Pulumi code with go, but the SDK wasn't published. With the multi-language packages, there's code gen. So I can write it in go. And then when I publish it, it will generate the SDK for all the other languages as well. So that makes it really, really accessible. So we're going to go ahead and do some NPM install just to get the packages we need. We need AWS. Actually, there's a couple more questions maybe we can take an opportunity. What are the different features sets for native Pulumi providers like Kubernetes and reused ones from Terraform? I think it depends on the specific provider. I don't have them off the top of my head. But if the capability exists in the API for the platform, it exists in Pulumi. On a native provider. On a reused one, it's if it's been expressed through the Terraform provider. So when there's a new functionality in Azure, the Terraform provider has to be updated to then present that to you so that you can consume it, whereas you'll get it pretty much right away because it's part of the API. Actually, can we maybe just clarify what's the use case here to use Pulumi with the Terraform provider that's also configured with like there seems to be multiple layers here. Maybe you're not actually it's what it is. It's not it's not this is a misconception with Pulumi. A lot of people think that Pulumi is wrapping Terraform. It's not wrapping Terraform. What you can do is you can if you have Terraform code. So there's two ways. You can either create a package as a Terraform bridge, which means it's generated from the Terraform provider. Or if you actually have existing Terraform code, you can import it into Pulumi. But when Pulumi runs, it's still running. It's even every even if the bridge providers, it's still running Pulumi code that is generated from the Terraform. So it's like a one time pretty much. Yeah, it's based on how you build that particular thing and what native providers are really the way where things are going and there's more and more things being created in that kind of the Terraform bridge was a way to say if you don't want to rewrite the provider in Pulumi and have it have all that goodness, you can consume it because there already is a whole bunch of great Terraform providers out there that can be a stepping stone to that. Yeah. So when you say can we use Terraform in Pulumi, you can take your existing Terraform and turn it into Pulumi. The question is Terraform a competing solution? Yeah, this would play in the same place as Terraform or Chef for that matter. You're not likely to use both, but you can use you might use both for a while. The only thing is the same thing back from my Chef days. You don't want to be running multiple config management against the same resources because they'll all start fighting with each other. While your organization may not use it everywhere, you want to make sure within projects you're not trying to do Terraform for part of the project and Pulumi for another part because then you get kind of a split brain thing that happens. Like when people wanted to run puppet for some stuff on their servers and Chef for other things, it's just not a pleasant place to end up. I'm also installing what's called the AWS X package. So one of the things we have packages that we call crosswalk and what these do is they abstract away some of the things you might need to do that are according to good practices. So for example, if I'm creating an EKS cluster, there's a lot of AWS resources I have to create as well that happen every time you create an EKS cluster. And if I wasn't using the crosswalk package, I would have to go in in my Pulumi code and create all of those things. Whereas that package wraps what are common good practices around things that would map to that and makes it a lot easier. And then you could use a similar idea to what we do in crosswalk. Again, within your organization for the packages that you might want to share with people to say like, okay, this is how we build EKS clusters. And we're going to expose just the parts that you need to turn the dials on. Again, it goes back to the way I used to think about Chef, where I'd say like, okay, if I want to spin up a Tomcat server and I'm a developer, there's like a thousand different things I could do in Tomcat. I care about three of them. So how can I abstract that away just to make sure that everything else just gets done the way that my organization does it? So now that we've got these cats installed, we need to actually, also we're just going to import them as AWS from Pulumi AWS. And then we also will import AWS X, which is that crosswalk package. I swear I know how to type. Okay, so we've got those, that's just fun typescript stuff. So now we'll just sort of let that sit there. But what we want to do is like, I talked about the config, right? So I need to set a couple of different config things. So one thing is going to be where do I want to put this, right? And in this case, I'm going to say we're going to run in US West too. So if I run Pulumi config set, and then I set AWS to US West too, sorry, AWS region, right? So now that that's set, oops, what did I type wrong? So it should be Pulumi config set AWS, oh, okay, AWS region. There we go. You can see, what's that? Oh, so it so it created this Pulumi dev YAML. So this is a configuration item, but it's at the stack level. This is just for the dev stack. And then likewise, we're also going to do a, we're going to set the AWS skip metadata API check. And that's just because it's running in an I am role. So it doesn't need to do that. That's something I know when I was setting this up, that that's, that's part of my config. And there could be other things that you might need that could go into there. So that's what we got our pieces we need. So we can talk to API to AWS. Now, we're going to do a couple of different things. So first, we do need a VPC to run a EKS cluster. So what we're going to do is we're going to go ahead and give the give our whole cluster a name, we're going to call it. Let's do this. I think that's different. Let's call it just to make sure I don't have something with that name already. And but then what's the name of the cluster, right? So this is going to be, I can pull, you know, name and then say it's going to be cluster, cool, fun, exciting. And then we want to do the same thing with our cluster tag that we're going to use. And since it's because we're setting these variables here, this is letting us interpolate them and kind of do all that stuff. So we know that the tag needs to be kubernetes.io cluster, and then it's going to be called us name, right? Cool. Very exciting setting constants. Now we want to actually create this VPC. So we're going to do, we're going to create this VPC as a new AWS object. That's an EC2. And so you see how the type ahead of getting all this stuff for free, right? VSCode doesn't know what Pulumi is, but because I've imported that AWS X package, then I get all of this helpful type ahead stuff, right? So go ahead and give ourselves, we're going to name it after our name. And we've got CiderBlock. So we're going to go ahead and set this to one, two. So that new keyword, it's a type 3, for those who don't know, this is a type script keyword. It's not like a special Pulumi magic. You're just creating a new object in the programming language and the magic happens behind the scenes. Yes. And then if you're used to, this is doing with type script, type script is very good at this kind of thing, but you'd see these similar type of heads and auto completes and stuff. If you were doing this in Python, because you'd have brought in the Python package for this, that provides all that. So it's, again, it's sort of cheating, if you will. I don't know if that's the word I want to use, but, you know, no more than any other library would be cheating by having type script do what type script does, right? So let's go ahead. And so the tags that we know we need on here are, oops, there we go. So the cluster tag, and then we do Kubernetes, bio, roll, session, internal, ELB. So it's, right, so you got that tag. And then we're also going to add one more, which is the public tag. Lazy. The difference is it's, this role is just ELB, right? And I've got, that's on my side, or I'm missing a curly in here, I think, because tags is closed. What, okay, hang on, give me a second here to figure out what I did wrong. If anyone wants to help us in the chat. This is what happens when I type and talk at the same time. So we've got type is public. Yeah, so the question, there isn't going to be a code extension for Pulumi because everything that Pulumi does short of typing in Pulumi up, like that would be the only thing I could think of that you could do with an extension would be that I could right click on a file and say run Pulumi up. But pretty much everything that's happening is coming from the programming language. Cluster tag is on, roll ELB one. You have this, this cat here is this one not closed. Hang on a second, we've got my subnets, this. Okay, I'm going to copy from my code that I did earlier today, because y'all don't need to watch me type. Okay, so the only thing that I just copied that wasn't there before is that also we're doing this overall tag. So this is basically getting us our VPC. Easy enough stuff. And then we want to go ahead and define this cluster. And this is what's kind of nice because so first we need to bring in the EKS provider. So we'll say install Pulumi. Yes. And then we're going to go ahead and import that as well. Now that we have that one, when we go ahead and we say we want to create the cluster, we just create it like this, we just say cluster is a new EKS cluster with the name. And we're using class name that we had that we defined before. And then we can because we have that VPC ID because we created that so I can get the value that came from the VPC that we created up there, that object called VPC. So the ID that's coming back from when it gets created I have available. And then when I do private subnet IDs, I can the same thing, I can get those from that object. And then the same thing will happen for the public subnet IDs, which are all the things that EKS needs to know, right? And then we can say my instance type. And in this case, I'm going to say T2 medium. So this is the size for the cluster nodes that need to happen. I want to have two of them because this is on my credit card. And then I can set min size to one max size. This is all your... And then we're going to go ahead and create the OIDC provider. And then we pretty much have that. So this code right there was everything to tell Pulumi what I want this cluster to look like. And we're using the variables that we've defined. So we don't have to keep retyping that over and over again. And this is even stuff that this could come from the Pulumi config from that Pulumi Debbie Amala, for example, the cluster name was something we wanted to be done dynamically based upon the stack. So now if we wanted to go ahead and do this so we run the Pulumi... When we run Pulumi up, what that's going to do is first it does a preview of what it's going to do. And it's looking at the Pulumi program and saying, okay, if I run this, this is what's going to happen. And so there's a lot. There's 59 resources that get created, but it's telling me these are all the resources that will get created if you want to apply this update. And in this case, we're going to go ahead and say yes, because we would like our cluster to exist. Now, this takes a little bit of time. And we're not going to sit and wait for the 15 to 16 minutes that it takes for an EKS cluster to come up, because that would take us to the end of the stream. And that would not be very exciting. So when this is chugging away, we can also see this if I switch over really quick to my Pulumi dashboard. Sorry, I'm moving the screen around. I know producer people that's screening up. If I could get the screen sharing back on. That's what I get for moving things around. There we go. Okay. So if I look at the project, so we created a new project called Matty Cluster. And we can see in the stack, so what we can see here is the configuration that we had set, the tags that exist from the Pulumi side. But if we look at activity, we can see there's an update running. And this is showing me the changes. These are the things that have happened. The changes is what happened to create these things. If I go to Timeline, we can see that right now it's working on these pieces and parts. This is also what we were seeing in the CLI, but giving us this in the... This is what's letting us see this from the web perspective, if that was the thing that was interesting to us. I'm going to switch screens on you one more time. Sorry, but I won't do it again. That's the last time I'm flipping. So what I want to do here while this is going along... Not seeing your screen yet. Oh, yeah, we need to... Yeah, that's okay. So one of the things we can do... So I'm going to switch over on my terminal. So this is on the cluster that I had created before. And what I want to do is if I... There's outputs that come out of the Pulumi program. And so, for example, if I were to say Pulumi stack output, these are the things that my Pulumi program is exporting, which you... And among other things, it's exporting a kube config. So what we can do with that then is I can go ahead and use the Pulumi... I could tee that out to my local kube config. As it happens, my local kube config is already pointing to this particular cluster, although it wouldn't actually hurt to do that. So you can see what it does. So if I do that, it's going to take the output of... It's going to dump that kube config where now I have that available to me. So I have... I can use my kube cuddle if I want and I could say get nodes. And that worked because of that kube config that it dumped out of that. And that's letting us go ahead and do those things. So real quick, so if we want to go ahead and deploy something, because it's great to have a Kubernetes cluster, but not if it doesn't do anything, I'm going to go ahead and create a new terminal here because that other one's going up there. So now if we go ahead and create... We're going to just go ahead and get ourselves our deployment going. So we're going to create a new... Better when I know how to type. There we go. Okay. Oh, we're already in it. Okay. Okay, so nothing's in there. And then we're going to go ahead and create ourselves a new Pulumi project. But this time we're going to say Pulumi new Kubernetes TypeScript. So it's going to... Instead of... And this time, yep, it's prompting us for the things we want to say. This was all the default on the last one. This time, instead of being a default, just blank TypeScript program, it's going to be one that if we go and take a look at this now, if we take a look at the package JSON, we can see that the Kubernetes packages are already in our NPM packages. And it went and it created some scaffolding for something you might want to do with Kubernetes. Kind of a start. There was a few things that we want to change in here because what I want to do is you can see the replica. How many replicas do I want? This is hard-coded in my code here. But that might be something that I want to be a little more dynamic. So we're going to use Pulumi's configuration system for that. So we'd say, let config... We're going to create a new Pulumi config. Oops, auto-complete. Got ahead of me. Pulumi... Doing that. Equal new Pulumi. There we go. You get rid of... Oh, I know I didn't work. Because I don't have Pulumi in here yet. Now that would have actually worked. So if we go over here, there it is. Type script is great as long as you use it right. So we're going to... I'm just going to go ahead and get rid of all the existing code here and write my own. So we're going to say we're going to create our labels and we're going to define our deployment here. So we're going to say let our nginx deployment. And this is going to be a new k8sv1 deployment. We're going to call it this. And then we're going to spec the deployment, right? So and because we have that labels variable up there, we're just going to go ahead and use that. And then what we're doing here is we're saying instead of replicas as one, we're going to say config and we're going to say get it's the thing we want as a number. And the value of the key value pair is going to be defined in our config as replicas. But then what I am going to do is I'm going to go ahead and say, but by the way, if it's not provided, then you should just do two of them because two is a good number. And that would come from that YAML? Yes. Now it wouldn't work right now because we haven't created that config yet. But we're... What's a constainer, Matty? Constainer is what happens when I've got my lemonade bottle and it leaks and it gets all over my pants. That's a constainer. The jokes aren't always great, folks. So and then again, we're just going to say we just want to use the Nginx image container. And we're in this case, we're going to say we're going to use 1.7.9 as the version of that image. And then the ports are... Let me just check my... Oh, I'm missing... Oh, the whole thing. Okay, I got ahead of myself. Spec, selectors. And then we... This... I started typing the spec before. The template is what is the outer... Yeah, that's the outer piece of that. So if I go ahead and... I'm going to hold on to that for a minute. Got the data on that. Now we do our spec. Got our containers, our ports. This is... I only need one more wrapping here. I want to make sure we don't run out of time here. So I'm going to... And then the big thing that we're going to do here is I'm going to take this export. And what I'm doing is I'm taking that Nginx deployment and I'm exporting it to an output in Pulumi. So I'll be able to get to it later. So now if I go ahead and I say Pulumi up on this particular piece here, it's going to actually... Does anybody know what... How many replicas is it going to create? No prizes. Does anybody know what I forgot to do or what I haven't done yet? I think it will create the default of two. The default of two, because we haven't set that. We haven't done replicas. We'll say, let's set it to four. So now that it's set there, so if we actually were to go ahead and do Pulumi up again, well, let's do before we do that, because we should see two. So if we go ahead and if we were to say Pulumi, if we go to describe the output, the deployment, but it's based upon that stack output, you see how I did the interpolation? I was able to say substitute in and then we can see the actual deployment. And then if we were to say, if we're to go into our friend kubectl, and then if we were to say we want to get the pods Nginx, because that's all there. Now, because I set this config, if I go to run Pulumi up again... Yeah, let me figure out what I... Something doesn't like something in my config here. One second. Yeah, I think we can skip that and just... You get the idea. You get the idea. You get the moral. It's super cool. Yeah, that's... So maybe what we can do, because I know we're starting to run short on time, if there's more questions. I saw one question about Pulumi, what's the relationship with him? And maybe it was before this demo of Kubernetes deployment, but maybe you could just tie it together. Absolutely. Actually, I'm going to... I'll show you a quick one. I'm going to switch over to... Let me... I'm trying to think about the fastest way to do this without changing windows. I have a project I did that deploys a Helm chart. So that's the short answer, is that there's a provider. So I can in my Pulumi code, I can write a Pulumi program, or my Pulumi program, because it might not only be one program that will deploy the Helm chart. And then I can also, with that provider, I can pass the variables that that Helm chart might need. And one of the things that's really kind of important about this, and this is a little bit of the difference between, you'd be like, well, why is how does the Pulumi, you know, running these Pulumi packages versus just running kubectl or whatever, is because Pulumi can also understand not kicking off the next resource till a resource before it is done. So if you have to get something from something else and then maybe inject that into the Helm chart for that to be able to work so you can be able to bring those pieces and parts there. So if you have Helm charts, you can absolutely use them in your Pulumi code. And we do. That's a pretty common case to do. Cool. Yeah, I really like the demo. It was really, even though, you know, some hiccups here and there, but the experience of writing programming language to set up stuff, I can see how it fits together in an application where, you know, today the boundaries are a little bit blurred between what's the app, what's the infrastructure. So that can be pretty useful. Thanks for the demo. Yeah, absolutely. Do you want to quickly again just shout out to the URL where people can go and check out Pulumi? Yes. So if you go to Pulumi.com, there's all the stuff to get started. If you go on to the doc site, which is linked in all sorts of different parts of the nav, there's some substantial number of tutorials getting started. So some of the things that I did today, there's some similar tutorials and you can, you know, bring your own Kubernetes. All this stuff will work with like MiniCube. If you're trying to just sort of test things out, there's just, of course, a few things, you know, that don't happen in MiniCube. And yeah, I would go ahead and give those a try. You can find me on Twitter. I'm at Matt Stratton. Would love to talk about questions you have, help people get going with stuff. That's what they pay me to do. Do you want to tell us about your upcoming appearance in Cloud Native TV? Maybe we'll see. So I do have, theoretically, a Cloud Native TV show that should be going live next week. We're seeing, we might have a little problem, but it's okay. But if you know this about me, I also run an online game show called DevOps Party Games. And so we're going to do something with Cloud Native TV in a similar spirit of just having some fun and some games and stuff. So there's a lot of great shows happening on Cloud Native TV. You should be checking out for sure. I'm really excited to be a part of it overall, and some awesome, awesome folks. Yeah, I also saw someone asking in the chat here, how do I learn about Cloud Native technologies? So I think that's, and also a great starting point. Yes, and actually, I'll give you a little bit of a shout out. There is a very cool project called Tinkerbell for bare metal Kubernetes stuff that is built using Pulumi. And I believe in a couple hours right here on Cloud Native TV, Kat Cosgrove's show will be talking about Tinkerbell, which I think is really, really cool. So, and it's a couple of great people on that episode too. So tune in for that one. Definitely. I'm totally going to binge on that. Yeah. So I see that a few more questions came up. I would ask those people, if you could please write them in the Slack channel that we have. And I believe we've posted that channel name before. Now it goes live on the screen, cloud-native.live under the CNCF Slack. Mati, thank you very much. It was a pleasure. Yeah, awesome. Thanks for having me. It was great. And look forward to seeing everybody in the community and what cool stuff we can build together. Yeah. And thank you, everyone, for joining. Don't forget, next week, same time, different story. Hope to see you again.