Introducing DevOps for Developers

Enable Static Website Hosting

Erik Reinert

Erik Reinert

Introducing DevOps for Developers

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

The "Enable Static Website Hosting" 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 how to enable static website hosting for aws buckets. A demonstration of how the resources look in aws is also provided in this segment.


Transcript from the "Enable Static Website Hosting" Lesson

>> So let's do this, let's go back to our frontend really quickly and let's see if there's anything else that we need really quickly before we move forward. So I'm just gonna get rid of this mostly because I don't really need those variables, and we also don't need getStack.

So I'm just kinda cleaning up the source code a little bit here. So at this point we have a frontend with two buckets. Oh-oh, [LAUGH] let me fix replica here. A replica bucket, right, and then a primary bucket. Outside of some other things that we would need to do, right, let's think about one other thing that we might wanna do here, which is enable website hosting, right?

And this is how you can actually get even more complex with these resources if you want. If I go back to here, and I say, okay, I want static website hosting. Let me ask you something. Do you think it's fair for me to go up to the developer and say, hey, add the policy, add the website configuration, add everything else, and then you're good to go?

You got web hosting. Basically having them add this block themselves, do we think that that would be a good approach, having the developers in the actual component source code? [LAUGH] Probably not, yeah. So what are we gonna do? Can anyone maybe think of, if we go back to our bucket, what might be one simple thing that we can add that can help us solve that problem with our existing bucket?

I'll give you a hint. It's within the DSL, or the domain specific language. Basically, we just do this. That's it. Adding that to the DSL now makes us give the developer the option if they want to make the bucket public or not, right? Again, we want the developers to be able to use these resources on their own and give them the equivalent of bowling alley, bumper lanes.

We are creating the bumpers here, oops, sorry. We are creating the bumpers here, right, and that's what they bump around. So, going all the way back to our technical design conversation and everything we've had before. When we talk about solving problems, especially with DevOps, that's DevOps, that three lines of code is DevOps, the rest, any other engineer could do.

It's true. But us saying if you want a frontend, you have to give it a name, you have to assign it a product, and it has to be known if it's public or not. Those are the DevOps opinionations and standards and practices that we are basically adding. So now what we can do is we can say if args.Public, right, it just becomes a super easy change.

And so we said that we needed a circumstance where our frontends, right, have the ability of having a statically-hosted bucket. Well, that's gonna be here, and a privately-hosted bucket, that's gonna be here. I put true, [LAUGH] would help to do that. Actually, what's a better way of fixing this?

Who could tell me? Because I was just a developer and I did a dummy.
>> The opposite of what you're going to do.
>> [LAUGH] Yeah, that's fair. But how could I lean on programming language so that I make sure a developer doesn't run into the literal gotcha I just ran into?

Make it optional. So what we can do is instead of saying the developer must give the boolean, that it's an optional argument. And so now what this means is this is now a deliberate decision, right? Whereas this one is the default one. So we stay on the course, even with our sec ops and security world, where we are deliberately not allowing access to anything by default.

And then once we add that simple public true, then we can. There we go. And so now we'll see that our FM bucket actually is getting the public access block cuz I flipped it, and our replica is not. So let's just flip that because I am a dummy and didn't do the right logic.

So if not, public. So you can see our replica is now blocked and it's not accessible via the Internet or any kind of public access. But our other bucket is, at least doesn't or it doesn't have that public access block on it. However, we're not done yet, because all we've done is just remove the replica.

Now what we wanna do is just we wanna actually add the rest of the configuration here, right? And so you might be like, well, that's interesting, do we wanna reuse the same bucket? Do we wanna create a new one? It's up to you. What I would suggest doing is trying always use the same resource and then write logic around that, so we are doing this kind of configuration when we need it approach.

So if we go back to this bucket, right, we'll see here that there's a few variables that we care about for both of them, the ACL, the policy, and then this whole website block here. The website block is gonna be specific to web hosting, right? The ACL is gonna be specific to both, and I believe the policy is going to be for the frontend, yeah, cuz we don't have anything there.

