SDLC Automation (Domain 1)

27. CodeDeploy - Deploy to AWS Lambda

So now let's have a look at a very high level of how code deployed with lambda works. So we'll create an application and call it Lambda Deployment Application. Okay? And then the computer platform is going to be AWS lambda. We'll click on Create application and here we go. We have the same kind of UI and need to create a deployment group. So we'll go ahead and create a deployment group and we'll call it the Demo Deployment Group. And we need to attach a service role to it. So we need to create a specific service role for code deployment for lambda. So let's go back to roles. For creating a role and deploying code, here it is. Lambda permissions. We take permission policies very seriously. Click on tags for review, and I'll call it code. Deploy the lambda role. Okay, let's create the role and it has been created. So back to our deployment group. We could refresh this page and call this one the Demo Deployment Group. Again, scroll down and attach the service role. Here we go for lambda. And now we need to look at the deployment settings and the deployment configuration. So this is what you need to remember from this lecture and the hooks as well. But first the deployment configuration. So the way it works with code deployment is that if you want to update your lambda function,you already have an existing version and then you're going to have a new version. So let's say version one and version two. So you have the option to shift traffic how your lambda function. Your new one will be used and you can say lambda all at once. That means that as soon as code deployment is done, all the traffic from version one will go to version two. And so the deployment happens all at once. But this could be problematic. If you have an issue with a lambda version, and something is wrong, then you need to deploy a rollback. So another option would be to use either a linear or a canary type of deployment. But what is the difference? So if we go to documentation, there is canary and linear. Canary is saying that traffic shifted in two increments. That means that V one and V two will coexist. Coexist for one increment. So we deploy the two functions and if you look at this kind of setting right here, we're saying okay, 10%of the traffic should go to the new lambda function. So the two lambdas function for five minutes. OK? And this is fine. And if everything goes well for 5 minutes and 10%of the traffic, then in the next iteration, all the traffic will be shifted to the new lambda function. So this is why it's called the Canary. Traffic is shifted in two increments, but in linear traffic it is shifted in equal increments with an equal number of minutes between each increment. So we go more gradually. Canary means "one before all," and linear means "step by step." So, if we use a linear configuration, such as lambda linear 10% every minute, 10% of traffic will be directed to our version two lambda function every minute. And so, if we do the math, after 10 minutes, all the traffic will have shifted. But this is more incremental and a bit more smooth if you're looking to monitor metrics and see the performance of how everything works. So the exam will ask you: should you choose a canary deployment or should you use a linear deployment? Remember, if you need to have traffic shifted in two increments, use Canary. If you need something more gradual with equal increments, then you should use a linear. And finally, if you don't care, just use it all at once. So this is our deployment group, a bit more simple and you could still attach triggers and alarm rollbacks as well if you wanted to. Then we'll click on "Create deployment groups." And here we go. Our deployment group has been created. So now you may ask me about the appspec YML file for lambda functions. Well, there is an app spec for YAML, but it's a lot simpler to understand and use. So a lambda function doesn't need to get the bundle from s three or anything like this. This is all done by code and deployed for you. So here's how it works. The deployment starts and a new lambda function is created. So it's deployed and then it's going to take traffic. But before it takes traffic, you have a beforeallow traffic hook where you can run another lambda function to see if everything is fine. Then traffic will be allowed through and you can run another lambda function to test after the traffic is allowed through if everything is working correctly. So you have two hooks. You have the new lambda function text traffic and the new lambda function track traffic. And because all these run in lambda,then you have to specify lambda functions. So your app spectrum will look just like this. You have before allow traffic where you specify a before allow traffic hook function name and after allow traffic where you specify an after allow traffic function name. And this is it for your spec YML. So you may ask me, what does it look like? What should we do in both before- and after-allow traffic? Well, for example, if you do before allowtraffic, maybe you want to make sure you have connectivity to your database. Maybe you want to make sure that the database has done some kind of migration of their schema before the new lambda function is being used. So it doesn't start too early. It's more like, what should you do to make sure that when your lambda function starts, it's ready to start. And after I load traffic, this one is more about what should we do after our function has started? How do we verify that everything is working properly? So this would be more health checks, monitoring, that kind of stuff. So this is it for code deployed in lambda. We're not going to do this by deploying a lambda function. That would be too complicated. But I hope you understand the idea behind the canary and the linear deployment configuration. And finally, the fact that you have two deploymenthooks available to you to invoke other lambda functions and perform some checks before and after your traffic is going to your lambda function. All right, that's it. I will see you in the next lecture.

