We are looking to of move to Spring Cloud Load Balancer to replace Ribbon. We use Eureka for service discovery and registration.
It looks like as of Spring Cloud Netflix 3.x, the EurekaRibbonClientConfiguration in the Eureka client module has been removed.
We were using the deploymentContextBasedVipAddress configuration to map our internal host name to a registered vip address in Eureka.
The configuration was similar to this:
some-sevice-v1.ribbon.NIWSServerListClassName=com.netflix.niws.loadbalancer.DiscoveryEnabledNIWSServerList
some-sevice-v1.ribbon.DeploymentContextBasedVipAddresses=some_service-v1
some-sevice-v1.ribbon.NIWSServerListFilterClassName=com.netflix.loadbalancer.ServerListSubsetFilter
We do this because the vip address that is registered with Eureka contains an _ in it and which is technically an invalid character for host names; the Java URI class will fail to parse a host with a _ in it. We are not able to change this at this point.
So my question is; can this similar configuration be done with Spring Cloud Load Balancer and the new Eureka client module in Spring Cloud Netflix 3.x, where we can provide aliasing for the vip address?
We have faced the same issue. Currently, we are using the following workaround for our feign clients:
#FeignClient(
value = "${my.amazing.service.name:amazing-service-name-default}",
contextId = "amazing-service",
configuration = AmazingServiceClientConfiguration.class,
path = "/amazing-service"
)
public interface AmazingServiceClient {
...
}
We can configure my.amazing.service.name the same way as DeploymentContextBasedVipAddresses.
There is also an open ticket for this issue: https://github.com/spring-cloud/spring-cloud-commons/issues/951
Hope, this helps.
Related
I have a Spring Boot (2.4) app (a generic service) and a Eureka discovery server running. The server doesn't register itself as an instance. I am able to navigate to the Eureka dashboard at the default location of localhost:8761 to get an overview of all the registered instances. I successfully see the service is registered in Eureka. However, this dashboard doesn't give any details about the instance except the name and the port number. I want to be able to see the instance meta data. Is this possible using the dashboard? O maybe there is some exposed URL by the Eureka server that I can call in a browser or postman? Or is there an URL available in the Eureka client (the service) that gives details about its Eureka metadata?
I read thet feign clients access something to be able to query the registry. Can I mimic this as human in a browser?
Go to localhost:8761/eureka/apps
I created in SAP Logon OData Service and Registed it.
I cheked it and it works good. Now, I want to create cloud connector using the link which I got when tested my Odata Service. It looks like:
http://mylink.com:1234/sap/opu/odata/sap/***_SRV/.
In cloud connector setting I put:
Internal host:mylink.com
Internal port:1234.
But, everytime when I try to check my connection in Cloud Connector it show to me Not Reachable.
Can anybody advice to me something about that and explain to me the reasons of it?
Thanks a lot.
Cloud connector requires two different addresses:
Internal Host and port: this should be the real network address of your on premise system. Typically the SAP Netweaver Gateway where the service URL is in. The address must be reachable from the Cloud Connector server
Virtual Host and port: this should be a non real (virtual) address. It’s a must that this address match the URL address of a destination configured in SAP Cloud Platform.
Moreover, apart from the on premise configuration you must enable which URL paths are allowed to be accessed from the cloud
Check whether your cloud connector and SAP LogOn OData service are in the same network. Then only the SAP cloud connector can reach your on-premise system through a secure channel.
we have a eureka server deployed on server and developers for development purpose register their microservices with it. but when some developers that work on same microservice, register own microservice's instance on eureka [sure with their local ip address] get wrong instance. developer can't change instance name because other services call their service with service name. what's best pattern for our problem?
Another approach to make the developers register their microservices as OUT_OF_SERVICE so then the services will not be called by the rest of services registered in Eureka but they can interact with the rest of services registered.
You can set it as out fo service by adding this to the application.yml:
eureka:
instance:
initialStatus: OUT_OF_SERVICE
Im working with Spring Cloud Zuul + Eureka Server. i know that Zuul will create routes dynamically when there is a service registered on Eureka and it will be route using their Service ID. Is it possible to delegate routes to group services ?
for example i have 2 services that i want to group:
server.port=8081
spring.application.name=company-account-api
server.port=8082
spring.application.name=company-transaction-api
eureka config
spring.application.name=api-discovery
spring.cloud.config.uri=${CONFIG_SERVER_URL:http://localhost:8888}
on Zuul is it possible define a route where i can access the 2 services registered on eureka ?
server.port=9090
spring.application.name=api-gateway
eureka.instance.preferIpAddress=true
eureka.client.registerWithEureka=true
eureka.client.fetchRegistry=true
eureka.serviceurl.defaultzone=http://localhost:8761/eureka
zuul.routes.company-api=/company-**
so when i access http://localhost:9090/company-api/company-account-api & http://localhost:9090/company-api/company-transaction-api the service registered on eureka will be available
You can achieve this with the following config
zuul.ignored-services=*
zuul.routes.company-account-api.serviceId=company-account-api
zuul.routes.company-account-api.path=/company-api/company-account-api/**
zuul.routes.company-transaction-api.serviceId=company-transaction-api
zuul.routes.company-transaction-api.path=/company-api/company-transaction-api/**
Explanation:
zuul.ignored-services=* This will supress the default config
zuul.routes.company-account-api.serviceId=company-account-api
zuul.routes.company-account-api.path=/company-api/company-account-api/**
What is exposed to public is /company-api/company-account-api/** which will be internally mapped to company-account-api service.
If you are not using service discovery then you can do it using url instead of service name
zuul.routes.company-account-api.url=http://accountapihost:accountapiport
zuul.routes.company-account-api.path=/company-api/company-account-api/**
I'm currently deploying on cloud foundry, Now I have a frontend server and a backend server.
Both deployed as micro services with the Cloud Foundry nodejs build pack.
I would like to hide the backend server from the outside world, that only my frontend server can access it. How do I do that?
If I remove the route to the backend server the server is hidden from the outside but then I do not know how to access it from my frontend.
I'm new to Cloud Foundry maybe there is an easy way.
Thanks
Andreas
Thanks for the information so far.
I do however not understand how I could now hide my backend instance from being accessed from the outside, but allow for access of the frontrontend?
Basically what roule would I need to set in my space in order to allow only port 80 to be accessed of my frontend instance (lets say the frontend ip is 168.192.0.5).
could you make an example?
If you are using OSS Cloud Foundry, you can put the backend services into their own space, and then set the security group rules for that space so that they will not respond to outside IP addresses:
https://docs.pivotal.io/pivotalcf/adminguide/app-sec-groups.html
If you are using Pivotal Cloud Foundry, you can use Spring Cloud Service Discovery, as Amit said.
What about using "cf push myjavaapp --no-route"?
The no-route option tell Bluemix that your backend is not a web application.
Another solution to hide the back-end microservice from the public is to use containers (also available on Bluemix, based on Docker, see https://www.ng.bluemix.net/docs/containers/container_gettingstarted.html). Containers have a private IP by default and can access other containers in the same space. You can assign the front-end microservice a public IP using e.g. following command
cf ic ip bind {public_ip} {container_name}
but don't assign a public address to your back-end microservices.
(A few weeks ago I've created a simple example for a microservice in a container, you can find the code at
https://hub.jazz.net/project/matthiashub/bluemix-unistuttgart-container/overview I admit that this was done in Java and not in nodejs but I think you get the idea.)