CI/CD Hands-On: Github (Actions) + AWS (EC2, CodeDeploy, S3) — Part 1
Refactoring Issue Has Arisen
In the last article, we have figured out how to construct a CI/CD pipeline and have seen it really work. Our pipeline is still good enough to automate the complicated deployment processes and prevent errors that might be likely to occur in manual deployment. However, it gives leeway to us so that we can build faster and find bugs easier.
A trap of Docker-Dependent Architecture
The Github Action file we wrote consists of three steps:
- Build w/ Gradle
- Push build file as an image to Docker Hub
- Pull the image and run in EC2
As the lion’s share of this pipeline is dependent on Docker, we will need to write a bunch of docker commands within a Github Action script or add a part of the docker file deliberately as more triggers are required. Furthermore, build speed could be slower than other pipelines since it passes build files through Docker Hub, which is outside of AWS platform.
Vulnerability In Using an external SSH key
In order to get access to our EC2 via SSH key, we have been using an open-source project, in which I created an SSH key pair and registered the public key in EC2. Adding keys that have not been made by AWS can let your application be exposed and vulnerability increases thereby.
For those reasons, we try to change this architecture to be more AWS-friendly, in detail, using AWS EC2, CodeDeploy, and S3. Here is the outline of it.
Brief Explanation of AWS Resources To Be Used
Amazon Elastic Compute Cloud (Amazon EC2) is a web-based service that allows businesses to run applications in the Amazon Web Services public cloud. EC2 allows a developer to spin up virtual machines (VMs), which provide for cloud workloads. An Amazon EC2 instance is a virtual server for running applications on the AWS infrastructure.
CodeDeploy is a deployment service that automates application deployments to Amazon EC2 instances, on-premises instances, serverless Lambda functions, or Amazon ECS services.
Amazon Simple Storage Service (Amazon S3) is an object storage service that offers industry-leading scalability, data availability, security, and performance.
Amazon Identity and Access Management (IAM) is a web service that helps you securely control access to AWS resources. You use IAM to control who is authenticated (sign in) and authorized (has permissions) to use resources.
Set Up EC2 Environment
For the very first time, you need to have your EC2 instance in order to run an application. Since this is the level-up course, we will use the instance created the other day.
If you now have one, install CodeDeploy in your instance with the commands below. One thing you need to know is that the
bucket-nameis the name of Amazon S3 bucket where the CodeDeploy resource kit is stored and
regin-identifier is the identifier for your region. As this is basically for Amazon Linux, please see this documentation if your instance is Ubuntu.
sudo yum updatesudo yum install rubysudo yum install wgetcd /home/ec2-userwget https://bucket-name.s3.region-identifier.amazonaws.com/latest/install# In case of Asia-Pacific (Seoul), use https://aws-codedeploy-ap-northeast-2.s3.ap-northeast-2.amazonaws.com/latest/install chmod +x ./installsudo ./install autosudo service codedeploy-agent status
Assign IAM role to EC2
Now that CodeDeploy gets installed, it can handle your instance in deploying any application. However, Amazon’s policy on resource handling is that one resource should have proper authorization to control the other, and permission in each action is necessary. We will give that to the EC2.
Go to the IAM and create a new role, which will be assigned to the instance. I attached 2 policies — S3FullAccess, CodeDeployFullAccess — onto the role. Going back to EC2, modify IAM role to the one we just made (mhjang-ec2-deploy), and save.
Great job, Now the EC2 having the role grants access to CodeDeploy! We will see how to make CodeDeploy settings as well as S3 things next time. Please stay tuned with me.