Pass Amazon AWS Certified SysOps Administrator - Associate Certification Exam in First Attempt Guaranteed!

All Amazon AWS Certified SysOps Administrator - Associate certification exam dumps, study guide, training courses are prepared by industry experts. Amazon AWS Certified SysOps Administrator - Associate certification practice test questions and answers, exam dumps, study guide and training courses help candidates to study and pass hassle-free!

Elastic Beanstalk for SysOps

6. Beanstalk Deployment Modes Hands-On

Okay, so let's do a hands-on with these deployment options. So I'm going to go into my production environment, and on the left hand side, I'm going to go to the configuration. Now in this configuration, if I scroll down, what I'm going to see is rolling updates and deployments, and I'm going to click on Edit and view the different settings. So at the top, it says "Application deployments." And this is what we are actually interested in seeing in the exam, so we can see your deployment policy. And we have four of them. We have to update all the instances at once, and this will take down my application for a bit. Rolling to roll on the existing E-two instance, which will still take a few downtimes before updating the application and bringing it back online. rolling with an additional batch where we create new EC2 instances.

And so this will be done a little bit by little bit, but we will not have availability problems. And finally, Immutable can just create an entirely new auto scaling group, create new instances there, and then transfer them over to the old auto scaling group. Okay, so as you can see, for each of these settings, we have a batch size. So, for example, for rolling, I can say if it's a percentage. For example, I would say only 30% of the instances at a time can be taken down, or a fixed number. For example, only one instance at a time can be taken down.

So this is good for Immutable. We don't need to enter the batch size. I don't know why they asked us to do so, but here we go. We don't really think you should need to have a batch size for immutable data anyway. So we have a deployment policy that is immutable, and we're good to go. Now on the configuration updates, as we can see, we could also specify a way to update the machine settings and the VPC settings. But this is out of scope for the exams, so I'll just leave it disabled, and then deployment preference is how you want to have health checks, for example, for deployments and look at the healthy threshold and the command timeout. For now, we don't worry about those either.

The only thing we're really concerned about for the exam is the application deployments. And for this, we will use immutable. Hands on. Okay, I will apply this, and we're good to go. Now we need to actually do a deployment. So for this, we need to deploy a new application version. So if I apply this configuration first, then I'm going to go back to my Beanstalk project environment, and any time I do a configuration update, this will launch an update of the environment. And so we need to wait a little bit for it to happen.

Anyways, while this happens, we're going to open a new tab and call it Beanstalk, go to Google, and type Binstock sample application zip. And so here we can get the tutorials and samples. And in here, I will just scroll down and find the sample application for NodeJS. So I'm going to go and scroll down, and here in NodeJS, it says NodeJS version one zip.So you click on it, you download it, and then you unzip it.

So in there, we can see a couple files that are very specific to NodeJS. There is a JSON packet that explains how to start the application. There is an index HTML that contains, well, the HTML files that we've seen in the web browser chromeYML just for scheduling tasks for the app JS, which is the JavaScript code used to launch this application. You don't need to really know anything about it.

There's also the.ed extension file. We'll see what that is in the next lecture. So first thing I want to do is basically modify the colour of my applications, and in the index HTML file, I will scroll down and find that green color, which is right here as the background color. So we have a text column background color, and I'll just change the whole thing to say blue, right? and I'll save it. So this is basically how you update the index HTML file. Then you have to zip this entire thing up. So I went ahead and I'll provide the zip file for you in the code directory that you downloaded at the beginning of the course. So, with the updated code blue because it can be difficult to zip these files at times and there are a few errors under Mac,

So we'll use that updated file and upload our applications so that the text background colour will become blue. So, let's return to the Beanstalk console. I'm going to update, upload, and deploy. So I'm going to choose a version. And so I have zip-filed my environment, but you can just use my zip if you want to. So it's NodeJS versus Two Blue Zip. This is the environment I've created and zipped for you. If you don't want to zip it, this is a good alternative. Or sometimes when you zip it on some platforms, such as Mac or Windows, you can run into problems. So you need to specifically zip it with some commands. Anyway, I have a zip for you; you can reuse it, and it's going to be much easier for this hands on.So here's the version label. I can call it the "blue" version to name it, and then we can look at the deployment preferences.

So it's going to be immutable. This is the one we set in the configuration for a healthy threshold. Allow the false health check to pass, and then set the batch size percentage to 100. This is great. So we'll click on "deploy," and now my blue version is being deployed onto our Beanstalk environment. So the cool thing about it is that we can see what happens in the events and see what is going on. So the first thing that happens is that the mutable deployment policy is enabled. And so we'll launch one instance with new settings to verify the health. So this is where a new auto scaling group is created, as well as an instance within that auto scaling group. So as we can see now, we created a temporary autoscaling group, this one. So, while this is going on, we can go to the health page and check the status of our instance. So far, we only have one application, healthy. And overall, it says that an application update is in progress.

