被 Terraform 折腾的那些日子（二）

前面提到，打算写几篇跟工作相关的系列技术文章。来记录那些为了不折腾而折腾的日子。

上一期送给自己的《倔强》，已在 全民K歌 上架。

从持续掉粉的情况来看，下一首《凉凉》已经在排练中了。

欢迎关注和监督我的练习进展。

之前的系列文章在这里：

被 Terraform 折腾的那些日子（一）

闲话少说，正文开始。

---

上一回，咱们说到，搞定了 Terraform AWS Provider 升级来支持 NLB TCP_UDP 协议后，需要将现有的 consul server 添加进 NLB target group，使得当请求过来时，NLB 知道将流量转发到哪里去。

关卡三：NLB 关联 target group

NLB 关联现有 consul server

使用 aws_lb_target_group_attachment 将现有的 consul server 添加进 NLB target group

So easy.

# add existing consul server to NLB target group
resource "aws_lb_target_group_attachment" "consul-a" {
  target_group_arn = "${aws_lb_target_group.consul_nlb_tg.id}"
  target_id        = "${aws_instance.consul-a.id}"
  port             = 8300
}

不过弄完去看了一眼 NLB，显示添加进去的 consul server 状态异常。

NLB 会通过检查 targets 机器的指定 heath check 端口（这里是 8300 端口），来判断是否处于正常状态。

不用想， security group 的问题。

不过，只有 ALB / ELB 才有 security group，NLB 是没有的。所以只能更改 target 机器对应的 security group。官方原话 是这样的：

If you're using a Network Load Balancer, update the security groups for your target instances, because Network Load Balancers do not have associated security groups.

但试了下，从 targets 机器 （consul server）上是可以 telnet NLB 8300 端口的。

面向 Google 编程，我是职业选手。

还是被机智的我从 ELB security-groups 里发现了蛛丝马迹。

需要在 consul 的 security group 里添加上 VPC CIDR，允许访问 TCP 8300 端口（使 NLB 可以进行健康检测 health check）

添加上以后，果不其然，target 机器都变成 healthy 健康状态了。

NLB 关联 ASG

接下来，需要把 NLB 和 ASG 关联起来，让 NLB 的 target group 指向 ASG （将来里面的 consul server 实例）。

因为 ASG 本身并不支持取到其 EC2 实例的 IP 地址。

所以笨办法是，使用 EC2 instances 的 data source，通过 tags 来得到 ASG 里的 instance IP。

data "aws_instances" "asg_consul_production" {
  depends_on = ["module.asg_consul_production"]

  instance_tags {
    Name = "asg-consul-production"
  }

  instance_state_names = ["running"]
}

接下来的步骤，就和上面已有的 consul server 一样，通过 aws_lb_target_group_attachment 方式，将 ASG 里的 机器 IP 添加进 NLB target group：

resource "aws_lb_target_group_attachment" "consul-asg" {
  count = "${length(data.aws_instances.asg_consul_production.ids)}"
  target_group_arn = "${aws_lb_target_group.consul_nlb_tg.id}"
  target_id        = "${data.aws_instances.asg_consul_production.ids[count.index]}"
  port             = 8300
}

不过，这里还有个问题：

当 ASG 为空，即里面没有任何 EC2 instance 时，上面两段代码都会出错。

因为 data source 会在返回结果为空时，会直接失败：https://github.com/hashicorp/terraform/issues/16380

我捋了捋一头秀发（就是这么自信），开启了一休哥的模式。

盏茶功夫，我感到镜片有光一闪而过。

当源头（NLB）行不通时，那就从目的地（ASG）考虑。

这么一找，还真让我发现有个现成的参数可以用 target_group_arns，直接在 ASG 里指定 NLB 的 target group 即可……

是的，就是这么简单（还是不够熟悉啊摔！）

module "asg_consul_production" {
  name                     = "consul-production"
  ...
  target_group_arns        = ["${aws_lb_target_group.consul_nlb_tg.id}"]
}

另外，多提一句需要注意的事项。

由于 consul 属于有状态的服务。所以在 ASG 配置时，需要避免异常时的重启。

比如这样：

关卡四：更新配置，重启 consul

到了这一步，按最开始的计划，DNS / NLB / ASG 都已状态妥当。

万事具备，只欠东风。

在其中一台 consul server 上，使用自定义的 DNS 替换了硬编码的 IP，然后重启 consul 生效。

我帅气地按下了回车。

consul[5818]: ==> Joining cluster...
consul[5818]: ==> read tcp AAAAA:51338->BBBBB:8301: read: connection reset by peer
consul.service: Main process exited, code=exited, status=1/FAILURE

如果有一首串烧可以形容我此刻的心情。

我想，应该是：

大约在冬季，

哗啦啦啦啦啦天在下雨，

冷冷的冰雨在脸上胡乱地拍。

上面是从 consul agent 查到的日志，agent 无法启动。

又查了一把 consul server 上的错误日志：

[ERR] consul.rpc: unrecognized RPC byte: 255 from=CCCCC:52988
[ERR] consul.rpc: unrecognized RPC byte: 9 from=CCCCC:57952

几番搜索无果。

作为面向 Google 和 StackOverflow 编程的熟练工种，我陷入了深深的沉思。

山重水复。

无路。

[欲知后事如何，且听下回分解]