I have problem with my traefik configuration ...
I would like frontend redirect regex for https services but in my docker-compose the following configuration seems not working (and not appear on trafik GUI).
In log (debug level) nothing interesting.
My labels :
- traefik.http.port=80
- traefik.http.frontend.entryPoints=http
- traefik.https.port=443
- traefik.https.frontend.entryPoints=https
- traefik.https.protocol=https
- traefik.backend.loadbalancer.stickiness=true
- traefik.frontend.rule=HostRegexp:{subdomain:[a-zA-Z0-9-_]+}.mydomain.com
- traefik.https.frontend.redirect.permanent=true
- traefik.https.frontend.redirect.regex=^https://(.*)/$$"
- traefik.https.frontend.redirect.remplacement=https://$${1}/myapp/
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)
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.
I have added the following command-line arguments to kube-apiserver to enable audit logging:
- --audit-log-path=/tmp/k8s-audit.log
- --audit-policy-file=/etc/kubernetes/audit.yaml
- --audit-log-maxage=1
- --audit-log-maxsize=100
- --audit-log-maxbackup=1
The contents of /etc/kubernetes/audit.yaml is:
apiVersion: audit.k8s.io/v1
kind: Policy
omitStages:
- "ResponseStarted"
- "ResponseComplete"
rules:
- level: RequestResponse
I have run a command with verbose logging, so that I can see the request body:
$ kubectl --v=10 uncordon cluster-worker2
And the kubectl command logs the request body as follows:
I0328 09:00:07.591869 47228 request.go:942] Request Body: {"spec":{"unschedulable":null}}
But I don't see this request body anywhere in the audit log file on the kubernetes server. What's wrong with my configuration?
The request is actually only logged in the ResponseComplete stage, somewhat unexpectedly. Even though Kubernetes could theoretically log the request as soon as it receives it, it doesn't.
So it's necessary to remove the ResponseComplete line from the omitstages in the policy configuration file (audit.yaml).
Problem
Does anyone know how to configure bootstrap.yml to tell Spring Cloud Vault to go to the correct path for k2 v2 and not try other paths first?
Details
I can successfully connect to my Vault, running k2 v2, but Spring Cloud will always try to connect to paths in the vault that don't exist, throwing a 403 on startup.
Status 403 Forbidden [secret/application]: permission denied; nested exception is org.springframework.web.client.HttpClientErrorException$Forbidden: 403 Forbidden
The above path, secret/application, doesn't exist because k2 v2 puts data in the path. For example: secret/data/application.
This isn't a show-stopper because Spring Cloud Vault does check other paths, including the correct one that has the data item in the path, but the fact a meaningless 403 is thrown during startup is like a splinter in my mind.
Ultimately, it does try the correct k2 v2 path
2019-03-18 12:22:46.611 INFO 77685 --- [ restartedMain] b.c.PropertySourceBootstrapConfiguration : Located property source: CompositePropertySource {name='vault', propertySources=[LeaseAwareVaultPropertySource {name='secret/data/my-app'}
My configuration
spring.cloud.vault:
kv:
enabled: true
backend: secret
profile-separator: '/'
default-context: my-app
application-name: my-app
host: localhost
port: 8200
scheme: http
authentication: TOKEN
token: my-crazy-long-token-string
Thanks for your help!
Add the following lines in your bootstrap.yml, this disables the generic backend
spring.cloud.vault:
generic:
enabled: false
for more information https://cloud.spring.io/spring-cloud-vault/reference/html/#vault.config.backends.generic
In addition to the accepted answer it's important to turn off (or just remove) fail-fast option:
spring.cloud.vault:
fail-fast: false
spring.cloud.vault.generic.enabled is deprecated in spring-cloud 3.0.0, but the 403 error is still there. To disable the warning (by telling spring to use the exact context), this is what I used:
spring:
config:
import: vault://
application:
name: my-application
cloud:
vault:
host: localhost
scheme: http
authentication: TOKEN
token: my-crazy-long-token-string
kv:
default-context: my-application
Other configs were set to default (such as port = 8200, backend = secret, etc.)
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