28. CodePipeline – Overview

So let's get an introduction to Code Pipeline. But if you already know what it is, you can just skip this lecture. Code Pipeline is a continuous delivery tool and it's a visual workflow. So we understand how to orchestrate our pipeline using it. You can define sources such as GitHubcode, commit, or Amazon s three.And then you can build using technology such as Code Build, Jenkins, and so on. You can even load test using third party tools for load testing.Then you can run deployments using code. Deploy beanstalk. Conformation ECS. And it's made of stages. Each stage can have sequential and or parallel actions. And we see this in the hands on.An example of a stage can be building testing, deploying, load testing, etc. You can also define manual approval stages at any time. So you can go into an ongoing delivery type of mindset. Okay, so where does CO Python sit? Well, Koeppipeline is here to orchestrate our entire CI CD pipeline. So, whether we get data from Code Commit and then build Code Build or Jenkins, deploy using Beanstalk, or deploy code Pipeline is here to bring everything together. So how does it do it? Well, it's using artifacts, and each pipeline stage can create artifacts, and the artefacts will be passed along to Amazon S3 onto the next stage. So what does it look like? Well, there will be a trigger to start our Code Pipeline pipeline. And the code will be in source. For example, they could commit and could commit. I'll set up the code pipeline. I will put the artefacts of code commits into s three.Then CodeBuild will pick up these artefacts from Step Three and run a build, for example. And then the output artefacts from it will be stored back into S Three and maybe can be deployed afterwards with all these input artefacts to use them to deploy them onto, for example, two instances. So the orchestration of the entire pipeline is what Code Pipeline is used for. So let's get started with this lecture and learn how to use code line in great depth.

29. CodePipeline - CodeCommit & CodeDeploy

