sameersbn / sameersbn/docker-gitlab
Outgoing proxy support?
Nobody has claimed this yet.
- Dominant language
- Shell
- Stars
- 8.1k
- Forks
- 2.1k
- Avg merge
- 17h 47m
- Merged PRs (30d)
- 7
Description
Hi,
First of all thanks for your great work. I really appreciate your work. Not only with GitLab, but also for you other container like squid, postgres etc.
Now let's get to my issue:
I have GitLab as Docker instance running in a corporate environment with mandatory proxy usage for all outgoing traffic - internal traffic must not use the proxy.
Normally I would define something like:
export http_proxy=http://myproxy.lan:3128
export http_proxy=https://myproxy.lan:3128
export http_proxy=ftp://myproxy.lan:3128
export no_proxy=*.coproate.lan
I found some hints that such a config needs to be provided to unicorn and sidekiq. But as far as I can see this is currently not supported by your setup.
Unfortunately this would not fit, since the no_proxy directive would not be there.
So I thought why not using your squid docker container and have this one being configured appropriately (forward all non RFC 1597/1918 networks to the corporate proxy and all other stuff just being ofloaded with the local squid).
What do you think? does this make sense to you? could you help me out?
Thanks and cheers
Tobias
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by examining the Docker configuration and how environment variables reach the Unicorn and Sidekiq entry points mentioned in the issue. Verify that HTTP, HTTPS, FTP, and no_proxy settings support external proxying while bypassing internal traffic; done means the behavior is documented and reproducible in the container setup.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, shell
- Domain
- devops, infrastructure
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100