today,i think about one question that is how to configure mutli zuul.routes to one server without ‘**’ in yml config.
so i try to do.
there is two format in yml config：
1.like object
zuul:
routes:
every name:
path: path
serviceId: server-name
2.key-value
zuul:
routes:
server-name: path
the first is succed ,but the secound is failed.
i try the second format.
Excample:
the /first is covered by /second ，
i find zuul.routes is Map in ZuulProperties,
/**
* Map of route names to properties.
*/
private Map<String, ZuulRoute> routes = new LinkedHashMap<>();
so the cover should be map.put().
zuul:
routes:
eureka-client-demo-01: /first
eureka-client-demo-01: /second
So ,i want to know how to configure mutli zuul.routes to one server without '**' in yml config and use the second format
Related
I'm currently replacing an api gateway using Netflix Zuul with spring cloud gateway. The setup uses discovery client (Eureka) for most of the routes, but we also have a solr instance running which requires manually defined routes (as solr doesn't support eureka)
Using a static route to solr running on localhost works fine using the following config:
routes:
- id: solr
predicates:
- Path=/solr/**
uri: http://localhost:10983
filters:
- RewriteLocationResponseHeader=AS_IN_REQUEST, Location,
However, I would like to use a load-balanced uri for this route as we have multiple solr instances. Looking at the documentation I've found that the way to implement this is to define a Bean returning a ServiceInstanceListSupplier. I've imlemented the following function:
#Bean
ServiceInstanceListSupplier serviceInstanceListSupplier() {
List<String> servers = Arrays.asList(microserviceGatewayConfig.getServers().split(","));
return new SolrServiceInstanceListSupplier("solrhosts", servers);
}
However, this seems to override the ServiceInstances defined from Eureka, meaning only the manual services are used...
Do anyone know if it is possble to combine manually defined serviceinstances with those generated from eureka?
The approach with creating a Bean returning a ServiceInstanceListSupplier doesn't seem to work in any way... However, I've found a way to achieve the same in application.yml, by adding the following config:
spring:
cloud:
discovery:
client:
simple:
instances:
solr-cluster:
- instanceId: cluster1
serviceId: solr-cluster
host: soa03i-t.usrv.ubergenkom.no
port: 10983
- instanceId: cluster2
serviceId: solr-cluster
host: soa04i-t.usrv.ubergenkom.no
port: 10983
This can be combined with autogenerated routes from service discovery (e.g. Eureka)
I am using Vue, Vuetify and my database is in postgreSQL with an API-backend from postgREST (https://postgrest.org/en/stable/). When using the localhost and hash mode everything is fine locally. I can open the component product in a new tab when using this syntax:
const route = this.$router.resolve({ path: `/product/${value.id}` }) (1)
window.open(route.href, '_blank') (2)
However, in the production environment with postgREST-server when opening in a new tab, I get the wrong url :
http:server_name/api/#/product/1 (3)
When I remove /api from the above url (3) and rewrite it like this :
http:server_name/#/product (4)
I get the correct page.
Is it a possible nginx rule that can be written to make sure that
http:server_name/api/#/product/1 is automatically rewritten to the correct url http:server_name/#/product? or How can I change vue-router or vue config file in order to get same behavior in production as in locahost ?
A possible client-side workaround is to strip the /api prefix in production mode:
const url = process.env.NODE_ENV === 'production'
? route.href.replace('/api', '')
: route.href
window.open(url, '_blank')
CF CLI now warns with a deprecation message:
Deprecation warning: Route component attributes 'domain', 'domains', 'host', 'hosts' and 'no-hostname' are deprecated. Found: host.
My manifest.yml looks like that currently:
applications:
- host: myexample-test
which results in a final route like: myexample-test.scapp.io
how to define this exact same route with the new manifest routes config?
These examples are taken from the cloudfoundry docs but I am not sure whether swisscomdev is adopting anything behind the scenes?
routes:
- route: example.com
- route: www.example.com/foo
- route: tcp-example.com:1234
UPDATE
Just tried it with suggested solution and this manifest:
applications:
routes:
- route: myexample-test.scapp.io
name: MyExample
buildpack: nodejs_buildpack
instances: 1
memory: 64M
which resulted in the following error message:
yaml: unmarshal errors:
line 2: cannot unmarshal !!map into []manifest.Application
Swisscom Application cloud does not do something special behind the scenes, so you can apply what's written in the CF CLI docs.
If we're doing something other than vanilla CF, we will mention this in our docs.
I quickly checked it, the following does the trick for your route:
routes:
- route: myexample-test.scapp.io
In your example, note that applications must be an array of maps, so make sure the first element key contains a -, otherwise it's treated as a map.
Full example:
applications:
- name: MyExample
routes:
- route: myexample-test.scapp.io
buildpack: nodejs_buildpack
instances: 1
memory: 64M
I'm using swagger-express for making RESTful API. Base /hello route works fine, but I tried to add some more sophisticated one, with database connection etc. Whenever I tried to send GET request on that route, I would get "Cannot GET /xxx". I triple-checked everything and it looked fine, so I decided to make an exact copy of /hello route called /test, just changed some variables - doesn't work too, same error. Here is my /test route in swagger.yaml
/test:
# binds a127 app logic to a route
x-swagger-route-controller: test-route
get:
description: route for testing
# used as the method name of the controller
operationId: test
responses:
"200":
description: Success
schema:
# a pointer to a definition
$ref: "#/definitions/TestResponse"
# responses may fall trough to errors
default:
description: Error
schema:
$ref: "#/definitions/ErrorResponse"
and here is my test-route.js controller
'use strict';
module.exports = {
test
};
function test(req, res) {
res.json("Test Route");
}
As I said, it's almost exact copy of /hello default route, all other files in swagger project were untouched.
Most of the examples that I see are one route definition to one service.
so this sort of thing:
zuul:
routes:
myserver:
path: /mypath/**
Lets say that I want to route several routes to one service so in effect it would be like this:
zuul:
routes:
myserver:
path: /mypath/**, /anotherpath/**
This isn't allowed in the configuration file and neither are you allowed to have the same route name twice. Is there any real way to do this?
It may be possible with something like this, but I've not tried it
zuul:
routes:
myserver_mypath:
path: /mypath/**
serviceId: myserver
myserver_another_path:
path: /anotherpath/**
serviceId: myserver