Stephane Nicoll
commit
a323ff7136
|
|
@ -988,21 +988,21 @@ They are also exposed as separate HTTP Probes by using <<actuator#actuator.endpo
|
|||
|
||||
You can then configure your Kubernetes infrastructure with the following endpoint information:
|
||||
|
||||
[source,yml,indent=0,subs="verbatim"]
|
||||
[source,yaml,indent=0,subs="verbatim"]
|
||||
----
|
||||
livenessProbe:
|
||||
httpGet:
|
||||
path: /actuator/health/liveness
|
||||
port: <actuator-port>
|
||||
failureThreshold: ...
|
||||
periodSeconds: ...
|
||||
livenessProbe:
|
||||
httpGet:
|
||||
path: "/actuator/health/liveness"
|
||||
port: <actuator-port>
|
||||
failureThreshold: ...
|
||||
periodSeconds: ...
|
||||
|
||||
readinessProbe:
|
||||
httpGet:
|
||||
path: /actuator/health/readiness
|
||||
port: <actuator-port>
|
||||
failureThreshold: ...
|
||||
periodSeconds: ...
|
||||
readinessProbe:
|
||||
httpGet:
|
||||
path: "/actuator/health/readiness"
|
||||
port: <actuator-port>
|
||||
failureThreshold: ...
|
||||
periodSeconds: ...
|
||||
----
|
||||
|
||||
NOTE: `<actuator-port>` should be set to the port that the actuator endpoints are available on.
|
||||
|
|
|
|||
|
|
@ -461,10 +461,10 @@ The following example `scrape_config` adds to `prometheus.yml`:
|
|||
[source,yaml,indent=0,subs="verbatim"]
|
||||
----
|
||||
scrape_configs:
|
||||
- job_name: 'spring'
|
||||
metrics_path: '/actuator/prometheus'
|
||||
- job_name: "spring"
|
||||
metrics_path: "/actuator/prometheus"
|
||||
static_configs:
|
||||
- targets: ['HOST:PORT']
|
||||
- targets: ["HOST:PORT"]
|
||||
----
|
||||
|
||||
For ephemeral or batch jobs that may not exist long enough to be scraped, you can use https://github.com/prometheus/pushgateway[Prometheus Pushgateway] support to expose the metrics to Prometheus.
|
||||
|
|
|
|||
|
|
@ -77,7 +77,7 @@ For example, doing so lets a management server be available over HTTP while the
|
|||
ssl:
|
||||
enabled: true
|
||||
key-store: "classpath:store.jks"
|
||||
key-password: secret
|
||||
key-password: "secret"
|
||||
management:
|
||||
server:
|
||||
port: 8080
|
||||
|
|
|
|||
|
|
@ -308,8 +308,8 @@ You can further tune how `Sniffer` is configured, as shown in the following exam
|
|||
elasticsearch:
|
||||
restclient:
|
||||
sniffer:
|
||||
interval: 10m
|
||||
delay-after-failure: 30s
|
||||
interval: "10m"
|
||||
delay-after-failure: "30s"
|
||||
----
|
||||
|
||||
|
||||
|
|
@ -327,7 +327,7 @@ In addition to the properties described previously, the `spring.elasticsearch.we
|
|||
spring:
|
||||
elasticsearch:
|
||||
webclient:
|
||||
max-in-memory-size: 1MB
|
||||
max-in-memory-size: "1MB"
|
||||
----
|
||||
|
||||
If the `spring.elasticsearch.*` and `spring.elasticsearch.webclient.*` configuration properties are not enough and you'd like to fully control the client configuration, you can register a custom `ClientConfiguration` bean.
|
||||
|
|
@ -604,8 +604,8 @@ In yaml files, you can use the yaml list notation. In properties files, you must
|
|||
[source,yaml,indent=0,subs="verbatim",configprops,configblocks]
|
||||
----
|
||||
spring.ldap.embedded.base-dn:
|
||||
- dc=spring,dc=io
|
||||
- dc=pivotal,dc=io
|
||||
- "dc=spring,dc=io"
|
||||
- "dc=pivotal,dc=io"
|
||||
----
|
||||
====
|
||||
|
||||
|
|
|
|||
|
|
@ -124,12 +124,12 @@ You can configure a sleep execution in a preStop handler to avoid requests being
|
|||
This sleep should be long enough for new requests to stop being routed to the pod and its duration will vary from deployment to deployment.
|
||||
The preStop handler can be configured by using the PodSpec in the pod's configuration file as follows:
|
||||
|
||||
[source,yml,indent=0,subs="verbatim"]
|
||||
[source,yaml,indent=0,subs="verbatim"]
|
||||
----
|
||||
spec:
|
||||
containers:
|
||||
- name: example-container
|
||||
image: example-image
|
||||
- name: "example-container"
|
||||
image: "example-image"
|
||||
lifecycle:
|
||||
preStop:
|
||||
exec:
|
||||
|
|
@ -379,26 +379,26 @@ Normally, you put this file in `src/main/appengine`, and it should resemble the
|
|||
|
||||
[source,yaml,indent=0,subs="verbatim"]
|
||||
----
|
||||
service: default
|
||||
service: "default"
|
||||
|
||||
runtime: java
|
||||
env: flex
|
||||
runtime: "java"
|
||||
env: "flex"
|
||||
|
||||
runtime_config:
|
||||
jdk: openjdk8
|
||||
jdk: "openjdk8"
|
||||
|
||||
handlers:
|
||||
- url: /.*
|
||||
script: this field is required, but ignored
|
||||
- url: "/.*"
|
||||
script: "this field is required, but ignored"
|
||||
|
||||
manual_scaling:
|
||||
instances: 1
|
||||
|
||||
health_check:
|
||||
enable_health_check: False
|
||||
enable_health_check: false
|
||||
|
||||
env_variables:
|
||||
ENCRYPT_KEY: your_encryption_key_here
|
||||
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:
|
||||
|
|
|
|||
|
|
@ -293,18 +293,18 @@ For instance, the two examples below produce the same result:
|
|||
----
|
||||
spring:
|
||||
config:
|
||||
import: my.properties
|
||||
import: "my.properties"
|
||||
my:
|
||||
property: value
|
||||
property: "value"
|
||||
----
|
||||
|
||||
[source,yaml,indent=0,subs="verbatim",configblocks]
|
||||
----
|
||||
my:
|
||||
property: value
|
||||
property: "value"
|
||||
spring:
|
||||
config:
|
||||
import: my.properties
|
||||
import: "my.properties"
|
||||
----
|
||||
|
||||
In both of the above examples, the values from the `my.properties` file will take precedence over the file that triggered its import.
|
||||
|
|
@ -472,14 +472,14 @@ For example, the following file has two logical documents:
|
|||
----
|
||||
spring:
|
||||
application:
|
||||
name: MyApp
|
||||
name: "MyApp"
|
||||
---
|
||||
spring:
|
||||
application:
|
||||
name: MyCloudApp
|
||||
name: "MyCloudApp"
|
||||
config:
|
||||
activate:
|
||||
on-cloud-platform: kubernetes
|
||||
on-cloud-platform: "kubernetes"
|
||||
----
|
||||
|
||||
For `application.properties` files a special `#---` comment is used to mark the document splits:
|
||||
|
|
@ -528,14 +528,14 @@ For example, the following specifies that the second document is only active whe
|
|||
[source,yaml,indent=0,subs="verbatim",configblocks]
|
||||
----
|
||||
myprop:
|
||||
always-set
|
||||
"always-set"
|
||||
---
|
||||
spring:
|
||||
config:
|
||||
activate:
|
||||
on-cloud-platform: "kubernetes"
|
||||
on-profile: "prod | staging"
|
||||
myotherprop: sometimes-set
|
||||
myotherprop: "sometimes-set"
|
||||
----
|
||||
|
||||
|
||||
|
|
@ -568,11 +568,11 @@ For example, consider the following YAML document:
|
|||
----
|
||||
environments:
|
||||
dev:
|
||||
url: https://dev.example.com
|
||||
name: Developer Setup
|
||||
url: "https://dev.example.com"
|
||||
name: "Developer Setup"
|
||||
prod:
|
||||
url: https://another.example.com
|
||||
name: My Cool App
|
||||
url: "https://another.example.com"
|
||||
name: "My Cool App"
|
||||
----
|
||||
|
||||
In order to access these properties from the `Environment`, they would be flattened as follows:
|
||||
|
|
@ -593,8 +593,8 @@ For example, consider the following YAML:
|
|||
----
|
||||
my:
|
||||
servers:
|
||||
- dev.example.com
|
||||
- another.example.com
|
||||
- "dev.example.com"
|
||||
- "another.example.com"
|
||||
----
|
||||
|
||||
The preceding example would be transformed into these properties:
|
||||
|
|
@ -789,10 +789,10 @@ This style of configuration works particularly well with the `SpringApplication`
|
|||
service:
|
||||
remote-address: 192.168.1.1
|
||||
security:
|
||||
username: admin
|
||||
username: "admin"
|
||||
roles:
|
||||
- USER
|
||||
- ADMIN
|
||||
- "USER"
|
||||
- "ADMIN"
|
||||
----
|
||||
|
||||
To work with `@ConfigurationProperties` beans, you can inject them in the same way as any other bean, as shown in the following example:
|
||||
|
|
|
|||
Loading…
Reference in New Issue