The Complete Course from ExamCollection industry leading experts to help you prepare and provides the full 360 solution for self prep including AWS DevOps Engineer Professional: AWS DevOps Engineer - Professional (DOP-C01) Certification Video Training Course, Practice Test Questions and Answers, Study Guide & Exam Dumps.

SDLC Automation (Domain 1)

22. CodeDeploy - appspec.yml Deep Dive.

So we've moved on to code deployment, but I never really showed you how it works. So now is the time to look into the app spec.dot YAML file. So if we go back to our repository and look at our coded webpage in here, I've pushed the latest version. So apps.dotYAML contains a bunch of YAML. just as we had build spec YAML for codebuild, we have app spec YAML for code deployed. So this represents how the deployment will work. So the first thing is the version is for now zerozero and the OS of operating system which is Linux. Then we deploy some files, so we have to say where the source of the file is. For example, we have this index HTML file that sits in our repository in our zipfile and is where we want it copied. We wanted this copy to go to VAR www.html, so if we go to our EC2 instance, we can see that the file will be copied there. Let's have a quick look. I'll just connect to one of these two EC instances, and I'll do a small check to see if that file is there. So ctrl-w HTML and then index HTML. Yes, it has been copied. Excellent. Okay, next in here we have a bunch of hooks andI will go into hooks in great details very very soon. Hooks, on the other hand, are scripts that will be executed as your instances' code is deployed. So we have five hooks here: application stop, after install, before install, application start, and validate service. And actually, I should have probably done the before install before the after install, but anyway, this is fine. So we go to code deploy, and in here for the lifecycle events of each instance, we can click on view events, and this is all the things that happened as the deployment happened for code deploy. So the application was stopped, then thebundle was downloaded, then the before installran install ran after install ran andthen application start and validate service. So for all of these except a few, we are able to have hooks. And so this is why we specify a bunch of scripts. And so the first script I will run is application stop, and the script is stop server sh. So if you look at what the script does, we go to stop server sh, and it says okay, look for httpd, and if it is running, stop it. So that makes sense, right? Then we have an after-before install. So what needs to happen before our application is installed? So we have the install dependency script, and this one says "Yum install one minus y for yes, httpd." So this will install an Apache Web server for us. As you can see here, the timeout is 300 seconds. So that gives our script 300 seconds to run, and it will be run as root. Therefore, we don't need to provide a pseudo here because this command will be run as root. Okay? Then after the before installthere is the install itself. But the install itself, well, we don't have access to it. We'll see this in the documentation. And so the next thing that we'll run is the installation. And after the install, you can run whatever you want. But here, I specified something a little bit fun. I said, okay, we're going to fetch the EC2 instance ID and let me zoom in. We're going to fetch the EC2 instance ID using the metadata service on the EC2 instance. So if you don't know what a metadata service is, let me show you in a second. If you go to the EC2 instance and curl this address (1692-541-6954, latest metadata instance ID) and press Enter, you will get the instance ID. But that metadata service contains a lot of information. So if you just remove the last bit, you see that all these things are available as metadata. So for example, if you wanted to see the security groups on our instance, we'll do slash securitygroups, and we'll see that the Launch Wizard One is a security group being attached to our instance. So it's a really fun thing. So I get the EC2 instance ID and the EC2 availability zone, and then I use the set command to edit the index or HTML file, such as now that we have was deployed, which is being replaced by was deployed on the name of the EC2 instance ID and the EC2 AZ. So this is why when we go to our web page, for example, when we go to this public DNS, we see that the application was deployed on this instance ID in EUC. So this is directly from the after-install script; it's just something fun that I let you add to add some dynamism to our scripts. Okay, so after the after install, what goes on? Well, let's go here and see what happens after this. We'll get the application started. So how do we start the application? So we'll use the start server sh, which is servicehtpd start, for this. And the reason it works is that, as we copied our file into VAR WWHL, this is where HTTP expects our index HTML file to be. So this is why it's working. And then we'll validate the service. So, what kind of health check can we have to ensure that everything is in working order? And so here I say, "Okay, let's use the curl command to query for local host ID, and let's see if the word "congratulations" is in it." If we don't have the word "congratulations," then maybe something's wrong. And so it goes, because if we go back to our website, we'll see a big congratulations in here. So this is how code deployment works, and this is how our appspec YML file was created. And as you can see, we're able to hook into all these events to process and customise our deployment a bit. And so this is why code deploy is such a powerful tool: you have all these optimizations and hooks possible for you to customise your deployment to.However, the application is being created. Alright, so when you're ready, when you understand how this file works, I will join you in the next lecture.

