
在开发过程中使用Docker已成为事实上的标准。 仅使用一个命令来启动具有所有依赖项的应用程序变得越来越普遍。 如果应用程序使用Web界面或某些HTTP API提供访问权限,则最有可能的是,前线容器通过将其与容器中的应用程序进行交互来将其唯一的端口(以及您正在并行开发的其他应用程序)端口转发给主机。 。
直到您拥有整个应用程序动物园为止,这种方法都可以正常工作,因为您需要记住方案和端口以及在某个位置修复曾经为哪个应用程序分配过哪些端口的应用程序,在它们之间进行切换会带来一些不便随着时间的推移发生了碰撞。
然后,您还想检查https上的工作-您必须使用根证书,或者始终使用curl --insecure ...
,并且当各种命令在应用程序上运行时,对的数量开始呈指数增长。
再次面对这样的问题-我的脑海里闪过一个念头,“停下来!”,而在两个周末的工作成果就是解决了这个问题的服务,将在下面进行描述。 对于急躁的人,传统上是参考 。
世界 我们将保存反向代理
以一种好的方式,我们需要某种类型的域区域,即本地主机将始终从中解析的所有子域(127.0.0.1)。 快速搜索指向*.localho.st
, *.lvh.me
, *.vcap.me
等域,但是如何为它们附加有效的SSL证书? 修补了我的根证书后,我设法获得了curl
错误,但并非所有浏览器都正确接受了curl
,并继续引发错误。 另外-我真的不想使用SSL进行“混乱”。
“好吧,让我们走到另一边!” -然后购买了一个名称为localhost.tools
的域,并委派给CloudFlare,配置了所需的解析度(所有子域都解析为127.0.0.1
):
$ dig foo.localhost.tools | grep -v '^;\|^$' foo.localhost.tools. 190 IN A 127.0.0.1
然后,在容器中启动certbot ,该容器在使用DNS记录从CF接收到KEY API时,确认域所有权并在输出中颁发有效的SSL证书:
$ docker run \ --entrypoint="" \ -v "$(pwd)/cf-config.conf:/cf-credentials:ro" \ -v "$(pwd)/cert:/out:rw" \ -v "/etc/passwd:/etc/passwd:ro" \ -v "/etc/group:/etc/group:ro" \ certbot/dns-cloudflare:latest sh -c \ "certbot certonly \ --dns-cloudflare \ --dns-cloudflare-credentials '/cf-credentials' \ -d '*.localhost.tools' \ --non-interactive \ --agree-tos \ --email '$CF_EMAIL' \ --server 'https://acme-v02.api.letsencrypt.org/directory' \ && cp -f /etc/letsencrypt/live/localhost.tools/* /out \ && chown '$(id -u):$(id -g)' /out/*"
文件./cf-config.conf
包含CF上的授权数据,有关更多详细信息,请参见certbot上的文档, $CF_EMAIL
随电子邮件发送的环境变量
好的,现在我们有了有效的SSL证书(即使是3个月,也仅适用于同一级别的子域)。 仍然需要学习如何在正确的容器中代理所有到达本地主机的请求。
Traefik在这里为我们提供帮助 (扰流板-它很漂亮)。 通过在本地启动它并通过卷将docker套接字转发到其容器,它可以将请求代理到具有必要docker label
的容器。 因此,我们不需要任何其他配置,除非开始为容器指定所需的标签(和docker网络,但在没有 docker-compose的情况下启动,尽管非常理想,但这不是必需的),我们想要通过域名和有效的SSL访问 !
完成所有这些操作后,灯光看到了一个带有此预配置的Traefik和通配符SSL证书的docker容器(是的,它是公共的)。
来自SSL的私有密钥在公共容器中?
是的,但是我认为这并不可怕,因为它位于始终解析本地主机的域区域中。 在这种情况下,MitM原则上没有多大意义。
证书变质怎么办?
只需重新启动容器即可拉出新图像。 该项目已配置CI,该CI会每月一次(此刻自动)每月一次更新证书并发布新图像。
我想试试看!
没有什么比这更容易了。 首先,请确保您的本地端口80
和443
空闲,然后执行以下操作:
现在我们可以测试:
$ curl -sS http://my-nginx.localhost.tools | grep Welcome <title>Welcome to nginx!</title> <h1>Welcome to nginx!</h1> $ curl -sS https://my-nginx.localhost.tools | grep Welcome <title>Welcome to nginx!</title> <h1>Welcome to nginx!</h1>
如您所见,它有效:)
说明文件存放在哪里?
不难猜测,所有内容都位于https://localhost.tools 。 此外,枪口是响应性的,并且可以查看反向代理守护程序是否在本地运行,并显示正在运行且可用于交互的容器列表(如果有)。
多少钱?
一点也不。 绝对是 为自己和我的团队完成了此任务后,我意识到它对其他开发人员/操作人员可能很有用。 而且,只有域名才需要花钱,其他所有东西都不需要付费。
PS该服务仍处于测试阶段,因此-如果发现任何缺点,错别字等 -只是在PM中涂鸦 。 指示集线器“编程”和“网站开发”,因为这种方法主要在这些行业中可能有用。