Praneet Loke – Pulumi Demo: Merging with confidence with Pulumi

Hi, my name is Pretty Low-Key, and today I want to do a demo of Pulumi and GitLab, and the topic that I want to talk about is how can you merge with confidence with Plumy and get labs? So I hope you all had a chance to catch up with Chris Smith from his talk about infrastructure testing. But there are two important concepts that I wanted to talk about were related to the demo today.

One is the the fact that as part of your merger request pipelines, you're running previews from Paluma in order to see if changes that you make in your branch will affect your infrastructure and in some way. And then once your merger request is approved and you merge the request, your Master Branch pipeline is going to run the up command from Pulumi to actually apply the update to your infrastructure as well as any application code. And so this is a great way to kind of separate the the fact that you have this review pipeline that that only shows you a possible desired state as well as any diffs with what's what's already out there versus what you're changing.

And then once you're merged, actually applying the update itself. And so you get get a preview of what how your infrastructure can actually be affected. So without further ado, I wanted to dive right into the demo here.

So first I wanted to show the setup of our pipeline itself. I pipeline here, which is which which just has one stage. And we use two two jobs in this one that runs the preview as part of merge requests.

And then the other one runs just for the Master Branch Builds, which is otherwise known as the merge builds or push bills, whichever terminology you're used to, and actually runs the Pulumi Up Command itself. The scripts that those jobs are running are pretty simple. For the preview step where we're restoring dependencies and selecting the plumy stack and then running the preview Command and then for the run Bloomy script were once again pretty much doing the same thing.

Except for this time we're running, Pulumi up and then passing the dash dash five, because this is a secure environment and it's not interactive. So of course, there are some things that you can do here, like caching dependencies and whatnot, which get Guillaume's offers. You can do artifact caching as well as dependency caching to speed up your pipeline.

Since this is a demo, I've kept it really simple, but there are some advanced features that you can take a look at by reading through some docs. As far as the gloomy application itself, we have a very simple application here that deploys a static website using the Plumy US package. Paul-Louis supports a lot of cloud providers, major cloud cloud providers, as well as cloud providers or service providers for for those cloud providers as well.

And so in this specific app, we create an S3 bucket and we we leverage the static website hosting feature by specifying the indexed document for for that bucket, which enables the static website hosting feature for that bucket. As well as we we read through the folder from the dub dub dub folder. We read through all the files and upload them as Buckett objects and we also finally create a public policy for this bucket.

Now, of course, I'm showing you a modified version of this. And if we were to change to master, we should see. That, yeah, we are creating a bucket policy that uses that public policy, so for demonstration purposes.

I wanted to show a potential merger request that one of your team members might raise. You're going about your daily changes. And one of the things, as you have a requirement to change the HTML file that that gets uploaded.

And so when when you make a merger request change, you should see that this file is changed and then you're able to merge that. And so let's let's take a look at that. So I already went ahead and pushed a change that changes the index down.

But I also went ahead and changed my index. As I was showing before, though, I have this function that can generate a public read policy. I'm actually I've deleted my public policy resource itself, which will leverage which would leverage that and attach that policy to my bucket objects.

So I've got two changes going on here. But as we all know and have come across, we've come across merge requests where the title says one thing, but then the changes actually are something else. And it's it's very likely that some people may may have been testing it and then they forget to undo the change and therefore a change slips into the merger request and because it was unknown, even though it was unintentional.

So looking at the changes, it's pretty clear that I've I've removed the bucket policy, but I also change the title. But then to a to an approver, the title looks pretty innocent here that I'm just updating the title or the title is pretty innocent looking. But then unless the approval actually goes into the pipeline or looks at the detailed view of the march itself, it's not pretty clear that that the bucket policy is being dropped, which is a dangerous thing here, because this is a public website.

It is a static website that we're deploying. And if the bucket policy for public road access is dropped, then the static website is no longer accessible to to anyone out on the Internet, though, there are some buckets where you don't want public access. This is one that we do actually want the public access for.

