最近，我为 Ruby 应用程序设置了一些部署脚本，我希望服务器能够处理 SSL 终止。
在“旧”时代，我会使用反向代理设置 Caddy，如下所示：
# Caddyfile
yourdomain.com {
reverse_proxy localhost:3000
tls
}
除此之外，我通常会运行 Caddy 作为 docker-compose.yml 文件中的依赖项之一，以便更轻松地安装和重新安装所有内容。
最近，Basecamp 发布了一个简单的反向代理服务器，它可以处理我在名为 Thruster 的 gem 中提供 Ruby 应用程序所需的一切。
根据 GitHub 存储库，以下是该服务器带来的内容：
对于 99% 的用例，这完全符合要求。最重要的是，我可以在与我的 Ruby 应用程序相同的容器中运行此。这意味着我不需要单独的容器来运行 Caddy。
配置几乎真实的。
实际上，您仍然需要（至少）向 Thruster 指定您希望它为哪些域请求 SSL 证书。这是通过环境变量 TLS_DOMAIN 完成的。
这样做的好处是可以指定多个域，因此 Thruster 可以自动为每个域请求正确的 Let's Encrypt 证书。
例如，如果我的应用程序从domain1.com 和domain2.com 提供服务，我可以将其指定为TLD_DOMAIN=domain1.com,domain2.com，Thruster 会很好地选择它。
运行推进器
例如，如果您使用 Rails，通常会输入 bin/rails server。
推进器的修改将是推力箱/rails 服务器。
我觉得这就是
为什么我如此喜欢Thruster。对于 Caddy，我需要设置一个反向代理（通常需要使用那个该死的 Caddyfile 进行试验和错误）。使用 Thruster，我能够在 3-5 分钟内完成设置。
使用案例
对于 (3)，有一个特殊用例：自托管应用程序。换句话说，您的客户在自己的基础设施上运行 Ruby 应用程序，并且他们是安装该应用程序的人。
所描述的三个选项之间的区别在于，在情况（1）和（2）中，devops 人员很容易进入并重新配置事物。
当向客户提供 Docker 映像（可能是最常见的情况）以进行自我托管时，有很多事情可能会出错。
例如，客户可能不熟悉管理自己的服务器。或者客户可能不想摆弄反向代理来使事情正常进行。
在这些情况下，更容易移交一个“正常工作”的 Docker 容器。
我在开发自托管电子邮件营销软件时遇到了这个问题，幸运的是 Thruster 可用。
当我将所有内容打包到容器中并提供 docker-compose.yml 文件时，这也将我的容器依赖项从 4 个减少到 3 个，从而无需运行 nginx 或 Caddy。
Thruster 是处理 Ruby 应用程序反向代理的一个非常好的替代方案。
其简单的“无配置”选项使其在许多场景下都能很好地工作。
对于我自己来说，当打包需要在我无法控制的环境中运行的 Ruby 应用程序（即客户计算机上的自托管应用程序）时，这就是要走的路。
以上是将 Thruster Web 服务器用于 Ruby 应用程序的详细内容。更多信息请关注PHP中文网其他相关文章！