Okay, so we have code in, code commit, and we are able to deploy that code using Code Deploy. And first we need to package it as an archive S3 in order for the deployment to work. What we want to do is to automate the transition from Code Commit into Code Deploy. And this is where we'll look at the code pipeline. So let's get started with our first pipeline. And we'll create a pipeline and I'll call it the CI CD Demo. Code pipeline demo. Okay, next I'm going to create a new service role. So this pipeline is going to take actions on our behalf, and therefore this pipeline should have an agent, and the agent will be created for us. And we'll be allowing the role to do all it should do to perform this pipeline. Okay, let's look at the advanced settings here for the artefacts store. We can create a default SThree bucket in our accounts or we could choose an existing SThree location from your account in the same region and accounts as your pipeline. So understanding these two settings is critical because if you start creating many, manyAWS code pipelines, OK, and keep choosing the default location, you will create manyS three buckets and may run into limits because you have too many S three buckets. So if you wanted to centralise all your S3 buckets, you could use a custom location. So let's use this as an example. I'm going to use three, I'm going to create a bucket, and we should actually maybe use the same bucket as before. As a result, AWS DevOps defines So we'll reuse the same bucket and we'll use an encryption key to be the default AWS managed keys. So here using this advanced setting, and I know this is the beginning of the code pipeline, but we need to look at this advanced setting. We can choose to have a central S-three location for all our code pipelines, or we could choose to have one S-three bucket for each code pipeline. It's our choice. But for now, let's use a custom location and we'll reuse the bucket that I've created from before. For the encryption, we either let AWS manage the key to encrypt all the artefacts of the code pipeline or we use a customer managed key. Then we have to create our own KMS key. We'll go ahead with the default AWS Manage key. Okay, next we'll click on Next. We need to have a source provider. So what is going to trigger our source in the code pipeline? And so we can choose codecommits, ECR, S3, or GitHub. So easy. We'll choose Code Commit because we want to have something that happens that happens whenever we push code into code commit. But ECR could be chosen if you want to trigger something when a new, for example, Docker image is pushed into ECR. Or we could have S Three when you have new artefacts in Israel and a new code in S Three. And finally, GitHub when you have new code on GitHub. Okay, let's use code commits. Now we have to choose a repository name. So we'll choose my web page and choose a branch that will trigger this pipeline. So as we see here, for the pipeline, it has to be triggered by a specific branch. So we need to create one code pipeline for each branch in our code commit repository. It is very important to remember that. Now, with the change detection option,this is extremely important. So we have two different kinds of detection options, and you need to remember those going into the exam. So the first one is to use Amazon CloudWatch events, which is the recommended way, which means that whenever we push a commit into code commits,a Cloud Watch event rule will be triggered. And the trigger of that rule will be this pipeline. This is the best and the recommended way because as soon as a change occurs in Codecommit, the pipeline will be triggered. Alternatively, if we don't want to use Cloud Watch events, we could use codepipeline itself to periodically check for changes. So that means that if we check, for example, every 30 seconds, then we'll have a 30 second delay between when the code gets pushed and the pipeline gets triggered. And that could be an issue. So, as such, we'll use Amazon CloudWatch events, which is the recommended way. But you need to remember that they're both existing, and when we're done creating this pipeline, we'll review the Cloud Watch events to understand exactly how things work. Okay, next build provider. Right now we don't have a building and we're not going to provide a building, so this is an optional stage. But we'll see in the next lecture how to use code build. And then jenkins, so we'll skip this building stage for now. Yes. Now for the deployment stage, where do we want to deploy to? Well, there are a lot of different options you can see, but for now we'll just focus on one. There will be AWS code deployed because this is the one we've been using so far. So we need to choose an application name, which is CodeDeploy demo, and we need to choose a deployment group. Let's talk about my development instances right now. So something I want to show you is that here for the deployment provider, for CodeDeploy, we are able to choose another region. So it is definitely possible to have a codepipeline in this region, for example, Ireland, but use code deployed in another region, for example, US East One, in which case, for now, because I don't have any code deployed in US East One, I cannot choose any application. But so we can start seeing how it would work for multi-regions if we had multiple code deployments in multiple regions. Then we could use one central pipeline to trigger many code deployments into different regions. For now, we'll go back to choosing our application and our deploymentgroup, which is my development instances. Click on Next and we'll review the settings. Everything looks good. And we create the pipeline. Okay, so the pipeline has now been created, which is cool. And we can see it is a very simple pipeline where we have the source and it gets deployed into Code Deploy. So as soon as we've created the pipeline, the source gets triggered. And so that means that the code is being pulled from AWS Code Commit. And that just worked. And now, that was the last commit from Master. And now Code Deploy is being triggered, and Code Deploy is doing our first deploy. So the really cool thing here is that we automated the fact that any change in the source will happen and be deployed by code deploy into our development instances. We'll test that in a second. So if we go to Code Deploy now and look at deployments, we'll get a deployment history of that. We can see that this deployment just happened right now. So that was a few seconds ago and it succeeded. So, yes, it should show success here as well. So, if we go to our instances, we can see the development server. So this is production; this is development. Excellent. And we go to this URL, and we see that it says "Congratulations v Five." Okay, now let's try to see if the automation works. So we'll go to our repositoriesand here on my web page. I'm going to change my webpage again. This file will be edited, and congratulations v6 will be performed. And let's just mix this really quickly. Okay, here we go. Commit changes. So now index HTML has been committed to toMaster and this is a new commit. And let's get back to deploying the code pipeline. And as you can see right away, the source is running again. That's because it detected a change right away thanks to Cloud Watch events. And now the source commit is running. So we'll need to wait a few seconds until this happens and then this should transition into Code Deploy right here. So let's go back to CodeDeploy and refresh this really quickly. Yes, the deployment is in progress within Code Deploy. And when it's done, we should be seeing the new webpage V6 on our instances. So let's verify that and we'll wait a few seconds again for this to be done. And it's now done. And if you go to our instance and refresh this page, it now says Congratulations v. Six. So this whole automation works, and this is quite cool. And let's look at one last thing. So if we go to Cloud Watch, let's go to CloudWatch console and we want to have a look at the Cloud Watch event that was created because it is really important to understand the DevOps that happens behind it. So let's go to Cloud Watch rules and we have Code Pipeline, my web app master rule, and this is a rule that has the source of AWS code commit. And by the way, you're supposed to be able to understand how to read these events. So let's have a look. So it says the source is advice code commits. The detailed type is code commit repository state change. So whenever the repository has a change, the source is the ARN of my code commit. So this is fine and the details must be created or updated for reference. So I guess that represents commits and the reference type is a branch and it has to be the branch named Master. So here it's saying any reference that's been created or updated in the master should trigger something. So let's scroll down and we can look at the targets. And the target for this is the CodePython demo. And so that means that an automatically coded pipeline demo will be triggered by this Cloud Watch event. It's super important to know how to read these things. So that's it. We've created our first pipeline, quite handy. Now, any change we commit to code will be the code deployed for development instances. So, I hope you enjoyed it, and I hope to see you in the next lecture.

