SpringCloud/spring-cloud-config
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Sync docs from master to gh-pages

Browse Source
This commit is contained in:
buildmaster
2018-05-29 15:28:35 +00:00
parent 6d6377e2aa
commit a8e42a9fd5
4 changed files with 17 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
spring-cloud-config.xml
View File

@@ -1123,6 +1123,11 @@ In that case, the items in the list are tried one by one until one succeeds.
This behavior can be useful when working on a feature branch.
For instance, you might want to align the config label with your branch but make it optional (in that case, use <literal>spring.cloud.config.label=myfeature,develop</literal>).</simpara>
</section>
<section xml:id="_specifying_multiple_urls_for_the_config_server">
<title>Specifying Multiple Urls for the Config Server</title>
<simpara>To ensure high availability when you have multiple instances of Config Server deployed and expect one or more instances to be unavailable from time to time, you can either specify multiple URLs (as a comma-separated list under the <literal>spring.cloud.config.uri</literal> property) or have all your instances register in a Service Registry like Eureka ( if using Discovery-First Bootstrap mode ). Note that doing so ensures high availability only when the Config Server is not running (that is, when the application has exited) or when a connection timeout has occurred. For example, if the Config Server returns a 500 (Internal Server Error) response or the Config Client receives a 401 from the Config Server (due to bad credentials or other causes), the Config Client does not try to fetch properties from other URLs. An error of that kind indicates a user issue rather than an availability problem.</simpara>
<simpara>If you use HTTP basic security on your Config Server, it is currently possible to support per-Config Server auth credentials only if you embed the credentials in each URL you specify under the <literal>spring.cloud.config.uri</literal> property. If you use any other kind of security mechanism, you cannot (currently) support per-Config Server authentication and authorization.</simpara>
</section>
<section xml:id="_security_2">
<title>Security</title>
<simpara>If you use HTTP Basic security on the server, clients need to know the password (and username if it is not the default).