The above image gives an overview of this article.

We will build a spring-boot application using Java and Maven and deploy it to AWS Elastic Beanstalk. Instead of manually deploying our application to AWS we will create a CI/CD pipeline using GitHub Actions for deployment.

If you followed my previous articles, you would have read about the SaaS application that was deployed to an EC2 instance, we are going to reuse the same code in this article but you can choose to use any spring-boot application to try the steps given here.

Before getting into the implementation, let’s try to refresh our memory on how Github Actions work. (we will not cover how GitHub Actions work in this article)

Implementation

Step 1: Create or download a Spring-Boot application.

We know that the default port where tomcat runs is 8080 and that’s where we access our spring-boot application as well. As we start using a registry or have more than one spring-boot app running in our local, we define the server port explicitly in the application property or yml file. Something similar needs to be done while deploying a code to AWS beanstalk. AWS has Nginx running at port 80 and that internally points to port 5000 by default. So, in our application, we would explicitly mention the server port as 5000.

Step 2: Create a new application on Elastic Beanstalk

Create an AWS account if you haven’t already and I would also recommend you to create an IAM user for this purpose, instead of using the Admin user.

Once the account is created, let’s create a new application with the following configurations,

Click on the “Create Application” button.

It takes a couple of minutes to configure the application before it becomes available for use.

Once done, we would be greeted with the below page.

Our sample application is up in AWS, we can copy the endpoint of this page as our application will be accessed using that endpoint.

Step 3: Implement CI/CD

In our previous article on Github Actions, we learned the basic concepts and what each keyword means. Let’s now use a few of them.

In the GitHub repository, let’s create a yml file under “.github/workflows” folder. We have named our yml file — deploy.yml but you can choose any other suitable name.

We have defined two jobs here, one is to build and another is to deploy the jar.

Make sure you replace the path in build to your “target/.jar and also rename the deployment_package field accordingly.

application_name and environment_name under deploy event should match with the name you provided to your beanstalk application and environment.

AWS access key and secret can be obtained from the AWS portal under Your profile -> Security credentials ->Access keys for CLI, SDK, & API access -> Create access key.

Store these values in your GitHub repository under settings -> Secrets.

Once the changes are made, commit the file. This would trigger the workflow and you can check the status under the actions tab.

Now, if you are using the “autocluck” code repository then you will need to set up MongoDB in an EC2 instance but if you are using a simple application that has no DB dependency then skip the next step.

Step 4: Set up Mongo DB in EC2 (Optional)

For those of us using the “autocluck” repository, we would need to create a new instance in EC2 and install Mongo DB in it. Follow the steps mentioned in my previous article to complete the setup.

Once done, check the public IP of that EC2 instance and update the connection string in “DatabaseConfig” java class in our application with that address.

final ConnectionString connectionString = new ConnectionString("mongodb://xx.xxx.xx.xxx:27017/test");

Commit the file.

Step 5: Test the application

Let’s test the application by hitting the health check API.

curl --location --request GET '<beanstalk -endpoint>:80/api/tweet/health' \

--header 'Content-Type: application/json' \

--data-raw '{}'

Response

200 OK

Conclusion

We just automated the deployment process of our spring boot application. With Github actions, we can now add more workflows to run the tests so we make sure broken code is not deployed to production and also add code coverage tools to maintain code standards. It’s also easy to collaborate with multiple users and take the product to market quickly.