Traefik as a simple Http Reverse Proxy not working - http

I am using Traefik as HTTP reverse proxy. I have two servers created using spring boot. Both servers are working properly on port 8081 and 8082
Traefik web UI is visible in port 8080.
What I wanted is to redirect http://localhost:7070/ to http://localhost:8081/ or http://localhost:8082/
traefik.toml config file
loglevel="INFO"
defaultEntryPoints = ["http"]
[entryPoints]
[entryPoints.http]
address = ":7070"
[file]
[frontends]
[frontends.frontend1]
backend = "backend1"
[frontends.frontend1.routes.test_1]
rule = "Host: localhost"
[backends]
[backends.backend1]
[backends.backend1.LoadBalancer]
method = "drr"
[backends.backend1.healthcheck]
path = "/app/health"
interval = "60s"
[backends.backend1.servers.server1]
url = "http://127.0.0.1:8081"
weight = 1
[backends.backend1.servers.server2]
url = "http://127.0.0.1:8082"
weight = 1
[api]
[ping]
[docker]
console output
INFO[2018-03-20T18:38:58+05:30] Using TOML configuration file
/home/kasun/apps/temp/traefik.toml
INFO[2018-03-20T18:38:58+05:30] Traefik version v1.5.4 built on 2018-
03-15_01:33:52PM
INFO[2018-03-20T18:38:58+05:30]
Stats collection is disabled.
Help us improve Traefik by turning this feature on :)
More details on https://docs.traefik.io/basics/#collected-data
INFO[2018-03-20T18:38:58+05:30] Preparing server http &{Network:
Address::7070 TLS:<nil> Redirect:<nil> Auth:<nil>
WhitelistSourceRange:[] Compress:false ProxyProtocol:<nil>
ForwardedHeaders:0xc4202a4520} with readTimeout=0s writeTimeout=0s
idleTimeout=3m0s
INFO[2018-03-20T18:38:58+05:30] Preparing server traefik &{Network:
Address::8080 TLS:<nil> Redirect:<nil> Auth:<nil>
WhitelistSourceRange:[] Compress:false ProxyProtocol:<nil>
ForwardedHeaders:0xc4202a4540} with readTimeout=0s writeTimeout=0s
idleTimeout=3m0s
INFO[2018-03-20T18:38:58+05:30] Starting server on :7070
INFO[2018-03-20T18:38:58+05:30] Starting provider *docker.Provider
{"Watch":true,"Filename":"","Constraints":null,"Trace":false,
"DebugLogGen
eratedTemplate":false,"Endpoint":
"unix:///var/run/docker.sock","Domain":"","TLS":null,
"ExposedByDefault":true,"UseBindPortIP":false,"SwarmMode":false}
INFO[2018-03-20T18:38:58+05:30] Starting server on :8080
INFO[2018-03-20T18:38:58+05:30] Starting provider *file.Provider
{"Watch":true,"Filename":"/home/kasun/apps/temp/traefik.toml",
"Constraints":null,"Trace":false,"DebugLogGeneratedTemplate":false,
"Directory":""}
INFO[2018-03-20T18:38:58+05:30] Server configuration reloaded on :7070
INFO[2018-03-20T18:38:58+05:30] Server configuration reloaded on :8080
INFO[2018-03-20T18:38:58+05:30] Server configuration reloaded on :7070
INFO[2018-03-20T18:38:58+05:30] Server configuration reloaded on :8080
WARN[2018-03-20T18:38:58+05:30] HealthCheck has failed
[http://127.0.0.1:8081]: Remove from server list
WARN[2018-03-20T18:38:58+05:30] HealthCheck has failed
[http://127.0.0.1:8082]: Remove from server list
WARN[2018-03-20T18:38:58+05:30] HealthCheck has failed
[http://127.0.0.1:8082]: Remove from server list
WARN[2018-03-20T18:38:58+05:30] HealthCheck has failed
[http://127.0.0.1:8081]: Remove from server list
When I load http://localhost:7070/ from the browser it gives
Service Unavailable
when I go to Traefik health dashboard it displays
Can anybody tell me what I am doing wrong here? I went through a few articles but unable to find the correct answer.

I suppose your are running Træfik in a container.
127.0.0.1 -> localhost inside the container, not in your local machine.

Related

how to send metrics to influx oss2 using jolokia in telegraf config?

after running teltelegraf -debug with jolokia config
[[inputs.jolokia2_agent]]
urls = ["http://<other ip>:8080/jolokia-war-unsecured-1.6.2/"]
[[inputs.jolokia2_agent.metric]]
name = "jr"
mbean = "java.lang:type=Runtime"
paths = ["Uptime"]
I get this errors:
[agent] Initializing plugins
2022-07-02T12:51:57Z D! [agent] Connecting outputs
2022-07-02T12:51:57Z D! [agent] Attempting connection to [outputs.influxdb_v2]
2022-07-02T12:51:57Z D! [agent] Successfully connected to outputs.influxdb_v2
2022-07-02T12:51:57Z D! [agent] Starting service inputs
2022-07-02T12:52:07Z E! [outputs.influxdb_v2] When writing to [https://MYIP:8086]: Post "https://MYIP:8086/api/v2/write?bucket=monitoringdb&org=myorg": http: server gave HTTP response to HTTPS client
2022-07-02T12:52:07Z D! [outputs.influxdb_v2] Buffer fullness: 81 / 10000 metrics
2022-07-02T12:52:07Z E! [agent] Error writing to outputs.influxdb_v2: failed to send metrics to any configured server(s)
2022-07-02T12:52:07Z E! [outputs.influxdb_v2] When writing to [https://MYIP:8086]: Post "https://MYIP:8086/api/v2/write?bucket=monitoringdb&org=myorg": http: server gave HTTP response to HTTPS client
This error is coming from your influxdb output. It says your client is using https; however, the server responded with an http response. In your config, you probably specified a URL with https://, but the server is probably only using http://.

web GRPC and Iroha (JS implementation for iroha)

I am trying to run this docker file https://gitlab.com/snippets/1713665
consoles
I have running iroha container as you can see in right console on 50051 port, but on running the above docker file for web GRPC then you can see in left console it is unable to make connection. as i have also tried with enabling and disabling the firewalls and also with opening the 50051 withudo ufw allow 50051 sudo ufw allow 50051 ...But in the end i have the same results
"Err: connection error: desc = "transport: Error while dialing dial tcp 127.0.0.1:50051: connect: connection refused". Reconnecting... system=system"
I have also posted this issue month ago but no once gave me any response, Thats why i am reposting with further elaboration
Try running the grpc web proxy, with the backend address as localhost, instead of whatever is default in the gitlab post.
ex. ./grpcwebproxy-v0.13.0-osx-x86_64 --backend_addr=localhost:50051 --run_tls_server=false
From the console logs, it looks like it is trying to connect to dev.localdomain:50051

404 after upgrading artifactory from 6.20 to 7.6.2

I am getting 404 accesing to https://my-dmain/ui/. If I try to access to https://my-dmain/artifactory it redirects to https://my-dmain/ui/ with 404. No log errors, only one warning:
2020-07-10T08:06:04.535L [35m[tomct][0m [WARNING] [ ]
[org.apache.catalina.startup.HostConfig]
[org.apache.catalina.startup.HostConfig deployDescriptor] - A docBase
[/opt/jfrog/artifactory/app/artifactory/tomcat/webapps/artifactory.war]
inside the host appBase has been specified, and will be ignored
2020-07-10T08:06:04.540L [35m[tomct][0m [WARNING] [ ]
[org.apache.catalina.startup.HostConfig]
[org.apache.catalina.startup.HostConfig deployDescriptor] - A docBase
[/opt/jfrog/artifactory/app/artifactory/tomcat/webapps/access.war]
inside the host appBase has been specified, and will be ignored
Just to confirm it, can you try to access the Artifactory using the server IP and port, like HTTP://1.2.3.4:8082? If you are able to access the Artifactory UI using the server IP and Port, I believe you need to tweak the reverse proxy being used.
Your problem is that with Artifactory 7.x the reverse proxy configuration is different. In this KB article you can find a working NGINX configuration.
One easy way to generate such configuration is to bypass your reverse proxy and go to Artifactory directly, there in the UI you will be able to log in, head to HTTP settings, and generate a new Apache or NGINX config.

Tyk gateway with Nginx and Apache Tomcat 8 (ubuntu 14.04)

Just wondering what I am missing here when trying to create an API with Tyk Dashboard.
My setup is:
Nginx > Apache Tomcat 8 > Java Web Application > (database)
Nginx is already working, redirecting calls to apache tomcat at default port 8080.
Example: tomcat.myserver.com/webapp/get/1
200-OK
I have setup tyk-dashboard and tyk-gateway previously as follows using a custom node port 8011:
Tyk dashboard:
$ sudo /opt/tyk-dashboard/install/setup.sh --listenport=3000 --redishost=localhost --redisport=6379 --mongo=mongodb://127.0.0.1/tyk_analytics --tyk_api_hostname=$HOSTNAME --tyk_node_hostname=http://127.0.0.1 --tyk_node_port=8011 --portal_root=/portal --domain="dashboard.tyk-local.com"
Tyk gateway:
/opt/tyk-gateway/install/setup.sh --dashboard=1 --listenport=8011 --redishost=127.0.0.1 --redisport=6379 --domain=""
/etc/hosts already configured (not really needed):
127.0.0.1 dashboard.tyk-local.com
127.0.0.1 portal.tyk-local.com
Tyk Dashboard configurations (nothing special here):
API name: foo
Listen path: /foo
API slug: foo
Target URL: tomcat.myserver.com/webapp/
What URI I suppose to call? Is there any setup I need to add in Nginx?
myserver.com/foo 502 nginx
myserver.com:8011/foo does not respond
foo.myserver.com 502 nginx
(everything is running under the same server)
SOLVED:
Tyk Gateway configuration was incorrect.
Needed to add --mongo and remove --domain directives at setup.sh :
/opt/tyk-gateway/install/setup.sh --dashboard=1 --listenport=8011 --redishost=localhost --redisport=6379 --mongo=mongodb://127.0.0.1/tyk_analytics
So, calling curl -H "Authorization: null" 127.0.0.1:8011/foo
I get:
{
"error": "Key not authorised"
}
I am not sure about the /foo path. I think that was previously what the /hello path is. But it appears there is a key not authorized issue. If the call is made using the Gateway API, then the secret value may be missing. It is required when making calls to the gateway (except the hello and reload paths)
x-tyk-authorization: <your-secret>
However, since there is a dashboard present, then I would suggest using the Dashboard APIs to create the API definition instead.

Kibana - socket hang up error

I am running Kibana behind IIS reverse proxy server and getting following error
Courier Fetch Error: unhandled courier request error: socket hang up
I am on Version: 4.2.2, Build: 9177.
I get this error only when I use proxy server which I need to restrict access to Kibana. I am not sure what is causing this or how to fix it.
Error: unhandled courier request error: socket hang up
at handleError (http://kibana-server/bundles/kibana.bundle.js:70047:23)
at DocRequest.AbstractReqProvider.AbstractReq.handleFailure (http://kibana-server/bundles/kibana.bundle.js:69967:15)
at http://kibana-server/bundles/kibana.bundle.js:69861:18
at Array.forEach (native)
at http://kibana-server/bundles/kibana.bundle.js:69859:19
at wrappedErrback (http://kibana-server/bundles/commons.bundle.js:39286:79)
at http://kibana-server/bundles/commons.bundle.js:39419:77
at Scope.$eval (http://kibana-server/bundles/commons.bundle.js:40406:29)
at Scope.$digest (http://kibana-server/bundles/commons.bundle.js:40218:32)
at Scope.$apply (http://kibana-server/bundles/commons.bundle.js:40510:25)
If you have enabled Integrated Windows Authentication in your IIS the Kibana server cannot process the request, because the http-Authorization-Header is too large (group memberships are stored in the PAC field of the kerberos tickets).
We had the same Problem with an Apache reverse proxy server in front of Kibana. The solution is to unset the Authorization-Header after Kerberos/NTLM-Authentication is done and before sending the proxy request to Kibana.
Configuration for Apache:
RequestHeader unset Authorization
Try removing http.cors and http.compression as noted in https://github.com/elastic/kibana/issues/6719

Resources