So, let us return to our surroundings. On the left hand side, we can quickly go to the ECU console, go to the autoscaling groups, and in here we should be able to see this new temporary autoscaling group. So this one has been created; it's called Immutable Stack. And one instance has been launched within it. So let's go back into bin stock; it should detect it very soon and start deploying that application, our new version application, onto this new EC2 instance. So yes, it says adding new instances to the load balancer, and that's waiting for those instances to pass the health checks. So if we go back to the Help tab, maybe we'll see something else. So we can see two simple instances in this health tab: the health check is running for 17 seconds, and we can see how long this deployment is taking.

So while this is done, this should pass the health check very, very soon. And so yes, the health check has been passed. And so now the new instance is going to be added to the permanent auto-scaling group. So it's going to be transferred from the first auto-scaling group to the second auto-scaling group. And so if I already opened my new environment, I should see, yes, some blue. So the blue application has been deployed. Now if I refresh, I only see blue. So we've been very quick. The old green application is being taken down, which is great. So we've completed our first immutable deployment and must now wait for everything to finish, but it now says waiting for post deployment configuration to complete.

But overall, we have successfully run an update of our production application into the background by updating a new version. So this was very successful. Okay, so now my product application has been successfully deployed. It took about ten minutes for this deployment to happen. And so the reason why I did this is that now we have a green environment and a blue environment. So let me close everything else, and we can be very, very clear. So, if I open it in a new tab, this development environment is green. And the second one, the production environment, if I open it, is blue. So we have a green environment and a blue environment.

And so what I want to do is show you the blue-green deployments by doing what's called a CNAME swap. So if I click on the production environment and then click on action, I can swap the environment URLs. So I can swap this URL of the development environment for this URL of the production environment. So let's do it. We'll swap the environment URLs, and this will modify the route 53 DNS configuration, which may take a few minutes. So we are going to take these two environments right here and swap them. So the prod environment is going to be swapped with the end environment, so the dev environment. And so what this will do is that this will become blue, and this will become green. So let's try it out. We're going to swap these out, and this will take a while because this is a CNAME type of operation. So this is something that needs to happen on Route 53.

And if your records are already cached, then this will take a while. But what I'll do is wait a little longer and show you that this will turn blue. so from green to blue, and this will become from blue to green. So let's wait a little bit, and I'll get back to you. So I have waited a few minutes, and hopefully this will work. So let me refresh this page and see now that it is blue. Excellent. And if I refresh the blue page, it is now green. So we have successfully performed a blue-green swap. So what I'm going to do is just reverse what I did. So I'm going to do another environment swap, this time swapping production for development, to get my environments back to normal. But that's it. You've seen all the ways to perform deployments on an elastic beanstalk. I hope you liked it, and I will see you in the next lecture.

7. Beanstalk for SysOps

Okay, so in this lecture, we're going to see what makes Beanstalk special for Cisco's exam. So the first thing you need to know is that Beanstalk can put your application logs directly into cloud watch logs. Then you manage the application. So you manage all the application code, and AWS will manage the underlying infrastructure.

AWS is responsible for ensuring that the ELB, ASG, and EC2 instances are operational. So you don't have to do this; you can still view them, but you don't have to manage them. Then you need to know the different deployment modes for your application. So everything we've seen in place—rolling, rolling with additional batch immutable, and blue green—is critical for you to understand the differences.

And if you get a route-3 type of question, you can definitely put an alias or CNAME record on top of your Beanstalk URL. That works really well. And finally, you're not responsible for patching the runtime. So if NodeJS or PHP has an issue with a vulnerability or anything like this, it's not up to you to patch it; it's up to the developers themselves to do it. So overall, I would say that beanstalk questions are quite basic in the CIS exam compared to the developer exam. But there are a few tricks, and the trick I'm going to walk you through is the next one. So with this bin stock, you need to understand how it actually deploys applications.

So the two easy instances will have a base AMI. And the important thing is that that can be configured by default. We use a base AMI; that's the default one, but we can configure that one and customise it for our needs. Then EC2 will get the new code of the application, and it will resolve the new application dependencies. and that can take a very long time. So if your application has a lot of dependencies and a lot of things that need to be pulled from the internet, imagine that every EC2 instance must do this, and that's very long. And then finally, when this happens, the apps get somewhat swept up in the two instances that the new version is running while the old version is not running anymore. And so the important thing to understand here is that resolving dependencies can take a very, very long time.

