Fix cross references
This commit is contained in:
Marcin Grzejszczak
committed by
spencergibb
spencergibb
parent
1e54f43e56
commit
8b8e55d747
@@ -42,7 +42,7 @@ The net result of this behavior is that all client applications that want to con
|
||||
[[discovery-first-bootstrap]]
|
||||
=== Discovery First Lookup
|
||||
|
||||
WARNING: Unless you are using <<config-first-bootstrap, config first bootstrap>>, you will need to have a `spring.config.import` property in your configuration properties with an `optional:` prefix.
|
||||
WARNING: Unless you are using xref:spring-cloud-config/client.adoc#config-first-bootstrap[config first bootstrap], you will need to have a `spring.config.import` property in your configuration properties with an `optional:` prefix.
|
||||
For example, `spring.config.import=optional:configserver:`.
|
||||
|
||||
If you use a `DiscoveryClient` implementation, such as Spring Cloud Netflix and Eureka Service Discovery or Spring Cloud Consul, you can have the Config Server register with the Discovery Service.
|
||||
@@ -211,7 +211,7 @@ spring:
|
||||
|
||||
The `spring.cloud.config.tls.enabled` needs to be true to enable config client side TLS. When `spring.cloud.config.tls.trust-store` is omitted, a JVM default trust store is used. The default value for `spring.cloud.config.tls.key-store-type` and `spring.cloud.config.tls.trust-store-type` is PKCS12. When password properties are omitted, empty password is assumed.
|
||||
|
||||
If you use another form of security, you might need to <<custom-rest-template,provide a `RestTemplate`>> to the `ConfigServicePropertySourceLocator` (for example, by grabbing it in the bootstrap context and injecting it).
|
||||
If you use another form of security, you might need to xref:spring-cloud-config/client.adoc#custom-rest-template[provide a `RestTemplate`] to the `ConfigServicePropertySourceLocator` (for example, by grabbing it in the bootstrap context and injecting it).
|
||||
|
||||
[[health-indicator]]
|
||||
=== Health Indicator
|
||||
@@ -332,7 +332,7 @@ The preceding code would sets the value of the `name` variable to `appAsecret`.
|
||||
|
||||
Since `4.0.0`, Spring Cloud Config Client supports Spring AOT transformations and GraalVM native images.
|
||||
|
||||
WARNING: AOT and native image support is not available for <<config-first-bootstrap, config first bootstrap>> (with `spring.config.use-legacy-processing=true`).
|
||||
WARNING: AOT and native image support is not available for xref:spring-cloud-config/client.adoc#config-first-bootstrap[config first bootstrap] (with `spring.config.use-legacy-processing=true`).
|
||||
|
||||
WARNING: Refresh scope is not supported with native images. If you are going to run your config client application as a native image, make sure to set `spring.cloud.refresh.enabled` property to `false`.
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ An optional property named `spring.cloud.config.server.bootstrap` can be useful
|
||||
It is a flag to indicate whether the server should configure itself from its own remote repository.
|
||||
By default, the flag is off, because it can delay startup.
|
||||
However, when embedded in another application, it makes sense to initialize the same way as any other application.
|
||||
When setting `spring.cloud.config.server.bootstrap` to `true` you must also use a <<composite-environment-repositories,composite environment repository configuration>>.
|
||||
When setting `spring.cloud.config.server.bootstrap` to `true` you must also use a xref:spring-cloud-config/server/environment-repository/composite-repositories.adoc[composite environment repository configuration].
|
||||
For example
|
||||
|
||||
[source,yaml]
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
|
||||
The configuration server can access a Git or Vault backend through an HTTP or HTTPS proxy.
|
||||
This behavior is controlled for either Git or Vault by settings under `proxy.http` and `proxy.https`.
|
||||
These settings are per repository, so if you are using a <<composite-environment-repositories,composite environment repository>> you must configure proxy settings for each backend in the composite individually.
|
||||
These settings are per repository, so if you are using a xref:spring-cloud-config/server/environment-repository/composite-repositories.adoc[composite environment repository] you must configure proxy settings for each backend in the composite individually.
|
||||
If using a network which requires separate proxy servers for HTTP and HTTPS URLs, you can configure both the HTTP and the HTTPS proxy settings for a single backend: in this case `http` access will use `http` proxy and `https` access the `https` one.
|
||||
Also, you may specify one sole proxy that will be used for both protocols using the proxy definition protocol between application and proxy.
|
||||
|
||||
|
||||
@@ -54,7 +54,7 @@ You can use the `order` property to specify the priority order for all your repo
|
||||
The lower the numerical value of the `order` property, the higher priority it has.
|
||||
The priority order of a repository helps resolve any potential conflicts between repositories that contain values for the same properties.
|
||||
|
||||
NOTE: If your composite environment includes a Vault server as in the previous example, you must include a Vault token in every request made to the configuration server. See <<vault-backend,Vault Backend>>.
|
||||
NOTE: If your composite environment includes a Vault server as in the previous example, you must include a Vault token in every request made to the configuration server. See xref:spring-cloud-config/server/environment-repository/vault-backend.adoc[Vault Backend].
|
||||
|
||||
NOTE: Any type of failure when retrieving values from an environment repository results in a failure for the entire composite environment.
|
||||
If you would like the composite to continue even when a repository fails you can set `spring.cloud.config.server.failOnCompositeError` to `false`.
|
||||
|
||||
@@ -3,8 +3,8 @@
|
||||
|
||||
Sharing configuration between all applications varies according to which approach you take, as described in the following topics:
|
||||
|
||||
* <<spring-cloud-config-server-file-based-repositories>>
|
||||
* <<spring-cloud-config-server-vault-server>>
|
||||
* xref:spring-cloud-config/server/environment-repository/sharing-configuration-with-all-applications.adoc#spring-cloud-config-server-file-based-repositories[File Based Repositories]
|
||||
* xref:spring-cloud-config/server/environment-repository/sharing-configuration-with-all-applications.adoc#spring-cloud-config-server-vault-server[Vault Server]
|
||||
|
||||
[[spring-cloud-config-server-file-based-repositories]]
|
||||
== File Based Repositories
|
||||
@@ -12,7 +12,7 @@ Sharing configuration between all applications varies according to which approac
|
||||
With file-based (git, svn, and native) repositories, resources with file names in `application*` (`application.properties`, `application.yml`, `application-*.properties`, and so on) are shared between all client applications.
|
||||
You can use resources with these file names to configure global defaults and have them be overridden by application-specific files as necessary.
|
||||
|
||||
The <<property-overrides,property overrides>> feature can also be used for setting global defaults, with placeholders applications
|
||||
The xref:spring-cloud-config/server/environment-repository/property-overrides.adoc[property overrides] feature can also be used for setting global defaults, with placeholders applications
|
||||
allowed to override them locally.
|
||||
|
||||
TIP: With the "`native`" profile (a local file system backend) , you should use an explicit search location that is not part of the server's own configuration.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
[[using-bootstrap-to-override-properties]]
|
||||
= Using Bootstrap To Override Properties
|
||||
|
||||
If you enable <<config-first-bootstrap, config first bootstrap>>, you can allow client applications to override configuration from the config server by placing two properties within
|
||||
If you enable xref:spring-cloud-config/client.adoc#config-first-bootstrap[config first bootstrap], you can allow client applications to override configuration from the config server by placing two properties within
|
||||
the applications configuration coming from the config server.
|
||||
|
||||
[source,properties]
|
||||
|
||||
@@ -20,6 +20,6 @@ At present, Spring Cloud Config can serve plaintext for git, SVN, native backend
|
||||
The support for git, SVN, and native backends is identical. AWS S3 works a bit differently.
|
||||
The following sections show how each one works:
|
||||
|
||||
* <<spring-cloud-config-serving-plain-text-git-svn-native-backends>>
|
||||
* <<spring-cloud-config-serving-plain-text-aws-s3>>
|
||||
* xref:spring-cloud-config/server/serving-binary-files.adoc#spring-cloud-config-serving-plain-text-git-svn-native-backends[Git, SVN, and Native Backends]
|
||||
* xref:spring-cloud-config/server/serving-binary-files.adoc#spring-cloud-config-serving-plain-text-aws-s3[AWS S3]
|
||||
|
||||
|
||||
Reference in New Issue
Block a user