Spring Boot

Deploying a Spring Boot application to the Cloud?

Spring Boot’s flexible packaging options provide a great deal of choice when it comes to deploying your application. You can deploy Spring Boot applications to a variety of cloud platforms, to container images (such as Docker), or to virtual/real machines.

This Article covers some of the more common deployment scenarios.

1. Deploying to Containers

If you are running your application from a container, you can use an executable jar, but it is also often an advantage to explode it and run it in a different way. Certain PaaS implementations may also choose to unpack archives before they run. For example, Cloud Foundry operates this way. The simplest way to run an unpacked archive is by starting the appropriate launcher, as follows:

$ jar -xf myapp.jar

$ java org.springframework.boot.loader.JarLauncher

This is actually slightly faster on startup (depending on the size of the jar) than running from an unexploded archive. At runtime you shouldn’t expect any differences. More Additional Information On Spring Boot Online Course

Once you have unpacked the jar file, you can also get an extra boost to startup time by running the app with its "natural" main method instead of the JarLauncher. For example:

$ jar -xf myapp.jar

$ java -cp BOOT-INF/classes:BOOT-INF/lib/* com.example.MyApplication

More efficient container images can also be created by copying the dependencies to the image as a separate layer from the application classes and resources (which normally change more frequently). There is more than one way to achieve this layer separation. For example, using a Dockerfile you could express it in this form:

FROM openjdk:8-jdk-alpine AS builder

WORKDIR target/dependency

ARG APPJAR=target/*.jar

COPY ${APPJAR} app.jar

RUN jar -xf ./app.jar



FROM openjdk:8-jre-alpine

VOLUME /tmp

ARG DEPENDENCY=target/dependency

COPY --from=builder ${DEPENDENCY}/BOOT-INF/lib /app/lib

COPY --from=builder ${DEPENDENCY}/META-INF /app/META-INF

COPY --from=builder ${DEPENDENCY}/BOOT-INF/classes /app

ENTRYPOINT ["java","-cp","app:app/lib/*","com.example.MyApplication"]

Assuming the above Dockerfile is in the current directory, your docker image can be built with docker build ., or optionally specifying the path to your application jar, as shown in the following example:

docker build --build-arg APPJAR=path/to/myapp.jar .

2. Deploying to the Cloud

Spring Boot’s executable jars are ready-made for most popular cloud PaaS (Platform-as-a-Service) providers. These providers tend to require that you “bring your own container”. They manage application processes (not Java applications specifically), so they need an intermediary layer that adapts your application to the cloud’s notion of a running process.

Two popular cloud providers, Heroku and Cloud Foundry, employ a “buildpack” approach. The buildpack wraps your deployed code in whatever is needed to start your application. It might be a JDK and a call to java, an embedded web server, or a full-fledged application server. A buildpack is pluggable, but ideally you should be able to get by with as few customizations to it as possible. This reduces the footprint of functionality that is not under your control. It minimizes divergence between development and production environments.

Ideally, your application, like a Spring Boot executable jar, has everything that it needs to run packaged within it.

2.1. Cloud Foundry

Cloud Foundry provides default buildpacks that come into play if no other buildpack is specified. The Cloud Foundry Java buildpack has excellent support for Spring applications, including Spring Boot. You can deploy stand-alone executable jar applications as well as traditional .war packaged applications.

Once you have built your application (by using, for example, mvn clean package) and have installed the cf command line tool, deploy your application by using the cf push command, substituting the path to your compiled .jar. Be sure to have logged in with your cf command line client before pushing an application. The following line shows using the cf push command to deploy an application:

$ cf push acloudyspringtime -p target/demo-0.0.1-SNAPSHOT.jar

In the preceding example, we substitute acloudyspringtime for whatever value you give cf as the name of your application.

See the cf push documentation for more options. If there is a Cloud Foundry manifest.yml file present in the same directory, it is considered.

At this point, cf starts uploading your application, producing output similar to the following example:

Uploading acloudyspringtime... OK

Preparing to start acloudyspringtime... OK

-----> Downloaded app package (8.9M)

-----> Java Buildpack Version: v3.12 (offline) | https://github.com/cloudfoundry/java-buildpack.git#6f25b7e

-----> Downloading Open Jdk JRE 1.8.0_121 from https://java-buildpack.cloudfoundry.org/openjdk/trusty/x86_64/openjdk-1.8.0_121.tar.gz (found in cache)

       Expanding Open Jdk JRE to .java-buildpack/open_jdk_jre (1.6s)

-----> Downloading Open JDK Like Memory Calculator 2.0.2_RELEASE from https://java-buildpack.cloudfoundry.org/memory-calculator/trusty/x86_64/memory-calculator-2.0.2_RELEASE.tar.gz (found in cache)

       Memory Settings: -Xss349K -Xmx681574K -XX:MaxMetaspaceSize=104857K -Xms681574K -XX:MetaspaceSize=104857K

-----> Downloading Container Certificate Trust Store 1.0.0_RELEASE from https://java-buildpack.cloudfoundry.org/container-certificate-trust-store/container-certificate-trust-store-1.0.0_RELEASE.jar (found in cache)

       Adding certificates to .java-buildpack/container_certificate_trust_store/truststore.jks (0.6s)

-----> Downloading Spring Auto Reconfiguration 1.10.0_RELEASE from https://java-buildpack.cloudfoundry.org/auto-reconfiguration/auto-reconfiguration-1.10.0_RELEASE.jar (found in cache)

Checking status of app 'acloudyspringtime'...

  0 of 1 instances running (1 starting)

  ...

  0 of 1 instances running (1 starting)

  ...

  0 of 1 instances running (1 starting)

  ...

  1 of 1 instances running (1 running)



App started

Congratulations! The application is now live!

Once your application is live, you can verify the status of the deployed application by using the cf apps command, as shown in the following example:

$ cf apps

Getting applications in ...

OK



name                 requested state   instances   memory   disk   urls

...

acloudyspringtime    started           1/1         512M     1G     acloudyspringtime.cfapps.io

...

Once Cloud Foundry acknowledges that your application has been deployed, you should be able to find the application at the URI given. In the preceding example, you could find it at https://acloudyspringtime.cfapps.io/.

2.1.1. Binding to Services

By default, metadata about the running application as well as service connection information is exposed to the application as environment variables (for example: $VCAP_SERVICES). This architecture decision is due to Cloud Foundry’s polyglot (any language and platform can be supported as a buildpack) nature. Process-scoped environment variables are language agnostic.

Environment variables do not always make for the easiest API, so Spring Boot automatically extracts them and flattens the data into properties that can be accessed through Spring’s Environment abstraction, as shown in the following example:

@Component

class MyBean implements EnvironmentAware {



    private String instanceId;



    @Override

    public void setEnvironment(Environment environment) {

        this.instanceId = environment.getProperty("vcap.application.instance_id");

    }



    // ...



}

All Cloud Foundry properties are prefixed with vcap. You can use vcap properties to access application information (such as the public URL of the application) and service information (such as database credentials). See the ‘CloudFoundryVcapEnvironmentPostProcessor’ Javadoc for complete details.

The Java CFEnv project is a better fit for tasks such as configuring a DataSource.

To get in-depth knowledge on Spring Boot Training

2.2. Heroku

Heroku is another popular PaaS platform. To customize Heroku builds, you provide a Procfile, which provides the incantation required to deploy an application. Heroku assigns a port for the Java application to use and then ensures that routing to the external URI works.

You must configure your application to listen on the correct port. The following example shows the Procfile for our starter REST application:

web: java -Dserver.port=$PORT -jar target/demo-0.0.1-SNAPSHOT.jar

Spring Boot makes -D arguments available as properties accessible from a Spring Environment instance. The server.port configuration property is fed to the embedded Tomcat, Jetty, or Undertow instance, which then uses the port when it starts up. The $PORT environment variable is assigned to us by the Heroku PaaS.

This should be everything you need. The most common deployment workflow for Heroku deployments is to git push the code to production, as shown in the following example:

$ git push heroku master



Initializing repository, done.

Counting objects: 95, done.

Delta compression using up to 8 threads.

Compressing objects: 100% (78/78), done.

Writing objects: 100% (95/95), 8.66 MiB | 606.00 KiB/s, done.

Total 95 (delta 31), reused 0 (delta 0)



-----> Java app detected

-----> Installing OpenJDK 1.8... done

-----> Installing Maven 3.3.1... done

-----> Installing settings.xml... done

-----> Executing: mvn -B -DskipTests=true clean install



       [INFO] Scanning for projects...

       Downloading: https://repo.spring.io/...

       Downloaded: https://repo.spring.io/... (818 B at 1.8 KB/sec)

        ....

       Downloaded: https://s3pository.heroku.com/jvm/... (152 KB at 595.3 KB/sec)

       [INFO] Installing /tmp/build_0c35a5d2-a067-4abc-a232-14b1fb7a8229/target/...

       [INFO] Installing /tmp/build_0c35a5d2-a067-4abc-a232-14b1fb7a8229/pom.xml ...

       [INFO] ------------------------------------------------------------------------

       [INFO] BUILD SUCCESS

       [INFO] ------------------------------------------------------------------------

       [INFO] Total time: 59.358s

       [INFO] Finished at: Fri Mar 07 07:28:25 UTC 2014

       [INFO] Final Memory: 20M/493M

       [INFO] ------------------------------------------------------------------------



-----> Discovering process types

       Procfile declares types -> web



-----> Compressing... done, 70.4MB

-----> Launching... done, v6

       https://agile-sierra-1405.herokuapp.com/ deployed to Heroku



To git@heroku.com:agile-sierra-1405.git

 * [new branch]      master -> master

2.3. OpenShift

OpenShift is the Red Hat public (and enterprise) extension of the Kubernetes container orchestration platform. Similarly to Kubernetes, OpenShift has many options for installing Spring Boot based applications.

OpenShift has many resources describing how to deploy Spring Boot applications, including:

  • Using the S2I builder
  • Architecture guide
  • Running as a traditional web application on Wildfly
  • OpenShift Commons Briefing

2.4. Amazon Web Services (AWS)

Amazon Web Services offers multiple ways to install Spring Boot-based applications, either as traditional web applications (war) or as executable jar files with an embedded web server. The options include:

  • AWS Elastic Beanstalk
  • AWS Code Deploy
  • AWS OPS Works
  • AWS Cloud Formation
  • AWS Container Registry

Each has different features and pricing models. In this document, we describe only the simplest option: AWS Elastic Beanstalk. More additional Information On AWS Online Training

2.4.1. AWS Elastic Beanstalk

As described in the official Elastic Beanstalk Java guide, there are two main options to deploy a Java application. You can either use the “Tomcat Platform” or the “Java SE platform”.

Using the Tomcat Platform

This option applies to Spring Boot projects that produce a war file. No special configuration is required. You need only follow the official guide.

Using the Java SE Platform

This option applies to Spring Boot projects that produce a jar file and run an embedded web container. Elastic Beanstalk environments run an nginx instance on port 80 to proxy the actual application, running on port 5000. To configure it, add the following line to your application.properties file:

server.port=5000

Google Cloud

Google Cloud has several options that can be used to launch Spring Boot applications. The easiest to get started with is probably App Engine, but you could also find ways to run Spring Boot in a container with Container Engine or on a virtual machine with Compute Engine.

To run in App Engine, you can create a project in the UI first, which sets up a unique identifier for you and also sets up HTTP routes. Add a Java app to the project and leave it empty and then use the Google Cloud SDK to push your Spring Boot app into that slot from the command line or CI build.

Enroll for live free demo on Spring Boot Online Training

App Engine Standard requires you to use WAR packaging. Follow these steps to deploy App Engine Standard application to Google Cloud.

Alternatively, App Engine Flex requires you to create an app.yaml file to describe the resources your app requires. Normally, you put this file in src/main/appengine, and it should resemble the following file:

service: default



runtime: java

env: flex



runtime_config:

  jdk: openjdk8



handlers:

- url: /.*

  script: this field is required, but ignored



manual_scaling:

  instances: 1



health_check:

  enable_health_check: False



env_variables:

  ENCRYPT_KEY: your_encryption_key_here

You can deploy the app (for example, with a Maven plugin) by adding the project ID to the build configuration, as shown in the following example:

<plugin>

    <groupId>com.google.cloud.tools</groupId>

    <artifactId>appengine-maven-plugin</artifactId>

    <version>1.3.0</version>

    <configuration>

        <project>myproject</project>

    </configuration>

</plugin>

Then deploy with mvn appengine:deploy (if you need to authenticate first, the build fails).

3. Installing Spring Boot Applications

In addition to running Spring Boot applications by using java -jar, it is also possible to make fully executable applications for Unix systems. A fully executable jar can be executed like any other executable binary or it can be registered with init.d or systemd. This makes it very easy to install and manage Spring Boot applications in common production environments.

To create a ‘fully executable’ jar with Maven, use the following plugin configuration:

<plugin>

    <groupId>org.springframework.boot</groupId>

    <artifactId>spring-boot-maven-plugin</artifactId>

    <configuration>

        <executable>true</executable>

    </configuration>

</plugin>

The following example shows the equivalent Gradle configuration:

bootJar {

    launchScript()

}

You can then run your application by typing ./my-application.jar (where my-application is the name of your artifact). The directory containing the jar is used as your application’s working directory.