#issue При обновлении #AMI для #ECS Autoscaling group через шаблон - есть проблема для действующих #prod систем. #CloudFormation не учитывает скорости деплоя убиваемых докеров (#task_definition) - новые инстансы (с обновлённым AMI) поднимаются очень быстро и как только они становятся доступными, предыдущие (ещё работающие с набитыми докерами) тупо терминируются. В результате появляется #downtime - пока на поднявшиеся новые инстансы задеплоятся убитые вместе с инстансами докеры.

Обсуждение этой проблемы на Reddit.

Из рубрик #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

При конструировании DNS для #s3 бакет нужно быть максимально внимательным - неоднозначное толкование официальной документации, где говорится про «you can use either of these endpoints» в реальности может давать различные проблемы.
С одной стороны, используя вариант с

.s3.amazonaws.com

даёт в результате перенаправление, а значит изначально #error #307 и лишь потом нужный файл/страницу. Это может приводить к некорректной работе критическим к такому поведению вещей. Например, когда через s3 бакеты подтягиваются конфиг-файлы #nginx, то такое поведение даст ошибку «unexpected end of file, expecting ";" or "}" in /etc/nginx/conf.d/...», т.к. получив 307 он не будет делать ещё один запрос по новому location из ответа. Потому правильно использовать именно вариант типа:

!Join ['',[!Ref Bucket, '.s3-', !Ref 'AWS::Region' , '.amazonaws.com' ]]

Однако бывает и противоположная ситуация, например, с регионом N.Virginia. Для #CloudFront #Origin (в том числе для Logging бакета) DomainName вариант bucket.s3-us-east-1.amazonaws.com даёт стабильные #error 502 для #distribution. Правильный вариант с bucket.s3.amazonaws.com:

Origins:
  - DomainName: !Join ['',[!Ref Bucket, '.s3.amazonaws.com' ]]

#issue

Использование #Lambda в #VPC сильно замедляет её старт, точней очень сильно (10 секунд плюс). #issue

И ещё про такую же #issue — #API_Gateway + #lambda + #vpc #performance.

Бывает, что, казалось бы, банальное копирование файлов в #s3 бакет:

aws s3 cp ./ s3://some-bucket/files --recursive

Когда это происходит из другого аккаунта, когда бакет расположен в другом регионе или с локального компьютера (между бакетами и т.п. не самые ординарные случаи), даёт странный эффект (#issue) — всё благополучно копируется, но после сам владелец бакета с админскими правами не может получить скопированное, получая #error:

An error occurred (AccessDenied) when calling the GetObject operation: Access Denied

И даже через консоль получаем ошибку доступа к файлам:

This XML file does not appear to have any style information associated with it. The document tree is shown below.
<Error> <Code>AccessDenied</Code> <Message>Access Denied</Message>...

Причина - у Owner-а бакета нет никаких прав на записанное (картинка ниже).
Чтобы исправить — повторяем копирование на источнике с добавлением нужных #ACL #permissions с помощью ключика --acl bucket-owner-full-control, который сразу обеспечит каждому объекту нужные права.

aws s3 cp ./ s3://some-bucket/files --recursive --acl bucket-owner-full-control

[​​](https://telegra.ph/file/b7ccedaea5085a104cd05.jpg)Будь наготове

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

Деньги-то она может поедать, но вот жить (вечно) - вопрос (маловероятно). Например, случившаяся на эти выходные ситуация - на картинке снизу.

В Амазоне что-то резко деградировало (читай - издохло) и виртуалка зависла в неопределённом состоянии. Хотя определённо не работала (нельзя зайти и не работают сервисы). Перезагрузить-остановить невозможно, только удалить.

Чтобы ваша забытая в дальнем аккаунте виртуалка бесконечно не жрала деньги, она самим Амазоном будет прибита через пару недель. Так что если вы не практикуете централизованный мониторинг, то о пропаже какой-то своей апишки вы можете узнать лишь спустя большое время и потом будете винить неизвестного админа или злобных хакеров, что убили без спросу виртуалку.

Отсюда вывод — используйте мониторинг и автоскелинг. Одна виртуалка - дёшево, но для прода крайне опасно. Шансы не самые большие, но на моей практике — раз в один-два года на каждом проекте случаются (как на картинке).

#ec2 #degradation #retirement #issue

Летне-временной баг закрыт

Бывают баги, которые можно проверить (и словить) лишь раз в году. Намедни заокеанские коллеги переводили стрелки и до этого года постоянно страдали от неработающего MFA в этот "час сурка" (стрелки переводятся назад и потому дважды наступает час ночи).

https://github.com/aws/aws-cli/issues/1611

Так что стоит учитывать и такие ситуации, ежели у вас чего-то странного происходило в это время.

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

#issue #closed

⁠bare metal инстансы + AWS Console

Когда вы хотите выбрать bare metal инстансы (i3 или или другие *.metal), чтобы, например, соблюсти какие-то жёсткие требования для вашего окружения, то при выборе в консоли по-прежнему обнаружите менюшку Tenancy и Shared по умолчанию.

Ничего такого в реальности нет, никакие Shared неприменимы к bare metal типу инстансов, вы полностью работаете напрямую с железом, без гипервизоров (потому можно запустить свою виртуализацию, что не позволяют другие типы инстансов - на них не получится запустить условный Virtual Box, только на bare metal) и без каких-то "соседей".

Недоработка текущей версии AWS Console.

#AWS_Console #bare_metal #issue