And a question, a very popular one now in the exam for Beanstalk, is: how do you make this time much shorter? How do you release a new version with a lot of dependencies on the OS or the app as soon as possible? And the reason the answer is yes is because you can use the golden AMI to fix the problem. So "golden AMI" is just a glorified term. Basically, that's saying if your application has a lot of application dependencies or OS dependencies and you want to deploy it as fast as possible, you create a "golden AMI," which is basically a standardised company-specific AMI on which you pack the OS dependencies, the application dependencies, and maybe some company-wide software.

And so why would we use a golden AMI? It's just an AMI, as you can see, but it just has a lot of stuff that's specific to you on it. And if we use a golden AMI as the base for easy to instance when deploying an application to Beanstalk, our application will not need to resolve all of these dependencies or configure itself because the configuration and everything is already done on the AMI.

So the AMI is kind of like something you do once, and then you make sure your application is packaged correctly on the AMI. And when you deploy it to Beanstalk, then their deployment is very, very quick because the application is already configured and ready to go. And so if you use a golden AMI in combination with blue-green deployments, which basically create a new ASG for all these things, then yes, it will cost you a lot more because you use blue-green, but it will be very, very quick, and that's a nice way to deploy quickly.

So I hope you remember this. Now, for troubleshooting Beanstalk, there could be a few questions about it. We've seen firsthand how the health of your environment can change. The log can then be looted by reviewing environment events. You can pull logs from the log file entries or from the cloud watch.

And you can even roll back to your previous working version of the application in case a new version actually corrupts stuff. When you access external resources, you need to make sure that the security groups are correctly configured.

So if you try to access the RDS database and it's external, make sure that the RDS database does allow traffic coming from your instances from Binstock by using security group rules. And then, in case of any command timeout, you can increase the deployment timeout. So if your entire Beanstalk environment fails because, I don't know, it took too long to resolve dependencies, you can always increase the deployment timeout. So that's it for the beanstalk.

Remember, it's a little bit simpler than the developer exam. And if you've done the developer course, then you should be very confident with Beanstalk. But that golden AMI thing is, I think, something new that you have to remember. Okay, I hope you liked it, and I will see you in the next lecture.

8. Beanstalk Cleanup

Okay, so to just clean up this section, please click on Applications on the left-hand side. Then you will select your application. Finally, select Action and Delete application. And this would go ahead and delete both environments, making sure that you don't spend any more on Beanstalk. So that's it. I will see you again. The next lecture

CloudFormation for SysOps

1. CloudFormation Intro

Welcome to this section on CloudFormation. In this section, we'll learn how to manage our infrastructure using code. Now, I know that some of you already know about cloud formation. We haven't covered this in depth yet in the developer course. I know some of you do not know about confirmation yet. So I just want to outline the fact that it is a very important exam topic.

And as such, I've included all the basic lectures from the developer course. So you can catch up if you don't know about it, and if you already know everything about it, you can still watch time. However, you can then proceed to the additional AdvancedSetups lecture. And basically, they will go over troubleshooting and the advanced class options, and there are many of them. They will also go over CFN in it as well as the CFN signal script. I hope you're prepared. Let's get started.

2. CloudFormation Overview

We are getting to the fascinating section on cloud formation, and cloud formation is one of my favourite topics in AWS. It is something I could talk about for hours and hours, but I'll try to make it short for you and for this exam.

So, infrastructure as code, what is it? Well, currently, we've been doing a lot of manual work. I mean, we've been doing manual work; we've automated it a little bit with elastic beanstalk. We configured our pipelines so that we could automate our CI CD using code bills, etc., and a code pipeline. But all this manual work that we've been doing is kind of tough to reproduce, right? If we want to reproduce it in another region, here we go again. We click, click, click everywhere. and that's a bit boring. It would be even more difficult to do it in another AWS account.

Even if someone in my company went ahead and deleted everything, forcing me to recreate everything in my region, that would be a nightmare. So what we really want is code for our infrastructure. And so that's a new concept, and this is quite a new phenomenon—a new training in the IT world called infrastructure as code. And so that means that this code that we're going to write will be able to be deployed, which will in turn create, update, and delete our infrastructure. This is where cloud formation comes in. Cloud formation is going to be a declarative way of outlining your infrastructure for any kind of resource. and most of them are supported.

For example, let's take a high-level sudo confirmation template and say I want a security group and I want to install machines using this group; I want two elastic IPS for these machines; and I want a rebuild cat. And by the way, I want the load balancer that is connected to these machines. So we say it in a declarative way because this is what we want cloud formation to do. And then cloud formation creates all these things for us in the right order with the exact configuration that we specify. And that's quite nice. So the benefits of cloud formation, which I'm sure you're already aware of, are that, for starters, we get our infrastructure as code, so no resources will be created manually, which is excellent for control.

