ALB Health проверяет цели нездоровые - PullRequest
Новая
       102

ALB Health проверяет цели нездоровые

0 голосов
/ 15 января 2020

Я пытаюсь подготовить кластер ECS, используя Terraform вместе с ALB. Цели появляются как Unhealthy. Код ошибки 502 в консоли Health checks failed with these codes: [502] Я проверил руководство по устранению неисправностей AWS и там ничего не помогло.

РЕДАКТИРОВАТЬ: у меня нет служб / задач, работающих на контейнерах EC2. Это ванильный кластер ECS.

Вот мой соответствующий код для ALB: 

# Target Group declaration 

resource "aws_alb_target_group" "lb_target_group_somm" {
  name                 = "${var.alb_name}-default"
  port                 = 80
  protocol             = "HTTP"
  vpc_id               = "${var.vpc_id}"
  deregistration_delay = "${var.deregistration_delay}"
  health_check {
    path     = "/"
    port     = 80
    protocol = "HTTP"
  }

  lifecycle {
    create_before_destroy = true
  }

  tags = {
    Environment = "${var.environment}"
  }

  depends_on = ["aws_alb.alb"]
}

# ALB Listener with default forward rule

resource "aws_alb_listener" "https_listener" {
  load_balancer_arn = "${aws_alb.alb.id}"
  port              = "80"
  protocol          = "HTTP"

  default_action {
    target_group_arn = "${aws_alb_target_group.lb_target_group_somm.arn}"
    type             = "forward"
  }
}

# The ALB has a security group with ingress rules on TCP port 80 and egress rules to anywhere. 
# There is a security group rule for the EC2 instances that allows ingress traffic to the ECS cluster from the ALB: 

resource "aws_security_group_rule" "alb_to_ecs" {
  type                     = "ingress"
  /*from_port                = 32768 */
  from_port                = 80
  to_port                  = 65535
  protocol                 = "TCP"
  source_security_group_id = "${module.alb.alb_security_group_id}"
  security_group_id        = "${module.ecs_cluster.ecs_instance_security_group_id}"
}

Кто-нибудь сталкивался с этой ошибкой и знает, как ее отладить / исправить?

Ответы [ 2 ]

1 голос
/ 15 января 2020

Похоже, вы пытаетесь зарегистрировать экземпляры кластера ECS в целевой группе ALB. Это не то, как вы должны отправлять traffi c в службу ECS через ALB.

Вместо этого вам нужно, чтобы ваша служба объединила задачи с целевой группой. Это будет означать, что если вы используете хост-сеть, то будут зарегистрированы только экземпляры с развернутой задачей. Если вы используете мостовую сеть, то он добавит временные порты, используемые вашей задачей, в вашу целевую группу (в том числе допускает наличие нескольких целей в одном экземпляре). И если вы используете awsvpc сеть, то он будет регистрировать ENI каждой задачи, которую запускает служба.

Для этого вам следует использовать блок load_balancer в ресурсе aws_ecs_service . Пример может выглядеть примерно так: 

resource "aws_ecs_service" "mongo" {
  name            = "mongodb"
  cluster         = "${aws_ecs_cluster.foo.id}"
  task_definition = "${aws_ecs_task_definition.mongo.arn}"
  desired_count   = 3
  iam_role        = "${aws_iam_role.foo.arn}"

  load_balancer {
    target_group_arn = "${aws_lb_target_group.lb_target_group_somm.arn}"
    container_name   = "mongo"
    container_port   = 8080
  }
}

Если бы вы использовали мостовую сеть, это означало бы, что задачи доступны в диапазоне временных портов на экземплярах, поэтому правило группы безопасности должно выглядеть следующим образом. : 

resource "aws_security_group_rule" "alb_to_ecs" {
  type                     = "ingress"
  from_port                = 32768 # ephemeral port range for bridge networking tasks
  to_port                  = 60999 # cat /proc/sys/net/ipv4/ip_local_port_range
  protocol                 = "TCP"
  source_security_group_id = "${module.alb.alb_security_group_id}"
  security_group_id        = "${module.ecs_cluster.ecs_instance_security_group_id}"
}
0 голосов
/ 15 января 2020

похоже, что http://ecsInstanceIp:80 не возвращается HTTP 200 OK. Я бы проверил это в первую очередь. Было бы легко проверить, является ли экземпляр publi c. Это не будет иметь место в большинстве случаев. В противном случае я бы создал экземпляр EC2 и сделал бы запрос curl, чтобы подтвердить это.

Вы также можете проверить журналы контейнера, чтобы увидеть, регистрирует ли он ответ проверки работоспособности.

Надеюсь, это поможет. удачи.

...