10 Commits

Author SHA1 Message Date
Madhura Bhave
7468f574d7 Add more context to the Kubernetes container lifecycle documentation
Closes gh-20932
2020-05-11 18:38:49 -07:00
Johnny Lim
5fad43ec40 Polish
See gh-20973
2020-04-16 13:46:53 +02:00
Phillip Webb
28da1da241 Update availability/probe documentation
Update the application availability and probes documentation following
the recent set of updates.

See gh-20962
2020-04-14 16:40:36 -07:00
Phillip Webb
d9fb4dd477 Don't use monospacing in documentation headings
Closes gh-20875
2020-04-07 11:08:57 -07:00
Madhura Bhave
0e1394ef30 Update reference documentation for layer changes
Update the reference documentation following the jar format changes.

See gh-20813
2020-04-03 00:34:27 -07:00
Phillip Webb
0717de723f Polish 2020-03-23 20:03:44 -07:00
Brian Clozel
4be64e8f9c Add "management.health.probes.enabled" config property
Prior to this commit, we were relying on the
`"spring.main.cloud-platform"` property for overriding cloud platform
detection and enabling liveness and readiness probes. Changes made in
gh-20553 have now been reverted.

This commit adds the `"management.health.probes.enabled"` configuration
property. The auto-configuration now enables the HTTP Probes and
`HealthIndicator` if this property is enabled, or if the Kubernetes
cloud platform is detected.

This property is `false` by default for now, since enabling this for all
Spring Boot applications would be a breaking change. In this case, the
global `"/actuator/health"` endpoint could report `OUT_OF_SERVICE`
during startup time because the application now reports the readiness as
well.

See gh-19593
2020-03-23 22:04:30 +01:00
Brian Clozel
ffdf9a422f Polish Liveness and Readiness support
This commit moves the core Liveness and Readiness support to its own
`availability` package. We've made this a core concept independent of
Kubernetes.

Spring Boot now produces `LivenessStateChanged` and
`ReadinessStateChanged` events as part of the typical application
lifecycle.

Liveness and Readiness Probes (`HealthIndicator` components and health
groups) are still configured only when deployed on Kubernetes.

This commit also improves the documentation around Probes best practices
and container lifecycle considerations.

See gh-19593
2020-03-20 23:54:00 +01:00
Brian Clozel
fd0b2f6695 Add Kubernetes Liveness and Readiness Probes support
Prior to this commit and as of Spring Boot 2.2.0, we would advise
developers to use the Actuator health groups to define custom "liveness"
and "readiness" groups and configure them with subsets of existing
health indicators.

This commit addresses several limitations with that approach.

First, `LivenessState` and `ReadinessState` are promoted to first class
concepts in Spring Boot applications. These states should not only based
on periodic health checks. Applications should be able to track changes
(and adapt their behavior) or update states (when an error happens).

The `ApplicationStateProvider` can be injected and used by applications
components to get the current application state. Components can also
track specific `ApplicationEvent` to be notified of changes, like
`ReadinessStateChangedEvent` and `LivenessStateChangedEvent`.
Components can also publish such events with an
`ApplicationEventPublisher`. Spring Boot will track startup event and
application context state to update the liveness and readiness state of
the application. This infrastructure is available in the
main spring-boot module.

If Spring Boot Actuator is on the classpath, additional
`HealthIndicator` will be contributed to the application:
`"LivenessProveHealthIndicator"` and `"ReadinessProbeHealthIndicator"`.
Also, "liveness" and "readiness" Health groups will be defined if
they're not configured already.

Closes gh-19593
2020-03-19 14:11:00 +01:00
Andy Wilkinson
ce99db1902 Port the build to Gradle
Closes gh-19609
Closes gh-19608
2020-01-10 14:15:35 +00:00