Automatically add containers to no_proxy

[krakhead22]

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.

[ndeloof]

Within a compose application you access other services using service alias, don't you?
So you can just configure your compose file with environment set to declare NO_PROXY accordingly:

services:
  db: 
    (...)
  app:
    image: backend
    environment:
      - NO_PROXY=db

[krakhead22]

You are correct, adding the environment variable to the compose file solves the problem for this instance, but my point is that it would be nice if projects could work on proxy connection without having to modify the compose files (assuming the proxy was configured with docker). Docker provides a mechanism to populate proxy information to containers automatically, it would be nice if compose could complete the job so the user doesn't have to override/augment the NO_PROXY variable.

[ja-pavi]

Hi I'm a UT Austin student, and would like to work on this issue if possible!

[mikesir87]

I was recently helping someone troubleshoot an issue in which container-to-container communication was failing. I validated the containers were on the right networks and the right DNS names were being used. I even went into the troublesome container and validated DNS was resolving correctly. When I did a curl with verbose logging, that's when I found the issue... HTTP proxies!

What was going on was she had the HTTP_PROXY env var set that sent everything to their corporate proxy. But she also had no_proxy (as well as NO_PROXY) set to not forward localhost and a few other names. But, obviously, the container alias names were not there. So, when the app tried to connect to policy-engine, DNS resolved locally, but the request went out to the corporate proxy, which obviously couldn't be forwarded correctly.

Adding that this capability would have helped her, but I do recognize it would be a little brittle - what happens if you add another service later? You can't easily update the environment variables (without bouncing the container anyways).

Workaround

As a workaround, you can add aliases to each service that all fall under a bogus domain name and then add that wildcarded domain name to the no_proxy setting. Something like this...

services:
  app:
    networks:
      default:
        aliases:
          - app.dev.local
  db:
    networks:
      default:
        aliases:
          - db.dev.local

And then set no_proxy=.dev.local. Granted, there's no standard definition for how no_proxy can/should be used (GitLab did a great writeup on this a while back)