All Amazon AWS DevOps Engineer Professional certification exam dumps, study guide, training courses are Prepared by industry experts. PrepAway's ETE files povide the AWS DevOps Engineer Professional AWS DevOps Engineer - Professional (DOP-C01) practice test questions and answers & exam dumps, study guide and training courses help you study and pass hassle-free!

SDLC Automation (Domain 1)

37. CodePipeline – CloudFormation

So we have seen that a code pipeline can be used to, for example, deploy CloudFormation templates. So if you go, for example, to deploy to production and we wanted to edit this pipeline, we could scroll all the way down, edit the stage, and in here we could have confirmation of deployment. Here we choose the action provider to be CloudFormation, and here we're able to say, "Okay, what do we want the input artefacts to be?" So, whatever, this is going to be our cloud formation template. Imagine this is a cloud formation template, and the action mode is to create or update a stack, delete a stack, replace a failed stack, changeset, and execute a chanceet. So there are a variety of cloud formation options available to us. So we'll just go with creating or updating a stack. Then we need to choose a stack name. So my production stack is a great name for it, and then there are the templates. So in this artifact, what is the file name for it? So my class formation templates read: So here we get the confirmation template from this artifact, okay?

And if we have a configuration for the template as well, we could get it from the artefact and say, "Okay, there's a config file, so my config file has JSON capabilities." So, if we use to create im resources, we must add all of these capabilities, as well as auto-expand if we have nested stacks, and then the role name is used to do this confirmation stack. So what role are we using to deploy this confirmation template and the output from it? As a result, the output of confirmation and the output artefacts If you want to add some advanced parameters, you can do so here. And I put artifacts, so I put "cloud formation artifacts," and then I clicked "Oops" and "Done," and then I just cancelled it. But anyway, you see all the options you have. So we can use a code pipeline to deploy cloud formation. Okay, that makes sense. But we can do more. We can have cloud formation while deploying pipelines. So here, a code pipeline is something we can definitely create manually, but it is supposed to be something you can reproduce at scale. And so it is quite common to create a code pipeline for AWS cloud formation. So you have three examples in here that I recommend you go through, which is how you can create an entire code pipeline using cloud formation. So you can use cloud formation to create an AWS commitco commit pipeline.

Click on this link, and then you'll see inside how everything works and how you can use cloud formation to deploy that entire pipeline. And you can look at the sample cloud formation templates somewhere in there. Finally, I want to bring your attention to something very important. Using a code pipeline and cloud formation, you can mix and match the two. So this is a GitHub repository in which you have a cloud formation template that's nested and that will create an entire code pipeline that has many, many different stages. So I do recommend you go through the exercise of deploying that project. Okay? And as you can see, this project will create a source, and the source will have a code commit repository. Then there will be a built-in test action. We'll build the code, put it into a three-bucket bucket, then have confirmation create a stack for us, test the stack, and then translate the stack at the end. Then we'll deploy the stack to staging.

So confirmation will create a change set at this time, and we'll execute a change set for the UAT stacks, the user acceptance testing. When we're done with the UAT stack, we have a manual approval stage before moving on to deploying to production. When we deploy to production, cloud formation creates another chain set, which we have to approve before it gets executed in our production stack, and so on. So this is quite a cool thing to do because we have CloudFormation to create this entire thing. So this is all infrastructure as code, but it also uses cloud formation to deploy our application. As a result, there is cloud formation in cloud formation.

So try to go through the exercise of deploying this. I think this is really good practise and will be a really good preparation for your exam as a DevOps because this is more what the pipeline should look like for best practises and production deployments. Finally, having a good pipelines cloud formation template allows you to replicate it as many times as you want. And so if we go back in here and look at the source for code commit, OK, could commit have a source? It was only pointing to master. So if we wanted to test another branch, if we wanted to test, for example, the develop branch, we would need to create another code pipeline for it.