30. CodePipeline - Adding CodeBuild

So now in this pipeline, we want more safety. Right now, any change we push to the source will be deployed by code deploy. But we want to make sure that our source code is tested and doesn't have any bugs before we push this into our development instances. For example, So we need to edit this pipeline and start making it a bit more complex. And as you can guess, we'll add code building in there. So let's edit this pipeline. And here we're able to add stages. So what is a stage? A stage is an astage in the pipeline, and they're sequential. So there's a stage called Sourceand a stage called Deploy. We'll add another stage, and this stage will be called Test. This is where we'll run our code build. Here on every stage, you have something called action groups. So let's add an action group and I'll call it Test for Congratulations because this is what Code Bill does. And the action provider will be one of these. And as you can see, there are a tonne of different providers. So it could be a build stage, it could be a deploy stage, it could be an invoke stage, or a source stage test. And we'll be talking about those great details very soon. But for now, we're interested in testing with Code Build. So I'll just add "good build." The region we want to run this in is Ireland, but we're able to choose any other region. So again, there is a possibility to have a pipeline in Ireland and invoke a test maybe in North Virginia or Northern Virginia. And then we need to choose the input artifacts. So what is Code Build going to test? And we need to use the sourceartifacts, which are defined by the source. And this comes from the previous stage in the code pipeline. So before, Can Build knew how to get the source, but now Can Build just does the building and we need to say, okay, what artefacts do we need to have and Can Build gets its artefacts from the source, which is Code Commit. Okay? Now the project name that we want to use is this one: my web app Codebuildmaster. And then the output artefact that it creates, if it was creating any output artefacts, would just remain. We'll just call it test results. OK, but we could create many different artifacts. Click on Done and here we go. So this stage gets the source from the source and runs the code build test right here. Then the artefacts will be passed on to Could Deploy. This is good right now. Look at this pipeline a little bit more. We are able to add many more actions. So here I run one test, but I could run another test, and I could say here is another test and add another action provider, for example, Jenkins, and do something with it. So we are able to add stages. And if they are in the same line right here,they're in the same line, they're called parallel stages. And if they're sequential, I'm able to add another action group name, so they're called sequential action groups. So we'll do a deep dive into those as well. But for now, we'll keep it simple and just add this one stage in action. Click on "Done. And here we go. This is my pipeline. As you can see, we're able to add stages pretty much everywhere, and we're able to edit stages as well for any kind of stage we want. Okay, let's click on Save and save our pipeline. So now the pipeline was saved successfully, and now we should probably test it. So, let's click on Release Change, which will start the entire pipeline for us. So here we go. The pipeline has been triggered. Now the source is running and it succeeded. And now Could Build should be run on the code that came from Code Commit. So if we go to Could Build and go to build history now, we should see that, yes,there is a build in progress right now that is running on the code that was just pulled. So we can click on this building to have a deep dive into it and see what happens. And we could look at the logs and so on. But for the build details, we can see that the source provider is now AWS Code Pipeline. So Code Pipeline sent the artefacts from CodeCommit into code build, which is different from what it was before and it felt. So let's have a look at the build logs. And here's the problem: There's access denied here. It seems like the primary sources in the source version were not able to be obtained. So it seems that our code built right here was not authorised to access our bucket AWS DevOps course. So that makes sense. We probably haven't permissioned it enough. So let's go back to our building project. And this is really good to get these kinds of errors because we go through them and fix them. And so we have an imm error. So why don't we go to Imright here and we'll go to Roles? And this was a buildable role. So let's take a look at what can be built. And if you look at the policy right here, this is the policy. It was able to access S Three, but I'm pretty sure that the S Three policy that it was able to access was too restrictive. So let's scroll down. Yes, it's able to do a get object and so on from Code Pipeline EU West One. And so the S three bucket we frequently use isn't called like this. It's also called "Stefan something." AWS DevOps successfully defended the course. So we also need to add this bucket to our policy. So why don't we just edit this policy? And here I'm going to go to S three. And for the resources, I could just say, "Okay, it should be any resource and all resources," and that's just going to be simple. It's not as secure as before, but at least we know it will work for any of the three buckets. So we'll review the policy, and now it looks good. Click on save changes.And now, hopefully, our pipeline should work. So let's go back to our pipeline. As you can see this build, this test failed, and so therefore the deploy did not happen. OK? And so that's really cool. We can see that any failure in the build stage did not trigger the deploy. So that's the whole point behind Code Pipeline. So let's retry this stage again. So now, hopefully CodeBuild will have enough permissions to access our artefacts in S Three. And while this happens, let's look at S three. So here we go. We have an S3 bucket called AWS DevOps defense. And in the Code Pipeline demo, the sourceartifacts were uploaded by Code Pipeline and these were the source artefacts that could be built, trying to access the source artefacts so they could build. Let's look at the building history. And now this has just succeeded. So that was 18 seconds ago. So now they should have worked. Here we go. So the test has been working and hopefully it will move on to the next stage very, very soon. Okay, we succeeded. And now the deployment is happening. So now every change that we make in AWS Code Commit will be tested and, if it works, it will be deployed. So we can definitely make sure of that by making a change that for sure will not work. So let's go to Code Commitand we'll edit our file again. And this time, because it tests for congratulations,I will just say error V six. And because the word "congratulations" will not appear here, the test phase should fail. So let's try this out. We have just pushed our change into code commits. Excellent. And now the source should be triggered in a second. Okay, the source has been triggered and the test is in progress right now. So could The build is running a new build, so we can refresh this and see that the build is actually in progress. So let's go into that build. And the building has failed. expectedly. If you look at the phase details, you will see that the build stage itself failed because this grep minus FQ congratulations index HTML did not succeed because we removed the word Congratulations. So if you go to Code Pipeline now, you can see that the test has failed and, therefore, again, the deploy did not happen. That is really cool. Everything is working just fine. We've tested our code pipeline and we've added a source, a test, and a deploy. We've seen the artefacts in this code in S three are here. So that makes sense. artefacts are created and uploaded into sthree and we can centralise those. We fixed minor issues so that we could build, and we've mostly finished putting everything together. These are outstanding accomplishments. I will see you in the next lecture.

