最近,我為 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中文網其他相關文章!