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’ve built your application (using, for example, mvn clean package
) and
installed the cf
command line tool, simply deploy your application using the cf push
command as follows,
substituting the path to your compiled .jar
. Be sure to have
logged in with your
cf
command line client before pushing an application.
$ cf push acloudyspringtime -p target/demo-0.0.1-SNAPSHOT.jar
See the cf push
documentation for more options. If there is a Cloud Foundry
manifest.yml
file present in the same directory, it will be consulted.
Note | |
---|---|
Here we are substituting |
At this point cf
will start uploading your application:
Uploading acloudyspringtime... OK Preparing to start acloudyspringtime... OK -----> Downloaded app package (8.9M) -----> Java Buildpack source: system -----> Downloading Open JDK 1.7.0_51 from .../x86_64/openjdk-1.7.0_51.tar.gz (1.8s) Expanding Open JDK to .java-buildpack/open_jdk (1.2s) -----> Downloading Spring Auto Reconfiguration from 0.8.7 .../auto-reconfiguration-0.8.7.jar (0.1s) -----> Uploading droplet (44M) Checking status of app 'acloudyspringtime'... 0 of 1 instances running (1 starting) ... 0 of 1 instances running (1 down) ... 0 of 1 instances running (1 starting) ... 1 of 1 instances running (1 running) App started
Congratulations! The application is now live!
It’s easy to then verify the status of the deployed application:
$ 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 hit the application at the URI given, in this case
acloudyspringtime.cfapps.io/
.
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 don’t 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:
@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 VcapApplicationListener
Javdoc for
complete details.
Tip | |
---|---|
The Spring Cloud project is a better fit for tasks such as configuring a DataSource; it also lets you use Spring Cloud with Heroku. |