So that's a bad thing. However, what if we had a way to show? That the changes that you're making.

Whatever we saw in the merger request pipeline logs, if there was a way to surface that into the context of our merger request itself and make it easy for our approvers to see that the bucket policy was actually being deleted along with the index dot html file being updated. Well, I'm happy to announce that Plumy now supports merger request nodes by way of GitLab Web hooks for both groups as well as project level hooks. So you should be able to set up a web hook for all of your projects.

And if you're using Paluma, you should be able to surface these useful comments in your merger request that really make the infrastructure changes front and center for your approvers or for your code reviewers. And more importantly, it helps you as the author of the mark, also to be aware that you made you made an unintentional change. And that's going to end up dropping the bucket policy, which looks which is a bad thing.

And so it's going to make you as the author of the memoir, to also take a second look at the changes that you've put in and act as the final stopping point for any unintentional changes. The other really useful thing here is we're also able to link into the specific preview for this Pelamis stack. And so, for example, I've got the stack on my local machine for this demo purpose.

But but basically, when you click this link, you'll be you'll be able to go directly into into that preview itself and then see all the detailed changes here. So you can see that the preview says that there's a delete action on the bucket policy and then an update action on the next HTML file. And if we look at the detailed view, you can see that the entire resource is being dropped and then the index is changing because the the content of the file itself changed, which that one is correct.

So. And because Paluma enables tight integration between GitLab, it's easy to see that this preview was associated with a specific merger request. And this was a pipeline number.

And this was the Emaar branch that triggered this preview. And so you get the full context of when did this preview run? Why did this review run and who ran it and such?

And so because I now know that the bucket policy is being deleted, I don't I can take the corrective action to to actually restore my bucket policy. So so I'm going to go back into my code here and. Restore my bucket policy.

OK, and then we'll push up that change. And we should see that a new change to a new change was pushed up to this branch, and we can see that because we pushed up a change to the FMA and note that we have a rule that says we should run the Paluma Prevue job for all merge requests. And so any changes to the merger request will trigger that pipeline to to run again.

And so our pipeline is running again. And when the new Prevue comment or previa note is added by the police service, we will see that the bucket policy is no longer being deleted and only the index HMO file will be will be updated. So while our pipeline takes a minute to run there, let's go back to our slides here.

OK, great. So while we have the pipeline running, I also wanted to talk about the testing strategies. I mentioned that with with the Web hook integration, we can surface the comments about any changes that you're applying to your infrastructure and make them front and center as part of your merger request.

There's also testing strategies that you can adopt to prevent mistakes in your infrastructure, as you probably already are aware, for for application testing. There's there's various ways of writing unit tests and integration tests and to be able to mock dependencies and such with infrastructure. And what specifically with Paluma?

Because we're using general purpose programming languages, you can pretty much do the same thing. So we have various testing strategies here, depending on what you're looking to achieve. You could either use unit tests which allow you to write really quick tests that that validates certain things about your infrastructure, or you can write policy tests that that enforce policies about or security policies or policies that that are organizational level policies on your police stacks.

Or you can also write integration tests which allow you to set up and tear down your infrastructure to to to validate that your entire infrastructure works as you're making changes. com and check out the testing guide to learn more. But let's go look at the the job itself.

And it seems that our job is completed now. And you can see that as as we expect, the bucket policy is no longer being deleted. The only thing that's being modified is our index e-mail staying true to our merger request title.

And you can also see that there's there's been a comment posted here that shows that only the index, not HTML file is is being updated and not the bucket policy is not being dropped anymore. And so if we head over to the preview and we can see to see the detail diff and the plumy console also showing that the bucket object for the indexed HTML file is the only thing that's being updated. So that's that's all I wanted to show you today.

But I hope that you get started with me today and check out our many examples. We also have guides to get you started on setting up Plumy and get labs and using the best practices with git ops and and also infrastructure testing and also head over to the docs to to learn how to how you can set up the Whitebook integration with GitLab and Pulumi and make sure that your infrastructure stays good and you can merge with confidence. All right.

That's it.