Eureka Client Registration under some rules - netflix-eureka

I have a eureka registry server and other 3 microservices. I am able to register any of microservices when I set eureka default zone from eureka.client.serviceUrl.defaultZone property. But I wanted to know if there are other way or some rules which avoids auto register of any microservices to it's registry server?
For the eureka main server I have :
# Configure this Discovery Server
eureka:
instance:
hostname: localhost
client: # Not a client, don't register with yourself
registerWithEureka: false
fetchRegistry: false
server:
enableSelfPreservation: true
server:
port: 1111 # HTTP (Tomcat) port
And in other client(s) i have properties like :
# Spring properties
spring.application.name = #nme#
# Discovery Server Access
eureka.client.serviceUrl.defaultZone= http://localhost:1111/eureka/
eureka.instance.leaseRenewalIntervalInSeconds= 20
#eureka.instance.leaseExpirationDurationInSeconds= 2
Here we have clearly stated serviceUrl in properties.
Thanks

Related

Spring Cloud Consul's gateway server returns Unable to find instance for mall-service-test

Please help.
I am using spring cloud consul 1.5.3 and spring boot 2.1.6. The default host and port that spring cloud consul uses to connect to the consul agent is localhost:8500. It works so far.
However when I change the consul host from 'localhost' to remote ip '192.168.1.89' and restart the gateway service, remote consul shows that Service Check is failed.
The output description is here:
Get http://PCOS-2019NFFBBI:8503/actuator/health:
dial tcp: lookup PCOS-2019NFFBBI on 192.168.1.1:53: no such host
And when I visited URL http://localhost:8010/mall-service-test/ to redirect to my service mall-service-test, shows the error:
org.springframework.cloud.gateway.support.NotFoundException:
Unable to find instance for mall-service-test
I use zuul gateway instead of Spring Cloud Gateway, it returns the same error.
Here is the spring cloud gateway application.yml:
server:
port: 8010
spring:
application:
name: angelcloud-gateway
cloud:
gateway:
discovery:
locator:
enabled: true
routes:
- id: mall-service-test
uri: lb://mall-service-test
predicates:
- Path= /mall-service-test/**
filters:
- StripPrefix= 1
consul:
host: http://192.168.1.89
port: 8500
healthCheckInterval: 15s
The Consul connection values need to go in bootstrap.yml.

spring cloud eureka UnknownHostException

Here is my eureka yml:
eureka:
instance:
hostname: eureka
client:
registerWithEureka: false
fetchRegistry: false
serviceUrl:
defaultZone: http://eureka:8761/eureka/
server:
waitTimeInMsWhenSyncEmpty: 0
And here is my zuul server yml eureka part:
eureka:
client:
serviceUrl:
defaultZone: http://eureka:8761/eureka/
When I registry the zuul server to eureka , it throws
java.net.UnknownHostException: eureka
If I change the zuul server yml to defaultZone: http://localhost:8761/eureka/
it would be deployed successfully,
so how can I use 'eureka' host replace localhost, can somebody help me?
You can try adding "127.0.0.1 eureka" to your hosts file.
If I change the zuul server yml to defaultZone:
http://localhost:8761/eureka/ it would be deployed successfully
Which means you have deployed Eureka server on your local machine. If you want to use eureka as hostname, you can change your hostname to eureka.
Or may be you meant to use ${eureka.hostname}. The documentation says;
${eureka.hostname} is a native placeholder only available in later
versions of Eureka. You could achieve the same thing with Spring
placeholders as well, e.g. using ${eureka.instance.hostName}

Securing Eureka, Zuul in Spring cloud

Can Spring cloud services like Eureka, zuul be secured by other than basic authentication? Instead of configuring like below (basic auth configuration), Is it possible to protect these services with token based mechanism (mostly a static token).
Eureka service configuration
security:
basic:
enabled: true
user:
name: username
password: password
Other services (register to eureka) configuration
eureka:
client:
registerWithEureka: true
fetchRegistry: true
serviceUrl:
defaultZone: http://username:password#localhost:8761/eureka/

Fallback Eureka Server Configuration for Discovery Clients?

Most of the Eureka client configurations I have seen look like this:
eureka:
client:
serviceUrl:
defaultZone: http://localhost:8761/eureka/
Is it possible to configure alternate zones, such that if the default fails the client switches over to the alternate? Also is it possible to use hystrix as a circuit breaker to switch over to an alternate Eureka instance?
ServiceUrl is a map. Each entry is for a different zone (defaultZone is the default zone).
eureka:
client:
serviceUrl:
defaultZone: http://localhost:8761/eureka/
zoneA: http://localhost:8761/eureka/
zoneB: http://localhost:8761/eureka/
For failover, you set a comma separated list as the value, eg.
eureka:
client:
serviceUrl:
defaultZone: http://localhost:8761/eureka/, http://localhost:8762/eureka/
Hystrix is not a load balancer, so that doesn't make sense and isn't supported.

Eureka Server: How to achieve high availability

I'm new to spring cloud. I've read this doc and it says the client application must specify a service url:
eureka:
client:
serviceUrl:
defaultZone: http://localhost:8761/eureka/
But what if localhost:8761 goes down?
Eureka Discovery Server should be used in the Peer-Aware config mode in production setups.
Check:
http://cloud.spring.io/spring-cloud-static/spring-cloud.html#_peer_awareness
For instance your first eureka server instance will have config like this:
server:
port: 1111
eureka:
instance:
hostname: peer1
client:
serviceUrl:
defaultZone: http://peer2:1112/eureka/
..and second server instance like this:
server:
port: 1112
eureka:
instance:
hostname: peer2
client:
serviceUrl:
defaultZone: http://peer1:1111/eureka/
When Eureka server instances will boot up they will look for each other. All microservices will register with them automatically, so if one goes down the other server instance will be always there. On both Eureka instances you will be able to see all the registered microservices. Like this you can scale-up and have multiple server instances in a production environment.
Note: If you are trying this on a single system, dont forget to edit the /etc/hosts file:
127.0.0.1 peer1
127.0.0.1 peer2