docker / docker/compose

Automatically add containers to no_proxy

Open
#11,433 5 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

kind/feature
Dominant language
Go
Stars
38.2k
Forks
5.8k
Avg merge
2d 14h
Merged PRs (30d)
55

Description

Description

When working with a proxy configured in docker config.json it automatically passes the proxy information to the created containers. The problem is that some projects using docker compose refer to containers via their hostname. With a proxy configured these connections can be sent to the proxy server rather than the expected container.

Since coordinating between multiple containers is most likely to occur within a compose project, and compose should be able to determine which containers are networked it would be nice if entries were automatically added to the NO_PROXY environment variables within the containers.

An example project where I encountered this behavior is https://github.com/ckan/ckan-docker which builds & runs fine out of the box on a non-proxied connection, but when a proxy is enabled ckan can't reach solr. I was able to add a few lines to the startup scripts to get past my issue, but it seems like a universal solution is feasible and would be better.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with Docker config.json proxy handling and the container startup scripts referenced in the report, then trace how Docker Compose determines networked service hostnames. Done means the relevant NO_PROXY environment variables include those reachable container names while existing proxy settings continue to work.

Written by the indexing model from the issue text.

Assessment

Tech stack
docker, docker-compose, go
Domain
devops, networking
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.