Skip to content

Enhancement: add proxy configuration to contexts #1621

@thaJeztah

Description

@thaJeztah

The docker cli allows configuring proxy servers to be used when creating containers (I don't think services/stacks currently use this feature, but that could be something to consider). This feature was implemented in #93 (Docker 17.07).

The existing feature allows you to define which proxies should be used for a specific connection

For example, the following example defines which proxies to use when deploying a container on development.corp.example.com or production.corp.example.com, but on any other connection ( default), no proxies will be used.

{
  "proxies": {
    "default": {
    },
    "tcp://development.corp.example.com:2376": {
      "HTTPProxy" :"http://dev-proxy.example.com:3128",
      "HTTPSProxy" :"https://user:password@dev-proxy.example.com:3129",
      "FTPProxy" :"http://dev-ftpproxy.example.com:21",
      "NoProxy" :"*.intra.example.com",
    },
    "tcp://production.corp.example.com:2376": {
      "HTTPProxy" :"http://proxy.example.com:3128",
      "HTTPSProxy" :"https://user:password@proxy.example.com:3129",
      "FTPProxy" :"http://ftpproxy.example.com:21",
    }
  }
}

Now that we have contexts, there's two separate locations to maintain configuration for environments;

  • define a context for the development.corp.example.com and production.corp.example.com connections
  • define which proxies to use for each in the ~/.docker/config.json

Proposal

Extend the context spec to support proxy-configurations per context. This will not only solve the issue mentioned above, but also allows (e.g.) and administrator to provide a .context file, containing the correct proxy-configuration that a user should use.

Note perhaps there are other configurations to consider in future (perhaps default labels to apply to containers, or even default memory or cpu constraints). When designing this feature (where to put it in the context), I think it would be good to take future expansion into account (e.g. a defaults section under which more container-configurations can be added, but also if those defaults apply to containers, services (or both)

We should also consider what to do with the existing configuration in ~/.docker/config.json; we can deprecate the "per host" setting (still support it, but add a note that docker context is the future direction if we feel that's the case)

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions