I have the following configuration of service with route in Kong:
- name: test
host: test-service
port: 80
protocol: http
path: /endpoint/
routes:
- name: test_route
strip_path: true
preserve_host: true
paths:
- /login
I am trying to understand the following behaviour:
when I access http://localhost/login, I will end up with the http://localhost/endpoint in my browser
however, when I try to access http://localhost/login/test/page, nothing will change and I am still in my browser on http://localhost/login/test/page and the upstream server served my request properly
My expectation was that using http://localhost/login/test/page, my browser will have eventually http://localhost/endpoint/test/page. Apparently I misunderstood it.
I understood that in this case, Kong will use the upstream path as /endpoint/test/page, because I have strip_path: true.
However, how it can be changed in case I want to end up with http://localhost/endpoint/test/page in case I will access http://localhost/login/test/page in my browser?
Related
I want to implement a simple redirect using Kong's request-termination & response-transformer plugins. The plugins mostly works, but I have an issue with handling query parameters.
My configuration for the plugins is similar to this (note: I'm using Kong in DB-less mode):
services:
- name: my-redirects
url: http://localhost:8080/
routes:
- name: redirect-route
paths:
- /context$
- /$
plugins:
- name: request-termination
config:
status_code: 301
message: Redirect to main page...
- name: response-transformer
config:
add:
headers:
- Location:/context/
I want to obtain the following behaviour:
User visits http://localhost:8000/ -> redirected to /context/
User visits http://localhost:8000/context -> redirected to /context/
User visits http://localhost:8000/?param=value -> redirected to /context/?param=value
User visits http://localhost:8000/context?param=value -> redirected to /context/?param=value
Basically both / and /context requests should be redirected to /context/ (with a final slash) but query parameters should be preserved.
How can I modify the configuration:
add:
headers:
- Location:/context/
to include query parameters matched in the request? I expect to be able to do something like:
add:
headers:
- Location:/context/$query_params
What we are using to solve this on kong running in kubernetes is to use an ingress Exact rule coupled with a pre-function plugin. It should be easy to adapt it to the non-k8s yaml config:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: foo-ingress-redirect
konghq.com/plugins: foo-redirect
spec:
...
rules:
- host: myhost.example
http:
paths:
- path: /foo/bar # redirect /foo/bar to /foo/bar/ via plugin above
pathType: Exact
backend:
...
and then plugin:
apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
name: foo-redirect
plugin: pre-function
config:
access:
- kong.response.exit(301, '', {['Location'] = '/foo/bar/'})
You can also play with kong.request interface if you need to e.g. pass the original query params on the redirect.
It's a bit convoluted but also did not find a simpler way.
I am trying to get an old project (not made by me) up and running, and I see that the routes are configured in some peculiar format. This is a typical route config:
customer_home:
path: /customer
host: "web.{domain}"
defaults:
_controller: "BackendBundle:Customer:index"
domain: "%domain%"
methods: [get]
options:
expose: true
requirements:
domain: '%domain%'
Now, I grepped the source code and found domain in the config files. It was null by default and by setting it to localhost:8000 I was able to at least load the root without complaints about %domain%. Now it complains about not finding a matching route, which makes sense, as none was configured. What was configured (which I found by doing console debug:router) was a root route for admin.{domain} and web.{domain}. I assume this means that if the domain is myapp.com, there should be routes configured for admin.myapp.com/ and web.myapp.com.
This is a local development setup, running on 127.0.0.1:8000, so I tried adding this to /etc/hosts:
127.0.0.1 web.localhost admin.localhost
I was now hoping that going to web.localhost:8000 would load a route, but none was matched. I still get NotFoundHttpException, but now I no longer understand why ... How can I configure this setup so that I can load the web and admin subdomains on my development machine? Other routes, like /api/1/doc, works fine.
I was not far off. The answer was to simply drop the port portion of what I had entered as the domain setting. So domain: localhost did the trick. The server is by default running on port 8000, no matter the setting, so it was not needed. I can now access web.localhost and admin.localhost (after adding them as host aliases for the loopback device in /etc/hosts).
I've been using elasticsearch, metricbeat and elastalert to watch my server. I have nginx intalled on it that is been used as a reverse proxy and I need to send an to it if nginx drop or return some error, I have already some alerts configured but how can I make a rule to send alert to nginx when it drop or return some error.
Thank a lot
Metricbeat is just for data about the system resources usage. What you need is installing filebeat and activating the nginx module. Then you can use the rule type any of elastalert and filter by fileset.module: nginx and fileset.name: error:
name: your rule name
index: filebeat-*
type: any
filter:
- term:
fileset.module: "nginx"
- term:
fileset.name: "error"
alert:
- "slack"
... # your slack config stuff
realert:
minutes: 1
I have a couple of NodeJS backends running as pods in a Kubernetes setup, with Ingress-managed nginx over it.
These backends are API servers, and can return 400, 404, or 500 responses during normal operations. These responses would provide meaningful data to the client; besides the status code, the response has a JSON-serialized structure in the body informing about the error cause or suggesting a solution.
However, Ingress will intercept these error responses, and return an error page. Thus the client does not receive the information that the service has tried to provide.
There's a closed ticket in the kubernetes-contrib repository suggesting that it is now possible to turn off error interception: https://github.com/kubernetes/contrib/issues/897. Being new to kubernetes/ingress, I cannot figure out how to apply this configuration in my situation.
For reference, this is the output of kubectl get ingress <ingress-name>: (redacted names and IPs)
Name: ingress-name-redacted
Namespace: default
Address: 127.0.0.1
Default backend: default-http-backend:80 (<none>)
Rules:
Host Path Backends
---- ---- --------
public.service.example.com
/ service-name:80 (<none>)
Annotations:
rewrite-target: /
service-upstream: true
use-port-in-redirects: true
Events: <none>
I have solved this on Tectonic 1.7.9-tectonic.4.
In the Tectonic web UI, go to Workloads -> Config Maps and filter by namespace tectonic-system.
In the config maps shown, you should see one named "tectonic-custom-error".
Open it and go to the YAML editor.
In the data field you should have an entry like this:
custom-http-errors: '404, 500, 502, 503'
which configures which HTTP responses will be captured and be shown with the custom Tectonic error page.
If you don't want some of those, just remove them, or clear them all.
It should take effect as soon as you save the updated config map.
Of course, you could to the same from the command line with kubectl edit:
$> kubectl edit cm tectonic-custom-error --namespace=tectonic-system
Hope this helps :)
I am developing a REST API using dropwizard. The resource can be accessed using https://<host>:port/item/1. As it can be seen there is no URI prefix. If I have to configure a URI prefix what needs to be done. Can it be configured in yaml configuration file?
Thanks!
Yes the URI prefix a.k.a root path can be configured in YAML. You could use the simple server factory configuration. It's simple, add these two lines in your YAML. I've used 'api' as the prefix. You can replace it with the URI prefix you want.
server:
rootPath: '/api/*'
A slightly more elaborate server configuration looks something like this,
server:
adminConnectors:
-
port: 18001
type: http
adminContextPath: /admin
applicationConnectors:
-
port: 18000
type: http
rootPath: /api/*
type: default
You can refer to this example https://github.com/dropwizard/dropwizard/blob/master/dropwizard-example/example.yml for server and other configuration details.
It's also a good idea to go through this if you are just getting started with dropwizard http://www.dropwizard.io/0.9.2/docs/getting-started.html