16. [DVA] CloudFormation Rollbacks
So let’s quickly talk about CloudFormation rollbacks. It’s very important to know how they work in case they appear at the exam. So if the stack creation fails, or if you upload a stack and the stack creation fails, by default, everything will roll back. That means they will get deleted. And so we can look at the log to understand what happens. But when you create the stack, you also have the option to disable the rollback in order to travel, shoot what happened, and get a bit more insight into what was created. If you update the stack, which was already created and is successful, and now you update it, if the update fails, the stack will automatically rollback to the previous known working state, which is the green state you just wanted to update. And thanks to error messages, you get the ability to see what happened in the log. So this lecture is all about showing you how rollback works. Okay? So in this example, we are going to show how rollbacks work. But first, let’s go and create a stack. And we’ll use a template that we’ll upload, and we’ll first use the zero, just EC. Two templates to get started with the basis that we know works And I’ll call it the stack failure demonstration.
I will click on Next, then Next, and finally I will create my stack. So this will create an instance, and then I will wait for the stack to be completed in the create state. So my stack has now been created, and I’m going to update it. I’m going to replace the current template, upload a new template, and this time I will choose the trigger failure YAML. So this file should trigger a failure, and I will show you why in a second. So for my security group description, I’ll simply say hello world. Click on Next, and then click on Next, and finally click on Update Stack. So first we just see the change sets, and as we’ll see in a second, the change set is exactly the same as before. So we have elastic IP security groups, and the EC2 instance should be replaced. But I’ve included something in my template that will trigger a failure. So we are working on an update, but let’s go see in the template what the problem is. So if I go to trigger failure YAML and scroll down here in my image ID, I say the AMI is 123456 and this AMI in this region, US East 1, does not exist, and therefore it will throw a confirmation error. So what I want to show you is what happens in confirmation when this error happens. So if we refresh this and go and have a look at the updates, the update is in progress. So the SSH security groups were created. So these were new SSH security groups. Then Confirmation tried to update my instance, but then it failed. And it gave me a reason why the AMI ID 123456 does not exist: it was not found. and that makes sense. So therefore, there was an update rollback in progress, and my EC2 instance has been rolled back. If I refresh this, we’ll be in more states, so let’s go see what happens. So we are in the middle of the update rollback in progress and then anything that was created before. So the SSH security groups that were created during this update are also being rolled back. So as we can see, the SSH security group and the server security group are in deletion progress, then they’re deleted, and then the stack is in update rollback completion. So in this instance, when there is a rollback occurring, anything created during the update, if there is an error anywhere else, will just roll everything else back to where it was before. So it’s good to know. Now let’s try to create a stack. And this time I will create a stack with new resources and I will use an upload template, and it will right away create this to trigger failure. So I will just say failure demo two. And here I will just say “hello,” I will click “next,” and this will trigger a failure right away. And so if I go in the advanced options on the rollback configuration, I can see that stack creation option. I will also see that there is a rollback on failure option, and right now it is enabled.
That means that if there is a creation failure, the entire stack should be rolled back. But if we want to troubleshoot it, we should set it as disabled, and then the stack will be stuck and we can troubleshoot based on the sources that have already been created. So if we leave it disabled, nothing will be rolled back, but if we leave it enabled, everything will be rolled back. So we’ll just create this one. We’ll just say enabled, click on Next, and then click on Create Stack, and this goes ahead and creates my failure demo number two, which should right away give me an error. So I should wait a little bit. My security groups are being created; the process is underway; however, I will soon receive an instance create failure, stating that this MMID does not exist and that my security groups will be rolled back. So let’s have a look. My instance is being deleted, and then right after that, my security groups are also being deleted. So now my stack is in a rollback-complete state, and if I look at the resources, there is nothing; everything has been deleted, and so I cannot travel or shoot. So, if I wanted to travel shoot, I’d have to change the settings from before and turn off rollback on failure. So now the cool thing we can see is that we have two stacks. One is an update roll by complete and one is a roll by complete. So the one stack that has been created in that state cannot be updated. The only thing we can do is delete it. So let’s go and delete it. Whereas the one that has an incomplete rollback is still working. So I could go ahead and update it if we have a fixed cloud formation template, or I can go back and delete it, and this is what I will be doing. So that’s it for this lecture. I hope you liked it, and I will see you in the next lecture.
17. CloudFormation Nested Stacks
So let’s talk about confirmation nested stacks, because these can happen at the exam. So nested stacks are stacks within other stacks, hence the name “nested.” They essentially allow you to isolate a pattern or common components in two separate stacks and simply call them from other stacks. So if you know, for example, how to configure a load balancer really well and you want to reuse that configuration all across the board for your company, then instead of copying and pasting, you would isolate that load balancer into a nested stack and reference that from within your stack. Maybe it’s a security group; maybe that’s an SSH security group that you want to have a specific configuration for it.
Maybe you want to isolate this into a nested stack. And so they’re considered best practices, and we’ll see how to use them in a second. And so, by the way, if you wanted to update an existing stack, you would always update the parent first, then the root stack, and then everything would get updated from there. So that’s the idea. They can have very small questions on the exam. So let’s go take a look at how it works in practice. So let’s create a stack, and this one will be a template file, and that will be the seven-nested stack YAML. So before we do this, let’s take a look at what’s inside that file, obviously. So in this one, we have an SSH key; this is the key pair we’re going to use to SSH into our instance. And now the cool thing, though, is that we have a cloud formation stack as a type.
So we have my stack within resources and the type of stack, which is an AWS cloud formation stack, and that is enough for you to declare a nested stack. So one of the properties is that you must define a template URL, and I use this template URL, which is the lamp single instance template. So we could follow this link. So I’ll just copy this link so you can see what it is. So let’s go take a look in there. And so this is just a template file; it’s in JSON format, but that doesn’t really matter. And so, as you can see, this has parameters. So there’s a key name, a database name, a database user, and all of these are parameters that we must pass, and then there’s a mapping that was defined, and then at the very bottom resources, it will create a webserver instance of type EC, two instances, and it will install using cloud formation. So we can see cloud formation in it again. It will install MySQL, HTTP, and PHP, so a lot more than is in the files. It will basically create an entire HTML file in there, which is quite nice. So as you can see, the cloud formation in it can be used to do some pretty crazy stuff, and the installation goes on and on and on, and at the very end we still have services running and some commands to configure everything.
So the cool thing is that now this stack won’t be copied and pasted into our stack; we’re just going to call it a nested stack. So let’s go have a look here. We’ll simply use a template URL to automatically pull in that stack, and we’ll pass in the parameters key name, DB name, DB user name, DB password, DB root password, instance type, and finally, when we want to SSH from this, the cool thing is that we can reference outputs of this stack directly into our output value. So, for example, by doing my stack outputs website URL, we can get an output from an ingested stack. So let’s go have a look because I think when we actually use it, it will make more sense. So here we go, we’re going to click Next. I’ll call it the “nested stack example,” and the SSH key will be the same as before. Click on Next, and then click on Create Stack. So the important thing is that within capabilities, it’s saying that because you’re using a confirmation stack, you need to acknowledge that you might create IAM resources and also that you need to have this IAM capability auto-expand because it needs to expand the nested stack we just referenced.
So we’ll just take these two boxes and click on “Create Stack.” Here we go. So now our thing is being initiated. So the cool thing is that now this stack itself will be created, and it’s been created in progress. So if we go back to the stacks now, we can see that even though I uploaded only one file, a nested stack example, within this thing there was a new stack with a new stack name that was being created, and that is the whole file that I just showed you from before, which is right here. And so this stack is, as we can see, nested. So it says they are nested right here, and within them we can look at the events. And here we see the web server security group, the web server instance, and everything else being created as we speak, as well as a description. So all these things are from within the nested template. So now the only thing we have to do is just wait for the web server instance to configure itself.
All right, so it looks like this nested stack has been completely created because the wait condition has received a success signal again. But now if you go back to my parent stack, which is called the “parent stack,” the main one, then if we go into resources, as we can see, we can get a crate complete. And as soon as my nested stack is finished being created, we get a fullcreate complete for the parent stack as well. So the really cool thing is that if we go to outputs now, we get a URL to access our underlying easy-to-instance, and that comes directly as an output from the nested stack. So let’s go take a look. It also says hello to the aqua formation PHP sample. and it says I connected to localhost successfully. So that’s pretty awesome. I mean, it’s just pretty basic, but it shows how nested stacks work. And then, most importantly, you’d never touch the nested stack, ever. You don’t update this directly. What you would do is update the parent stack, and so what we would do is delete everything; we’ll delete the parent stack, so I’ll delete the parent stack, and automatically my nested stack will get deleted as well. So that’s about it. Okay, I hope you’ve enjoyed it, and I will see you in the next.
18. CloudFormation ChangeSets
All right, so let’s quickly talk about change sets. So when you update a stack, maybe sometimes you want to be sure that the stack will update the way you want it. So maybe you want to have greater confidence. And for this, we use change sets and change that will basically tell us what happens, but it won’t let us know if it will work or not. So it’s not a way to just do QA and make sure, yes, there won’t be any failures. Changes don’t work like this; they just help you understand that some things will change, some things will be deleted, and some things will be created. So let’s take an example. From the documentation, we have our original stack. We’re going to create a change set, and then we’re going to view that change set. So we’ll see what gets added, changed, or removed. And maybe optionally, we can create additional change sets if you want to refine our methodology. And then, when we’re ready, we’re going to execute that change set and go get our updated confirmation templates. So that’s the idea, though. We’ve actually used ChangeSet without knowing beforehand. But here, we’re just going to formalize this in this lecture. So for this example, we’ll just use the zero with just EC 2 and then the oneSG with easy 2 with Seep dot YAML.
So let’s go ahead. First, we’re going to create a stack. We’re going to upload our templates, and it’s going to be our zero, just EC 2. just like before. In the very, very beginning, I’ll call it the Stack CS Demo, and there are no parameters needed. I’ll go ahead and click on Next, and I’ll go ahead and click on Create Stack. So this will go ahead and create our EC2 instance for us. All right, so our stack has now been created. And so if I go to the left-hand side, as you can see, there are no change sets right now available. So we can click on here and create a change set directly for the Stack CS Demo. So another way we could do this is to go to Stacks, then click on Stack CS Demoaction and create change sets for current stacks. So there are two approaches. Now we can basically say that we want to reuse the current template and just change some parameters, or we want to replace the current template with something new, or we’ll replace the current template with something new in Designer and upload what the new is.
The new one is this one. One EC, two with SGE, and one with IP. So now we want to know what would happen if I were to apply this update to my template. So I’ll just create a description. I’ll call it FUBAR because I want to be quick. Okay, then we click on Next, and here we go. We have specified the template and the parameters are “FUBAR for the security group description, and I will go ahead and bottom and say “Create Change Sets” so we can describe it. We can name it if we want to. I’ll click on “Create Change Sets” and here we go. Our change set has now been created. So if we go to change set on the left hand side, as we can see, it says “Create Complete,” but it hasn’t been applied yet. Now let’s have a look at the inputs. The inputs are all the parameters and the things we’ve sent it before. The template is what we’ve just uploaded, and the JSON changes represent what is going to change. So the JSON changes are quite hard to read, to be honest. There’s very, very verbal. But if you go to the Changes tab and actually scroll at the bottom, we can see that it is going to add a server security group.
Add an SSH security group. It’s going to modify my EC2 instance, and it’s actually going to replace it. So it’s a replacement. True. So we will lose our current EC2 instance, and a new one will be created, and then it will add an EIP. And so the cool thing about this is that we can see beforehand if we are willing to make this change. Maybe I didn’t want my EC2 instance to get replaced, so maybe I don’t want to apply this. In my case, I don’t mind, so I’ll apply it. But this is why a set of changes will be helpful. So when you’re ready, you can either delete it or execute it. I will execute it, and basically, it just triggers an update that we already know. And so I’ll just wait for the update to be complete; there are no surprises here. The cool thing is that if you go back to change sets now, it will display the most recently executed chance set. But there are no new chance sets you can apply, so you have to create a new one if you want to update it. So that’s it. I’ll just wait a little and then delete that stack. But I won’t film that. I hope you understand how transfers work now, and I will see you in the next lecture.
19. [DVA] CloudFormation Drift
So we’ve seen that cloud formation is great for creating infrastructure, but we are not protected by cloud formation against manual changes in the configuration of what we create with cloud formation. So to make it clear to someone who is not, you could go into the console and change the configuration of some resources that were indeed created with cloud formation. So this is called a drift, and to detect it, we can use the feature called Cloud Formation Drift. So not all resources are supported, but you can go to this URL to check them out. But I found that the coverage was already pretty good. So let’s go hands-on to get a demo of how CloudFormation drift works. So let’s go ahead and practice drift by creating a stack. The template is ready; I’m going to upload it, and we’ll choose three drift security groups in YAML.
We can look at this template in the designer just to see what it looks like. And if you look at the template itself, which is not very handy here, we have two security groups run in tandem, and if we look at them, there is an SSH security group and an HTTP security group, as well as a VPC parameter to link it to the security groups. And so what we want to do is ensure that the configuration of the security groups has not changed over time. So let’s go ahead and first create the template. So I clicked on the Cloud Upload button, which is going to make me click on Next, and then I’ll call it Demo Drift SG. We need to specify a VPC ID. So I will use a drop-down and specify my default one. Click on “Next.” Scroll down and click on “Create Stack.” So the effect of this is that this is going to create two security groups, and as you can expect, I’m going to change the security group configuration manually. So this should be very quick. The security groups were in “create in progress,” and they’re now both completed. So if I go to resources, I have a link to my two security groups. So if I go to my HTTP security group and look at the inbound rule, I can edit it and, for example, change it to say that I want a different cider and add a description.
So fubar, and then maybe I want to add HTTP as well to the security group from anywhere. Okay, click on Save Rule, and in terms of the other security group, which is right here, this one, I can go into Inbound Rule and edit them, and just delete this rule overall and click on Save. So obviously the configuration of our security groups has changed, and therefore I’m going to have to detect the drift. But right now, confirmation is not aware that anything has changed. To make it aware, we can go to “Stack Actions,” then “Detect Drift,” which will launch a drift detection mechanism, and then go to “Stack Action,” view Drift results. You can look at the results, and as you can see, it’s already finished. The drift status is drifted, so there are two modified security groups, and we can click on one, for example, and click on View Drift Detail. So it is saying that the sender’s IP is not equal, and there’s been one rule added. So there are two differences, and they show us what the expected configuration is and what the actual configuration is.
So as we can see here, they’re not equal. And so we can go ahead and either update our templates to match the actual configuration because maybe this is something we want to include in our templates, or we want to revert our stack by making sure this is applied instead. And we could go into Cloud Trail, for example, to see who changed our security group and when, in order to get to the bottom of this. And so for the SSH security group, again, I can click on “View Drift Details,” and it’s modified, and we can see here there’s a change. This rule has been removed, and so the expected is this and the actual is that. So it’s really cool to see the drift because it’s very useful to know if your confirmation templates have drifted every now and then. So I would recommend that you run the drift quite often if you can. You can also access the Drift menu from the left-hand side of the screen, and this will take you to the Drift menu. But that’s it. And when you’re done, just delete this template, and you’re good to go. I will see you on the next slide.
20. CloudFormation DeletionPolicy
All right, let’s learn how to retain data after deletion so we can put something called a DeletionPolicy on any resource we want to control what happens when the confirmation templates get deleted. So we can say Deletion Policy equals Retention, and we’ll specify on any resource we want. And in that case, confirmation will preserve or backup that resource, which is kind of neat. And we can tell it to keep a resource; we’ll use Retain, and it works for anything: resources, nested stacks, whatever you want. There’s another one called “deletion policy equals snapshots.”
And this one is quite cool because it only applies to EBS volumes, the elastic ash cluster, replication groups, the rdsdb instancedb cluster, and the redshift cluster. But what we get is that the actual instance gets deleted for whatever I just named here, but it will make a snapshot just before deleting it. Hence, we can keep our data. So if you have a development environment and for some reason you want to delete the development environment but you want to keep the data for later use and analysis, maybe you want to use a deletion policy that equals snapshots. Finally deletion. Policy equals delete. That’s the default behavior. That’s what we would do. And by the way, there are a few other exceptions. For a DB cluster, the default policy is snapshots. But for the rest of the resources and confirmation templates, deletion policy equals delete. And if you wanted to delete an extra bucket, something you should know is that you first need to delete everything in that bucket and make it empty before you can delete the extra bucket yourself. So let’s go take a look at how retaining data on deletes works.
So I’m going to open the deletion policy. YAML. And very simply, we have a My Security group. This is a security group that enables SSH access on port 22 from anywhere. And the deletion policy for this one is retained, so we won’t lose that security group when we delete our stack. And we have an EBS volume, and it’s an EC-2 volume. And the deletion policy this time is snapshots. And the properties are that the availability zone is going to be in USD one A, the size is going to be 1 GB, and it’s going to be GP two. So when we delete our stack, we should expect the security group to remain and the EBS volume to go away, but a snapshot to be made of it. So let’s go and create a stack. I will upload a template file, and I will choose my Deletion Policy stack. All right, excellent. Click on next, and I’ll call it the deletion policy. And I’m really bad at writing right now, but whatever. And we’ll click on “next” and then “create stack.” And so very quickly for us, this will provision an EBS volume and a security group.
So as we can see now, both my security group and my EBS volume are in the Create Complete stage. So in my resources If I refresh this, I have an EBS volume and I have a security group. So here they are. I’m going to close the rest. All right. Here’s my EBS. Volume 1GB. GP two. And right here is my deletion, my security group. So now what I’m going to do is go to my stack and click on the stack name. and then click on “Action: Delete Stack.” and this will delete the stack itself. So click on “delete.” And so, based on what we’ve seen before, when we delete a cloud formation stack, everything should go away. But because we have specified, if you remember, a deletion policy retained for the security group and snapshot for the EBC Two volume, we shall see a very different behavior. So let’s go take a look. Here we have a deletion in progress. And if we look at the events, as we can see, my EBS volume is getting snapshotted. So it is actually creating a snapshot for us. And my security group was in the process of being deleted. So this is kind of neat.
So now, if we can see, our volume for now is still here. But if I click on snapshots, we can see that there is a 1 GB snapshot that was created for me automatically by cloud formation. So let’s go back to the cloud formation stack and refresh everything. And so we can see now that the snapshot is in Create Complete. So now what should happen is that now that it is in Create Complete, my EBS volume should be in Delete In Progress. So it’s going to be deleted because it’s been snapshotted. So let’s go back to the volumes. And as we can see, we do not have any EBS volumes anymore because they have been deleted. So it’s a cool way to expose how things work. And then finally, our entire stack is in the delete complete stage, so we have no more stacks to display. So the outcome of this is that we have a security group that is still there, and we have a snapshot that gets created for us for this EBS volume automatically. So what you need to remember, though, is that once you do these things well, you need to delete these things manually. So we’ll delete the snapshot manually to clean it up properly, and I’ll also delete the security group manually to delete it properly. But it’s quite a neat trick to see. Remember that we have a deletion policy, that we keep snapshots, and that we delete by default. All right, that’s it. I will see you at the next lecture.
