Sync docs from 1.4.x to gh-pages

1.4.x/multi/multi__service_discovery_eureka_clients.html

@@ -99,12 +99,12 @@ traffic to application in state other then 'UP'.</p><p><b>application.yml.&nbsp;
     healthcheck:
       enabled: true</pre><p>
 </p><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Warning"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Warning]" src="images/warning.png"></td><th align="left">Warning</th></tr><tr><td align="left" valign="top"><p><code class="literal">eureka.client.healthcheck.enabled=true</code> should only be set in <code class="literal">application.yml</code>. Setting the value in <code class="literal">bootstrap.yml</code> will cause undesirable side effects like registering in eureka with an <code class="literal">UNKNOWN</code> status.</p></td></tr></table></div><p>If you require more control over the health checks, you may consider
-implementing your own <code class="literal">com.netflix.appinfo.HealthCheckHandler</code>.</p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="_eureka_metadata_for_instances_and_clients" href="#_eureka_metadata_for_instances_and_clients"></a>1.7&nbsp;Eureka Metadata for Instances and Clients</h2></div></div></div><p>It&#8217;s worth spending a bit of time understanding how the Eureka metadata works, so you can use it in a way that makes sense in your platform. There is standard metadata for things like hostname, IP address, port numbers, status page and health check. These are published in the service registry and used by clients to contact the services in a straightforward way. Additional metadata can be added to the instance registration in the <code class="literal">eureka.instance.metadataMap</code>, and this will be accessible in the remote clients, but in general will not change the behaviour of the client, unless it is made aware of the meaning of the metadata. There are a couple of special cases described below where Spring Cloud already assigns meaning to the metadata map.</p><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="_using_eureka_on_cloudfoundry" href="#_using_eureka_on_cloudfoundry"></a>1.7.1&nbsp;Using Eureka on Cloudfoundry</h3></div></div></div><p>Cloudfoundry has a global router so that all instances of the same app have the same hostname (it&#8217;s the same in other PaaS solutions with a similar architecture). This isn&#8217;t necessarily a barrier to using Eureka, but if you use the router (recommended, or even mandatory depending on the way your platform was set up), you need to explicitly set the hostname and port numbers (secure or non-secure) so that they use the router. You might also want to use instance metadata so you can distinguish between the instances on the client (e.g. in a custom load balancer). By default, the <code class="literal">eureka.instance.instanceId</code> is <code class="literal">vcap.application.instance_id</code>. For example:</p><p><b>application.yml.&nbsp;</b>
+implementing your own <code class="literal">com.netflix.appinfo.HealthCheckHandler</code>.</p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="_eureka_metadata_for_instances_and_clients" href="#_eureka_metadata_for_instances_and_clients"></a>1.7&nbsp;Eureka Metadata for Instances and Clients</h2></div></div></div><p>It&#8217;s worth spending a bit of time understanding how the Eureka metadata works, so you can use it in a way that makes sense in your platform. There is standard metadata for things like hostname, IP address, port numbers, status page and health check. These are published in the service registry and used by clients to contact the services in a straightforward way. Additional metadata can be added to the instance registration in the <code class="literal">eureka.instance.metadataMap</code>, and this will be accessible in the remote clients, but in general will not change the behaviour of the client, unless it is made aware of the meaning of the metadata. There are a couple of special cases described below where Spring Cloud already assigns meaning to the metadata map.</p><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="_using_eureka_on_cloud_foundry" href="#_using_eureka_on_cloud_foundry"></a>1.7.1&nbsp;Using Eureka on Cloud Foundry</h3></div></div></div><p>Cloud Foundry has a global router so that all instances of the same app have the same hostname (it&#8217;s the same in other PaaS solutions with a similar architecture). This isn&#8217;t necessarily a barrier to using Eureka, but if you use the router (recommended, or even mandatory depending on the way your platform was set up), you need to explicitly set the hostname and port numbers (secure or non-secure) so that they use the router. You might also want to use instance metadata so you can distinguish between the instances on the client (e.g. in a custom load balancer). By default, the <code class="literal">eureka.instance.instanceId</code> is <code class="literal">vcap.application.instance_id</code>. For example:</p><p><b>application.yml.&nbsp;</b>
 </p><pre class="screen">eureka:
   instance:
     hostname: ${vcap.application.uris[0]}
     nonSecurePort: 80</pre><p>
