сбой fargate при извлечении докера в частной подсети - PullRequest
Новая
       33

сбой fargate при извлечении докера в частной подсети

0 голосов
/ 21 ноября 2018

У меня проблемы с развертыванием кластера fargate, и он не работает на образе извлечения докера с ошибкой "CannotPullContainerError".Я создаю стек с облачной информацией, что не является обязательным, и он создает полный стек, но не удается при попытке запуска задачи на основе вышеуказанной ошибки.

Я приложил файл стека облачной информации, который мог бы выделить проблему, и я дважды проверил, что в подсети есть маршрут к nat (ниже).Я также ssh'ed в экземпляр в той же подсети, которая была в состоянии маршрутизировать извне.Мне интересно, если я не правильно разместил необходимые части, то есть service + loadbalancer находятся в частной подсети, или я не должен размещать внутренний фунт в той же подсети ???

В этой подсети в настоящее время размещено, но все 3 в файле имеют одинаковые настройки nat.

маршрутизируемая подсеть (subnet-34b92250) * 0.0.0.0/0 -> nat-05a00385366da527a

приветствует заранее.

скрипт создания облака yaml: 

AWSTemplateFormatVersion: 2010-09-09
Description: Cloudformation stack for the new GRPC endpoints within existing vpc/subnets and using fargate
Parameters:
  StackName:
    Type: String
    Default: cf-core-ci-grpc
    Description: The name of the parent Fargate networking stack that you created. Necessary
  vpcId:
    Type: String
    Default: vpc-0d499a68
    Description: The name of the parent Fargate networking stack that you created. Necessary
Resources:
  CoreGrcpInstanceSecurityGroupOpenWeb:
    Type: 'AWS::EC2::SecurityGroup'
    Properties:
      GroupName: sgg-core-ci-grpc-ingress
      GroupDescription: Allow http to client host
      VpcId: !Ref vpcId
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: '80'
          ToPort: '80'
          CidrIp: 0.0.0.0/0
      SecurityGroupEgress:
        - IpProtocol: tcp
          FromPort: '80'
          ToPort: '80'
          CidrIp: 0.0.0.0/0
  LoadBalancer:
    Type: 'AWS::ElasticLoadBalancingV2::LoadBalancer'
    DependsOn:
      - CoreGrcpInstanceSecurityGroupOpenWeb
    Properties:
      Name: lb-core-ci-int-grpc
      Scheme: internal
      Subnets:
      # # pub
      #   - subnet-f13995a8
      #   - subnet-f13995a8
      #   - subnet-f13995a8
      # pri
        - subnet-34b92250
        - subnet-82d85af4
        - subnet-ca379b93
      LoadBalancerAttributes:
        - Key: idle_timeout.timeout_seconds
          Value: '50'
      SecurityGroups:
        - !Ref CoreGrcpInstanceSecurityGroupOpenWeb
  TargetGroup:
    Type: 'AWS::ElasticLoadBalancingV2::TargetGroup'
    DependsOn:
      - LoadBalancer
    Properties:
      Name: tg-core-ci-grpc
      Port: 3000
      TargetType: ip
      Protocol: HTTP
      HealthCheckIntervalSeconds: 30
      HealthCheckProtocol: HTTP
      HealthCheckTimeoutSeconds: 10
      HealthyThresholdCount: 4
      Matcher:
        HttpCode: '200'
      TargetGroupAttributes:
        - Key: deregistration_delay.timeout_seconds
          Value: '20'
      UnhealthyThresholdCount: 3
      VpcId: !Ref vpcId
  LoadBalancerListener:
    Type: 'AWS::ElasticLoadBalancingV2::Listener'
    DependsOn:
      - TargetGroup
    Properties:
      DefaultActions:
        - Type: forward
          TargetGroupArn: !Ref TargetGroup
      LoadBalancerArn: !Ref LoadBalancer
      Port: 80
      Protocol: HTTP
  EcsCluster:
    Type: 'AWS::ECS::Cluster'
    DependsOn:
      - LoadBalancerListener
    Properties:
      ClusterName: ecs-core-ci-grpc
  EcsTaskRole:
    Type: 'AWS::IAM::Role'
    Properties:
      AssumeRolePolicyDocument:
        Statement:
          - Effect: Allow
            Principal:
              Service:
                # - ecs.amazonaws.com
                - ecs-tasks.amazonaws.com
            Action:
              - 'sts:AssumeRole'
      Path: /
      Policies:
        - PolicyName: iam-policy-ecs-task-core-ci-grpc
          PolicyDocument:
            Statement:
              - Effect: Allow
                Action:
                  - 'ecr:**'
                Resource: '*'
  CoreGrcpTaskDefinition:
    Type: 'AWS::ECS::TaskDefinition'
    DependsOn:
      - EcsCluster
      - EcsTaskRole
    Properties:
      NetworkMode: awsvpc
      RequiresCompatibilities:
        - FARGATE
      ExecutionRoleArn: !Ref EcsTaskRole
      Cpu: '1024'
      Memory: '2048'
      ContainerDefinitions:
        - Name: container-core-ci-grpc
          Image: 'nginx:latest'
          Cpu: '256'
          Memory: '1024'
          PortMappings:
            - ContainerPort: '80'
              HostPort: '80'
          Essential: 'true'
  EcsService:
    Type: 'AWS::ECS::Service'
    DependsOn:
      - CoreGrcpTaskDefinition
    Properties:
      Cluster: !Ref EcsCluster
      LaunchType: FARGATE
      DesiredCount: '1'
      DeploymentConfiguration:
        MaximumPercent: 150
        MinimumHealthyPercent: 0
      LoadBalancers:
        - ContainerName: container-core-ci-grpc
          ContainerPort: '80'
          TargetGroupArn: !Ref TargetGroup
      NetworkConfiguration:
        AwsvpcConfiguration:
          AssignPublicIp: DISABLED
          SecurityGroups:
            - !Ref CoreGrcpInstanceSecurityGroupOpenWeb
          Subnets:
            - subnet-34b92250
            - subnet-82d85af4
            - subnet-ca379b93
      TaskDefinition: !Ref CoreGrcpTaskDefinition

Ответы [ 2 ]

0 голосов
/ 21 ноября 2018

К сожалению, AWS Fargate поддерживает только изображения, размещенные в ECR или общедоступных репозиториях в Docker Hub, и не поддерживает частные репозитории, размещенные в Docker Hub.Для получения дополнительной информации - https://forums.aws.amazon.com/thread.jspa?threadID=268415

Даже мы столкнулись с той же проблемой, используя AWS Fargate пару месяцев назад.У вас есть только два варианта:

  1. Перенос ваших изображений в Amazon ECR.

  2. Использование пакета AWS с пользовательским AMI, где пользовательский AMIсоздается с использованием учетных данных Docker Hub в конфигурации ECS (которую мы сейчас используем).

0 голосов
/ 21 ноября 2018

Определите эту политику в своем реестре ECR и присоедините роль IAM к своей задаче. 

{
    "Version": "2008-10-17",
    "Statement": [
        {
            "Sid": "new statement",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::99999999999:role/ecsEventsRole"
            },
            "Action": [
                "ecr:GetDownloadUrlForLayer",
                "ecr:BatchGetImage",
                "ecr:BatchCheckLayerAvailability",
                "ecr:PutImage",
                "ecr:InitiateLayerUpload",
                "ecr:UploadLayerPart",
                "ecr:CompleteLayerUpload"
            ]
        }
    ]
}
...