So we need to go to the pipelines and create a pipeline just for that one specific branch. And so to do this at scale, we can either take this pipeline and clone it, so you have the option to click on the pipeline and clone the pipeline. But this is very manual. Alternatively, we could have used cloud formation to automatically generate this pipeline and select a source repository to which we could commit but on a different branch.

And so we can see from a DevOps perspective how using cloud formation with code pipelines would allow us to have as many pipelines as we wanted for many different code commit branches. Okay, so something to think about going into the exam. Again, this is more general knowledge that I give you, but as a DevOps professional, you need to think about how you scale your operations, how you create many pipelines predictably, and how you have your infrastructure as code. So all of these are the integration with code, pipeline, and confirmation, and hopefully that gives you a lot of good ideas for it. Alright, well, that's it for this lecture. I will see you at the next lecture.

38. CodeStar – Overview

Okay, finally, just an overview, but we have this service called Code Star, and this is not going to be a deep subject at the exam, but you need to know how this works at least once so you can understand what it does. And if it comes up in the question, then you know what it is. So Code Star is an integrated environment in which you can quickly develop, build, and deploy applications on AWS. And it integrates, can commit code, build pipelines, and deploy all together, and presents you with a more simplified type of UI. So when you start with CodeStar, you create a role and say, "Yes, please create a role." And then you choose the kind of project templates you want to use. So in terms of templates, it could be for EC 2, it could be for a rest lambda, or it could be for elastic beanstalk.

And so, for example, let's take Amazon EC2 as an example. So maybe you want a static website, maybe you want a NodeJS application, maybe you want express JS. So, for example, let's choose NodeJS and say my demo could start project is the name of my project. Okay, next you need to use a kind of repository to hold your code, and it could be Code Commit or GitHub. So we'll use Code Commit, click on Next, and then it shows us all the things that will be created by that project. So as you can see, not much gets created right now.

There are three options: Code Commit, Co Deploy, and Amazon Cloud Watch. However, if we had a more sophisticated project, we could have gone back and chosen something with an elastic beanstalk and Python Flask. My demo is good, but maybe we'll have something a bit more sophisticated. So still, we use Code Commit, and then we deploy with Beanstalk and Cloud Watch. This is fine. This will suffice for the time being. We'll create this and need to choose a key pair. So I get this key pair and start working on the project. Here we go. Then you need to specify how you want to edit your code. So do you want to use your command line? Do you want to use Visual Studio?

Do you want to use Cloud Nine or Eclipse? For now, I'll just skip it. It's just going to be a repository under Code Commit, and as such, we will have a clone repository URL to use. And we can just use that just the way we've done this before, using the command line, for example. So we'll just keep this going, and here we go. The Code Start project is being set up, and that can take a few minutes. It's because it's going to set up a good pipeline that could commit for us, and so on. So let's just wait a few minutes until this is done. OK, so my project was successfully created, and if I scroll down, I can see that we have an initial commit made by Costar during the project creation. So Costar has this dashboard in which we can see all these different things. So I can close different panels and just see what I want to see.

And so what we can see here is that under continuous deployment, there is a good pipeline that was created for us, and it's going from source to build to deploy. So we can see that there is a code commit, a good build, and a cloud formation. So the really good thing is that you also have integration with Amazon CloudWatch for your application activity. So this is an all-in-one integrated development environment for deploying your applications. We can also see the different branches in our commit history and so on. We've also integrated Jira if we need to track an issue within your CodeStar project. So CodeStar is just an easier way to get started with your deployments.

So if I click on code, it's going to take me directly into a code commit. And here I can see I have my demo CodeStar repository that was created for me with a lot of files, and we will recognise a few of them. We'll recognize, for example, build spec dot YML, which is used by Cutbill to build our project. OK, and this is how we see how the project is being built.

So could start is great if you want to start with templates and work on a project that you know will work right away. Okay, next you can use "could build," and so we can look at the "good build" building project. As a result, this is the project I refer to as my democstar. And right now, it's running my first build, and the instructions are obviously coming from this build specification YML. So if you click on this build run and go to phase details, we can see how long each phase took.