-</p><p>Depending on the way the security rules are set up in your Cloudfoundry instance, you might be able to register and use the IP address of the host VM for direct service-to-service calls. This feature is not (yet) available on Pivotal Web Services (<a class="link" href="https://run.pivotal.io" target="_top">PWS</a>).</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="_using_eureka_on_aws" href="#_using_eureka_on_aws"></a>1.7.2&nbsp;Using Eureka on AWS</h3></div></div></div><p>If the application is planned to be deployed to an AWS cloud, then the Eureka instance will have to be configured to be AWS aware and this can be done by customizing the <a class="link" href="http://github.com/spring-cloud/spring-cloud-netflix/tree/master/spring-cloud-netflix-eureka-client/src/main/java/org/springframework/cloud/netflix/eureka/EurekaInstanceConfigBean.java" target="_top">EurekaInstanceConfigBean</a> the following way:</p><pre class="programlisting"><em><span class="hl-annotation" style="color: gray">@Bean</span></em>
+</p><p>Depending on the way the security rules are set up in your Cloud Foundry instance, you might be able to register and use the IP address of the host VM for direct service-to-service calls. This feature is not (yet) available on Pivotal Web Services (<a class="link" href="https://run.pivotal.io" target="_top">PWS</a>).</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="_using_eureka_on_aws" href="#_using_eureka_on_aws"></a>1.7.2&nbsp;Using Eureka on AWS</h3></div></div></div><p>If the application is planned to be deployed to an AWS cloud, then the Eureka instance will have to be configured to be AWS aware and this can be done by customizing the <a class="link" href="http://github.com/spring-cloud/spring-cloud-netflix/tree/master/spring-cloud-netflix-eureka-client/src/main/java/org/springframework/cloud/netflix/eureka/EurekaInstanceConfigBean.java" target="_top">EurekaInstanceConfigBean</a> the following way:</p><pre class="programlisting"><em><span class="hl-annotation" style="color: gray">@Bean</span></em>
 <em><span class="hl-annotation" style="color: gray">@Profile("!default")</span></em>
 <span xmlns:d="http://docbook.org/ns/docbook" class="hl-keyword">public</span> EurekaInstanceConfigBean eurekaInstanceConfig(InetUtils inetUtils) {
   EurekaInstanceConfigBean b = <span xmlns:d="http://docbook.org/ns/docbook" class="hl-keyword">new</span> EurekaInstanceConfigBean(inetUtils);
@@ -117,7 +117,7 @@ implementing your own <code class="literal">com.netflix.appinfo.HealthCheckHandl
     instanceId: ${spring.application.name}:${vcap.application.instance_id:${spring.application.instance_id:${random.value}}}</pre><p>
 </p><p>With this metadata, and multiple service instances deployed on
 localhost, the random value will kick in there to make the instance
-unique. In Cloudfoundry the <code class="literal">vcap.application.instance_id</code> will be
+unique. In Cloud Foundry the <code class="literal">vcap.application.instance_id</code> will be
 populated automatically in a Spring Boot application, so the
 random value will not be needed.</p></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="_using_the_eurekaclient" href="#_using_the_eurekaclient"></a>1.8&nbsp;Using the EurekaClient</h2></div></div></div><p>Once you have an app that is a discovery client you can use it to
 discover service instances from the <a class="link" href="multi_spring-cloud-eureka-server.html" title="2.&nbsp;Service Discovery: Eureka Server">Eureka Server</a>. One way to do that is to use the native

1.4.x/spring-cloud-netflix.xml

@@ -4,7 +4,7 @@
 <book xmlns="http://docbook.org/ns/docbook" xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
 <info>
 <title>Spring Cloud Netflix</title>
-<date>2018-04-13</date>
+<date>2018-04-23</date>
 </info>
 <preface>
 <title></title>
@@ -182,9 +182,9 @@ implementing your own <literal>com.netflix.appinfo.HealthCheckHandler</literal>.
 <section xml:id="_eureka_metadata_for_instances_and_clients">
 <title>Eureka Metadata for Instances and Clients</title>
 <simpara>It&#8217;s worth spending a bit of time understanding how the Eureka metadata works, so you can use it in a way that makes sense in your platform. There is standard metadata for things like hostname, IP address, port numbers, status page and health check. These are published in the service registry and used by clients to contact the services in a straightforward way. Additional metadata can be added to the instance registration in the <literal>eureka.instance.metadataMap</literal>, and this will be accessible in the remote clients, but in general will not change the behaviour of the client, unless it is made aware of the meaning of the metadata. There are a couple of special cases described below where Spring Cloud already assigns meaning to the metadata map.</simpara>
-<section xml:id="_using_eureka_on_cloudfoundry">
-<title>Using Eureka on Cloudfoundry</title>
-<simpara>Cloudfoundry has a global router so that all instances of the same app have the same hostname (it&#8217;s the same in other PaaS solutions with a similar architecture). This isn&#8217;t necessarily a barrier to using Eureka, but if you use the router (recommended, or even mandatory depending on the way your platform was set up), you need to explicitly set the hostname and port numbers (secure or non-secure) so that they use the router. You might also want to use instance metadata so you can distinguish between the instances on the client (e.g. in a custom load balancer). By default, the <literal>eureka.instance.instanceId</literal> is <literal>vcap.application.instance_id</literal>. For example:</simpara>
+<section xml:id="_using_eureka_on_cloud_foundry">
+<title>Using Eureka on Cloud Foundry</title>
+<simpara>Cloud Foundry has a global router so that all instances of the same app have the same hostname (it&#8217;s the same in other PaaS solutions with a similar architecture). This isn&#8217;t necessarily a barrier to using Eureka, but if you use the router (recommended, or even mandatory depending on the way your platform was set up), you need to explicitly set the hostname and port numbers (secure or non-secure) so that they use the router. You might also want to use instance metadata so you can distinguish between the instances on the client (e.g. in a custom load balancer). By default, the <literal>eureka.instance.instanceId</literal> is <literal>vcap.application.instance_id</literal>. For example:</simpara>
 <formalpara>
 <title>application.yml</title>
 <para>
@@ -194,7 +194,7 @@ implementing your own <literal>com.netflix.appinfo.HealthCheckHandler</literal>.
     nonSecurePort: 80</screen>
 </para>
 </formalpara>
-<simpara>Depending on the way the security rules are set up in your Cloudfoundry instance, you might be able to register and use the IP address of the host VM for direct service-to-service calls. This feature is not (yet) available on Pivotal Web Services (<link xl:href="https://run.pivotal.io">PWS</link>).</simpara>
+<simpara>Depending on the way the security rules are set up in your Cloud Foundry instance, you might be able to register and use the IP address of the host VM for direct service-to-service calls. This feature is not (yet) available on Pivotal Web Services (<link xl:href="https://run.pivotal.io">PWS</link>).</simpara>
 </section>
 <section xml:id="_using_eureka_on_aws">
 <title>Using Eureka on AWS</title>
@@ -222,7 +222,7 @@ public EurekaInstanceConfigBean eurekaInstanceConfig(InetUtils inetUtils) {
 </formalpara>
 <simpara>With this metadata, and multiple service instances deployed on
 localhost, the random value will kick in there to make the instance
-unique. In Cloudfoundry the <literal>vcap.application.instance_id</literal> will be
+unique. In Cloud Foundry the <literal>vcap.application.instance_id</literal> will be
 populated automatically in a Spring Boot application, so the
 random value will not be needed.</simpara>
 </section>