Из рубрик #error + #issue. Пренеприятная проблема была получена при попытке срочного разворота важного окружения. В процессе подъёма #autoscaling_group для #ecs_cluster с несколькими рабочими нодами и сервисами на них с важным моментом - docker image лежит не в ECR, а в #private_docker_hub, то на давно отрепетированном сценарии (правда лишь с одной нодой) вылезла страннейшая ошибка - вторая (!) нода не могла загрузить контейнер. Т.е. первая грузила и успешно работала, а вторая (такая же, этот же образ) - зависала на ошибке:

STOPPED (CannotPullContainerError: API error (404): pull ac)

Не получив образ по таймауту срабатывал откат. Ошибка нерегулярная, т.к. с энной попытки получалось задеплоить и успешно работать. Либо поставить одну ноду - и тогда ни разу не было такой ошибки.
Гуглинг показал, что у такой же ошибки есть братья по разуму, где, судя по всему, такая ситуация возникала именно в связке докерхаб + новый #ecs_agent. И в данном случае он как раз был обновлён. потому наверняка это одна из причин.
После детального изучения выяснилось, что в результате, видимо, каких-то неадекватных лагов с отдачей второго образа, амазоновская команда для подключения в #autoscalig_group:

/opt/aws/bin/cfn-signal -e $? --stack ${AWS::StackName} --resource autoscalingGroup --region ${AWS::Region}

вылетала в ошибку и расположенный за ней код не исполнялся! И если, как в моём случае, именно после этой команды задавалась переменная ECS_ENGINE_AUTH_DATA для авторизации на докере, то, получается, она не попадала в ecs.config и агент после никак не мог получить доступ к приватному репозиторию.
Изменения последовательности команд - решило проблему. При чём важно учесть, что есть и другие команды, которые обладают таким поведением, потому важный код помещаем в начало #UserData, а проблемные - в самый конец и с учётом важности:
/opt/aws/bin/cfn-signal -e $? --stack ${AWS::StackName} --resource autoscalingGroup --region ${AWS::Region}
stop ecs
start ecs

Завести #external (internet-facing/#public) #LoadBalancer (#ELB/#ALB/#NLB) на расположенные в #private #subnet виртуалки никаких проблем нет. Просто указываем для него, как и положено, #DMZ #subnet (#public):

albExt:
  Type: AWS::ElasticLoadBalancingV2::LoadBalancer
  Properties:
    Name: externalAlb
    Scheme: internet-facing
    Subnets: # DMZ if public
      - !ImportValue subnetVpc4DmzA
      - !ImportValue subnetVpc4DmzB
    SecurityGroups:
      - !Ref sgAlb

А виртуалкам, расположенным и в #private_subnet добавляем в #security_group правила полного доступа с данного балансера:

sgInstance:
  Type: AWS::EC2::SecurityGroup
  Properties:
    VpcId: !ImportValue vpc4
    GroupDescription: Full access for ALB
    SecurityGroupIngress:
      - IpProtocol: tcp
        FromPort:   0
        ToPort:     65535
        SourceSecurityGroupId: !Ref sgAlb
        Description: All TCP trafic - only for ALB

#CloudFormation #templates

​​Обнаружив ошибку CannotPullContainerError в логах CodeBuild:

Unable to pull customers container image: toomanyrequests. You have reached your pull rate limit.
You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit (status code: BUILD_CONTAINER_UNABLE_TO_PULL_IMAGE)

Которая обозначает, что превышен лимит для вытягивания публичных образов из докерхаба, то решить вопрос можно, добавив аутентификацию:

https://aws.amazon.com/blogs/devops/how-to-use-docker-images-from-a-private-registry-in-aws-codebuild-for-your-build-environment/

Для чего потребуется создать секрет, прописав его ARN в CodeBuild. Для получения секрета нужно добавить сервисной роли права на secretsmanager:GetSecretValue:

https://docs.aws.amazon.com/codebuild/latest/userguide/sample-private-registry.html#private-registry-sample-create-project

#CodeBuild