31. CodePipeline - Artifacts, Encryption and S3

So I want to talk about the relationship between Code Pipeline and S Three. So in Code Pipeline, when we did create our pipeline, if you go back to the pipeline creation, we had to choose where to store the artifacts. And we could have a default S Threebucket in your account that was not created. Or we could choose an existing SThree location from your account in the same region and account as our pipeline. So this is definitely something. Just remember, we could set a central S Three repository and S Three buckets for all our pipelines. OK? Next, we had to select an encryption key so we could use a default managed key or a customer managed key. So if we have a look at the Code Pipeline Demo and we have a look at these artifacts, for example, we can see that they are encrypted by AWS KMS. So if I click on Properties and click on Encryption, it is encrypted by AWS KMS. And the encryption key that was used is AWS S Three.But we could have defined our own customer managed key if we went into KMS and created a key for it. So first of all, that's the first thing to remember. The second thing is that our Code Pipeline here is called Code Pipeline demo. And at every stage, we create artifacts. And as such, if we go to our CodePipeline demo S3 buckets, we can see there's a directory named Code Pipeline Demo which presents the exact same name as our Code Pipeline. And then we have different folders. Each folder has artefacts and the name of the folder source Arty and Test results actually comes from the fact that it is source and test. Okay, so here the source artefacts represent, every time the code weapon is run,the entire Code Commit repository. And then every time the code is tested successfully,it will create another artefact here and be passed on to the next stage. So artefacts are the way for Code Pipeline to have these services communicate with one another. As a result, the code commit is pulled and then placed in s three. Then they could create something that will pull that file from SThree, test it, and then return it to SThree. And then we could deploy. We'll pull that file from SThree and put it onto our EC two instances. And this is why we had an IEM issue before. So you need to remember that SThree is the backbone of the Code Pipeline. The Code Pipeline will interact with us three times during our pipeline to pass on the artifacts. Okay, next, another type of integration. You should know that we could want to have our artefacts in another S-3 bucket at the end. We want to maybe upload our artefacts to another SThree account, another SThree bucket, and so on. So, as such, we could edit our pipeline. So let's edit it in the deploy stage. Maybe you want to edit the stage and here add a parallelaction and I'll call it upload to other S three buckets. And the action provider is going to be S Three. Excellent. Now we need to choose a region, which was Ireland, and we need to choose input artifacts. So let's choose the test results, and the Stwo bucket is going to be another one. CI CD staff and DevOps. And we could choose an object key. So I'll call it Artifacts from Code Build and we could choose to extract the file before deploying. And we could also specify some additional configuration. For example, a KMS encryption key ARN that's optional. We could choose between Canscl and Cache Control. So excellent, we'll just keep it like this and click on Done. So now we have added a parallel stage to our codepipeline, such that when it does a code deploy, it also applies to S three at the very same time. Let's click on Done and let's save this. I'll say this and here we go. It's been saved. So now let's go ahead and push the change to code commit. So we'll change this to CongratulationsV Seven and commit these changes. So an A.com makes changes, and here we are. Index HTML has been committed to master, and now we need to wait for the pipeline to happen. So I'll just pause the video until we get to the deployment stage. Okay, so the deployment is happening and, as you can see, the upload to Amazon S three has already succeeded. So, if we go to Amazon S Three, we can go to my other bucket, which is called CI CD Stefan DevOps. Then in there we see the artefacts that could be built. This file right here was uploaded by the code pipeline for us. And the encryption standard is AES 256 because we have enabled default encryption for this. The default encryption was enabled, so artefacts uploaded by the code pipeline were automatically encrypted by AES 256. And so that's our code pipeline. And as you can see, the upload to Sthree and code deployment are happening in parallel. So that makes a lot of sense as to how we could use parallel stages to do different types of deployments. Maybe a code deploy and maybe a deploy to S three. Okay, finally I want to attract your attention to the artifacts. So I said artefacts get passed around between each stage, and I was right. But remember that you could build as well as have artifacts. And so when we went to our could build, and it was in our source repository here, and we had builtspec YAML, we had to find that an artifacts.So the build artefacts could be different than the code deploy artifacts. OK, the build artefacts are slightly different, but they will get reused for the code pipeline. And so you need to remember that there is a concept of could-build artefacts and the concept of code pipeline artifacts. And this is where we had our other extrabuckets cascades defend DevOps that was used by codebuild to create all these artefacts and hear all the build IDs that happen in all the artefacts that get created from these build IDs. Okay, so that's it for this lecture. So I'm really interested in understanding the interaction between the three pipelines and the artifacts. I hope you liked it and I will see you at the next lecture.

ExamSnap's Amazon AWS DevOps Engineer Professional Practice Test Questions and Exam Dumps, study guide, and video training course are complicated in premium bundle. The Exam Updated are monitored by Industry Leading IT Trainers with over 15 years of experience, Amazon AWS DevOps Engineer Professional Exam Dumps and Practice Test Questions cover all the Exam Objectives to make sure you pass your exam easily.