I think Spring Boot brings something new to the table, especially concerning DevOps - and I’ve already written a post about it. However, there’s more than metrics and healthchecks.
In one of another of my previous post, I described how to provide versioning information for Maven-built applications. This article will describe how this later post is not necessary when using Spring Boot.
As a reminder, just adding adding the spring-boot-starter-actuator
dependency in the POM, enable many endpoints, among them:
/metrics
for monitoring the application/health
to check the application can deliver the expected service/bean
lists all Spring beans in the context/configprops
lists all properties regarding the running profile(s) (if any)
Among those, one of them is of specific interest: /info
.
By default, it displays…
nothing - or more precisely, the string representation of an empty JSON object.
However, any property set in the application.properties
file (or one of its profile flavor) will find its way into the page.
For example:
Propery file | Output | |
---|---|---|
Key |
Value |
|
|
|
|
Setting static info is sure nice, but our objective is to get the version of my application within Spring Boot.
application.properties
files are automatically filtered by Spring Boot during the process-resources
build phase.
Any property in the POM can be used: it just needs to be set between @
character.
For example:
Propery file | Output | |
---|---|---|
Key |
Value |
|
|
|
|
Note that Spring Boot Maven plugin will remove the generated resources, and thus the application will use the unfiltered resource properties file from the sources. In order to keep (and use) the generated resources instead, configure the plugin in the POM like this:
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<addResources>false</addResources>
</configuration>
</plugin>
</plugins>
</build>
At this point, we have the equivalent of the previous article, but we can go even further.
The maven-git-commit-id-plugin
will generate a git.properties
stuffed will all possible git-related information.
The following snippet is an example of the produced file:
#Generated by Git-Commit-Id-Plugin #Fri Jul 10 23:36:40 CEST 2015 git.tags= git.commit.id.abbrev=bf4afbf git.commit.user.email=nicolas@frankel.ch git.commit.message.full=Initial commit\n git.commit.id=bf4afbf167d51909bd984c35ad5b85a66b9c44b9 git.commit.id.describe-short=bf4afbf git.commit.message.short=Initial commit git.commit.user.name=Nicolas Frankel git.build.user.name=Nicolas Frankel git.commit.id.describe=bf4afbf git.build.user.email=nicolas@frankel.ch git.branch=master git.commit.time=2015-07-10T23\:34\:46+0200 git.build.time=2015-07-10T23\:36\:40+0200 git.remote.origin.url=Unknown
From all of this data, only the following are used in the endpoint:
Key | Output |
---|---|
|
|
|
|
|
Since the path and the formatting is consistent, you can devise a cronjob to parse all your applications and generate a wiki page with all those information, per server/environment. No more having to ssh the server and dig into the filesystem to uncover the version.
Thus, the /info
endpoint can be a very powerful asset in your organization, whether you’re a DevOps yourself or only willing to help your Ops.