So what we can do is, because Pulumi is also typed, right, I can now say const bucketArgs, sorry, actually, let bucketArgs. And then we can start giving it with some defaults. So we could say, all right, acl, that can be private, right? Private by default, because remember, we want sane defaults.

If you set it to public by default, well, that's your own fault. [LAUGH] So then we're gonna do s3.BucketArgs, Just to make sure that we are typing them, right? And then the other thing we want, actually that's it. Yeah, so that's it. So then what we can do is instead of all this, so we can grab our tags too, We can now put this like this and then, see if we need bucket too, sorry, put this right here.

So now we just say bucketArgs, like such. However, it's still only handling the private case. So what we're gonna do now is we're gonna say if args.Public, Then we're gonna say bucketArgs.acl = "public-read", right? Because if it's public, we need to give it public-read access. I don't know what policy they're attaching here, I'm wondering what that is or why they're doing that, but then we'll do the website, right?

So we'll copy this block of code here. And then we'll do bucketArgs., you see that, website, like that. Why don't you, Okay, I copied something wrong. No, I guess it's just how it formats it. Okay, cool. Okay, so now if it's a public bucket, right, we'll set the acl to public-read, and we'll set the website to whatever we've got here, right?

So now, let's go ahead and save this, and let's do up again. Okay, so let's do this. Let's look at the details, actually. So if we look at the details, we get a much more in-depth look of a diff, essentially, right? And if we look at this diff, we'll see that we are creating a frontend, right?

It is our devops-course-example frontend. We're creating our first bucket, which is our DevOps course example bucket, and this is our replica. We look at the replica, we'll see that it's private replica, and look at this, devops-course-example-replica-dev. So even know, by just looking at the bucket name, which environment it's in.

If we go down here, bucket, here's our public one example. And look at this, public-read, devops-course-example-dev, still same naming convention, right, environment, with the website stuff set up here for us. So if we'd apply that, then we'd actually get everything. And as a matter of fact, I'm gonna do that.

So I'm actually gonna go ahead and apply this now so that we can take a look at what this looks like in Amazon. No, that's not gonna work, sorry. Yes, I injected the secrets. Yes. Boom, so I've got seven created. I hope my session didn't expire. Cool, it didn't.

All right, so let's do this. Let's zoom in a little bit. Oop, not that much. All right, and then let's go to, Here. Now, what are we expecting to actually see in Amazon? Just a bunch of buckets, [LAUGH] that's really it, right? So let's see if we get those.

So we go here, scroll down. Look at this. There's our bucket, devops-course-example-dev. And hey, look at that. It's actually saying, hey, this is public, you might wanna be aware of that. So if we go a little bit further and we actually go down to, where is it? Website hosting.

See, yep, there it is. All right, chat. Okay, there we go. Cool, now it's failing because I have nothing in the bucket, of course, but look at that. With the automation we have, out of the box, developers can add a simple block of code, right? I need a new frontend.

Hey, DevOps, I need a new frontend. Okay, cool. What is it called? It's called example-2. Okay, cool. What product is it for? devops-course. Cool, all right, done And there we go. I have a completely separate frontend infrastructure that I just created. And if I go back here, I go back here, sorry, and we close this, and we'd find buckets my name.

Now that this is done, should be able to do devops, and look at that. Now, I have four buckets, right? And they still keep that convention of if it's a public one, it'll get the correct public access that it needs. It'll also make sure it gets a replica that's private, right, all that stuff.

And what's also very nice, let's say we don't want the replica bucket anymore. We don't need it. We realize, you know what, that was kind of an over-optimization. We really don't need it. Done. Now we've deployed two frontends, right? But I removed one resource. And because it's, again, centralized, right?

Yeah, look at that. Look at what it's removing. Just the replicas and everything related to them. So if I do that, I'm gonna go back here. Now we've just got our two.

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