Category: Kev’s Blog

Posted on

Deploying a Docker container to AWS Elastic Beanstalk

In my previous post, I looked at using the EB cli to deploy a Spring Boot app to Beanstalk. If you have an app that you have packaged in a Docker container, you can prepare this for deployment to Beanstalk using the EB cli command:

$ eb init -p docker application-name

This is described in the docs here.

This command inits the app for deployment, creating a default .elasticbeanstalk/config.yml file that looks like this:

branch-defaults:
  default:
    environment: null
    group_suffix: null
global:
  application_name: beanstalk-docker-with-mounted-volume
  branch: null
  default_ec2_keyname: null
  default_platform: Docker
  default_region: us-west-2
  include_git_submodules: true
  instance_profile: null
  platform_name: null
  platform_version: null
  profile: null
  repository: null
  sc: null
  workspace_type: Application

Next create a Beanstalk environment for deploying your app:

$ eb create environment-name

This will take a few minutes on your first deploy as it provisions everything required for running your app on Beanstalk, including an Auto Scaling Group and an EC2 instance.

Posted on

Using WireMock with Spring Boot 3 and JUnit 5

To use WireMock with JUnit 4.x you use a @Rule statement to configure the WireMock server:

@Rule
public WireMockRule wireMockRule = new WireMockRule();

With JUnit 5, @Rule was replaced with extensions, so the equivalent setup looks like this:

@RegisterExtension
static WireMockExtension wm1 = WireMockExtension.newInstance()
    .options(options().port(8089))
    .build();

Testing Spring Boot 3 apps with JUnit 5 however gives the following error as Spring Boot 3 does not have Jetty 11 dependencies, so WireMock’s use of Jetty 11 fails to start:

com.github.tomakehurst.wiremock.common.FatalStartupException: Jetty 11 is not present and no suitable HttpServerFactory extension was found. Please ensure that the classpath includes a WireMock extension that provides an HttpServerFactory implementation. See http://wiremock.org/docs/extending-wiremock/ for more information.
at com.github.tomakehurst.wiremock.WireMockServer.lambda$getHttpServerFactory$2(WireMockServer.java:95)

Per the WireMock docs here, wiremock-spring-boot provides support using another approach. To use, add this dependency:

<dependency>
    <groupId>com.maciejwalkowiak.spring</groupId>
    <artifactId>wiremock-spring-boot</artifactId>
    <version>2.1.2</version>
    <scope>test</scope>
</dependency>

Enable for your test by adding @EnableWireMock:

@SpringBootTest
@EnableWireMock({
        @ConfigureWireMock(name = "your-mock-service", property = "your-url-to-mock.url")
})
class YourTest {
...
}

Inject the WireMock server into your test with:

@InjectWireMock("your-mock-service")
private WireMockServer wiremock;

@Value("${your-url-to-mock.url}")
private String wiremockUrl;

While this is a neat option to use with SpringBootTests, unfortunately it still doesn’t work with Spring Boot 3.3.x because of WireMock’s dependency on Jetty 11.

Tickets posted on the wiremock-spring-boot project suggest to avoid this in the meantime by using a dependency for wiremock-standalone instead:

        <dependency>
            <groupId>com.maciejwalkowiak.spring</groupId>
            <artifactId>wiremock-spring-boot</artifactId>
            <version>2.0.0</version>
            <scope>test</scope>
            <exclusions>                
                <exclusion>
                    <groupId>org.wiremock</groupId>
                    <artifactId>wiremock</artifactId>
                </exclusion>
            </exclusions>
        </dependency>
        <dependency>
            <groupId>org.wiremock</groupId>
            <artifactId>wiremock-standalone</artifactId>
            <version>3.3.1</version>
            <scope>test</scope>
        </dependency>

This works as expected.

Posted on

Changing MacOS keybindings for Home/End keys to behave the same as Windows

Sometimes muscle memory is hard to unlearn. I can’t get used to the Home and End keys on a Mac jumping to the top and end of a file instead of start and end of a line. Yes, I know Cmd-left and Cmd-right do the same thing on a Mac, but pressing Home and having it jump to the top of a file is too much for me to handle when in the middle of editing something in an IDE like Eclipse.

To remap the Home and End keys to behave the same as on Windows, make a dir here:

mkdir ~/Library/KeyBindings

and create a file called DefaultKeyBinding.dict (NOTE: this file must be named exactly as shown to work) containing this content:

{
    "\UF729"  = "moveToBeginningOfLine:";
    "\UF72B"  = "moveToEndOfLine:";
    "$\UF729" = "moveToBeginningOfLineAndModifySelection:";
    "$\UF72B" = "moveToEndOfLineAndModifySelection:";
}

Logoff and log back on again, and the Home and End keys should now work the same as on Windows. (source here)

If this still doesn’t work in Eclipse, it maybe because Line Start and Line End and explicitly mapped to Cmd-left and Cmd-right – these can be changed in Preferences under Keys:

Delete the existing mappings for Home and End and change to the Home and End keys:

Posted on

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

Service Port Configuration

By default, Beanstalk services are deployed on port 5000. Since Spring Boot apps are on port 8080 by default, the quickest way to configure Spring Boot to accept incoming requests on port 5000 is to edit the ‘Updates, monitoring and logging’ section and add a new env var for Spring Boot to reconfigure to use port 5000 instead (this is described here)

Added new env var SERVER_PORT=5000:

Proudly powered by WordPress