Setting up CI/CD Pipeline for a Monolithic Service

Read first:

• PART 1: How I designed and deployed a scalable microservice architecture with limited resources

As mentioned in the last part, we have already setup and deployed our three services, but we don’t want to keep pulling the changes every time we make a small change in the codebase, that’s why we need to setup our CI/CD Pipeline.

Let’s get started…

Let’s first treat all our services as Monolithic, and deploy them to the instance.

Create IAM Roles for CodeDeploy and EC2 Instance.

• Go to IAM → Roles in your AWS Console
• Create an IAM Role with AmazonEC2RoleforAWSCodeDeploy and AutoScalingNotificationAccessRole policies.
• Let’s name this IAM Role as CodeDeployInstanceRole
• Create another IAM Role with AWSCodeDeployRole policy.
• Let’s name this one as CodeDeployServiceRole

Configure EC2 Instance for the application

Make sure you already have an instance running.

You just gotta modify the tags to let the CodeDeploy Agent know which instances to deploy the code on.

• Let’s put two tags: env: production and name: my-application

Create S3 Bucket for application revision

This bucket will be used to store our revised application before it is deployed to the instance.

Note: Creating this bucket is necessary if you want to add some files to the codebase that you couldn’t store in the Github repository, such as .env files.

If you don’t have any such thing, then you can skip this step.

• You may name the bucket whatever you like.
• Make sure Block all public access option is checked.

Configure CodeDeploy

• Navigate to CodeDeploy in AWS Management Console.
• Create an application and give it a name.
• Under Compute Platform choose EC2/On-premises
• Create Application.

• After creating the application, create a deployment group
• Name it whatever you’d like, and under Service Role choose CodeDeployServiceRole.

• Under Deployment Type choose In-place.
• For Environment Configuration choose Amazon EC2 instances and specify the tags that we specified previously for our instances: env: production and name: my-application
• For Deployment Settings choose CodeDeployDefault.OneAtATime.

• Deselect Enable Load Balancing
• Create Deployment Group.

Phew, we are done with setting up on the AWS side, now let’s get to the good stuff.

Setting up on the Code Repository Side

Create an appspec.yml file, and place it in the root of the directory.

Let’s setup our CI workflow now. I am using Github Actions for my CI/CD setup.

Create a .github/workflow/deploy.yml file

Note: In the Configure Secrets step, we are fetching our secrets from a AWS S3 Bucket where we have stored to .env files, as those can not be stored on the Github repository.

If you don’t have any secrets to configure, you can deploy directly from Github repository. Instead s3-location, you'd need to specify github-location: reference

Now, we just have to configure AWS Credentials that we used above.

Setting up CodeDeploy IAM User

• Go to IAM -> Users in your AWS Console.
• Create a new IAM User, let’s name it CodeDeployUser, and give it Programmatic Access

• We need 2 sets of permissions: AmazonS3FullAccess and AWSCodeDeployDeployerAccess

• Create the user, and save the user’s credentials ACCESS_KEY_ID and SECRET_ACCESS_KEY

Set those secrets in your Github Repository and you are all good to go!

Great! now, every push you do to your repository will be deployed to your EC2 instance.

But, wait. If you push to your repository after modifying just one of the services, all of them need to be restarted, that’s not how a Microservice Architecture works.

We need to decouple all our services from each other for all of them to operate separately.

Let’s get to that stuff in PART 3…

Read Next:

• PART 3: How I designed a CI/CD setup for a Microservice Architecture at zero cost