Introducing DevOps for Developers

Storing Static Resources

Erik Reinert

Erik Reinert

Introducing DevOps for Developers

Check out a free preview of the full Introducing DevOps for Developers course

The "Storing Static Resources" Lesson is part of the full, Introducing DevOps for Developers course featured in this preview video. Here's what you'd learn in this lesson:

Erik demonstrates creating Components by extending Pulumi's ComponentResource class to create a new class component. A discussion regarding the results of Pulumi initially bridging Terraform providers to Pulumi is also covered in this segment.


Transcript from the "Storing Static Resources" Lesson

>> So let's actually start programming now and start focusing on our problem. So if we go back here, right, why don't we start with front ends? We have store our static files in an ingress of some type. And we said that basically, in some regard, we will need at least a bucket or something like that.

So, how I like to structure things, and again this isn't standard, this is just how I like to do it, is I like to lean on two main things. The first one is just folder structure, having good structure around where things are so that you can easily access them.

So what I'm gonna do is I'm going to first create a directory and I'm going to call it resources, right. These are going to be what we can kinda consider as our raw resources that are gonna get reused over and over and over and over again, right. And then the second thing we're gonna do is we're gonna create a directory called services.

Services use resources, right? So what we want to do is we want to first set up a base of resources, and then we wanna create services that are reusable, like a front-end service, a back-end service, things like that, right? So we're gonna go into here. And we're really just gonna delete everything outside of the main three lines, or actually the main two lines at the top.

So we're just gonna keep those two lines. And so then what we're gonna do is we're gonna go into resources and we're going to create a new file for that. And we're gonna say file bucket.ts because we're automating, right, we're automating. Why do two things twice? If necessary, we can create one bucket definition and make that, even an interface as well that we can work with.

And this is a common concept in Pulumi that I'm going to introduce you to called Pulumi components. Now, if you've ever worked with TerraForm, you might have heard of TerraForm modules, basically the same idea. Pulumi allows you to take a series of resources, and then logically group them into a component resource very similar to how front end even works.

And so the whole idea here is is that we're basically saying we're gonna create a class called my component, right? And this is going to extend Pulumi's component resource. Well, what does that mean? It means that we're literally taking the component resource class that Pulumi uses, and extending it to making our own.

After we do that we then create a very simple constructor and use the super to define what the actual name of the component in that stuff is? So if we wanted to, we could literally just copy this. Go back to our source code. Right, and then paste it.

Right, we're gonna change a couple things though. First, we'll call it a fmbucket, right. Why would I say fmbucket, does anyone know what fm might mean? Frontend Masters [LAUGH] we want to not just create a generalized bucket. Why do we not want to do that? Because if we have to create another one later, then we have to discern between the two of them.

You always need to understand that even though this might seem like a perfect solution. Something might come up, right? So in what I try and do with naming conventions is I try and focus on what's the problem I'm solving, right? I wanna create a standardized front-end master's bucket that the rest of the company can use.

If they need a bucket, they use our bucket with our parameters and things like that available to us, right? So we're gonna say we need a fmbucket, and then it's gonna complain about a couple of things that we need to import. So let's go and do that really quickly as well.

So we're gonna go to the top, we're gonna say import Pulumi from Pulumi and I think that might be it. I don't want my editors freaking out. Okay, there we go, cool. All right, so we've imported Pulumi and we've created our very simple bucket. Now, again, if you've ever worked with automation before, you're probably used to looking up documents and copying things from documents and basically doing that.

We're gonna do that. [LAUGH] It's not that different still, even with what we're saying, except for we're going to give opinions around it, right? So we said that our class is fm-bucket. So let's go ahead and make sure that our component name as well is an fm-bucket, right?

And then let's find bucket automation, right? So we're just gonna say Pulumi AWS bucket. And sure enough, Google, or DuckDuckGo I should say, gives us the answer we're looking for, which is we want to find a AWS bucket here. Now before I go any further, there's a couple things to note about Pulumi, and I'm gonna just kinda give this as a forewarning.

When Pulumi started adopting to basically becoming a product, there wasn't a lot of support for providers and so what Pulumi decided to do was essentially bridge Terraform providers to Pulumi. So a lot of the resources, customization, options, and things like that are in some cases literally one-to-one to Terraform because its generating from the same essential provider, and it's creating a Pulumi variant of that.

And so, if you ever find yourself in a scenario where, you can actually go to the Terraform documentation [LAUGH] and find that. However, there are some things that Pulumi just kinda realized that, and so they're now doing what they call their classic and native approach. Classic really just means Terraform or used to be Terraform.

Native means now we're gonna write it in Pulumi source code and it's actually fully supported by Pulumi. There's no translation or anything like that involved. The native packages are nice, they're not feature complete. So you might find yourself in a scenario where you get really far with one of the two, but then there's a random attachment resource that isn't there and you gotta go use classic or something like that.

So I recommend using the classic ones for now until you know for sure that you can move to them. Now because we did a Pulumi AWS thing, right. If we look at our package.json, we'll actually see it's already here, right, it's right here. So we don't have to worry about it because we did the Pulumi new AWS type script.

It set it up for us, it added all the stuff for us and everything like that.and they do that for a few things, I believe there's an Azure Typescript as well, and stuff. So just so you know, it took care of it for us but you might have to install this package if you're starting from complete scratch or something like that

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now