Deploying a Spring Boot app to AWS Elastic Beanstalk with the eb cli

Deploying a Spring Boot app to AWS Elastic Beanstalk is relatively easy using the eb cli tool, if you’re prepared to accept some defaults as part of the deploy. It’s probably possible to configure/customize IAM roles, Security Groups etc, but accepting the defaults is an easy way to deploy during development.

To initialize a new Elastic Beanstalk deployment, run in the root of your Spring Boot source folder:

eb init

Before creating the environment and deploying your app, edit the .elasticbeanstalk/config.yml that the previous step creates, to configure the built app jar to be deployed, by adding this section:

deploy:
artifact: target/your-app-jar-0.0.1-SNAPSHOT.jar

To create a single dev/test env with no load balancing:

eb create --single

To tear down the deployed ec2 instance running your Spring Boot app:

eb terminate

AWS Lambda – querying and updating the Lambda runtime with the AWS CLI

In a previous post I used jq to parse the responses from the aws cli for Lambdas to search for or parse the results for specific property values. Querying Lambda properties can also be done via the aws cli itself without using jq (although using jq is significantly more powerful).

If you’ve received an email from AWS about runtimes that are reaching End of Life, the emails usually contain an example use of the cli showing how to query for specific runtimes, for example:

aws lambda list-functions --function-version ALL --region us-west-1 --output text --query "Functions[?Runtime=='nodejs14.x'].FunctionArn"

The long term solution for upgrading a runtime should be to redeploy and test with the latest runtime and then redeploy your production value after testing. It is possible for a quick fix to update the runtime of a deployed Lambda directly via the aws cli. Once you’ve identified which Lambdas need to update, use this command to update:

aws lambda update-function-configuration --function NAME --runtime RUNTIMENAME

Refresher: serverless framework local development workflow

It’s been a while since I’ve written any notes about the Serverless framework, so here’s a few notes as a refresher on typical steps I use for local development.

As a reminder to self, regions I typically deploy to are:

  • us-west-1 : SF
  • us-west-2: Oregon
  • eu-west-2: London

AWS regions are listed here.

To deploy:

serverless deploy --region eu-west-2

To invoke local:

serverless invoke local --function functionName

To invoke remotely:

serverless invoke --function functionName --region eu-west-2

To check logs from last invoke:

serverless logs --function functionName --region eu-west-2

serverless framework remove error: “An error occurred: xyzRole – Cannot delete entity, must detach all policies first.”

Attempting a ‘serverless remove’ on a deployed error, I got this unexpected error I haven’t seen before:

An error occurred: xyzRole - Cannot delete entity, must detach all policies first.

A quick Google found an issue with the same error and an explanation. There is another policy attached to this Lambda that was not added via the serverless.yml for this stack, so CloudFormation is refusing to delete it. This answer describes exactly what I had done to add the new policy:

I also had added XRay to this Lambda via the Console, and this added an additional managed policy to enable Xray. Checking the IAM Role, here’s the XRay related policy that was added:

I deleted the XRay policy, but at this point serverless has already removed most of the stack but left the IAM role in place, but won’t delete the stack itself, so a manual delete from the Console completed the cleanup.