The provisioning took 30 seconds, the pre-building took 10 seconds, and so on. Now, if you go to Code Star, we can also view the code pipeline that was created with it. So, in the code pipeline, there is a source (AWScould commit), a build stage (AWSCouldBuild), and a cloud formation stage. So something new that we haven't seen before, but a confirmation stage that is running to generate a change set, and that change set will then be executed in cloud formation, which is still ongoing. So every time we change the code and commit it, it will be built, and a cloud formation template will be created out of it, and this confirmation template will be executed, generated, and then executed in this deploy stage.

So the good thing about CodeStar is that all these things were created for us, and now we can just go ahead, modify our code, and code commit using our favourite extensions or CLI. And automatically, it will be deployed. because this was an elastic beanstalk project. Then, if I go to Elastic Beanstalk, I should see that my project has been created.

Yes, here it is. And I probably need to give it a few more minutes to be ready. So let me pause the video right now. Okay, so my application has now been created in Binstock, and I can go to the URL and see how well this is working perfect. So, as we can see, Beanstalk was created entirely by my code pipeline. So everything worked just fine. And if we go to cloud formation now, let's quickly go to cloud formation. We should start seeing a few stacks that were created by Code Star. So here are the stacks created by CodeStar, and there's a stack created for Elastic Beanstalk as well. So this is really good.

Code Star was able to get us started and running with a project in no time. And that was deploying from a code commit, built by codebuild, and then deployed using cloud formation onto our Beanstalk environment, which I can't remember where it is. It's here: the Beanstalk environment and Hello World. So finally, the only thing you need to know about CodeStar is how it's working behind the scenes. So how do we change some parameters for CodeStar? And you could go into a project and look at all of the project resources that were created IAM roles: the three Binstock pipeline buckets you could commit to, the conformation you could build, and so on. But the real secret of Code Star is in the code commit.

So let's go to code commits. Here we go. So this is my co-star project. As a result, we know that the bill set builtspec dot YAML file is for a successful build. And we know that EBextensions is for Elastic Beanstalk. We'll see this in the next section. But there's this new file called "template YAML." And this is for Code Star. As a result, this is a Code Star-specific template. And this appears to be the point of transformation. This is where everything that you need to know about Code Star is. So if you wanted to change a few parameters, for example, for your Beanstalk configuration templates, then you would change them here. The same goes for your Binstock environment and everything else that CodeStar generates.

So if you want to learn more, you can go to codestartemplate.yml and you'll have a reference document for all the Code Star project templates. And they will explain to you how you can customise these templates to change whatever you want. So read through it, but at a high level. You need to understand that CodeStar needs to be modified using template YML for any kind of configuration. Okay, so that's it for this lecture. just a very quick overview of CodeStar, but hopefully you understand everything that goes on in there. And if you're ready, you can go ahead and delete that project. Do that project at the bottom. If we can delete this project right here, Okay, so that's it. I will see you at the next lecture.

39. Jenkins – Architecture

Okay, so in this lecture, we are going to set up Jenkins on EC 2. So let's go into EC 2. And here are our running instances. I'm going to launch an instance, and I'm going to launch a Linux 2 AMI on 2 micros. This is fine. And for the instance details, I'll leave them alone. So no enrollment, nothing special for the storage; we'll leave it as is. tags, it's fine. I'm going to add a tag and call it Jenkins. Then we're done. And for the security group, I can create a new security group, and I will add http on port 80. I'll also add another custom TCP rule from anywhere on port 8080. So this is to access Jenkins. OK, I'll click on "lunch" and say, "Yes, we do have access to that key pair." So Jenkins, my easy-to-remember instance name, is now running.

In this simple case, we'll install Jenkins as a master and slave because this will be a stand-alone installation. Easy enough. I'm going to right-click and connect to my instance using Amazon Easy Connect. Here we go. It should open a new tab, and I should be able to SSH into my instance. Perfect. Now we have to run some commands to install Jenkins. And I have created a Jenkins MD file. So the first thing we have to do is do a Yam update to update the packages. And then we add the Jenkins repository to install Jenkins from. We do an import to trust that key from the Jenkins repository. Then we install Java 8 to be able to run Jenkins because Jenkins is a JVM application. Then we do sudo yum install jenkins to install Jenkins.

