Skip to main content

Spring Boot on EC2

This article is about installing a Spring Boot Application on AWS using this technology stack:

  • EC2 to run the Java program

  • systemctl to control start/stop/restart the application

  • Configuration of the Spring Boot application using environment variables


We start from the assumption that a jar file has been created and is available on AWS S3 or some other artifact repository.

Step 1: Create the EC2 Instance


Prerequisites:

  • AWS account

  • 1 VPC - dev-vpc

  • 1 subnet -  dev-apps-subnet


I created an EC2 instance of size small with an Amazon Linux image.

In that instance, I created a folder for the application and copied the jar file genova-1.0.jar containing the Spring Boot application to that folder.

Step 2: Configure the Process to Run the Java Application


SystemD is a Linux facility that automatically starts, restarts, and stops processes.

In this case, it consists of a file in /etc/systemd/system:



Also, it is possible to configure other environment variables in the file genova.conf:


JAVA_HOME=/usr/lib/jvm/java-11-openjdk-11.0.13.0.8-1.amzn2.0.3.x86_64
JAVA_OPTS="-Xms256m -Xmx256m"


Because we want to use the same approach on multiple deployments (EC2, Docker, Elastic Beanstalk), we will remove the configuration from the .conf file and move it all to the .service file. It is shown in this article as an option.


Commands used:


  • sudo systemctl daemon-reload - reload the configuration

  • sudo systemctl start  genova.service - start the service

  • sudo journalctl -u genova.service - list recent log entries

Step 3: API Gateway Configuration

The EC2 instance is in a private subnet for security purposes and is inaccessible directly over the public Internet. To provide access to the application, we used the AWS API Gateway, which acts in this case like a load balancer:










Popular posts from this blog

View - A Functor for Web App Design

This blog is about practical applications of Category Theory to the development of Java + Spring applications. I am looking at a design approach to simplify the development of web applications. Traditionally, this kind of back-office application is based on the Web 1.0 technology stack, using Spring Boot and Thymeleaf. My approach is to keep using Spring Boot but replace the generation of HTML with J2HTML and higher-order views. From a Category Theory point of view, we can look at web applications as mappings from the Category of Business Entities and the Category of UI Widgets. If we go one step further, both business entities and UI widgets are mapped to Java classes. Thus, we can view a web application (or a part of it) as an endofunctor in the Category of Java Classes. We define the View-functor as follows: domain(V) - Java classes representing business entities - e.g., Invoice, User - and, codomain(V) - Java functions that render the business entity as a DomContent object (DomCont...
Read more

Performance Testing a New CRM

Performance testing  is challenging, frustrating, often underestimated typically getting attention only after an incident. How did we the performance test and what did we learn during the development and implementation of  web-services for a new CRM system?
Read more

On Defining Messages

“Defining Message Formats” is the title of a message posted on the Service Oriented Architecture mailing list [1]  which attracted a lot of attention.  The post summarizes  the dilemma faced by solution architects when they have to define a service interface: 1. Base the internal message format on the external message standard (MISMO for this industry). This message set is bloated, but is mature, supports most areas of the business, and is extensible for attributes specific to this company and its processes. 2. Create an XML-based message set based on the company's enterprise data model, which the company has invested a great amount of money into, and includes a very high percentage of all attributes needed in the business. In a nutshell, we've generated an XML Schema from ER Studio, and will tinker with that construct types that define the payloads for messages. 3. Use MISMO mainly for its entity definitions, but simplify the structure to improve usability. We benefit fr...
Read more