Sync docs from master to gh-pages
This commit is contained in:
buildmaster
@@ -2,7 +2,7 @@
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
|
||||
<title>7. Spring Cloud Config Client</title><link rel="stylesheet" type="text/css" href="css/manual-multipage.css"><meta name="generator" content="DocBook XSL Stylesheets V1.79.1"><link rel="home" href="multi_spring-cloud-config.html" title="Spring Cloud Config"><link rel="up" href="multi_spring-cloud-config.html" title="Spring Cloud Config"><link rel="prev" href="multi__push_notifications_and_spring_cloud_bus.html" title="6. Push Notifications and Spring Cloud Bus"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">7. Spring Cloud Config Client</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="multi__push_notifications_and_spring_cloud_bus.html">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> </td></tr></table><hr></div><div class="chapter"><div class="titlepage"><div><div><h1 class="title"><a name="_spring_cloud_config_client" href="#_spring_cloud_config_client"></a>7. Spring Cloud Config Client</h1></div></div></div><p>A Spring Boot application can take immediate advantage of the Spring Config Server (or other external property sources provided by the application developer).
|
||||
It also picks up some additional useful features related to <code class="literal">Environment</code> change events.</p><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="config-first-bootstrap" href="#config-first-bootstrap"></a>7.1 Config First Bootstrap</h2></div></div></div><p>The default behavior for any application that has the Spring Cloud Config Client on the classpath is as follows:
|
||||
When a config client starts, it binds to the Config Server (through the <code class="literal">spring.cloud.config.uri</code> bootstrap configuration property) and initializes Spring <code class="literal">Environment</code> with remote property sources.</p><p>The net result of this behavior is that all client applications that want to consume the Config Server need a <code class="literal">bootstrap.yml</code> (or an environment variable) with the server address set in <code class="literal">spring.cloud.config.uri</code> (it defaults to "http://localhost:8888").</p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="discovery-first-bootstrap" href="#discovery-first-bootstrap"></a>7.2 Discovery First Bootstrap</h2></div></div></div><p>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.
|
||||
When a config client starts, it binds to the Config Server (through the <code class="literal">spring.cloud.config.uri</code> bootstrap configuration property) and initializes Spring <code class="literal">Environment</code> with remote property sources.</p><p>The net result of this behavior is that all client applications that want to consume the Config Server need a <code class="literal">bootstrap.yml</code> (or an environment variable) with the server address set in <code class="literal">spring.cloud.config.uri</code> (it defaults to "http://localhost:8888").</p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="discovery-first-bootstrap" href="#discovery-first-bootstrap"></a>7.2 Discovery First Bootstrap</h2></div></div></div><p>If you use a <code class="literal">DiscoveryClient</code> 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.
|
||||
However, in the default <span class="quote">“<span class="quote">Config First</span>”</span> mode, clients cannot take advantage of the registration.</p><p>If you prefer to use <code class="literal">DiscoveryClient</code> to locate the Config Server, you can do so by setting <code class="literal">spring.cloud.config.discovery.enabled=true</code> (the default is <code class="literal">false</code>).
|
||||
The net result of doing so is that client applications all need a <code class="literal">bootstrap.yml</code> (or an environment variable) with the appropriate discovery configuration.
|
||||
For example, with Spring Cloud Netflix, you need to define the Eureka server address (for example, in <code class="literal">eureka.client.serviceUrl.defaultZone</code>).
|
||||
@@ -10,7 +10,7 @@ The price for using this option is an extra network round trip on startup, to lo
|
||||
The benefit is that, as long as the Discovery Service is a fixed point, the Config Server can change its coordinates.
|
||||
The default service ID is <code class="literal">configserver</code>, but you can change that on the client by setting <code class="literal">spring.cloud.config.discovery.serviceId</code> (and on the server, in the usual way for a service, such as by setting <code class="literal">spring.application.name</code>).</p><p>The discovery client implementations all support some kind of metadata map (for example, we have <code class="literal">eureka.instance.metadataMap</code> for Eureka).
|
||||
Some additional properties of the Config Server may need to be configured in its service registration metadata so that clients can connect correctly.
|
||||
If the Config Server is secured with HTTP Basic, you can configure the credentials as <code class="literal">username</code> and <code class="literal">password</code>.
|
||||
If the Config Server is secured with HTTP Basic, you can configure the credentials as <code class="literal">user</code> and <code class="literal">password</code>.
|
||||
Also, if the Config Server has a context path, you can set <code class="literal">configPath</code>.
|
||||
For example, the following YAML file is for a Config Server that is a Eureka client:</p><p><b>bootstrap.yml. </b>
|
||||
</p><pre class="programlisting"><span xmlns:d="http://docbook.org/ns/docbook" class="hl-attribute">eureka</span>:
|
||||
|
||||
@@ -580,7 +580,7 @@ The strategy to use when you want to override the behavior is <code class="liter
|
||||
In addition to the JSON notifications from Github, Gitlab, Gitee, or Bitbucket, you can trigger a change notification by POSTing to <code class="literal">/monitor</code> with form-encoded body parameters in the pattern of <code class="literal">path={name}</code>.
|
||||
Doing so broadcasts to applications matching the <code class="literal">{name}</code> pattern (which can contain wildcards).</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Note"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Note]" src="images/note.png"></td><th align="left">Note</th></tr><tr><td align="left" valign="top"><p>The <code class="literal">RefreshRemoteApplicationEvent</code> is transmitted only if the <code class="literal">spring-cloud-bus</code> is activated in both the Config Server and in the client application.</p></td></tr></table></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Note"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Note]" src="images/note.png"></td><th align="left">Note</th></tr><tr><td align="left" valign="top"><p>The default configuration also detects filesystem changes in local git repositories. In that case, the webhook is not used. However, as soon as you edit a config file, a refresh is broadcast.</p></td></tr></table></div></div><div class="chapter"><div class="titlepage"><div><div><h1 class="title"><a name="_spring_cloud_config_client" href="#_spring_cloud_config_client"></a>7. Spring Cloud Config Client</h1></div></div></div><p>A Spring Boot application can take immediate advantage of the Spring Config Server (or other external property sources provided by the application developer).
|
||||
It also picks up some additional useful features related to <code class="literal">Environment</code> change events.</p><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="config-first-bootstrap" href="#config-first-bootstrap"></a>7.1 Config First Bootstrap</h2></div></div></div><p>The default behavior for any application that has the Spring Cloud Config Client on the classpath is as follows:
|
||||
When a config client starts, it binds to the Config Server (through the <code class="literal">spring.cloud.config.uri</code> bootstrap configuration property) and initializes Spring <code class="literal">Environment</code> with remote property sources.</p><p>The net result of this behavior is that all client applications that want to consume the Config Server need a <code class="literal">bootstrap.yml</code> (or an environment variable) with the server address set in <code class="literal">spring.cloud.config.uri</code> (it defaults to "http://localhost:8888").</p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="discovery-first-bootstrap" href="#discovery-first-bootstrap"></a>7.2 Discovery First Bootstrap</h2></div></div></div><p>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.
|
||||
When a config client starts, it binds to the Config Server (through the <code class="literal">spring.cloud.config.uri</code> bootstrap configuration property) and initializes Spring <code class="literal">Environment</code> with remote property sources.</p><p>The net result of this behavior is that all client applications that want to consume the Config Server need a <code class="literal">bootstrap.yml</code> (or an environment variable) with the server address set in <code class="literal">spring.cloud.config.uri</code> (it defaults to "http://localhost:8888").</p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="discovery-first-bootstrap" href="#discovery-first-bootstrap"></a>7.2 Discovery First Bootstrap</h2></div></div></div><p>If you use a <code class="literal">DiscoveryClient</code> 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.
|
||||
However, in the default <span class="quote">“<span class="quote">Config First</span>”</span> mode, clients cannot take advantage of the registration.</p><p>If you prefer to use <code class="literal">DiscoveryClient</code> to locate the Config Server, you can do so by setting <code class="literal">spring.cloud.config.discovery.enabled=true</code> (the default is <code class="literal">false</code>).
|
||||
The net result of doing so is that client applications all need a <code class="literal">bootstrap.yml</code> (or an environment variable) with the appropriate discovery configuration.
|
||||
For example, with Spring Cloud Netflix, you need to define the Eureka server address (for example, in <code class="literal">eureka.client.serviceUrl.defaultZone</code>).
|
||||
@@ -588,7 +588,7 @@ The price for using this option is an extra network round trip on startup, to lo
|
||||
The benefit is that, as long as the Discovery Service is a fixed point, the Config Server can change its coordinates.
|
||||
The default service ID is <code class="literal">configserver</code>, but you can change that on the client by setting <code class="literal">spring.cloud.config.discovery.serviceId</code> (and on the server, in the usual way for a service, such as by setting <code class="literal">spring.application.name</code>).</p><p>The discovery client implementations all support some kind of metadata map (for example, we have <code class="literal">eureka.instance.metadataMap</code> for Eureka).
|
||||
Some additional properties of the Config Server may need to be configured in its service registration metadata so that clients can connect correctly.
|
||||
If the Config Server is secured with HTTP Basic, you can configure the credentials as <code class="literal">username</code> and <code class="literal">password</code>.
|
||||
If the Config Server is secured with HTTP Basic, you can configure the credentials as <code class="literal">user</code> and <code class="literal">password</code>.
|
||||
Also, if the Config Server has a context path, you can set <code class="literal">configPath</code>.
|
||||
For example, the following YAML file is for a Config Server that is a Eureka client:</p><p><b>bootstrap.yml. </b>
|
||||
</p><pre class="programlisting"><span xmlns:d="http://docbook.org/ns/docbook" class="hl-attribute">eureka</span>:
|
||||
|
||||
@@ -1205,7 +1205,7 @@ When a config client starts, it binds to the Config Server (through the <literal
|
||||
</section>
|
||||
<section xml:id="discovery-first-bootstrap">
|
||||
<title>Discovery First Bootstrap</title>
|
||||
<simpara>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.
|
||||
<simpara>If you use a <literal>DiscoveryClient</literal> 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.
|
||||
However, in the default <quote>Config First</quote> mode, clients cannot take advantage of the registration.</simpara>
|
||||
<simpara>If you prefer to use <literal>DiscoveryClient</literal> to locate the Config Server, you can do so by setting <literal>spring.cloud.config.discovery.enabled=true</literal> (the default is <literal>false</literal>).
|
||||
The net result of doing so is that client applications all need a <literal>bootstrap.yml</literal> (or an environment variable) with the appropriate discovery configuration.
|
||||
@@ -1215,7 +1215,7 @@ The benefit is that, as long as the Discovery Service is a fixed point, the Conf
|
||||
The default service ID is <literal>configserver</literal>, but you can change that on the client by setting <literal>spring.cloud.config.discovery.serviceId</literal> (and on the server, in the usual way for a service, such as by setting <literal>spring.application.name</literal>).</simpara>
|
||||
<simpara>The discovery client implementations all support some kind of metadata map (for example, we have <literal>eureka.instance.metadataMap</literal> for Eureka).
|
||||
Some additional properties of the Config Server may need to be configured in its service registration metadata so that clients can connect correctly.
|
||||
If the Config Server is secured with HTTP Basic, you can configure the credentials as <literal>username</literal> and <literal>password</literal>.
|
||||
If the Config Server is secured with HTTP Basic, you can configure the credentials as <literal>user</literal> and <literal>password</literal>.
|
||||
Also, if the Config Server has a context path, you can set <literal>configPath</literal>.
|
||||
For example, the following YAML file is for a Config Server that is a Eureka client:</simpara>
|
||||
<formalpara>
|
||||
|
||||
Reference in New Issue
Block a user