Self-Hosted Version
26.5.2
CPU Architecture
x86_64
Docker Version
29.7.1
Docker Compose Version
5.3.1
Machine Specification
Installation Type
since the fresh install version 24.X
Steps to Reproduce
- Deploy self-hosted behind a filtering outbound proxy (in my case a Squid proxy in a DMZ where all outbound traffic is controlled).
- Configure the proxy variables (HTTP_PROXY, HTTPS_PROXY, http_proxy, https_proxy) in .env.custom, as documented.
- Run the install/build process so install/dc-detect-version.sh computes these proxy build-args and Docker builds the jq, sentry and cron images.
Expected Result
The proxy variables computed by install/dc-detect-version.sh should be passed through to the jq, sentry and cron Dockerfiles as build ARGs, the same way the rest of the installation already honors the proxy configured in .env.custom. The builds should succeed without needing any outbound access outside the proxy.
Actual Result
The jq/Dockerfile, sentry/Dockerfile and cron/Dockerfile never declare the proxy variables as ARG, so Docker silently discards them at build time. In practice this causes pip install to time out in sentry/Dockerfile, and apt failures in jq/Dockerfile and cron/Dockerfile.
Since v25, I've had to manually patch these three Dockerfiles on every update with a bash script I maintain myself, otherwise the build breaks in my environment.
This isn't isolated: I ran into a related issue with the snuba-api healthcheck routing local requests through the proxy when it shouldn't (urllib.request doesn't support CIDR notation in NO_PROXY), opened separately as #4441. Both point to the same root cause: self-hosted has likely never been tested end-to-end behind a mandatory proxy, even though that's my everyday setup and probably the case for others deploying in corporate environments with filtered outbound access.
I had submitted a fix for this in #4443, but the PR was closed, more over form than over the substance of the problem. The bug is still there, and I'm still working around it with my script on every version bump. I'm opening this issue to put the underlying need back on the table independently of my previous patch, and I'm happy to rework a PR once we agree on the approach.
Thanks !
Event ID
No response
Self-Hosted Version
26.5.2
CPU Architecture
x86_64
Docker Version
29.7.1
Docker Compose Version
5.3.1
Machine Specification
Installation Type
since the fresh install version 24.X
Steps to Reproduce
Expected Result
The proxy variables computed by install/dc-detect-version.sh should be passed through to the jq, sentry and cron Dockerfiles as build ARGs, the same way the rest of the installation already honors the proxy configured in .env.custom. The builds should succeed without needing any outbound access outside the proxy.
Actual Result
The jq/Dockerfile, sentry/Dockerfile and cron/Dockerfile never declare the proxy variables as ARG, so Docker silently discards them at build time. In practice this causes pip install to time out in sentry/Dockerfile, and apt failures in jq/Dockerfile and cron/Dockerfile.
Since v25, I've had to manually patch these three Dockerfiles on every update with a bash script I maintain myself, otherwise the build breaks in my environment.
This isn't isolated: I ran into a related issue with the snuba-api healthcheck routing local requests through the proxy when it shouldn't (urllib.request doesn't support CIDR notation in NO_PROXY), opened separately as #4441. Both point to the same root cause: self-hosted has likely never been tested end-to-end behind a mandatory proxy, even though that's my everyday setup and probably the case for others deploying in corporate environments with filtered outbound access.
I had submitted a fix for this in #4443, but the PR was closed, more over form than over the substance of the problem. The bug is still there, and I'm still working around it with my script on every version bump. I'm opening this issue to put the underlying need back on the table independently of my previous patch, and I'm happy to rework a PR once we agree on the approach.
Thanks !
Event ID
No response