AWS 弹性负载均衡器背后的 Jenkins 实例并启用粘性

Jenkins instance behind AWS Elastic Load balancer and enable stickiness

我按照以下文档创建了一个包含两个 AWS Jenkins 实例的目标组。

然后我创建了一个 ALB 并使用目标组作为侦听器。

我使用了 Amazon ACM 并在我的 ALB 上启用了 HTTPS。我在 ALB DNS 名称的 Route 53 中添加了一条 CNAME 记录。

现在，当我尝试使用 CNAME 登录时，我观察到以下情况

如果我的 TG 中有多个 EC2 实例，我继续尝试登录，但仅在第 3 次或第 4 次尝试后才成功。这是什么原因？如何调试这个？我可以在 ELB 级别设置 Cloudwatch 日志来检查吗？
如果我的 TG 中只有一个 EC2 实例，那么第一次尝试登录总是成功。
如果我直接登录到每个实例，我总是可以在第一次尝试时登录到它们。
此外，如果我在 TG 级别启用 stickiness，那么即使我的 TG 中同时拥有两个 EC2 实例，我也可以使用我的第一次尝试登录别名记录？为什么我必须启用粘性及其影响？

有没有办法让我知道我是否正在部署 Web 应用程序（第 3 方，如 Jenkins），是否以及何时需要启用粘性以及执行此操作的副作用？

提前致谢。

负载均衡器将流量发送到 TG 中的一个 EC2 实例。 Jenkins 使用会话令牌和 cookie 进行响应，以便您的浏览器和服务器保持同步。

当只有 1 个实例时，所有流量都发送给它。当有两个或更多实例时，流量将依次发送到每个实例，这是典型的 round-robin 行为。

问题是 Jenkins 控制器不是可集群资源。基本上 Jenkins A 不知道其他 Jenkins 的存在。

所以，发生的事情是登录请求转到 Jenkins A，它以会话令牌响应，然后发生登录重定向，您的浏览器发出对仪表板页面的请求并发送会话令牌，这请求被发送到 Jenkins B，Jenkins B 立即否认会话令牌的所有知识并将您弹回登录页面。

Jenkins 的建议是拥有一个主实例和一个“热”备用实例，当主实例出现故障时，备用实例将联机。

如果您正在运行构建集群以构建更多东西，那么您可能需要运行更多代理并将它们连接到控制器，以便它们可以由 AutoScaling 组配置需要时放大，安静时缩小。