23. CodeDeploy - Hooks & Environment Variables

So that app specification The YAML file exposes a few hooks. And these hooks depend on if you're deployed to ECS, to AWS Lambda, or to EC2 with on-premises deployment. So we don't have to know them all by heart, but you need to understand them at a high level. So for now, let's go into the hooks for easy on-premises deployment. So for easy two-tier and on-premises deployment, you have a lot of lifecycle events. You have an application. Stop. That's the hook we've been using when the application needs to be stopped. and the tricky thing about it is that this application stop happens before the new application revision is downloaded. So you need to make sure that if you change the way you change, you stop your application. You do this in two steps. Then there is the download bundle, which, when code is deployed, will go ahead. Let's go here to see it. The download bundle, when code is deployed, will go ahead and instruct the EC Two instance to get the revision from S Three. Okay, next we have the install. And this is where we can have another hook where we can set up any kind of preinstalled task, such as installing packages, etc. Then the install, which is where the CodeDeploy agent is located, will copy the revision files from the temporary location to the final destination folder. And so this represents the file section right here. Then we have our "oops." Then we have our "after install," which is what happens after an application is installed. Application Start, which is how we start applications is another hook available to us, and validate the service, which is the last deployment in the lifecycle events, just to verify that the deployment was successful. But if you use a load balancer—and we haven't used one—you get all these other hooks before blocking traffic. Block traffic, after block traffic, before allow traffic, allow traffic, and after allow traffic, which allows the load balancer to drain the connection onto our EC2 instance and ensure that it is unused before we begin the installation process. And then, when we want to put it back in service, we get all these permit traffic hooks as well. So this gets very, very complicated as to what you get access to. So if you have an in-place deployment, okay, then you have access to all these event hooks. Okay, application stop before installation, installation after installation, and application start? And then, if you have a load balancer, here they are. So for input deployments, they all happen sequentially. But for blue-green, obviously, some will only happen in the original instances. For example, everything that blocks the traffic will happen in the original instances. And everything on the new bluegreen instances will take place on the right side. So you need to see these matrixes. So let's take a look at this from a simpler perspective. Everything in blue is something we have access to that we can change. So if you look at it, application stop, before install, after install, application start, and validate service—we can create these hooks. And these are the hooks that we've created right here. But if we go in here with a classic load balancer, then we have access to more hooks before blocking traffic, after blocking traffic, and then before allowing traffic and after allowing traffic. So you don't need to remember all these hooks you have access to, but you do need to remember that these are hooks that you can have. Some of them are not exactly available to you. Some of them will be available to you. Some of them are only available if you use a load balancer. for example, before blocking traffic and after blocking traffic. And you need to remember the kind of orders that they will appear in. But this is something that should feel natural to you. First you stop the application, then you download the bundle, then you do something before installing. Then you install. Then after you install, applicationstart and validate service. I feel like I'm repeating myself a lot, but I really want to get this point across. So remember to look at the documentation if you don't feel confident about those. Finally, there is something that needs to be remembered for you, which is the environment variable availability for hooks. So every time you do a deployment, you get some environment variables applicable to you. And this is the application name, so okay, which application is this deployment into? So code deploy demo. For example, then you're going to get the deployment ID, which is the unique ID for this deployment, and the deployment group name. So the instances are aware of which deployment group name they're part of, the group ID if you need an ID, and the lifecycle event that is happening at any time. So this is cool because now, thanks to all these five environment variables, we're able to customise our deployment. For example, maybe for the group named development, we want to do something, and for the group named production, we want to do something else. So instead of having multiple apps specs in a YAML file, we could have an if statement in our scripts for our apps file that checks whether or not the deployment group name is development or production. And then customise the behaviour of the deployment from within. So all these environment variables allow us to have some more dynamic features, to have some more conditional features, and to understand that we don't need to create different deploy applications just for the sake of customising a little bit the behaviour of the deployments. So, more theory than hands-on for this one. But what you really need to remember is that all of these environmental rules are available to you, as are all of these hooks. And as such, all you need to create from a deploy perspective is an application and a few deployment groups, and then you're able to customise all your deployments in time. So, that's it for this. I hope you enjoyed it. I would recommend that you check out this documentation because it's very enlightening. And I will see you at the next lecture.

