web-dev-qa-db-fra.com

AWS Fargate Tâche échoue aux chèques de santé de l'ELB

Comment puis-je le résoudre plus loin? J'essaie d'exécuter un simple conteneur Nginx, mais l'équilibreur de charge se plaint que des contrôles de santé sont échoués et que la tâche ne répond pas sur son numéro IP, probablement en raison de l'erreur avec l'équilibreur de charge.

J'ai défini la priorité à 2 dans Cloudformation pour la tâche. Si j'essaie de définir la priorité à 1, la pile CF ne parvient pas à déployer. Peut-il avoir quelque chose à voir avec ça?

# 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'

Les ressources ressemblent à:

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'
4
Niklas R.

Vous n'avez pas inclus l'équilibreur de charge réel de votre modèle. Veuillez inclure cela, pour une réponse complète.

Votre problème est très probable que votre équilibreur de charge - qui a probablement une adresse IP privée dans vos sous-réseaux et communique avec cela - n'est pas autorisé à communiquer avec vos instances ECS, car elles ne permettent que le trafic de 138.106.0.0/16.

2
M. Glatki

Pour d'autres, qui pourraient faire face au même problème:

Cela pourrait être un problème avec l'itinéraire que vous avez configuré pour la santé.

Votre itinéraire configuré doit renvoyer une success response(status : 200) sur OBTENIR appel.

Si "/" est l'itinéraire que vous avez configuré pour la santé de la santé, assurez-vous de vous assurer que vous OBTENEZ appel à yourwebsitename.com/ retourne un 200 code d'état.

De même, si "/health-check" Vous avez configuré pour le contrôle de santé, assurez-vous de vous assurer que vous OBTENEZ appel à yourwebsitename.com/health-check retourne un 200 code d'état.

0