4

How can I troubleshoot it further? I am trying to run a simple nginx container but the load balancer complains that health checks are failed and the task does not respond on its ip number, likely because of the error with the load balancer.

I set the priority to 2 in cloudformation for the task. If I try and set the priority to 1 then the CF stack fails to deploy. Can that have something to do with it?

# Create a rule on the load balancer for routing traffic to the target group
  LoadBalancerRule:
    Type: AWS::ElasticLoadBalancingV2::ListenerRule
    Properties:
      Actions:
        - TargetGroupArn: !Ref 'TargetGroup'
          Type: 'forward'
      Conditions:
        - Field: path-pattern
          Values: [!Ref 'Path']
      ListenerArn: 
        Fn::ImportValue: !Ref LoadBalancerListener
      Priority: !Ref 'Priority'

The resources look like:

Resources:

  # The task definition. This is a simple metadata description of what
  # container to run, and what resource requirements it has.
  TaskDefinition:
    Type: AWS::ECS::TaskDefinition
    Properties:
      Family: nginx
      Cpu: 256
      Memory: 512
      NetworkMode: awsvpc
      RequiresCompatibilities:
        - FARGATE
      ContainerDefinitions:
        - Name: nginx
          Cpu: 128
          Memory: 256
          Image: nginx
          PortMappings:
            - ContainerPort: 80

  Service:
    Type: AWS::ECS::Service
    DependsOn: LoadBalancerRule
    Properties:
      ServiceName: !Ref 'ServiceName'
      Cluster: 
        Fn::ImportValue: !Ref EcsCluster
      LaunchType: FARGATE
      DeploymentConfiguration:
        MaximumPercent: 200
        MinimumHealthyPercent: 75
      DesiredCount: !Ref 'DesiredCount'
      NetworkConfiguration:
        AwsvpcConfiguration:
          AssignPublicIp: ENABLED
          SecurityGroups: 
            - !Ref EcsHostSecurityGroup
          Subnets:
            - !ImportValue core-vpc-PublicSubnet1AID
            - !ImportValue core-vpc-PublicSubnet1BID
      TaskDefinition: !Ref 'TaskDefinition'
      LoadBalancers:
        - ContainerName: !Ref 'ServiceName'
          ContainerPort: 80
          TargetGroupArn: !Ref TargetGroup

  TargetGroup:
    Type: AWS::ElasticLoadBalancingV2::TargetGroup
    Properties:
      HealthCheckIntervalSeconds: 6
      HealthCheckPath: /
      HealthCheckProtocol: HTTP
      HealthCheckTimeoutSeconds: 5
      HealthyThresholdCount: 2
      TargetType: ip
      Name: !Ref 'ServiceName'
      Port: !Ref 'ContainerPort'
      Protocol: HTTP
      UnhealthyThresholdCount: 2
      VpcId: !ImportValue core-vpc-VPCID



  # This security group defines who/where is allowed to access the ECS hosts directly.
  # By default we're just allowing access from the load balancer.  If you want to SSH
  # into the hosts, or expose non-load balanced services you can open their ports here.
  EcsHostSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      VpcId: !ImportValue core-vpc-VPCID
      GroupDescription: Access to the ECS hosts and the tasks/containers that run on them
      SecurityGroupEgress:
        - CidrIp: 0.0.0.0/0
          IpProtocol: "-1"
      SecurityGroupIngress:
      - IpProtocol: tcp
        FromPort: '443'
        ToPort: '443'
        CidrIp: 138.106.0.0/16

# Create a rule on the load balancer for routing traffic to the target group
  LoadBalancerRule:
    Type: AWS::ElasticLoadBalancingV2::ListenerRule
    Properties:
      Actions:
        - TargetGroupArn: !Ref 'TargetGroup'
          Type: 'forward'
      Conditions:
        - Field: path-pattern
          Values: [!Ref 'Path']
      ListenerArn: 
        Fn::ImportValue: !Ref LoadBalancerListener
      Priority: !Ref 'Priority'
2

You did not include the actual Load Balancer in your template. Please include that, for a full answer.

Your problem is most likely that your Load Balancer - which most likely has a private IP in your subnets and communicates with that - is not allowed to communicate with your ECS instances, since they allow only traffic from 138.106.0.0/16.

| improve this answer | |
0

For others, who might be facing the same issue:

It might be an issue with the route that you configured for health-check.

Your configured route should return a success response(status : 200) on GET call.

If "/" is the route you configured for health-check, please make sure you GET call to yourwebsitename.com/ returns a 200 status code.

Similarly, If "/health-check" you configured for health-check, please make sure you GET call to yourwebsitename.com/health-check returns a 200 status code.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.