24. CodeDeploy - CloudWatch Events, CloudWatch Logs, CloudWatch Alarms, Triggers

So now let's talk about rollbacks with code deploy. So we deploy new application versions, and at some point something will go wrong and maybe some deployments will fail. Now we need to choose what needs to happen. Do we want to stay in a bad state? Do we want to have automatic rollbacks or do we want to have a manual rollback? So we'll see an automatic rollback in a second. But let's talk about manual rollbacks because they're very easy to reason with. For example, if you haven't set up automatic rollback and a deployment goes wrong, to do a manual rollback, you would just deploy a previous version, and automatically, Code Deploy will try to roll everything back by doing basically a new deployment. So this is very easy. Right now, let's talk about automatic rollbacks. And for this, let's go directly to the deployment group. So I'm in my production instance deployment group, and I will edit it. Let's scroll down and see how to do it. So all the way down, advanced is optional. So here we have the option to select rollbacks. So I'll disable the checkbox that says "Disable rollbacks." And so I can say to roll back when a deployment fails or roll back when alarm thresholds are met. So what is the first option? Roll back when a deployment fails. This means that at any point in time,if any deployment fails on any instance automatically,the deployment will be rolled back. So this is quite handy. For example, if one instance goes wrong, thenwe're done, we stop or and or forexample, roll back when alarm thresholds are met. So it is super important to understand this concept of alarm thresholds because the DevOps exam will test you on this. So imagine we're doing a new application revision and the deployment actually succeeds. We managed to deploy the application onto our new EC2 instances. But it turns out that we are tracking, say, CPU utilization, and our application suddenly skyrockets a CPU. We haven't really tested it, and it goes to 100% all across the board. We definitely want to roll it back because this cannot keep going for long, right? So this is when we would use an alarm threshold. So what is an alarm? Here is an alarm that we can add to our deployment group. And you click on Add Alarm, and you search for a Cloud Watch alarm. So for example, let's go to Cloud Watch and create an alarm. We'll create one right here, and I'll create an alarm, and I'll select a metric. It will be an easy metric per instance, and I will choose Web Server CPU utilization. This could be a per-instance metric, or we could have it aggregated by different types of instances. But for the sake of it, I'm just going to create one. Okay, so CPUT, I'll select this metric, and here it is, and I'll say, okay, you need to click on Next. And we want to look at whether or not itwill be greater the CPU utilisation than, for example, 70%,because this is something that we think is abnormal. 70%. Click on "next. Next. Next. Next. Next. Next, oops, we need to select a notification. So this is great. And next, the alarm name is going to be easy to utilize. Okay, next. And here we go. And then finally click on "Create Alarm." So it's just a dumb alarm that I've created just for the sake of it, right? So here we go to Code Deploy, and we add an alarm. And we are able to—if I refresh this page, okay—go into Advanced Optional and add an alarm to it for easy utilization. So now this is saying what? This is saying that if this alarm goes off, so if we start deploying our application and somehow the EC Two CPU utilisation goes over 70, then this alarm will be triggered, and we can continue deployments even if the alarm status is available or ignore the alarm configuration. But by default, if the alarm is triggered, then the deployment will stop. And if we enable rollback when alarm thresholds are met, that means that if we do deploy and this alarm goes off, not only will the deployment be stopped, it will also roll back to a good version. So this is a really cool integration because we can say, "All right, let's go into Cloud Watch and set up a metric utilisation for all of our Cue instances, network traffic, CPU utilization, or whatever you want." And this alarm will determine if our code deployment is successful or not. And if it's not successful thanks to this alarm, then we should roll back. And so we have some niceautomations right here going on. And so this is something that you have to understand—this is part of the code that deploys native features. It is quite complicated to set up, to be honest, becauseyou need to set up that code, deploy that Cloud Watchalarm, then set up your rollback settings and so on. But it is something that could deploy, can do. And you must know this going into the exam. So feel free to just toy around, read the documentation right here around redeploy and rollbacks for Code Deploy, and read the advanced options for deployment groups as I just showed you, because these will definitely come up in the exam and you will be tested on them. All right, I hope you like this lecture, and I will see you in the next lecture.