And finally, run sudo service Jenkinsstart to start Jenkins. So let's just run all these commands right here. I will go ahead and paste those in here. And now we can see that after the sudo services Jenkins start command, it says okay, and the Jenkins service has started. So let's go to our instance and get the public DNS, which is right here. I'm also going to use port 80. So make sure you add port 80 80.And in there, I should connect directly to Jenkins. And so to unlock Jenkins, you need to find the password for it. And the password is in this file. And so we need to categorise this file. So let's go in here. I'm going to clear the screen and dot cat this file. And I need soda. Permission. So I do pseudo-cat, and let's type pseudo-cat correctly. Cat this file with sudo. And here we go. I get a long password. So I'm going to select it, copy it, and then paste it here. That's my admin password. Excellent.

Now we get to the setup wizard, and I can install the suggested plugins. So I'll just click on that, and it's going to go and install a few plugins for me, and then I can go ahead and create my first username. So Stefan and admin password: Stefan, and it's Stefan. atexample.com Here we go. Save and continue. And now we have the Jenkins URL we can use before saving and finishing. And the Jenkins setup is complete, so we can start using Jenkins.

So this was a really quick setup, but we have set up Jenkins as a master on our instance. And now Jenkins is ready to be used. So we could create new jobs if we wanted to. We could create a freestyle project, a pipeline, or a multiconfiguration. And this is knowledge related to Jenkins that you do not need to have for the exam, but you do need to know that it is possible to get started with Jenkins for a project. Now let's look into the code pipeline a little bit. So, if we return to the code pipeline and open it, we can see our pipeline right there. Here's the pipeline demo, which I'll be editing.

So, perhaps for testing, we should edit the stage, add an action, and specify "use Jenkins." Jenkins will be the action provider in this case. As a result, we could use Jenkins to run a build or test. And if that's the case, we have input artifacts. So we'll say, for example, that these ones are the source artifacts and the provider name. So the name you've configured in the Jenkins plugin For this, we'll need to install a plugin on Jenkins for code pipeline and get the server URL for our Jenkins server. So probably this one, the project name, and the output artifacts. So I'm not going to do this here because we don't have a Jenkins file available to us, but we can see that we can use Jenkins within our code pipeline and directly use this instance we set up. But what I want you to realise is that we went through the process of creating a G2 micro-instance.

So that's a master NSA for the time being. But if that instance gets overloaded, then Jenkins will go slowly. If we want to scale, we need to set up a new scaling group and some automation, and that will take a lot of time. So Jenkins is a great way to do build, test, and deployments on AWS, but it does require management. And managing Jenkins may be a cost you don't want. So if you want a fully serverless managed alternative, then you could build, you could deploy, and you could pipeline, which is probably going to be a better choice. And the exam will test you on these things. Okay, now in the next lecture, we'll just visit the Jenkins plugins because you need to know that they're there and what they do. So, until the next lecture, we'll see you.

40. Jenkins - Setup on EC2

Okay, so we have our Jenkins server, and it's a master. It's simple to think of Amazon. And you recall how, in order to have built slaves, we needed to create more Amazon simple-to-create instances. And so there are plugins for us that will do these things, so we don't have to set up all these build slaves. Jenkins, for example, has something called "easy to plug in" that will allow Jenkins server to create Amazon easy-to-instances for us, evenspot instances, and then stop them when they're unused. So it makes Jenkins on AWS a little bit more natural to use.

And you need to know that these plugins exist. So let me show you how to install plugins on Jenkins on AWS. Okay, so let's go back to the Jenkins dashboard, and I'm going to click on Manage Jenkins. And this is where we can configure plugins. So we'll click on "Manage plugins" right here. And then we'll have it available on this tab. So the second tab And this is the list of all the plugins available for Jenkins. As you can see, there are a lot of them, and each plugin does something very specific.

