我按照以下檔案創建了一個包含兩個 AWS Jenkins 實體的目標組。
https://www.jenkins.io/doc/tutorials/tutorial-for-installing-jenkins-on-AWS/
然后我創建了一個 ALB 并將目標組用作偵聽器。
我使用了 Amazon ACM 并在我的 ALB 上啟用了 HTTPS。我在 Route 53 中為 ALB DNS 名稱添加了 CNAME 記錄。
現在，當我嘗試使用 CNAME 登錄時，我正在觀察以下情況
如果我的 TG 中有多個 EC2 實體并且我繼續嘗試登錄，但它僅在第 3 次或第 4 次嘗試后才成功。這是什么原因？如何除錯這個？我可以在 ELB 級別設定 Cloudwatch 日志來檢查嗎？
如果我的 TG 中只有一個 EC2 實體，那么登錄總是在第一次嘗試時成功。
如果我直接登錄到每個實體，我總是可以在第一次嘗試時登錄到它們。
此外，如果我在 TG 級別啟用粘性，那么即使我的 TG 中有兩個 EC2 實體，我也可以使用 CNAME 第一次嘗試登錄？為什么我必須啟用粘性及其影響？
有沒有辦法讓我知道我是否正在部署 Web 應用程式（如 Jenkins 之類的第三方），是否以及何時需要啟用粘性以及執行此操作的副作用？
提前致謝。
uj5u.com熱心網友回復：
負載均衡器將流量發送到 TG 中的 EC2 實體之一。Jenkins 使用會話令牌和 cookie 進行回應，因此您的瀏覽器和服務器是同步的。
當只有 1 個實體時，所有流量都發送給它。當有兩個或更多實體時，流量會依次發送到每個實體，這是典型的回圈行為。
問題是 Jenkins 控制器不是可集群的資源。基本上 Jenkins A 不知道另一個 Jenkins 的存在。
所以，發生的事情是登錄請求轉到 Jenkins A，它以會話令牌回應，然后登錄重定向發生，您的瀏覽器發出對儀表板頁面的請求并發送會話令牌，這個請求被發送到 Jenkins B 會立即否認會話令牌的所有知識并將您彈回登錄頁面。
Jenkins 的建議是有一個主實體和一個“熱”備用，當主實體出現故障時，它會上線。
如果您正在運行集群以構建更多東西，那么您可能需要運行更多代理并將它們連接到控制器，以便它們可以由 AutoScaling 組進行配置，并在需要時擴大規模，并在一切安靜時縮小。
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/454492.html
上一篇：詹金斯管道內的awk腳本