25. CodeDeploy – Rollbacks

So we need to know how to use on-premise instances for code deployment, and at a high level, we need to configure each on-premise instance so the code deployment agents register it, and then we have the option to tag on-premise instances. So you need to remember that tagging on-premises instance instances is something that's only available for code deployment, and then we'll be able to deploy application revisions directly to the on-premise instances. So to do it for an on-premises instance, the documentation gives us three ways, and they can be grouped into two different kinds. One is when we use an Im user ARN to authenticate requests, and so we'll have to create an Imuser for each on-premises instance that we create. So that works for a small number of instances. The other option is to use an IAM role ARN to authenticate requests, and I will use the STS Security Token service. This is used to register a large number of on-premises instances, but it is more painful to do. So you need to remember that the second one is definitely the most secure, and you need to remember the steps at a high level. But for this hands-on, we'll do this one where we create an ImuserARN, and you'll see that's complicated enough. Now we'll use the register on premise instance API call. We'll use a second tutorial then because it is the same API call that we'll use for it or for STS. Okay? So let's go ahead and create and choose the second link. So use the "register onpremise instance" command using an im user arm to register an onpremise instance. So the first thing we have to do is create an on-premises instance, and because I expect you not to have an on-premises instance, what we'll do is create an easy-to-create instance, but we'll just call it on premise.So this is a simple two instance, a T, two micro, and we're not going to assign it any role, okay? Because we don't want to fake it, we'll make it look like a VM with nothing AWS on it, and then we'll add storage, tags, and, for the sake of name, I'll say it's on premise. And for the environment, maybe we'll call it on premise as well. Okay? Security group wise, we'll just leave it as is for port 22, and actually we'll just attach the one we had from before review and launch, launch.And yes, I have that key pair to launch instances. Okay? So that instance is the instance we will use, and this is our fake on-premises instance that will register using this tutorial. OK, the first thing we have to do is create an IAM user for the on-premises instance. So for this, we need to create an imuser. So let's go to IAM in here, okay? and we'll go ahead and create a user. So add a user, and they recommend that we identify them by a name that's going to be explicit. So we'll use the username code to deploy the user on-prem. Remember that you need to create one Im user per on-premises instance, and we'll just give it programmatic access because we have an access key ID and a secret access key. Next for permissions, we'll look at what the permissions are and how they're assigned, and they'll recommend that we give it the S three permissions to read from it. That makes a lot of sense, right? We want our on-premises instance to be able to retrieve files from S3, so we'll head over to I am and attach policies directly, opting for S3 read-only. Okay, we won't add any tags to it next, so click on review and create that user. So here is our user, the code "deploy user on demand." We have an access key ID and a secret access key, and I'll just keep this in this tab for now. OK, so we're done with Step 2, then we get the Im credentials. So this is what we have in this open tab, so we'll keep it as is, and then we'll scroll down and we'll need to add a configuration file to the on-premise instances, so we need to create a file named CodeDeploy on-premise YMLand we need to create it at this location. So let's do it right now; we'll go to instances, right-click connect using the easy to instance connect tool, and connect to it. And we need to create this file called EC called deployagent conf, and then within it we need to create this code to deploy on-premise YML, so let's go here and click sudonano, and then the file name is going to be confused. Yamo, and I'm not even sure this will work. Let's see, the directory does not exist, so we need to first create that directory. So why don't we do pseudo-make directory and then just specify the entire directory, so excellent except here I will do minus p so that it creates all the directories in between, so excellent, and now we can clear the screen and use nano to create our file. Okay, now within our file, we need to specify the following: so we'll pace this and there is the secret access key, the access secret key, and this is not really well suited for this UI unfortunately, so let's try VI and see if that works better. So one, two, three, then we have the access key ID, so let's do it and we'll copy this one from Im. So here is the one we want to copy, then we need to copy the secret access key. So let's paste the one that we get from here, and I'll just copy this and paste it. Then we'll need the im user ARN. So we need to get that user's ARN from here. So let's close this, click on this user, and here's the full ARN. So I'm going to paste this in here. And finally, we need the region. And for me, the region is the EU West. OK, we got it. I'm saving this file. So this file has been written, and this step is over. Let's keep on going. and now we need to install and configure the Aus CLI. So thankfully, the A CLI is already installed on my EC2 instance because it runs Amazon Linux too. But we need to configure it. So we'll just do AWS. So I'll clear the screen for AWS configuration, and in here I will enter the same things we had from before. So the access key idea is good, except I don't have them. So let me get them from that code-deploy agent file. OK, so now we're configuring the access key from all the way here. So let me just copy this entirely. Okay, the secret access key is in here, Excellence. The default region name is us-1, and the upper-format JSON. Okay, so now that we've configured the CLI, we need to set the AWS region environment variable, but I don't think we have to do it now because we've set up all these region identifiers. Then we need to install the code to deploy agents. So let's go and install that code to deploy agents. So all these commands are right here; we have to run them. So I'll just paste them in here, and this will run the installation for me. And then finally, we need to register the on-premise instances with code deploy. And for this, we can use the addressCLI and run this command right here. So we'll call the register on presumptive instances, which is this command right here. So let's try it out. So the trick here is that this command has to be run not from the on-premises instance itself, but from our own CLI. So I'll have it here. So we need to register the on-premises instance; we need to give it an instance name; we'll use this asset tag under whatever name they give it, so it's a pretty funny name. Then, for the im user ARN, we must provide the ARN that we just created. So let me get that from my Web browser. So in here I will say that I am managing console; I'll copy this ARN, paste it, and then make sure that it's the right profile I'm using. So it was a DevOps project, and the region I'm in is EU West One. They should do it. Okay, this command has succeeded. So now my instance has basically been registered via on-code deployment with the instance named here and the associated user ARN. Okay, we're almost done, then we need to tag the on-premises instance. So we can either use the CLI or the Code Deploy console. So let's go to Code Deploy, and we can refresh this on-premise instance page. And here we go. We can see that our instance has been registered in here, and so I should be able to click on it to add tags to it. For example, I could say that your name is on the premises, and we could have the environment be developed and submitted several times. And here we go. Our instance has been tagged. So this is excellent. And then finally, we can deploy application revisions to the on-premises instance. So we're ready to create a first deployment. So how do we do this? We will create in our application a new deployment group. I'll call this one on-premises instances, and it's in place. It's going to use on-premise instances. And here we can use the environment for development. I think that's the one that I had. Okay. And then disable load balancing and click on "Create Deployment Group." Here we go. So we have created a deployment group for the on-premises instance, and finally I should be able to create a deployment to it. So, on premise, here is the last revision. I want to publish to it, so I click on Create Deployment. And here we go. The deployment has been created, and hopefully it's going to be successful. So it's in progress. It's installing the application on our instances, and by the end of it, it should be all ready to go. So the thing I want you to remember out of it is that we have run a lot of different steps, and the takeaway is that we have eleven steps. But the major point here is that we have to use an Im user credential for each on-premises instance. So this is fine for a small number of on-premises instances, but it doesn't work at scale. So at scale, you need to look at this other tutorial, and we're not going to do it. It's a bit more tricky, but you need to use an IM session arm and the STS service to refresh temporary credentials. And this allows not only for more automation but also for more security. So these are all the steps, and we're not going to do them. And this is pretty painful to do. But what I'm going to remember out of this is that yes, in this case, we can use an Im role instead of an IAM user to register our on-premises instances. The other thing I want you to remember is that in code deploy, when we went to our on-premise instances and registered them, we had to tag them correctly. So we had to add them, for example, as a name tag or an environment tag so that, for example, the deployment groups in code deploy could appropriately get them and understand how they work. So that's it. And I'm not even sure this is actually working right now. I probably missed something, which is probably fine but is still in progress, so it's probably not working very well. But I hope you get the idea of it. I probably just messed up my configuration file, to be honest. But the idea is that for on-premise instances, we set up code-deploy agents to use a specific IAM user, register the instances, tag them, and we should be ready to go. So that's it. I hope you liked it, and I will see you in the next lecture.