But for us, we want to use AWS plugins. So let's just tap AWS on the right-hand side for the filter, and we can see all the plugins for AWS. There are quite a few of them. OK, but let me draw your attention to some of the most important plugins you need to know. So there is this Amazon EC to plug in. By the way, if you click on the plug, it will open up the documentation for you. Okay? So this plugin says that if Jenkins notices that your build cluster is overloaded, then it will start instances using the EC2 API and automatically connect them as Jenkins agents.

Agents mean slaves. And so when the load goes down, the two excess instances will be terminated. So the idea is that thanks to this plugin, we have a more elastic way of creating Jenkins slaves. And so Jenkins will manage a whole fleet of Jenkins slaves for us. So it is a really, really good plugin. Okay? But there is an even better one. So let's scroll down and find it. Here we go. This is what AWS could build. And so this does the exact same thing as the ECQ plugin. And this is an official plugin. Okay? But now, by using this, Jenkins could build a plugin. Jenkins will direct all builds into could build. So, yeah, mind blown, right? So the idea is to create someone who will run the Jenkins system that our company built for us.

So what do we get out of this? Well, if we use the code-built plugin, then the idea is that we don't need two instances of slaves. Each slave will be of a specific type and will self-destruct when finished. So we have a much more serverless way of running our Jenkins slave using AWS codebuild. There are other alternatives as well. If you wanted to run the same kind of slaves in the cloud, you could have something using ECS. So let's type ECS in here because I can't find it. Here we go. Amazon's elastic container service So this plugin and that plugin, Amazon EC2 Container Service with auto-scaling capability, will allow us to launch our slaves into the ECS service on AWS. So again, we get the ability to have elastic slaves or elastic agents right here. So many extremely powerful plugins So that's four plugins that are quite interesting already. But you get the idea that with these four plugins—the EC2, the code build, and the ECS plugins—I don't know where they are.

The ECS plugins What you get out of it is the ability to create slaves on demand in a more elastic way and only pay for what you really, really need. Other plugins that will be very interesting are those for Code Pipeline. So Pipeline. So, AWS Pipeline steps, or I'm pretty sure if I type Code Pipeline in there, we're good to go. We get the AWS Code Pipeline integration we need, which is what we would need if we wanted to deploy and use Code Pipeline and Jenkins directly in our pipelines. So that's perfect. And one last plugin that could be really helpful would be the S3 publisher. So the artefact manager on S-3 will allow Jenkins to keep artefacts on SB. And that would be really helpful when we start building some jars and so on. So these are the plugins you should be familiar with at a high level. And remember what they do because it may come up in one of the two examination questions.

If you wanted to go ahead and install these plugins, you clicked on "Install" without restarting. And here we go. Jenkins is currently installing the plugins on the fly. And so it gets prepared. As you can see, it's installing them one by one. And then I'm not going to go into the configuration of all these plugins, because that's not the point. The point is that you need to know that they exist. They do a lot of things, and by configuring them correctly using the documentation, we provide some additional capability to our Jenkins master to create slaves on demand and also use CodePipeline or S3 with deep integrations. OK, so that's it for this lecture. I hope to see you again in the next lecture.

41. Jenkins - AWS Plugins

So Jenkins is something you have to know at a high level on AWS, but you need to know it exists and need to know why it exists and what it can replace. So what is Jenkins? Jenkins is an open-source CI/CD tool. And because it is a CI CD tool, it can replace all the services we've seen, such as code build, code pipeline, and code to deploy. So you can replace all of them or just some of them. Jenkins also has tight integrations with the code build custom pipeline and can be deployed so that it is only replaced in parts of your pipelines. Jenkins has this weird setup in which you need to have a master and then a bunch of slaves. And so the master will be telling the slaves what to do and what to build. So as you start setting up Jenkins on AWS, it becomes a bit painful because you have to manage multiple AZs for your master. You don't want your master to fail if an AZ has a failure. And you must deploy your stuff on EC too. So that becomes a bit more complicated. Now, projects that use Jenkins as an open source ID tool must have a file called a Jenkinsfile, which is similar to a build specification that YAML could build to tell Jenkins what to do. Finally, Jenkins can be extended thanks to so many plugins. And we'll have a lecture on all these plugins on AWS.

