摘录

MAR 22 Proxy all the Containers! In the continuing struggle to get my version of sane applied to the docker containers, I've moved through a number of different configurations for setting proxies. To recap:

  • ENV http_proxy - works, but only on the host that has the proxy, will break if the proxy doesn't exist (ie. non-portable Dockerfile).
  • Dynamic/conditional http_proxy setting - can't do it - ENV doesn't allow execution of code as far as I can see, and RUN won't let you set an environment variable - and you can't reference host environment in the Dockerfile. So there's no way to make the setting of the http_proxy ENV variable conditional on the host environment (even though I'd argue strongly that this is useful).
  • "-e" on build - again, the docker community has seemingly decided that this leads to images built differently on different servers, and should therefore not be allowed. I contend this is a mistake - http_proxy in particular is more about the host environment than the containers, and allowing environment settings for build only is more useful than it is damaging. I note, it's already possible to affect the build from the host - try playing with --dns on the docker daemon to return the values you want, for instance, or using iptables (more on that below). Why DNS settings are considered less impactful on the container than proxy settings, I don't know.

apt-get has a special undocumented setting that will allow for calling a script every time you do an apt-get command, to determine whether to use the proxy or not. This is perfect, for apt-get (and you can see it in action at https://github.com/silarsis/personal_dev/blob/master/docker/base/Dockerfile. Unfortunately, it only works for apt-get, not for anything else.

So, finally, I come to iptables (with much sadness). The basic approach here is to run a proxy server in transparent proxy mode, and use iptables to redirect all web requests coming over the docker0 interface to it. Then it's just a matter of tuning the caching configuration to play nicely with your various package repositories - apt, npm, gem, rpm, etc.

Ideally we'd also run the proxy in it's own container - if for no other reason than it makes it easy to swap between different proxies to try things out. However, that means we'll have to exempt that container from the iptables rule, so it can do web traffic. A minor wrinkle, but worth remembering. More importantly, this is essentially equivalent to running a firewall redirecting traffic to a separate machine on your network doing NAT. This actually doesn't really work - if you NAT your outbound traffic over to the proxy server, the proxy server has no idea where you were headed in the first place. So, we need to get cunning.

点评

NULL

原文

点击这里查看原文

其它

本帖内容由21QA云收藏工具自动生成,欢迎使用。

系统消息 若觉得内容不错,请点击左上角的"赞"图标,以优化网站的内容呈现。 另外,请及时验证注册邮箱,否则收不到21QA发出的红包。 官方Q群:250203055

asked 11 Mar '17, 15:25

%E8%B7%AF%E4%BA%BA%E7%94%B2's gravatar image

路人甲
131615768887

Be the first one to answer this question!
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link: [text](http://url.com/ "title")
  • image: ![alt](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×894
×36

question asked: 11 Mar '17, 15:25

question was seen: 553 times

last updated: 11 Mar '17, 15:25

powered by O*S*Q*A

粤ICP备14040061号-1