 and welcome everyone. Thank you for joining us for this live stream event. Before we begin, I'd like to review two items, our code of conduct. Microsoft Reactor seeks to provide a respectful environment for both our audience and our presenters. We encourage engagement in the chat, but we just ask that you're mindful of your commentary remaining professional on the topic. So this session is being recorded. It will be available on demand through the Microsoft Reactor YouTube channel in about 48 to 72 hours. I'll share the link to the channel in our chat momentarily. If you've not been on a live stream before, if this is your first time to engage in chats for most of the channels we're streaming to, you do need to have an account. So I would take this opportunity now to set that up or sign in just so that we can get all your questions answered while we're live. So today's session, Deploying Azure Resources with Python and Pulumi. Today we are joined by Jay Gordon, a cloud advocate here at Microsoft, and then Maddie Stratton and Kat Cosgrove are joining us from Pulumi. This is a exciting session. We have a lot of people here today and we're looking forward to getting started. So I'm going to pull the speakers up. Hello, everybody. Welcome. Welcome. Let me just pop my camera on here for a moment. Hey, there. Rebecca. Thank you guys so much for doing this. We really appreciate you partnering with us and kind of running through it. I'm sure the audience is excited for it as well. So just FYI, everybody out there in the universe, this session will go for about an hour, give or take, depending on questions as well. Questions can be dropped into the chat throughout. We'll be happy to respond to them where there's an opening and I'll let you all take over from here. Cool. Hey, everybody. My name is Jay Gordon. I am a cloud advocate as Rebecca shared with everybody. I'm really glad to be here. I want to talk to you today about deploying Azure resources with Python and Pulumi and I'm going to say hello to our guests. First, Maddie. Hi, Maddie. How are you today? Hey, Jay. I'm doing well. I'm getting ready for seven to 10 inches of snow here in Chicago tomorrow. So doing good today. Don't talk to me tomorrow. That's terrible. And also joining us from the lovely Pacific Northwest is Cat Cosgrove. Hi, Cat. How are you? I'm good. It is a beautiful sunny day here in Seattle, which is mildly alarming. I'm pretty sure we're experiencing a fall spring. It is February. Should not be this warm and sunny, but I'm going to enjoy it while I've got it. Well, you know, we've got a few more months of winter left here in New York City and it's never going away. It is always going to be cold here. It feels like, except when it's nuclear hot, but that is what it is. You have two seasons? Yeah. We have nuclear hot and oh my God, it's so cold. So rather than talk about the weather, we're going to talk a little bit about infrastructure as code and how to implement it using Python and Pulumi in order to build your resources with Azure. This session is going to be about an hour. So if you're ready, make sure you take some notes, make sure you take a look at all the links, and hopefully you learned something really useful to help you start building. I am going to get us started with just a brief reminder of an introduction to infrastructure's code. So let me bring this up. I'm going to just talk through this really fast because what Matt and Kat have to show me today is far more interesting, I think, but I want to make sure that we're all on the same page. So infrastructure's code doesn't quite trip off the tongue and meaning isn't always straightforward, but infrastructure's code has been with us since the beginning of DevOps and some experts say that DevOps wouldn't be possible without it. And as the name suggests, infrastructure's code is the concept of managing your operations environment like you do for applications or other code for general release. So infrastructure is treated the same way any other code would be. The elasticity of a cloud paradigm and the disposability of cloud machines can only be used by applying the principles of infrastructure's code to all of your infrastructure. So with infrastructure's code, you can capture your environment or environments in a text file, if you will, sometimes YAML, sometimes something else. Your file might include network servers and other compute resources. You can check the script for definition file into version control or definition file, excuse me, into version control and then use it as the source for updating existing environments or creating new ones. For example, you can add a new server by editing the text file with your information in it and running the release pipeline rather than remoting into the environment manually provisioning a new server. This table lists the significant differences between a manual deployment and an infrastructure's code one. Infrastructure's code promotes auditing so that you can trace what was deployed, provides consistent environments from release to release, greater consistency across the development test and production environments, automate scale-up and scale-out processes, allows configurations to be version controlled, provides code review and unit testing, uses immutable service processes, meaning if a large change is needed to an environment, a new service is deployed and the old one is taken down, it isn't updated. Allows for blue-green deployments so that we can swap out an existing infrastructure resource, set of resources into a brand new one, make some changes to our DNS, bring up our new app version and it treats infrastructure as a flexible resource that can be provision, deprovision and reprovisioned. So configuration management refers to automated configuration management, typically inversion-controlled scripts for application and all the environments needed to support it. For example, adding a new port to a firewall could be done by editing a text file and running the release pipeline, not going into Azure and adding it manually. Manually changing the configuration of a single application and environment can be challenging, the challenges are even more significant for managing multiple applications and environments across multiple servers. So automated configuration or treating configuration as code can help with some of the manual configuration difficulties. There are a bunch of benefits to configuration management, bugs are easily reproduced, provides consistency, increased your deployment cadence, less documentation, enables automated scale-up and scale-out, version control helps correct and detect configuration drift, provides code review capabilities, treats infrastructure also is a flexible resource and promotes automation. So there are two different approaches. There is declarative. The declarative approach states what the final state should be when run and the script or definition will initialize and configure the machine to have a finished state declared without defining how that should be achieved. In the imperative approach, the script states the how for the final state of the machine by executing the steps to get to the finished state. It defines what the final state needs to be, but also includes how to achieve that final state. So it can consist of coding concepts like if then loops matrices. And the final thing that I will talk about is idempotency. So it's the mathematical term that can be used in infrastructure's code and configuration as code. It is can apply more than one operations against a resource resulting in the same outcome. For example, running a script on a system should have the same outcome despite the number of times you execute the script. It shouldn't error out. It shouldn't do the same action or do the same actions irrespective of the environment starting state. In essence, you apply deployment to a set of resources a thousand times. You should end up with the same result after each application of the script or template. So I think I've given you a really good short introduction to infrastructure's code and why it's useful. If you'd like to learn more, you can go over to Microsoft Learn. You can check out this module about what infrastructure's code is and how to get started using it. I think it will really help you get some foundation. So that's my introduction. And I hope you're ready because my guests are ready to give you even more detail on infrastructure's code, how that works alongside with Bloomy, and how we can use Python to create those resources. Awesome. Thanks, Jay. Fundamentally, nothing I asked Jay earlier when he was going to the slides, I'm like, am I allowed to argue with your slides if I disagree? And he said, I don't think you're going to disagree. And I was like, ah, a challenge, but I don't. But a couple of things I want to touch on because they address into why Bloomy is different and why we're going to talk about the things that we are. So one of the things I like to think about is we talk about infrastructure as code. And all the things that Jay said about infrastructure as code are true about infrastructure as code. With Bloomy, sometimes we think about this idea of infrastructure as software. And where this becomes different a little bit is what we've done all this time with things like Puppet and Chef and Ansible and Terraform and all these things like we took our code that defined our configuration in our systems and we treated it like code, but we didn't necessarily write. It wasn't code. It wasn't software, right? It didn't have components or, you know, conditionals or things like that. So the first bit of background to understand with Bloomy, and we're going to dig into this and show it to you. But with Bloomy, you write your infrastructure software or your infrastructure as code using a general purpose programming language like JavaScript or Go or .NET. You want to write it in C sharp? You want to write your info code in VB.NET? Go for it, man. It's awesome. Or in Python, as we're going to address today, that's what we're going to show. Everything we're doing today using Python as an example is exactly the same in the other programming languages that Bloomy works with, with the difference of that it's the flavor of the programming language, right? So like, you know, but everything we're doing, if you are into C sharp, nothing that Kat's going to show you or that we're going to work on today will fundamentally be any difference. So that's one of the advantages, right? Like you already number one, you have maybe knowledge and skill with this programming language, but also you have the whole ecosystem of that programming language, the IDEs, the testing tools, et cetera. And one other thing that's important to think about with Pulumi, so Jay talked about imperative versus declarative, right? Which again, in the config management space, we like those words, we argue about that a lot, and we argue about the word item potent. We use those words a lot, which are fancy ways, item potent is a fancy way of saying a test and repair loop, because that's basically what our info code is doing. It's doing a test and repair. It's saying, is this the way that I want it to be? Yes, cool. No, fix it, right? So that's what we're doing. So Pulumi will look imperative because we are writing using a general purpose programming language that is an imperative way of addressing things, but Pulumi creates a declarative state. So you'll, and I know this sounds like I'm being very pedantic, and I am a little bit, but the reason that matters is declarative is how you get item potents. Declareative is how you know you're going to get the same result every time. So what we are going to do today is we said, okay, well, we're doing this thing on Reactor, Jay's an Azure advocate. So, okay, cool. Let's build some Azure resources. That's rad. Cat is a very accomplished Python developer, as opposed to me, who is a very accomplished Python installer and copy-paster. But we're going to, yeah, we're going to write a Pulumi program to deploy some stuff to Azure and kind of go along and explain how this might be helpful and useful. And as questions come in, we'll either answer them as they come or kind of catch towards the end. Let it rip. Yeah, definitely don't. If you have a question, you don't need to wait until the end at all. Don't feel bad about interrupting me or interrupting Matt talking. A lot of this will be Matt talking while I'm writing code, because I have, as I'm sure you may have noticed, an extremely loud keyboard, and you can hear it in the next county. So I'm going to be writing some Python. We're going to build a little Pulumi project. I'm kind of the pundit here. Cat's like, cat's on the field and I'm the pundit. Color commentary. Well, miss click clack. I already have a question for you. And I think it'll help you kind of kick off what you're going to be talking about. Okay. So Siegfried wants to know, please compare Python versus C sharp for use with Pulumi. So for this use case, there isn't really like a functional difference. And that's true for like most use cases. The thing about Pulumi is that the behavior is consistent regardless of which programming language you're using. So if you're more comfortable with C sharp than you are with Python or TypeScript or Go, you can use C sharp and the outcome is going to be the same. Like there is an Azure native provider that works in C sharp, just like there's one that works in Python or Go or TypeScript. So it's not any different. There is no comparing to do in that case, really, which I think is great, actually. That's really cool. That's super useful. It's much more flexible that way. It doesn't force you to like make a developer learn a language that they don't already know or that they don't really like. They don't really understand well, which is a benefit over using like a domain specific language. You can use whatever you're comfortable with. I will drop into the chat. So we're doing an example using Python with Azure. There are a, I'll put in the link that is basically a whole bunch of different bits of example code that are using C sharp. And if I poke around a little bit, if we have a little time, I might even be able to find the example that looks almost exactly like what Kat is doing. I think there's one in TypeScript and there should be, I think there's one in C sharp or you can at least drop them the C sharp. I just said the C sharp. Yeah, I just actually did the Azure. Yeah, that should take them right to the examples repo. Actually, sorry, let's, there we go. Jay did it. Someone who could put in the main chat did it for me. But yes, we'll talk through that a little bit more. But yeah, but the idea now you may see as you look at examples, we don't necessarily have examples published for every use case with every level we're working on, on that just takes a little bit of time. But fundamentally, the API references the same, the approach is the same. So it's whatever makes the most sense for you and what you know and what your team knows. Yeah, which I don't know. I love that about it because I don't know C sharp at all, but I do know Python pretty well and go tolerably well and TypeScript also tolerably well. So that's a lot of flexibility for me on a lot of toleration there. Well, let's see how well you know Python cat. Let's do it. Oh, I'm sorry, Kat. I just want to say I love the fact that we can allow teams to use what they know rather than having to add a new DSL into a domain specific language into the way in that they're doing work. Sorry about interrupting. Please. No, you're good buddy. I do hesitate to call myself a good programmer. But here we go. You're the best trier. I try so hard. And that's that's ultimately what matters. We're just we're here to make friends and try hard. So shots fired. Yeah. All right. So here we go. I have moved all of this over into a GitHub repo for y'all. I will drop this link in the stream yard chat so Jay can share it with everyone if you want to follow along or if you want to do this later. Because I do we do have this setup so that you can open it in Git pod, which is what I'm going to be working from today, which is really cool. This includes two labs. We're going to be going through this first one because it's it's relatively quick, but it's also relatively clear what's going on. So let's get on over into the get pod. I have done a couple of things already here that are just, you know, kind of awkward to do on a live stream. I have logged into Pulumi with my token, and I have also logged into the Azure CLI. The get pod is going to install the Azure CLI and Pulumi for you. Go ahead, Matt. That's exactly I was just going to say that the get pod will have handled. Your prerequisites to doing this work is you need to have the Azure CLI installed and you need to have Pulumi installed, which in this case, the get pod had that for you. That was helpful for me to say what you just said. Thank you, Maddie. I appreciate you. You're here for backup. What Cat talked about needing to be logged into Pulumi. What that is is so when you run a Pulumi program, it is going to have, it has to have somewhere to understand your state, right? Your state is, remember, we talked about like test and repair. Like what is the state? Is the state where I want it to be or is it not? And Pulumi supports a bunch of different back ends. You can store it in Azure Blob Storage. You can do it all sorts of different ways. The easiest way is to use the Pulumi service, which is free for individuals. And then that way when, and we'll kind of cattle show you as we build some stuff, we'll be able to use the back end to sort of see what's happening besides just what we see in Azure. So a couple of things Cat's doing here as I'm narrating. So every Pulumi program is basically a directory full of files. So she created a directory called IAC Workshop. And then while inside there, she ran the Pulumi new program. Now, Cat, can you back scroll the tiniest bit? I want them to see the command you put. Okay, she said new Azure Python. So there's different templates. So if you could just say, you could say, for example, Pulumi new Python, and that would generate a Pulumi program that was scaffolded just for Python. In this particular case, there was an Azure one, which it did a few things. So like if you know anything about Python, which I know very little, but there's that requirements.txt, right? So this is saying these are the libraries or the packages that are needed for this program. So because we did the Azure Python one, it added the Azure provider to that. So and then one of the things, okay, you're going a little fast with a couple of things. So what the first thing when it got created, it creates this Pulumi.yaml. This is just the overall projects configuration. And the only thing that really matters in here is the runtime. It says this project uses Python. Now, the other thing that happened is there's config, so Pulumi has this idea of what we call stacks. And the stack is like an instance of your program. The first default stack is called dev. So when cat had to set a configuration, which was what Azure location do I want to be in, it doesn't set that globally across the whole program, because maybe you want to use it differently in dev versus pre-prod versus prod. So that created that Pulumi.dev.yaml. So this is configuration that's specific to that particular stack. And Cat, I don't know what you did after that. What is, what is, did you just already start your program? Nope. This is, so what happened? Is it still Pulumi.new? Yeah, so it is installing all of my requirements for me. Now, it, it, I did not have to run a Pulumi.up or a Pulumi.new or whatever for that. It's, it's just going installing the pre-rex, which for some of these takes a little bit of time. And there's not really anything Pulumi can do about that. It's a Python thing, but now it's done and all of my requirements are installed in the virtual environment that I have not yet opened. Okay. So for that, because you're, you're getting, you want to speak a little bit about this virtual environment and how you're going to be working, because this is very Python-y. This is very Python-y. So I don't know C-sharp, so I can't comment on how, well, okay, I know how it works with dependencies, but so in Python, you don't install your dependencies, like globally, like by the way you do with like JavaScript or TypeScript. Things exist inside of a virtual environment, inside of a bubble when you're working in a project, ideally. Now I can go and install all of these requirements globally, like in the entire this container, but that's bad practice. And we try to avoid doing that because it kind of gets really messy really quickly. If you wanted to, sorry, with C-sharp it's, I don't remember exactly, but like for example in Node, right, how you're, unless you specifically install a Node module globally, it installs it in just the context of the project. A Venn virtual environment in Python is like that, right? It's like that. So now I'm inside of the virtual environment. You just set your source to this directory was created like by Pulumi, and that includes a binary to activate the virtual environment. There are other ways to manage virtual environments in Python. This is the one that is built into Python. It's the one that comes with it, but there are like third-party packages that do it a little bit differently. So here we are inside of our virtual environment. If I wanted to install all of my requirements manually, which you may need to do if you end up on a new machine, you just do that. PIP3 is... What happened to your... We lost yours. There you go. Okay. I muted it while I was typing the command. Oh, got it. Got it. Got it. Yeah. So you just go PIP3 install minus R requirements.txt, and that'll install all of your prerequisites, all of your dependencies. However, Pulumi has already done it for us in this case as a part of creating the new project, which is really cool because I'm lazy. Yes. And then you know what's standard. And then you know what's standard. So this is what Pulumi has created for us by default. This is the template that you get when you create an Azure Python project. It goes ahead and defines a resource group for us, imports some dependencies, sets up an account, and exports the primary key of the storage account. This is the export that'll show that to us if we were to run Pulumi up. So when we run... So this is like Kat said, this is sort of a default program that might be what you want. It might not be. But a couple of things to look at when we kind of look back if you scroll up a little bit. Because again, by the fact that we're using a programming language, it lets us do a couple interesting things. So the first thing we want to do is we need a resource group. So that was kind of a boring little bit of code. It's just saying create an object called resource group, and it's a new resource group. But then where this gets interesting is if we look at the storage account. So if you look at line 12, you'll see you have to say for this storage account, what is the resource group I want. And we can refer to that programmatically because we created it and it has a parameter that is dot name. So this is the kind of thing we start to see about because we're using a general purpose programming language. We can pass values around as those things get created, things we might not know what they're going to be. And that just continues all the way down, right? And then like Kat said, with Pulumi, we have this idea of imports and exports. So an export is something that maybe I want to pass that value back to the command line. Maybe I want to pass it to another Pulumi program. It's just getting something out of there. And in this case, it's just the primary. We're going to do some more interesting things though. Yeah. So first I'm going to delete all of this and build some stuff like piece by piece so you can see how it comes together. And also more importantly, so that you can see how you can change a Pulumi program after you've already set it up. So let's start by deleting absolutely everything by retyping some of that exact code. One of the things that as Kat does, I want to point out is that you'll see there's, now at this point, this is just adding some Python packages. But when she starts to define resources, you'll see that there's going to be some type ahead. Oh, look at that, right? So equals resource dots. You know, it can, are you not getting that type ahead? Do you just save it so that it knows the packages? I have to save it. It might be that just like VS code misbehaves inside of the pod because it does do this if I like use VS code natively. But yeah, we'll find out. Okay. So, but the point was there's no Pulumi plugin for VS code. This is all because it's what's built into the programming language. So like the packet, you know, whatever VS code knows about what to do with the Pulumi Azure native Python package, it can VS code or your IDE in however way knows what to do with all that stuff. I think I don't want to go off on a tangent, but I think this is a weird VS code thing where I think you needed to pip install those packages outside of the VENV so that VS code knew they existed. You don't need to do that. Oh, I remember running into this problem. This is a very Python specific thing with VS code. Yeah, this is a Python specific problem with VS code, yeah. But we're getting the idea. Okay. So what we had here just to again, all that we've got, we've created a resource group and then cats exporting its name. And then when we run Pulumi up, what this is going to do is it's actually going to run something called Pulumi preview. So this is going to, it's not going to actually do anything. It's going to say if I were to run this program, this is what would happen. I would create a new stack because we've never created that stack yet before, and I would create that resource group. And if you were to, if cat were to go into details as the option, it will, oh, you could do this too. Also, the other difference too, like this is the, we talked about seeing the back end. So everything that we're seeing there is available on the web. So if you were to click the diff, I think that would show you, you can actually see the very detailed specific things of what it's going to do. Now, I want to, okay, let's go ahead and run our Pulumi up. Okay. So this is now going to reach out there. Now, one of the things that you didn't see us do, but just so you know, like cats that we sort of like the environment variables have already been set to what Azure Tenet and the service principle to use this, there's, it all depends on how you create this. Yeah, and there's like a little bit of weirdness with accessing the Azure CLI from inside of the Git pod. So that's, that's why we use the set up the environment variables beforehand. So we saw that we had in the output, it output, it said it created a resource group that's called my resource group. And then there's kind of this identifier at the end. But it's like, but wait a minute, if we look at line four, we called it my dash resource group, we didn't call it my resource group 5B614682. So how did that happen? So we go ahead and add a like semi randomly generated. It's just, it's a UUID to the end of the name for purposes of avoiding collisions. This is not as controversial as it sounds. This is the thing that we, like we do by default, but you can overrule this. It doesn't, it doesn't have to be this way. I am keeping it that way for ease of like the code being more readable and, you know, one less thing for me to explain in an introduction to a whole like tool and potentially concept that you're unfamiliar with. But just know that this is the default behavior, but you can overrule it if you want like a unique Cuban readable name for each resource, which is what I do. Or a unique, if you know it has to be unique. And there are definitely cases where you want that. Yes, Jay. Hey, I'm back and welcome back. Hey, thanks. Well, we have a question. Let's go. Lovely audience. Basileo asks, is it possible to create Python libraries to create libraries that manage the creation and maintenance of my resources? So I can just define the resources in the stack yaml file. What do you say? You can get very, very close to doing that. Like, so actually, to be honest, you could, if you have all of those things are set as configuration parameters. Actually, I'm going to take a step back when I say you can get very, very close. And I'm actually going to say that is actually exactly how you should, one of the ways you should use Pulumi, right, which is that those values are all set as configuration. So we're not seeing like, for example, the value that cat set of the region, the Azure provider uses that natively. So we don't have to do anything, but we can write code inside our code. We can grab any of the values from the configuration. Yeah, and I'll show that later on in this. Like, yeah, there is a point where I like, I change something from, I will change something from like hardcoded to a config value. So I can show you exactly how we do that. Perfect. Then we will, then we will absolutely be covering that. It was a great question. Yeah. Cool. Okay. What are you going to do? So we got our resource group. You can also do this. I'd like to point out. Oh, so you can like, at any point, see the outputs of your stack, if you need to use them for something else. And those are accessible to like, to other things. So if you want to grab the output of a stack and consume it in some other way, like if you need some other application to consume the output of a Pulumi program, you can do that. Because it's just like there, vibing with the Pulumi stack output, which is pretty neat. But yes, now we are going to add some more stuff to this infrastructure. We're going to add a storage account. So Matt, I'm going to mute myself. And oh, yeah, I got to mute myself. That's fine. I'll talk it through as we go. Okay. So this is going to look similar. But again, remember that when we create a storage account, so now we have to add storage because we had just imported from the provider, just those particular parts of the library. So now we're going to say, okay, we're going to name it, we're going to call it account. It's going to be a storage, a storage account. And again, we give it a name, which it's going to have a unique identifier at the end of it. By the way, we're not going to show it because I don't know enough about what's in our Azure to know if we're going to create a conflict. But you see how all of these things that are happening, these are all the arguments or the parameters. One of those parameters is name. So if you set that where you see how, for example, she said skew equals blah, blah, blah, at that same level, if cat said name equals cat is awesome, then the auto naming goes away and it just becomes named that. That said, unless you have a really strong reason, like, we have something else that picks up and, you know, like, maybe I've got something that's managed outside of Pulumi that needs to know that this, you know, cloud front endpoint or whatever, sorry, now I'm talking about AWS, whatever, is called exactly this, then you could do that. Okay, I see Bob Kusumoto asks, are there Pulumi specific extensions for VS code? And there are not. And the reason is there's, I have yet to figure out what one would be that we don't get automatically just from the programming language. Yeah, this is again, because of we're not getting the type ahead because the way it got set up and this might be a little bit of the thing. But like if usually you would be getting all of the type ahead that like when cat starts to do dot storage account, it will know all of those because it's Python, the Python interpreter, I guess is the right word or the language host reads it from the package. So okay, something happened. Uh, I have a typo somewhere is what's going on. Is it called resource? Oh, you always can love when you're doing it live. Honestly, I have had I've had a live demo like a live coding thing go flawlessly one time, one time, and I was so uncomfortable the whole time. I actually don't like it. It's like when you build Ikea furniture and there's parts left over and you're like, Oh, no, it just it feels like live coding. There should always be something that goes wrong. Like I should fat finger something. Right. Like, otherwise, I don't know. We learn from failure. Don't we do we do and part of like that's part of our job. Right. Like you get to watch me make a mistake live and debug it, which is cool. So, so, okay. So this went now we got now. So this is if you want to just really quick for fun cat, you want to bop over to the console, the plume console, because now we've done a couple things so we can see our history. So go back to yep. So we had our dev stack and we can see none of this is terribly interesting. But if you look at activity, we can see the two times that cat ran, pull me up and what changed. So the changes we can see that. And again, the timeline, it'll show us everything that happened. Actually, timeline might be interesting. So you can see it ran this. Now, here's a fun one, which I don't think it's going to look go to resources at the top and click the graph view. Now, there's not a whole lot of resources in our Pulumi program. So this is not a terribly interesting graph. But as dependencies start to happen, this view becomes very, very interesting. So that's all fun stuff that happens on the back end, especially if you're using the Pulumi sass, if you're if you were just storing your state in blob storage, you don't have all of that wonderful stuff. All right, so we're going to get okay, we're going to export out the storage account name, because we want to know what it is. Just because we need that I'm not going to run another Pulumi app. Yeah, just to get that. And and and actually I think if you did a Pulumi preview, you would actually get the name because it knows it. So do a Pulumi up but don't run or just do Pulumi up but just don't run it. Yeah, don't don't apply it. But I think it will give you that value. Yes. So you can say no, we don't need to we don't need to run a whole up just to get that value back. But cool, what are we doing next? We're going to actually throw a container at it. Like a container like a blob container. Yeah, as we say here, throw it. Yeah, we're going to throw we're going to throw a couple two tree containers at it. Hey, you know, do what you got to do. So again, and what we're what we're getting to at this point is eventually getting some some, you know, basically creating kind of a static set of stuff. Now this is not necessarily a thing you might do as part of the stuff that you're building, but you're seeing how these building blocks go together. Okay, I see a question in the chat from Anais says I dropped in late, how would I get started with Pulumi? Well, one way is you could actually just go to I believe it's as easy as Pulumi. Let's see if I can do it. Is it getting if oh, oh, oh my goodness. Okay, I'm going to have to have a conversation that Pulumi.com slash getting started. Oh, it's not work. No, we need to redirect. I will here's the Anais. Oh, it is. Oh, yeah, yeah, yeah. They said nice things about you already. I just put in the chat. So the link for our getting started. There's a bunch of tutorials. There's also a really we have some learning paths. I'm also going to put these links in that somebody who can get them to the rest of the world will share them. Yep. Thanks, reactor folks. Yes. So the learn path will go through Pulumi fundamentals and actually right now I think they're mostly written those workshops or journals are happened to be in Python, but we're adding the other languages to them as as we speak. Okay, so we put the blob container and basically just made a container called files. So there's nothing in it yet. But now we have it. It'll go ahead and create that relatively quick. And now you'll see the blob container name. It couldn't in the preview. It couldn't tell us what that output was because it didn't exist. It hadn't been created. But now again, I'm pointing at my screen and you can definitely see what I'm pointing at. We can see that it has a value. Cool. Should we put some files in there? Is that what we're going to do next? This is no, this is where we're going to start talking about using Pulumi's config. Oh, yeah. So there is the lab two for this does get more complicated and involve like a serverless application, but we don't have time for that. So instead, we're going to talk about using Pulumi config to make this like a little bit more flexible. So you saw me early on when I was setting this up set a config value via like the Pulumi CLI. It was asking which region I wanted to deploy this in. And I left it at the default, which is West US. Now you can change that. And that's one of the configs that Pulumi just like just handles by itself. You don't have to import Pulumi config in your code to do that one. But if I want any of these hard coded names to be a little bit more flexible, I want it to be a variable. Maybe it depends on whether this is dev or pride or, you know, you just decide that you want something to be named differently for whatever reason or you're importing a value from another application and it needs to be able to change. It's not static. We do that with Pulumi config. So yeah, a little bit like the question that came up about, could I define things in the config and then, you know, so someone would just have to create a stack and they wouldn't, you know, to get the thing they wanted. And that's honestly quite a bit of how a lot of Pulumi programs that you share within your organization will work. Yeah. So right now our blob container is just called files. So like we're clearly just using it for like flat file storage, right? We're throwing like whatever cat pictures in there. But maybe I want this to be a little bit more flexible than that. So instead of giving it a name explicitly, we just do this. Okay. So now if I try to run Pulumi up, this is going to barf because I am not giving it a required config value. So I've said here, like this is a hard requirement. I need to be explicitly told what to call this before Pulumi can touch it. So it yelled at me. So which then that's helpful if you know that your program you're writing, you want people, they won't have the ability to run the Pulumi program without setting those. And it also does give even the command, you'll see it's a set of value using the command Pulumi config set, you could do it manually in the YAML yourself if you felt so inclined. But you know, now one of the other things we're not going to dig into right now, but the reason of that so Cal go ahead and set that you can also set values that are encrypted that are secrets. And if a config value is set as secret, it will be encrypted in the config file, but also Pulumi knows to never ever ever show that value in a log or in a stream or anything like that. So those kind of where those kind of go in now in this case. Cool. So yeah, so now it's holding it by container name. So we should see. And again, it does Pulumi doesn't know in the preview because it hasn't evaluated to know what that actual name is going to be yet. Even though you would think it could because we set it in the config, but because it has to evaluate the program and see what happens with the cloud resources. I think you're still in your I hopped over to the output from this to know, but I was like, was it this run or was it the run? It was this one. Oh, yeah, it was this one. So you can see here that all it did was change files, which was the hard coded name before to HTML, which is the name I gave it through config. So and that that holds true for like literally anything in here. I mean, like I guess in theory, you could like write most of this through configs, but it would be really awkward and inconvenient and over the top. And now that I think about it, that's like super stupid. And I'm probably going to do it for fun. Well, you could, I mean, but if you think about it, because there's this is the where the abstractions come in, right? So like there's certain things that you, you know, your subject matter expert who writes a plumi program who knows like when we set up these things, there's the dials that people can change in the dials that they can't, right? I this is this is the example I used to give a long time ago, which will date me because I'm going to talk about Tomcat for a minute. But I might say let's say I was writing a program to get an instance of Tomcat and I'm the, you know, Tomcat genius like so I know the 150 different configuration things you could set. Kat just wants an instance of Tomcat and knows three things that she wants to set about it. So one of the ways you could think about it is in your plumi program, you're defining the shape of the dial. And then in the config, people say what I want the dial set to, but you also don't have to expose every configuration as something that someone can set because you might say, for example, the region, you're like, Nope, we just insist that everything's in West US. I mean, please don't do that. You know, it doesn't, you don't necessarily have to allow that to be overridden. But then again, you might say the name of it is a different thing. So yeah. So I have created not a whole bunch of resources, but you know, some resources on Azure that are now sitting there on my like employer's Azure account just vibing. But I don't want them to be there anymore because I don't want to get yelled at for clogging up our Azure account with a bajillion resources from workshops. So what if I'm done working on this and I want it gone? You just run plumi destroy and we get a little preview of the things that it's going to delete just like every time we stood something up just to just to make sure that you actually want to delete these these things. Say yes, and it goes this one takes usually, I don't know, a minute ish tops. This one's actually it's going pretty fast. So cool. Well, while you wait for that in the minute ish, we could use your help answering a question if that's cool. Let's go because we've got we've got plenty of time for questions now. Sure. Damola asks, can plumi help in a situation where there is already resources created in Azure or doesn't need to be created from scratch with polumi? So it doesn't need to be created from scratch with polumi, right? Matt, like it already has like the resources have names and stuff and IDs. Like if you can do it to the Azure CLI, you should be able to I want to kind of where there's already resources created. Oh, I think I understand what the question is what you would need to do and what you can do is so you can import. So polumi can only manage things that you've told it about, but you can point polumi towards your infrastructure and it will slurp in those existing resources. And then you can start to manage them in state. So like you said, if there's already resources created in Azure, you can can get from that. Yes. Yeah, so it's not you're not stuck like starting over from scratch or whatever just because you want to switch to polumi. Like if the you're using something else to manage your infrastructure, there's there is a way to import that into polumi or like if you can manage it with the Azure CLI. It's yeah, same thing because this is this is a native provider that we're using. So so actually that's a really good point. Let's talk about that for one second. So the provider when we call it a native provider in polumi, what happens is the Azure provider is built basically nightly from the API spec from Azure. So that means as soon as Azure exposes a new functionality in Azure, you know, within 24 hours, you can use it in polumi. And there are even certain things that are not exposed through that API spec that are still in our provider. So when we look for stuff where we're like, okay, there might be a feature in Azure that is just not through the through the through that spec that we can build, it still ends up getting handled. But the vast majority of it comes from that. So that's actually a really powerful thing about the native provider and the Azure one especially. So does anybody have any questions for us? Comments? Vibes? Problems with your life? I mean, yeah, if you've got problems with your life, you want to talk about Matt and I are we're here to listen to you. This therapy session just got weird. Oh, I'm so glad my therapist isn't a software engineer. I would be I would just talk about work all the time. You know, sure. So you've got like about 10 minutes left. I just want to keep you abreast on time. So what are your shows? What you got? Well, so we showed the, okay, so you've, you know, we've cleaned up after ourselves. Now one of the things before you, so Kat, why don't you go so you'll see, like it said, it said the resource was deleted. But no, no, no, don't do that. I'm going to go look at it. That's what I wanted to say. I was going to say we actually, even though all those resources got deleted, we still have all of the history, all of the things that happened, you know, so if we went and ran it, but, you know, in this case, you know, Kat really, you know, just wants this gone. So we can actually delete the entire stack. And then all of that history and everything is gone, you know, which to be honest, this is a thing that you, you know, deleting a stack like this is a thing as a developer advocate and someone who's just demos does all the time in real life. You should very rarely, right? Unless you're just like, this whole project is over, you know, we built a new feature and like it's just dead. It's just gone. But yeah. Yeah. So then now if you, you should 404, I think. Yeah. If I refresh this, it'll 404. Yeah. Because the stack is not even there. Yeah. So this organization does not have a project named IAC workshop because it's just, I nuked it for orbit. So it's gone. You just see my other ones. So there's a couple of things I would say as well. If there aren't questions and stuff, I will give a link. If you go to plume.com slash resources, that's going to be a lot of, you know, kind of upcoming, whether they're streams or conferences or workshops or things that we've got going or recordings of past ones. To keep an eye on that, we do, if you want to learn more Pulumi stuff, if you go to youtube.com slash Pulumi TV, we have a couple series, Modern Infrastructure Wednesday, Quick Bites of Cloud Engineering. And every Thursday, we stream at twitch.tv slash Pulumi. So if you tune in tomorrow afternoon, I will be, I apparently decided I'm taking my personal website that's built in Hugo, and I'm going to write Pulumi code to deploy it to some cloud providers somewhere. And we're just going to see how it goes. It's not going to be a slick demo. It's just going to be maddy live coding. So, you know, come in and maybe I'll give out prizes or something. I'll figure something out. I'm going to hackle at the minimum. People love prizes. Yeah. People love prizes. Well, any last minute questions for us about Pulumi, about infrastructure as code, about being developer advocates, about Twitter? Wow, that's a... Well, you know, it looks like right now we are just about out of questions. We're going to ask our audience. If you have anything left to ask about Pulumi or Azure or Azure and Pulumi, feel free. If not, we can start wrapping up. Hi, Rebecca. Hey, I figured I'd pop on and do my survey thing while we wait to see if there's any questions that come through in the interim. So I dropped into the chat just to survey. We ask our audience who you are. Just tell us a little bit about you because we build our content around our audience. So just let us know a little bit about your learning level, what interests you have, et cetera, et cetera. And then if you are not familiar with the Microsoft Reactor program, if you're tuning in from another channel, do feel free to find us. Check us out. We have on-demand content on YouTube from all of our live sessions. We post them over there. You can find us on Twitter. We are on Meetup. We have 12 physical spaces around the world. So find your time zone that works for you and check us out. And that's that. I think Jay, did you have anything else to follow up with or? No, I just wanted to say thanks a lot to both Kat and Maddie. We had a really good time. We learned a whole bunch of stuff. I think that if you wanted to find a new way to deploy your applications and not have to learn a new language, this really will just hit your zone. So definitely check out Volumi. Check out all the resources that we provided you with today. Both Kat and Matt, thank you so much today for being part. And so I'm going to ask you, Kat, first, where can people find you on the Internet? Where can't you find me on the Internet? I am constantly online in a way that is potentially unhealthy. But you can find me on Twitter at Dixie3 Flatline. You may also attempt to send me an email at kat at polumi.com. I am notoriously super bad at responding to those. So good luck. I love the terminally online. We are a good breed. We're doing our best, Jay. Yes, I agree. Hey, Matt, same question. Where can everybody find you on the Internet? Yeah, same thing as Kat. So you'll find me on Twitter at Matt Stratton. That's the easiest way to hunt me down. You can, if you want to work on something together, polumi-related or whatnot. I love collaborating, either writing blog posts, doing a stream, doing a video. I am Maddie at polumi.com. I read my email maybe more frequently than Kat. I even sometimes star it and need to respond to that. No, I star it to respond to it, and then I don't. No, I'm kidding. Actually, if you need something and we're joking, but if you want to collaborate on something, another thing, if you do want to do collaborating, if you send an email to DA, like developeradvocates, at polumi.com, that'll come to our whole team. And we would love to work on stuff with you. Stuff like, this is great. We do streams. We do videos. We do blogs. If you're doing something awesome, let's do something together. And if you forget all those email addresses, just find us on Twitter. You don't have to be a professional speaker or an internet hotshot or whatever to do something with us. If you are just a software engineer doing a cool thing and you would like to collaborate with us or just use us as a resource, you can. Please reach out. We'd love to. Sounds great. Well, I think we're ready to close the shop. I really have enjoyed this, and I know our viewers have. Francis just sent us a note and said thanks for the fun intro to polumi. Thanks for watching Francis. And I think that's about it. I just want to give a big shout out to Rebecca, who helps put all of these together. Thank you so much, Rebecca. Thank you guys. And thanks everyone. And thanks for tuning in until the next time.