I am going to build a route along some specified roads.
For example:
Is it possible to build a route using HERE Routes API along Interstate 80?
Related
I would like to add the assembly version to every AWS Xray trace as an annotation for both asp.net core web apis and lambda projects. I want this to be added globally for every request/invocation. How can this be achieved?
I believe this would be two code parts: 1 for lambda, and another for Web API. I imagine the WebAPI would need to have it contained within somewhere in startup.cs middleware, but what about lambda?
For WebAPI, you'll need to initialize an instance of AWSXRayRecorder in your request path. Then you can use AWSXRayRecorder.Instance.AddAnnotation("key", "value") to add an annotation to the segment of any request that flows through that path. My guess it that you'll need to do this in the controllers rather than the startup.cs since middleware is only registered during application start.
For lambda it's a bit tricky. Since you cannot add annotation/metadata to the auto-created segment, you'll need to manually create a subsegment, fetch the subsegment from the context, and use subsegment.AddAnnotation("key", "value") to add annotation to the subsegment
We use nomad to deploy our applications - which provide gRPC endpoints - as tasks. The tasks are then registered to Consul, using nomad's service stanza.
The routing for our applications is achieved with envoy proxy. We are running central envoy instances loadbalanced at IP 10.1.2.2.
The decision to which endpoint/task to route is currently based on the host header and every task is registered as a service under <$JOB>.our.cloud. This leads to two problems.
When accessing the service, the DNS name must be registered for the loadbalancer IP which leads to /etc/hosts entries like
10.1.2.2 serviceA.our.cloud serviceB.our.cloud serviceC.our.cloud
This problem is partially mitigated by using dnsmasq, but it is still a bit annoying when we add new services
It is not possible to have multiple services running at the same time which provide the same gRPC service. If we e.g. decide to test a new implementation of a service, we need to run it in the same job under the same name and all services which are defined in a gRPC service file need to be implemented.
A possible solution we have been discussing is to use the tags of the service stanza to add tags which define the provided gRPC services, e.g.:
service {
tags = ["grpc-my.company.firstpackage/ServiceA", "grpc-my.company.secondpackage/ServiceB"]
}
But this is discouraged by Consul:
Dots are not supported because Consul internally uses them to delimit service tags.
Now we were thinking about doing it with tags like grpc-my-company-firstpackage__ServiceA, ... This looks really disgusting, though :-(
So my questions are:
Has anyone ever done something like that?
If so, what are recommendations on how to route to gRPC services which are autodiscovered with Consul?
Does anyone have some other ideas or insights into this?
How is this accomplished in e.g. istio?
I think this is a fully supported usecase for Istio. Istio will help you with service discovery w/ Consul and you can use route rules to specify which deployment will provide the service. You can start explore from https://istio.io/docs/tasks/traffic-management/
We do something similar to this, using our own product, Turbine Labs.
We're on a slightly different stack, but the idea is:
Pull service discovery information into our control plane. (We use Kubernetes but support Consul).
Organize this service discovery information by service and by version. We use the tbn_cluster, stage, and version (like here).
Since version for us is the SHA of the release, we don't have formatting issues with it. Also, they don't have to be unique, because the tbn_cluster tag defines the first level of the hierarchy.
Once we have those, we use UI / API to define all the routes (e.g. app.turbinelabs.io/stats -> stats_service). These rules include the tags, so when we deploy a new version (deploy != release), no traffic is routed to it. Releases are done by updating the rules.
(There's even some nice UI affordances for updating those rules for the common case of "release 10% of traffic to the new version," like a slider!)
Hopefully that helps! You might check out LearnEnvoy.io -- lots of tutorials and best practices on what works with Envoy. The articles on Service Discovery Integration and Incremental Blue/Green Releases may be helpful.
We have multiple services running that serve different parts of our public API. These parts implement the same interface and share the same base path.
I am looking for a good way to implement an API Gateway, or reuse an existing software (e.g. reverse proxy) that can route incoming requests to the respective service, depending on an ID inside the request's path parameter.
/v1/things/{ID}
ID_1 -> route request to internalIP1/v1/things/{ID}
ID_2 -> route request to internalIP2/v1/things/{ID}
Whenever a new "thing" is created in our (fictional) registration-service and a new ID_x is generated, then the routing tables should be updated via an API. Afaik, API Gateways like tyk do not support this use case.
Nginx Plus offers a HTTP API where we could update the mapping dynamically for instance making a simple internal request. Nginx Plus costs money, however.
"Regular" Nginx also allows extensions written in lua which could access these advanced mappings from some kind of data storage, which should probably not http-based itself (speed and overhead), but maybe in-memory like a redis-based shared storage could another alternative.
This related question is four years old by now.
Can I get a list of target endpoints in a javascript policy?
Let's say I have a proxy endpoint that connects to multiple target endpoints. Can I write a javascript policy so that if a request is made to a specific url on that proxy, it will make a call to all the target endpoints and aggregate the results?
Yes that's possible. The apiproxy definition itself holds all the target endpoints defined for it.
For example:
curl -v https://api.enterprise.apigee.com/v1/o/{org}/apis/{api}/revisions/{rev}/targets
would give you the list of all targets.
Then you can get each target URL from the list by calling:
curl -v https://api.enterprise.apigee.com/v1/o/{org}/apis/{api}/revisions/{rev}/targets/{target}
You can parse out each URL in a for loop and then make a request to each of these URLs. If your requests a simple GET calls without any variation in the request object like headers, body etc. then a simple for loop would be good enough.
For example:
var geocoding = httpClient.get(URL);
context.session["geocoding"] = geocoding;
This piece of code can be called in a loop for all the target endpoints that you might have.
The only catch here is that, to get the target endpoints you are making a management api call from the runtime layer. Which means if at any point of time the Apigee management layer is down for maintenance or experiencing degraded service due to scheduled maintenance, your runtime calls would tend to fail. The other solution could be to isolate the two scripts:
Get the list of endpoints in one javascript and maybe store the URLs in cache (populateCache policy) or keyvaluemaps (given that proxy endpoint URLs won't change too often)
Read the list of endpoints from cache or kvm and then trigger another javascript that can make calls to these endpoints and then aggregate the response.
There is not a way to call a target endpoint from JavaScript. In fact, you can only call 0 or 1 target endpoints for a single call to the proxy, not multiple target endpoints.
You can call make multiple HTTP requests from within JavaScript using httpClient, and aggregate the results, but not target endpoints. An example of this is found here.
Using Symfony2, I'm looking for a way to easily access the main route prefix for a given request, outside any controller:
I am trying to figure out the best way to deal with access control related to some database elements in Symfony2.
I would like to restrict the access to some 'applications' located in the path /application/APP_ID according to the Subscription stored in the database.
Every restricted resource will be in this path.
The subscriptions are referencing a User entity and an Application entity. It includes an ending date. After this ending date, the application should not be accessible anymore.
The restriction should be : for every resource starting with /application/APP_ID, I need to check if the controller should be accessed.
This prefix is static and is actually defined in the app/config/routing.yml as a 'prefix' and the corresponding route name is stored in one of the Application entity attributes. The other involved routes are defined in an independent routing.yml file located for example in MyAppBundle/Resources/config/routing.yml and imported in the main routing file.
Can I easily know if the current route requested (ex. /application/APP_ID/action/1) is included in the route defining the prefix (ex. /application/APP_ID) in order to know what Application is concerned?
Or, is there a way to do that without having to give a list of routes or paths which necessarily require modifications for every application added, route added or modified?
Did you try to develop your own Voter ? As explained here : http://symfony.com/doc/current/cookbook/security/voters.html.
Instead of testing $request->getClientIp, you could test $request->getRequestUri. And you could have an access to doctrine, using $this->container->get('doctrine'). I think you could have all informations you need to secure your paths.
I did it few days ago to store my own RoleHierachy in database, it works well.