Okay, so that's all you need to remember for Jenkins. But let's look into some architectures so we can understand better what's happening. So there's this idea of Jenkins as master and slave, constructing a farm. I'm sorry this is a little bit blurry, but this is the best resolution I have. So the idea is that you can have two kinds of options: the master and the workers, or the slaves are on the same instance, and this is fine, but if you have many, many builds, then the master may be overloaded. Or you have the option to separate the master from your workers. And in this case, you can scale your workers independently from your master and have a much more scalable solution. So all of this comes from the white paper on Jenkins. Now, if you go on AWS now, you would probably deploy the Jenkins Master server on an Amazon EC2 instance and maybe attach an elastic IP to it. DNS names like this provide a consistent and simple way to access your Jenkins server.

And then all your built-in slaves would be running on Amazon in two instances. In an auto-scaling group like this, perhaps you build fewer slaves when you don't need them and more when you do. So this is an option to get started with Jenkins on AWS. Obviously, you don't have to be in a public pool. You could be in a private subnet as well. So this is up to how you want to deploy Jenkins yourself. Now let's talk about master-slave architecture. So, back to the white paper. You could have one master and many different workers, but you're able to have a multimaster set up in different AZs. For instance, AZ 1, AZ 2, and AZ 3 And all of these masters may share some states using Amazon EFS, which is not depicted here, while the workers are located in different AZs. So the deployment option on the right is slightly more expensive, but it is multi-AZ safe.

So that means that if an AZ goes down, we still have other masters to take over the work. Okay, so we'll see how we can simplify this architecture using the plugins. Now, let's talk about the integration of Jenkins with Code Pipeline. So it is possible to integrate these two things. And for this, a developer, for example, commits code into Code Commit and then, instead of invoking Code Build, can invoke Jenkins on an EasyToInstance to perform a build step. When Jenkins is done, then we send the code and artefacts to Code Deploy, and Code Deploy will deploy them on our application servers. So this is a very common way of using Jenkins. So in this case, Jenkins replaces CodeBuild and is invoked by Code Pipeline. We can also have Jenkins with ECS. So now Jenkins' instance is directly pulling code from Code Commit. So Jenkins is sort of replacing CodePipeline here and then will interact with Amazon ECR to get darker images. And once they've been built and pulled, they'll be pushed to ECS. In this case, Jenkins should replace the code in the Pipeline and deploy it. Jenkins could be combined with a device farm.

So, for example, when we pull some code for a mobile application from Code Commit, then we launch a DeviceFarm directly from Jenkins to test our mobile application. We could have Jenkins with a S-Lambda. So here Jenkins has pulled the code from Code Commit and invoked a lambda function, and the lambda function can do a lot of things, such as pulling data from Amazon S3 or interacting with DynamoDB, and so on. We could also have Jenkins to use with CloudFormation, and this is a very similar pattern. Jenkins will pull the cloud formation templates from the code commits, and the team may perform a security review on the code commits. And then, when ready, Jenkins will push the confirmation templates and deploy them. So again, Jenkins is a replacement for Code Pipeline. So these are all architecture diagrams and explanations. You can find them in the Jenkins white paper, but that hopefully gives you an idea at a high level of how Jenkins is used on AWS. Now, in the next lecture, we will setup a Jenkins master and then review all the Jenkins plugins for AWS. Follow me into the next lecture.

Amazon AWS DevOps Engineer Professional practice test questions and answers, training course, study guide are uploaded in ETE Files format by real users. Study and Pass AWS DevOps Engineer Professional AWS DevOps Engineer - Professional (DOP-C01) certification exam dumps & practice test questions and answers are to help students.