"504 Gateway Timeout" when running "clairctl report" to get /indexer/api/v1/index_report/..
kamalpreetSec opened this issue · comments
Description of Problem / Feature Request
I have setup the testing env local-dev-up-with-quay as mentioned in https://quay.github.io/clair/howto/testing.html. While running clairctl report to scan an image, the path "/indexer/api/v1/index_report/.." is not reachable on indexer container and getting response status="504 Gateway Timeout". Here's the output:
[root@user clairctl]# ./clairctl-linux-amd64 -D --iss quay report 127.0.0.1:8080/clairv4-org/testing:latest
2021-09-22T11:44:42Z DBG fetching ref=127.0.0.1:8080/clairv4-org/testing:latest
2021-09-22T11:44:42Z DBG using text output
2021-09-22T11:44:43Z DBG found manifest digest=sha256:af4a4ac8bb35672a6279b45efc8ee7c696ceae4d5cc060a69855e5da48e0cc5b ref=127.0.0.1:8080/clairv4-org/testing:latest
2021-09-22T11:45:13Z DBG method=GET path=/indexer/api/v1/index_report/sha256:af4a4ac8bb35672a6279b45efc8ee7c696ceae4d5cc060a69855e5da48e0cc5b status="504 Gateway Timeout"
2021-09-22T11:45:13Z DBG index error error="unexpected return status: 504" ref=127.0.0.1:8080/clairv4-org/testing:latest
2021-09-22T11:45:13Z ERR error="unexpected return status: 504"
I have already set the proxy env variables:
http_proxy, https_proxy, no_proxy
Expected Outcome
The indexed report should be accessible
Actual Outcome
[root@user clairctl]# ./clairctl-linux-amd64 -D --iss quay report 127.0.0.1:8080/clairv4-org/testing:latest
2021-09-22T11:44:42Z DBG fetching ref=127.0.0.1:8080/clairv4-org/testing:latest
2021-09-22T11:44:42Z DBG using text output
2021-09-22T11:44:43Z DBG found manifest digest=sha256:af4a4ac8bb35672a6279b45efc8ee7c696ceae4d5cc060a69855e5da48e0cc5b ref=127.0.0.1:8080/clairv4-org/testing:latest
2021-09-22T11:45:13Z DBG method=GET path=/indexer/api/v1/index_report/sha256:af4a4ac8bb35672a6279b45efc8ee7c696ceae4d5cc060a69855e5da48e0cc5b status="504 Gateway Timeout"
2021-09-22T11:45:13Z DBG index error error="unexpected return status: 504" ref=127.0.0.1:8080/clairv4-org/testing:latest
2021-09-22T11:45:13Z ERR error="unexpected return status: 504"
The docker logs in clair-traefik:
172.26.0.1 - - [22/Sep/2021:09:30:01 +0000] "GET /indexer/api/v1/index_report/sha256:af4a4ac8bb35672a6279b45efc8ee7c696ceae4d5cc060a69855e5da48e0cc5b HTTP/1.1" 504 15 "-" "-" 29 "indexer@docker" "http://172.26.0.15:6000" 30000ms
Environment
- Clair version/image: git@github.com:quay/clair.git
- Clair client name/version: Clairctl 4.1.5 (https://github.com/quay/clair/releases/tag/v4.1.5)
- Host OS: Oracle Linux 7 5.4.17-2102.204.4.4.el7uek.x86_64
- Kernel (e.g.
uname -a): 5.4.17-2102.204.4.4.el7uek.x86_64 #2 SMP Tue Aug 17 20:25:28 PDT 2021 x86_64 x86_64 x86_64 GNU/Linux - Kubernetes version (use
kubectl version): NA - Network/Firewall setup: Behind Corporate proxy
It looks like traefik has a timeout.
It looks like traefik has a timeout.
Is there a commandline parameter which I can set ?
I'm not sure, please refer to the traefik documentation.
I recreated the containers with proxy settings in the environment section of docker-compose file. Now I am getting the following issue:
./clairctl-linux-amd64 -D report --host http://localhost:6060 oraclelinux:6-slim
2021-09-30T06:24:04Z DBG fetching ref=oraclelinux:6-slim
2021-09-30T06:24:04Z DBG using text output
2021-09-30T06:24:07Z DBG found manifest digest=sha256:bc77589bd852d5a6030f388d02390a8d2f4eaf89902ddb8160233835eee824fc ref=oraclelinux:6-slim
2021-09-30T06:24:07Z DBG method=GET path=/indexer/api/v1/index_report/sha256:bc77589bd852d5a6030f388d02390a8d2f4eaf89902ddb8160233835eee824fc status="502 Bad Gateway"
2021-09-30T06:24:07Z DBG index error error="unexpected return status: 502" ref=oraclelinux:6-slim
2021-09-30T06:24:07Z ERR error="unexpected return status: 502"
Traefik logs:
172.19.0.1 - - [30/Sep/2021:05:34:02 +0000] "GET /indexer/api/v1/index_report/sha256:bc77589bd852d5a6030f388d02390a8d2f4eaf89902ddb8160233835eee824fc HTTP/1.1" 502 2814 "-" "-" 10 "indexer@docker" "http://172.19.0.15:6000" 71ms
Closing because this is a traefik configuration issue.
There's a pending branch (#1397) that has a much less convoluted configuration that can actually be supported.