Skip to main content

Deploying Spring Boot talking to MySQL on AWS

In a recent post, I listed some very basic information about running a MySQL database on AWS.  In most cases, we don't want a database alone; we want an application that uses that database for CRUD.

I've created a simple Spring Boot application that exposes a REST API to create and manage lists of things.  The list values are all stored in a MySQL database.

When I went to deploy the application on AWS using Elastic Beanstalk, there were some really good, automatic things that happened to make my life easy:


  • AWS can deploy a Spring Boot jar very easily by simply uploading the jar during setup.
  • AWS creates security groups on the fly so I don't have to worry about extra security configuration.
  • AWS automatically generates DNS information and provides me a URL for accessing the application.
As I deployed the application and saw all of these things, I was pretty excited.  It is nice to have a lot of this stuff taken care of for me.

Then, I tried to test my application... and it was time to deal with problems.

For anyone who has ever worked in software development, you know that nothing ever just fully, magically works.  There is some configuration somewhere that has to be done.  For me, here are the things I had to do:

1. Configure the deployment port
Spring boot deploys on port 8080 by default -- this is common/classic spring.  AWS Elastic Beanstalk wants me to deploy on port 5000 because it somehow magically redirects traffic from standard web/HTTP ports to port 5000.  To make this magic work, I had to modify Software under Configuration:


Once there, we have to set the SERVER_PORT environment variable to 5000.  Spring automatically detects this environment variable and updates the server.port property to use this value.  Problem #1 solved.


2. Configure the database password
I am using JdbcTemplate on top of a MysqlDataSource in my application.  The data source is configured to pull the server name, user, and password from standard spring data properties:
  • spring.datasource.url
  • spring.datasource.username
  • spring.datasource.password
I don't mind leaving the url and username in the properties file for deployment (if I was really serious about security, then I WOULD mind), but I certainly don't want a plain text password out there anywhere being used.  Even though I checked in a dummy password into the properties file, that password is incorrect and won't work against the AWS database for my user.  So I also have to set the password somehow.  Using the same configuration options as the port problem, I set the SPRING_DATASOURCE_PASSWORD variable to the appropriate password.  Spring reads this value and automatically maps it to spring.datasource.password.  Problem #2 solved.

3. The application cannot talk to the database because of AWS security
When I created the MySQL database server, AWS put that server into a security group whose configuration said "only allow the IP address of the workstation that created this database server to access the database."  So even though the database was created with 'public' access, that access was still restricted to a single IP address.  The Spring Boot application running in AWS Elastic Beanstalk doesn't have my workstation's IP addresss, so the application could not connect to the database server.

To resolve this problem, I had to configure the security groups in my overall AWS environment.  This meant going to the EC2 management console, viewing Security Groups, and then adding an Inbound Rule to my database server security group that allows the Spring Boot app to connect.  Problem #3 solved.

How to get to EC2 Security Groups:

The new rule.  Notice that the Source is just the group id for my Spring Boot app.

Now, I run a Postman test against an endpoint at the URL given to me by AWS Elastic Beanstalk, and everything looks good!


Labels:

Comments

Post a Comment

Popular posts from this blog

Spring Security - Authority vs Role

I have spent a lot of time recently trying to understand the difference between Authority and Role in Spring Security.  This is a brief review of what I found. When creating a UserDetailsService or overriding configure(AuthenticationManagerBuilder auth) in the security config class that extends WebSecurityConfigurerAdapter, I basically get complete control over what I populate inside of the UserDetails that is used/returned.  This is important because the UserDetails interface really only cares about how to return one thing: Collection<? extends GrantedAuthority> getAuthorities(); A GrantedAuthority just seems like a glorified String wrapper that names some thing.  The question is... what is that thing? This is where the subtle difference between Authority and Role comes into play. I think that Role is an older thought/construct that automatically gets plugged into Authority if we just create a user with a Role.  But completely forget about the code and classes for a mi
Post a Comment
Read more

JHipster, Liquibase, MySQL, and initializing data, including booleans!

When generating a data model from JHipster JDL, we will often declare entities with Boolean fields.  I have so far abandoned H2 as a database because of liquibase issues, and both my dev and production databases will be MySQL.  This is relevant to the Boolean field desire there is a long history in software development of how to store Boolean data types in a SQL database whose standards classically do not support Boolean. In the current JHipster/Liquibase incarnation, tables in MySQL are generated for us, which is really nice.  The Boolean data types are stored as BIT  (1).  This is not a problem so far -- most developers seem to agree now that as a best practice, we should store values in databases as false = 0 and true = 1, and a BIT(1) is a great, simple way to do that. An issue arises when we try to use liquibase to set/update our database to the desired starting state.  For my project, I've chosen gradle instead of maven as a build tool, and gradle has a plugin for liquiba
Post a Comment
Read more

SQL, Booleans, JPA, and Hibernate

For a long time, SQL and Booleans have not gotten along.  Standards for SQL never really addressed the need for boolean data -- it was assumed that some other data type could easily just step in and address this need.  The result was a lot of different data models for boolean values.  Here are some examples. TRUE or FALSE T or F Y or N 1 or 0 <any value> vs NULL The internet shows the debate has gone on , even as SQL standards have changed .  Coming from a professional background with Oracle, I struggled with this across my teams because everyone had a different opinion, which led to a lot of time wasted due to debate. This said, I appreciate working with native queries in hibernate's JPA implementation against MySQL.  MySQL supports a BIT data type I recently discussed .  When we represent data in MySQL with BIT and restrict the length to just 1 (ie 1 bit), Hibernate JPA magically knows to query and return this data as a Boolean in the data returned by getResul
Post a Comment
Read more