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 组进行配置，并在需要时扩大规模，在完全安静时缩小规模。