As 'host' is deprecated for manifest.yml - how to configure a standard scapp.io route? - swisscomdev

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

Related

Google API Gateway OpenApi Swaagger 2.0 to CloudRun Parameter configured for Path turns out in query instead of path

I'm testing an API Gateway setup on Google Cloud to access specific endpoints on a service deployed on Cloud Run. I'm following the steps shown here. We need to authenticate using an API Key, so the API Key specific configuration that went into the API Gateway config was picked from this documentation.
The API Gateway config is as shown below:
# api_gateway_config.yaml
swagger: '2.0'
info:
title: myappapi
description: API with Cloudrun Backend
version: 1.0.0
schemes:
- https
produces:
- application/json
paths:
/:
get:
summary: Greet a User from service
operationId: hello
x-google-backend:
address: https://myappapi-asldfjoiewjfv-uc.a.run.app/
security:
- api_key: []
responses:
'200':
description: A successful response
schema:
type: string
/reports/results/{id}:
get:
summary: Get Report Results for specified report id
operationId: GetReportResults
x-google-backend:
address: https://myappapi-asldfjoiewjfv-uc.a.run.app/v1/reports/results/{id}
parameters:
- in: path
name: id
required: true
type: integer
security:
- api_key: []
responses:
'200':
description: A successful response
schema:
type: string
securityDefinitions:
# This section configures basic authentication with an API Key.
api_key:
type: "apiKey"
name: "key"
in: "query"
For a sample call to the /reports/results endpoint as http://myappapi/reports/results/1,
the expectation is for calls to get converted to https://myappapi-asldfjoiewjfv-uc.a.run.app/v1/reports/results/1?key=MyAPIKeyHere. But instead they turn out as https://myappapi-asldfjoiewjfv-uc.a.run.app/v1/reports/results?key=MyAPIKeyHere&id=1
Is there a way to get the API calls go as https://myappapi-asldfjoiewjfv-uc.a.run.app/v1/reports/results/1?key=MyAPIKeyHere ?
Thanks in Advance!
As mentioned in this documentation
Set path_translation as part of setting x-google-backend:
x-google-backend:
address: https://GCP_REGION-PROJECT_ID.cloudfunctions.net/hello
path_translation: [ APPEND_PATH_TO_ADDRESS | CONSTANT_ADDRESS ]
The default value of path_translation depends on where you set x-google->backend in your OpenAPI spec:
When x-google-backend is used at the top level of the OpenAPI specification, path_translation defaults to APPEND_PATH_TO_ADDRESS.
When x-google-backend is used at the operation level of the OpenAPI specification, path_translation defaults to CONSTANT_ADDRESS.
For more details on path translation, please see the Understanding path translation section. You can also check this stackoverflow thread.

Spring cloud gateway with discoveryclient and static routes

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)

"DedupeResponseHeader" not working with Greenwich.SR3

DedupeResponseHeader is not working for me in Spring Cloud Greenwich.SR3, I have added CORS configuration in application.yml, and downstream application is also sending Access-Control-Allow-Origin in response header, which in ending up with:
The 'Access-Control-Allow-Origin' header contains multiple values 'http://localhost:4200, http://localhost:4200', but only one is allowed.
I have used DedupeResponseHeader but that is not working for me still seeing same error in browser console. Following is the config for CORS and DedupeResponseHeader:
spring:
cloud:
gateway:
default-filters:
- DedupeResponseHeader=Access-Control-Allow-Origin, RETAIN_UNIQUE
globalcors:
add-to-simple-url-handler-mapping: true
corsConfigurations:
'[/**]':
allowedOrigins: "http://localhost:4200"
allowedMethods: "*"
allowedHeaders: "*"
Tried in filters also, but also didn't work
spring:
cloud:
gateway:
routes:
- id: dedupe_response_header_route
uri: http://localhost:4200
predicates:
- Method=OPTIONS
- Method=GET
filters:
- DedupeResponseHeader=Access-Control-Allow-Origin
Couldn't figure out the reason why its not working, double checked the spring cloud version. I appreciate, if someone could help to understand why DedupeResponseHeader not working.
You can use the latest version of the spring cloud i.e. 2020.0.2 --- it is working perfectly there.

Serverless - Referencing api gateway address in CloudFront origin definition

Using Serverless Framework,
i am creating an api gateway in my template :
functions
test:
handler: test.handler
events:
- http:
path: save-subscription
method: post
cors: false
later on i want to use this api address xxxxxxx.execute-api.us-east-1.amazonaws.com/dev/
as a domain name of an oigin of my cloudfront origins
DomainName: xxxxxxx.execute-api.us-east-1.amazonaws.com
OriginPath: dev
Is there a way to reference the api address dynamically/programmatically before it even exist, and do I need to use depends on?
Thanks
- DomainName:
Fn::Join:
- ""
- - "Ref": "ApiGatewayRestApi"
- ".execute-api.${self:custom.region}.amazonaws.com"
worked for me.
Found the answer here : https://www.richdevelops.dev/blog/how-do-i-get-my-api-gateway-url

Multiple Zuul routes to one service

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