All the code can be version controlled, for example, using Git. So we can version-control our cloud formation, which is nice. And all the changes to the infrastructure will be reviewed through code review, which is also very nice. In terms of cost, confirmation itself is free, but each stack that you create has an identifier, so you can easily track the cost of a stack and estimate the cost of your resources using the confirmation template itself.

So if you want to have a savings strategy using cloud formation right in your development environment or your smaller accounts, you could automate the deletion of all the templates at 5:00 p.m. and then recreate them at 8:00 a.m. safely. And so, because your infrastructure is code, everything will come back up, and you will save a lot of money. Productivity will benefit from cloud formation as well. So you're able to destroy and recreate your infrastructure on the fly as many times as you want.

You can automate the generation of diagrams for your templates, which is very useful if you make presentations, and it's declarative programming, so you don't have to figure out what comes before—in terms of ordering or orchestration—cloud formation tracks and it does that for you. There's a true separation of concerns as well. So you can have as many tags as you want for many apps and many layers. And so it's quite common to have a VPC confirmation stack that creates all the networks and the subnets. There is an application stack, so for each application you'll deploy, there's going to be an application stack.

So that's something we've already seen with Elastic Beanstalk. Each time we created an environment in Elastic Beanstalk, it went ahead and created cloud formation templates behind the scenes. And so the idea is that we want to reuse as much work as possible out there, so we're not going to reinvent the wheel. There are a lot of confirmation templates on the web that we can already leverage, and we can also leverage the documentation, which is huge and sometimes hard to navigate, but on the documentation you will find everything you will ever need to know. So, for confirmation, how do they work? Well, we always upload the templates to Amazon S3 behind the scenes, and cloud formation pulls them from S Three.

And so when we want to update the templates, we actually can't edit a previous template, like we'll see in the next letter anyway. However, we must upload a new version of the template to AWS, and then cloud formation will do something different and figure out what it needs to do to update from version one to version two. Stacks will be identified by a name, and the names can be very long. And if you delete a stack, every single artefact that was created through the confirmation stack will be deleted with it. So it's really nice because you can delete all these resources that have been created with one click, and you're sure that you're not leaving anything behind.

Now to deploy cloud formation templates. There's a manual way in which we added templates into cloud formation designer and used the console to input parameters, and then there's the automated way, which is to add a template in a YAML file using a text editor, and then you use the AmazonCLI or command line interface to deploy the templates. It's the recommended way when you want to take some automation out of your flow, but you're free to choose either manual or automated; I think they're both fine. In terms of the building blocks, you're going to learn quite a lot about those in the section, but there are the template components, so we'll get the resources, and the resources are basically the AWS resources that we'll declare in the template, and that has to be a mandatory section.

OK, your confirmation template cannot work if you don't specify resources. So resources can be easy to access for machines: elastic, IP, security groups, load balancers, name it; everything you can think of really has parameters. So these are dynamic inputs that you can ask for in your templates. So users will just reference those mappings, which are static inputs for your templates, static variables outputs, which is basically saying, "Okay, out of our template, we can export some stuff, and other templates can reference it conditionally," which is a list of conditions.

So if statements are basically to control what gets created and metadata overall, we'll see a deep dive into all of those. So don't worry too much; you'll get to understand them in their own time. And for templates, you get helpers. And so you can use references, so you can basically link your stuff within your template, and you can use functions to transform data within your templates. So, again, a high-level overview, but I just wanted to give you this 101.

Now this is an introduction to confirmation to me; it takes over 3 hours to properly learn and master cloud formation, and I do teach it somewhere else. So this section is really meant for you to get a good idea of how it works, but not drill too deep into it because it's not needed for the exam. So we'll be slightly less hands-on than in other sections, but still hands-on enough so you get a good idea of how things work.

We'll learn everything we need anywhere to answer questions for the exam, so do not worry about this. And the exam does not require you to actually write down cloud formation. It will mostly ask you about what feature you should use in cloud formation to perform XYZ. As a result, you should be fine. So the exam, though, expects you to understand how to read cloud formation, and we're going to read a lot of cloud formation in this course. So that was a short introduction to cloud formation. In the next lecture, we'll go ahead with a small example to get an idea of how it actually works. So, until the next lecture.

AWS Certified SysOps Administrator - Associate certification practice test questions and answers, training course, study guide are uploaded in ETE files format by real users. Study and pass Amazon AWS Certified SysOps Administrator - Associate certification exam dumps & practice test questions and answers are the best available resource to help students pass at the first attempt.