sourcegraph / sourcegraph-public-snapshot

Code AI platform with Code Search & Cody
https://sourcegraph.com
Other
10.1k stars 1.28k forks source link

Support for HTTPS_PROXY, HTTP_PROXY, and NO_PROXY env vars #12377

Closed dadlerj closed 4 years ago

dadlerj commented 4 years ago

Requested by https://app.hubspot.com/contacts/2762526/company/557692805

Context at https://sourcegraph.slack.com/archives/CTQ5LTF8D/p1592858268356300 and https://sourcegraph.slack.com/archives/CTQ5LTF8D/p1595011378044800

Hey team, I’m currently having issues reaching github.com from our sg instance. I’ve configured proxy env vars on three pods: gitserver, repo-updater, and github-proxy. These seem be to working correctly as when I sh into one of the containers I can hit the appropriate endpoints such as $REDACTED_URL. However, I am still getting the following error in the logs of github-proxy:

t=2020-06-22T20:28:37+0000 lvl=warn msg="proxy error" err="Get \"$REDACTED_URL\": dial tcp $REDACTED_IP:443: connect: connection timed out"

purpose of the proxy: allow access to the internet at large. we aren’t allowed to make direct contact with the internet, we must go through the proxy. so requests to github.com etc, must go through the proxy

result of curl: once i am in the github-proxy container, with the appropriate vars set, I able to curl the url i listed in the original message and get results.

for full context here is the proxy config for github-proxy pod:


- name: http_proxy
  value: "http://$REDACTED:8099"
- name: https_proxy
  value: "http://$REDACTED:8099"
- name: HTTP_PROXY
  value: "http://$REDACTED:8099"
- name: HTTPS_PROXY
  value: "http://$REDACTED:8099"
- name: no_proxy
  value: "$REDACTED"
- name: NO_PROXY
  value: "$REDACTED"
dadlerj commented 4 years ago

Update from @slimsag:

To be completely clear, my analysis is that (1) we do not support *_PROXY and (2) that we should not support it because it is too limited. We need a different format than just respecting _PROXY so it is not brittle, preferably done through the site configuration.

unknwon commented 4 years ago

I think we're using a common HTTP cli underneath already (IIRC @keegancsmith did that), so theoretically shouldn't be a problem.

keegancsmith commented 4 years ago

We do support HTTP_PROXY environment variables. I was surprised this wasn't working, and it seems github-proxy is the only place we don't support it :) Sending a PR to fix.

Note: I went down the route of supporting this via our site settings. It made everything way more complicated and I spun my wheels on it for a while.

The only services which do external communication are repo-updater, gitserver and github-proxy (missed that last one when I fixed). So I just made sure they worked.