我们有一个在 RHEL 6.6 上运行的稍旧的 Docker 服务器。现在我们的运营团队没有很好地支持它，所以我们不能轻易升级。现在它从 EPEL 存储库运行 Docker 1.3.2。如果我通过 ssh 来完成概念验证所需的一切，这将有望帮助我推动管理以改进对 Docker 的基础设施支持。
我将它设置为侦听 TCP/TLS，并且我能够连接到它，但它拒绝运行我的本地 docker 客户端给出的命令。
$ docker version
Client version: 1.4.1
Client API version: 1.16
Go version (client): go1.4
Git commit (client): 5bc2ff8
OS/Arch (client): darwin/amd64
FATA[0000] Error response from daemon: client and server don't have same version (client : 1.16, server: 1.15)
我知道连接本身有效，因为fig有效：
$ cat > fig.yml
test:
image: busybox
$ fig run --rm test sh
/ # hostname -f
084f75fb59d4
有什么方法可以告诉较新的 docker 客户端使用较旧的 …
（我的问题并不是关于 Django。而是关于替代的 http 端口。我只是碰巧知道 Django 是一个相对著名的应用程序，默认情况下使用 8000，所以它是说明性的。）
我在野外有一个开发服务器，我们偶尔需要在不同的端口上运行多个 httpd 服务。当我需要启动第三个服务并且我们已经在使用端口 80 和 8080 时，我发现我们的安全团队已经锁定了来自 Internet 的端口 8000 访问。我知道端口 80 是标准的 http 端口，而 8080 通常是 http_alt，但我想向我们的安全团队提出案例，也开放 8000。为了证明这一点，我希望这个问题的答案可以为我提供在某些情况下使用 8000 端口而不是 8080 端口的合理论据。
还是只是一个没有意义的随机选择？
我们运行多个 Web 应用程序，一些仅用于内部，一些内部/外部。我正在提出一个建议，即我们使用反向代理服务器来隔离源服务器、提供 SSL 终止和（如果可能）提供负载平衡。对于我们的大部分设置，我相信它会很好地工作，但是我们确实有一些鲜为人知的专有应用程序，当我们继续进行反向代理时可能需要特殊处理。
在将源服务器从前线转移到代理后时，哪些类型的陷阱会导致问题？（例如，如果应用程序需要知道传入请求的 IP 地址，我可以想象问题。）