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:
/metricsfor monitoring the application/healthto check the application can deliver the expected service/beanlists all Spring beans in the context/configpropslists 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 [email protected] 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 [email protected] 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.