AWS 彈性負載均衡器后面的 Jenkins 實例並啟用粘性

Question

我按照以下文檔創建了一個包含兩個 AWS Jenkins 實例的目標組。

https://www.jenkins.io/doc/tutorials/tutorial-for-installing-jenkins-on-AWS/

然后我創建了一個 ALB 並使用 Target Group 作為監聽器。

我使用了 Amazon ACM 並在我的 ALB 上啟用了 HTTPS。 我在 ALB DNS 名稱的 Route 53 中添加了一條 CNAME 記錄。

現在，當我嘗試使用 CNAME 登錄時，我觀察到以下情況

• 如果我的 TG 中有多個 EC2 實例，並且我繼續嘗試登錄，但它僅在第 3 次或第 4 次嘗試后成功。 這是什么原因？ 如何調試這個？ 我可以在 ELB 級別設置 Cloudwatch 日志來檢查嗎？

• 如果我的 TG 中只有一個 EC2 實例，那么登錄總是在第一次嘗試時成功。

• 如果我直接登錄到每個實例，我總是可以在第一次嘗試時登錄到它們。

• 另外，如果我在 TG 級別啟用粘性，那么即使我的 TG 中有兩個 EC2 實例，我也可以使用 CNAME 首次嘗試登錄嗎？ 為什么我必須啟用粘性及其影響？

有沒有辦法讓我知道我是否正在部署 web 應用程序（第 3 方，如 Jenkins），是否以及何時需要啟用粘性和執行此操作的副作用？

提前致謝。

Answer 1

負載均衡器將流量發送到 TG 中的一個 EC2 實例。 Jenkins 響應 session 令牌和 cookies 因此您的瀏覽器和服務器同步。

當只有 1 個實例時，所有流量都發送給它。 當有兩個或更多實例時，流量將依次發送到每個實例，這是典型的循環行為。

問題是 Jenkins Controller 不是可集群資源。 基本上 Jenkins A 不知道另一個 Jenkins 存在。

所以，發生的事情是登錄請求轉到 Jenkins A，它以 session 令牌響應，然后發生登錄重定向，您的瀏覽器發出儀表板頁面請求並發送 session 令牌，該請求被發送到 Jenkins B 立即否認對 session 令牌的所有了解，並將您彈回登錄頁面。

來自 Jenkins 的建議是擁有一個主實例和一個“熱”備用實例，當主實例出現故障時，該備用實例將聯機。

如果您正在運行集群以構建更多東西，那么您可能需要運行更多代理並將它們連接到 Controller，以便它們可以由 AutoScaling 組進行配置，並在需要時擴大規模，在完全安靜時縮小規模。