Using AWS CodeDeploy To Deploy a Portal Web Application
Using AWS CodeDeploy To Deploy a Portal Web Application

This course has been replaced with a new course which you can access here:


In this course, we’ll provide you with an introduction to AWS CodeDeploy and how it can be used to automate deployments of applications to servers either running in the cloud or on-prem and/or into the Lambda service. We’ll show you where AWS CodeDeploy sits in a CI/CD setup. This course will familiarize you with the AWS CodeDeploy service and ensure you know when and where to use it within your own software projects. We'll then provide a demonstration where we use AWS CodeDeploy to deploy our web portal project onto EC2 infrastructure. 


- [Instructor] And now, next demonstration, we'll use the CodeDeploy service to deploy our build artifacts that we created in our previous demonstration. Before we create our CodeDeploy application, we'll first spin up an EC2 instance, which will be the endpoint to which we deploy to. We'll use the Amazon Linux AMI, and we'll use a t2.micro instance. We'll deploy it into a Network that has access to the Internet. This will be required to be able to download the CodeDeploy Agent. We'll create an IAM role for it. This will be required to give the EC2 instance access to the build artifacts stored in s3. Clicking the next button takes us to the permissions screen. Here, we'll create a custom policy. We'll click on the JSON tab, and we'll customize the policy by hand. We've got a pre-crafted one already, so we'll just paste this in. This policy gives us access to our catestbuild s3 bucket, as we can see here. So this is the bucket that holds our artifact which was built using codebuild. So back within IAM, we'll edit the action just to give permissions to GetObject. This is sufficient to give the EC2 access rights to get the build artifact. So we'll give the policy a name, BuildBucketAccess, S3BuildBucketAccess. We'll click the Create policy button, and then finally, we'll attach the policy to our IAM role that we're creating for our EC2 instance. So clicking Refresh, we should be able to see the new policy, indeed we do, we select it, we attach it, and finally, we need to give our new role a name. In our case, we'll call it WepAppServerRole, and finally, we click the Create role button. Okay the role has been created. We go back into our EC2 console launch interface, refresh, select it. Under the Advanced Details section, we'll paste in our bootstrapping script to install the CodeDeploy Agent. Here you can see we're using bash to actually run the script. The first thing we do, is we change into the EC2 user home directory. We then use wget to a download of the CodeDeploy Agent, install rpm, and then we use yum to actually run the install. Okay, in the Storage section, we'll increase the volume size for the root directory. Next, for Tags, we're gonna give it a name tag with the value WebInstance. Clicking on Security Group, we'll configure a new security group with SSH and HTTP access. We'll give it a name. We'll call it WebInstanceSG. We then click on Review and Launch. Review the settings, and then click Launch, and we'll select an EC2 key pair. Okay, so that's launching the EC2 instance, and this will be the instance that we will use CodeDeploy to deploy to. So the first thing we'll do, is we'll grab the Public IP address, and we'll SSH into this instance. So jumping over to our terminal, we do ssh -v for verbose,


- i for the key pair, the username ec2-user, and then the IP address, enter, and we see we'reis fully connecting over ssh, okay excellent. Here we'll run a command to show the processes, and here we can see that the codedeploy-agent installed successfully at status successfully, which is what we want, so that's good. The next thing I'll do, is I'll jump back in to the browser and we'll attempt to make a connection to the web application to see whether we can see which we can we expect to fail, because we haven't actually done the deployment yet, okay, so as expected. So now we'll complete the CodeDeploy setup. We click on Create application. We'll give it an application name of WebApp. The Compute Platform will be EC2, and we'll establish a deployment group called WebApp Deployment Group. We leave the deployment settings as defaults, and then for the Environment configuration, we select Amazon EC2 instances, we give it a key name of Name, and a value of WebInstance, and we can see, we've already detected the one instance that we've just spun up. We leave the remaining settings as defaults, but then we realize we need to set the Service Role for CodeDeploy. So we'll go back in to IAM, and we'll create a Service Role for CodeDeploy. So the service that will be used for this will be CodeDeploy. We'll click on Permissions, and by default, we select the AWS CodeDeploy role policy. We'll give our role a name of CodeDeployServiceRole, and we complete this by clicking the Create role button. Okay, that role has been successfully created. We need to select it, so that we can copy the role, and we'll copy this, and we'll paste it back in to our CodeDeploy project, pasting it here, we then complete the creation of the application, and our deployment group has been successfully created. We select it, and then we'll setup a new deployment revision. So, under the Revision location, we need to place the URL to our WebApp artifact. So this is s3://catestbuild/ We get the option to specify the File type, and by default, it's being set to the right one, .zip. We can give a Deployment description. In this case, we'll type Portal Web App. We'll leave the remainder of the settings as defaults, and click the Deploy button. Now if all goes well, if we've got all our security settings correct, the deployment should go green to indicate that it has been successfully deployed. So in the background, the CodeDeploy Agent, will be polling for updates. It will find that we're attempting to do a deployment, and it will reach out to the s3 bucket, and grab the artifact, and then run through the appspec.yml file to tell it how to do that. So we can see here the status has succeeded. So we'll go back to our browser, and we'll reload this URL, and, excellent, our application and WebApp had been successfully deployed, and our Web Services started up and we're able to actually browse to this. So we'll jump back in to visual code, and we'll take a closer look at that appspec.yml file. So this drives the CodeDeploy deployment on the instance itself via the CodeDeploy Agent. The first thing we do, is we do some file management. So we deploy webpage directory into the /var/www directory. We then run a script called install_dependencies, and all this does is it uses the yum package manager to install the nginx web server, followed by a command to reset the home directory for nginx that it serves out of. So it's reset to the /var/www. Following on from there, we make a call out to our start_server script, which simply calls service nginx start. So jumping back in to the EC2 instance terminal, if we rerun the processes command, we can see now that we've got an additional process, which is our nginx web server process. If we examine the /var/www directory, we should find the contents of our portal. So this is our Web Portal App, one of our static assets, our HTML files, CSS files, and JavaScript files. So navigating into their production directory, we can see our index.html file. So all of this is being done by the CodeDeploy Agent. Lets take a look at a couple of the log files. The first log file represents the login done for the CodeDeploy Agent. So if you run into some problems, this is a good log to consult. The next log file is a log file that is maintained for the actual deployment of our artifact. So this is in /opt/codedeploy-agent/deployment/root, and then deployment -logs, and then codedeploy-agent-deployments.log, and here we can see the outputs of the scripts that were run, the first one to install nginx, and then towards the bottom, we can see that we make a call to start our server, and that this is done. Okay, so that is our CodeDeploy service, and the end result is a deployment of our WebApp to our EC2 instance.

About the Author
Learning Paths

Jeremy is a Content Lead Architect and DevOps SME here at Cloud Academy where he specializes in developing DevOps technical training documentation.

He has a strong background in software engineering, and has been coding with various languages, frameworks, and systems for the past 25+ years. In recent times, Jeremy has been focused on DevOps, Cloud (AWS, Azure, GCP), Security, Kubernetes, and Machine Learning.

Jeremy holds professional certifications for AWS, Azure, GCP, Terraform, Kubernetes (CKA, CKAD, CKS).