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

Если при использовании #pg_dump получаем #error схемы #topology

pg_dump: [archiver (db)] query failed: ERROR: permission denied for schema topology

или другого #PostGIS расширения для #Postgres #RDS, то нужно выполнить следующие спеллы:
1. Сменить владельца расширения #rdsadmin на #rds_superuser.
2. Сменить владельца объектов с помощью функции.
alter schema topology owner to rds_superuser;
CREATE FUNCTION exec(text) returns text language plpgsql volatile AS $f$ BEGIN EXECUTE $1; RETURN $1; END; $f$;
SELECT exec('ALTER TABLE ' || quote_ident(s.nspname) || '.' || quote_ident(s.relname) || ' OWNER TO rds_superuser;')
FROM (
SELECT nspname, relname
FROM pg_class c JOIN pg_namespace n ON (c.relnamespace = n.oid)
WHERE nspname in ('tiger','topology') AND
relkind IN ('r','S','v') ORDER BY relkind = 'S')
s;

При изменении #EBS с обычного на #iops, нужно учитывать, что эта операция может занять некоторое время (до 40 минут для 200ГБ), а вернуть обратно (на обычный) можно будет лишь через шесть часов, иначе #error:

Wait at least 6 hours between modifications per EBS volume.

Кроме того, операция возвращения будет ещё более длительной (раза в два дольше - до двух часов на 200ГБ).

Бывает, что, казалось бы, банальное копирование файлов в #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

Если свежесозданный #CloudFront отдаёт #error 307 при доступе в (также свежесозданный) бакет, находящийся не в дефолтном регионе (N.Virginia), то не стоит искать ошибку в вашем шаблоне — это лаг самого Амазона на создание DNS бакета в своём в регионе и тут придётся просто ждать (5-45 минут, в зависимости от текущего здоровья Амазона).
Когда он разродится, ошибка исчезнет сама (чтобы это увидеть быстрей - потребуется инвалидация кэша).

Ситуация не возникает по понятным причинам (время проходит и так), когда всё создаётся ручками. Чтобы как-то нивелировать проблему, желательно максимально разнести по времени процессы создания бакета и клаудфронта и/или, если окружение поднимается-удаляется (например, для тестов), то не удалять бакет (пустой бакет денег не ест).

Спасительный флажок bucket-owner-full-control, решающий вопросы доступа в #s3 бакет для двух аккаунтов, не поможет для ситуации с тремя и более аккаунтами. Это когда файл копируется из аккаунта A в бакет аккаунта B, а после нужно расшарить это для аккаунта C (также имеющего доступ в бакет аккаунта B).
Использование --acl bucket-owner-full-control не поможет и получим #error:

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

Хотя точно у всех есть нужные #IAM #permissions и прописаны правильные #bucket_policy в #shared_bucket.

Дело в тех же owner-ах, как и для "двух-аккаунтной" схемы, только решается много сложней. Объекты в shared-bucket имеют лишь права для этих двух аккаутов A и B, аккаунт C имеет доступ в бакет, но его нет среди owner-ов объектов, потому ничего с ними сделать не может.

Решается ситуация лишь из аккаута owner-а, т.е. из аккаунта A — при копировании нужно добавить в список owner-ов сразу все аккаунты (т.е. в т.ч. C). Обычная #aws_cli команда s3 cp так не умеет — нужно использовать #s3api:

aws --region=us-east-1 s3api put-object --bucket my-shared-bucket --key my-bucket-dir/conf.tar.gz --body my-local-dir/conf.tar.gz --grant-full-control id=d0cecf42b8a1bed065b8a1b2fdbf76c1b6acda99e0338822e3cece21a8c71058,id=1208ecf5e61d2b67a525edee13f7667ab45d2be85b1fdb11a9338a60609ee5f9,id=780e8bdf2b68d6cc2da2cfcaa6192fac4f437190322277db24ce81ce9aa698f9

Очень непростая и плохо документированная, но рабочая конструкция.
my-shared-bucket — бакет в аккаунте B
--key — путь к файлу в этом бакете
--body — локальный путь к файлу (на виртуалке)
--grant-full-control id=s3-canonical-A,id=s3-canonical-B,id=s3-canonical-C — #s3_canonical аккаунтов A, B и C (именно в таком виде - через запятую без пробела, чего нет в доке, враги)

Не нужно путать S3 Сanonical ID с тем, что используется для CloudFront при доступе в непубличный бакет (S3 canonical user ID). Это уникальный ID для аккаунта, который идёт в паре с AWS ID и может быть получен с помощью aws s3api list-buckets
{
"Owner": {
"DisplayName": "my-account-A",
"ID": "d0cecf42b8a1bed065b8a1b2fdbf76c1b6acda99e0338822e3cece21a8c71058"
},
"Buckets": []
...

Это ID значение получаем для каждого аккаунта, который должен иметь доступ к данному файлу в shared-bucket. Если потребуется расшарить к новому аккаунту - придётся повторить процедуру для каждого файла (объекта).

Потому если нужно раздавать (непубличные) файлы для переменного количества аккаунтов, то #s3 не лучший способ при таком сценарии. В рекомендациях от Амазона это решается с помощью роли в аккаунте A или B, в которую должен переключиться юзер из аккаунта C для получения файла, однако такое (переключение в роль) не всегда возможно сделать в уже имеющемся ПО и библиотеках.

При ошибках в работе с #S3 бакетами есть некоторый набор вещей, что требуется проверить, чтобы найти причину и всё исправить. Очевидные проблемы доступа (не настроенные права) не в счёт, как и вопросы шифрования (это отдельная тема). Далее выстраданные болью и болью вещи.

===
Некоторые достаточно очевидные, что нужно перебрать и проверить.
===

• регион бакета - он может отличаться от того, из которого идёт доступ

• в современных регионах - только Signature Version 4

• популярные ошибки в #IAM: не стоит политика на бакет без * (звёздочки, wildcard):

"Action": [
    "s3:GetObject",
    "s3:ListBucket",
],
"Resource": [
    "arn:aws:s3:::my-bucket",
]

... или наоборот (только с *)

"Action": [
    "s3:GetObject",
    "s3:ListBucket",
],
"Resource": [
    "arn:aws:s3:::my-bucket/*",
]

• есть операция с каталогом, а нет политики 's3:ListBucket'

===
Некоторые не самые и совсем неочевидные (из серии #magic).
===

• сильно отличается время на инстансе (в любую сторону - несколько минут и больше), что часто даёт #error:

A client error (403) occurred when calling the HeadObject operation: Forbidden

• версия #aws_cli старая (локально на старых виртуалках)

• стоит флажок --recursive, а работа идёт с файлом (может возникнуть после копипаста в скриптах) — в результате ничего не будет - ни ошибки (что самое противное), ни копирования файла

• при операциях с https - нужно учитывать заголовки в CORS (что есть HEAD среди них, который часто по дефолту не стоит)

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
    <AllowedOrigin>*</AllowedOrigin>
    <AllowedMethod>HEAD</AllowedMethod>
    <AllowedMethod>PUT</AllowedMethod>
    <AllowedMethod>POST</AllowedMethod>
    <AllowedMethod>GET</AllowedMethod>
    <AllowedHeader>*</AllowedHeader>
</CORSRule>
</CORSConfiguration>

• проверяем доступ на конкретный файл с помощью

aws s3api get-object-acl --bucket my-bucket --key my-path/some.file

... если получаем ошибку:

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

... хотя точно есть все права/роли для бакета (на другой аккаунт, нужные операции и путь), то значит файлы в бакете имеют хозяина, недоступного запрашиваемому — см. выше про #shared_bucket
В нормальной ситуации был бы ответ типа:

{
"Owner": {
"DisplayName": "my-dev",
"ID": "c0123f42b8a1bed065b8a1b2fdbf76c1b6acda99e0778822e3cece21a8c71058"
},
"Grants": [
{
"Grantee": {
"Type": "CanonicalUser",
"DisplayName": "my-dev",
"ID": "c0123f42b8a1bed065b8a1b2fdbf76c1b6acda99e0778822e3cece21a8c71058"
},
"Permission": "FULL_CONTROL"
},
{
"Grantee": {
"Type": "CanonicalUser",
"DisplayName": "jenkins",
"ID": "8933ecf5e61d2b67a525edee13f7667ab45d2be85b1fdb82a9338a60609ee5f9"
},
"Permission": "FULL_CONTROL"
}
]
}

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

#s3_debug

⁠Стэк для VPC peering должен быть в том же регионе (cross-region появился в конце 2017), где находится VpcId:

peerManagementVpc4:
Type: 'AWS::EC2::VPCPeeringConnection'
Properties:
VpcId: !Ref VpcManagement
PeerVpcId: !Ref Vpc4
PeerOwnerId: !Ref AwsAccountVpc4
PeerRoleArn: !Ref RoleInVpc4

т.к. #CloudFormation ищет VpcId именно в этом регионе (аккаунте), а в шаблоне (т.е. в самом CloudFormation #templates) нет возможности задать регион (как минимум - пока).

В результате при попытке это сделать через шаблон будет #error:
VpcPeeringConnection failed to stabilize

А потому #cross_region #vpc_peering пока можно сделать лишь вручную через консоль (где есть возможность задать #aws_region).

⁠You reached the quota on quotas

У анонсированного ранее #service_quotas тоже есть свои #лимиты и потому при активных попытках повысить ваши текущие квоты, можно получить #error:

An error occurred (QuotaExceededException) when calling the RequestServiceQuotaIncrease operation: This account has reached the maximum number of open service quota increase (SQI) requests. Before opening another SQI request, wait for an open SQI request to be accepted or rejected.

#lim(lim)

⁠Ошибка CloudFront - Status Code: 409; Error Code: CNAMEAlreadyExists

Одна из (не)весёлых ситуаций. Вы создаете себе #CloudFront на свой родной тёплый ламповый домен и вдруг #error:

One or more aliases specified for the distribution includes an incorrectly configured DNS record that points to another CloudFront distribution. You must update the DNS record to correct the problem. For more information, see https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html#alternate-domain-names-restrictions (Service: AmazonCloudFront; Status Code: 409; Error Code: CNAMEAlreadyExists; Request ID: a679d06c-aaee-11e9-8a2d-edaa84658d9b)

Как? Что? Где? Когда??? Кто сидел на моей кровати?!? Мой домен — кто мог создать на него дистрибуцию???

Нервный гуглинг вас приведёт на официальную страницу данной проблемы:

https://aws.amazon.com/premiumsupport/knowledge-center/resolve-cnamealreadyexists-error/

Там красиво всё. Объяснения причины - кто же занял ваш домен - найти не получится. А прочитав последний пункт мазохисты получат истинное удовольствие:

3. After the TXT record is created and you've added an SSL certificate to the distribution, contact AWS Support.

— Што-а-а?!??? У вас косяк, а мне в саппорт?!?

И, кстати, да - это возможно лишь при наличии платной подписки. Занавес.

===

Расслабтесь. В Амазоне не всё работает как должно. Да оно вам и не должно.

Обозначенная проблема имеет простое решение, включать временно платную подписку для обращения в саппорт (да, так можно) не потребуется. Просто создайте дистрибуцию БЕЗ (совсем) CNAME. А после создания добавьте нужный CNAME. Всё - просто в два этапа, а не сразу (как, в принципе, должно и раньше могло работать).

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

#i_love_aws

Башеписание в UserData

При использовании сложных баш-конструкций в CloudFormation UserData типа:

UserData:
 Fn::Base64: !Sub |
   #!/bin/bash -xe
   CurZone=$(curl http://instance-data/latest/meta-data/placement/availability-zone)
   CurRegion=${CurZone:0:${#CurZone} - 1}

Строчка CurRegion=${CurZone:0:${#CurZone} - 1} даст #error:

Template error: variable names in Fn::Sub syntax must contain only alphanumeric characters, underscores, periods, and colons.

Для правильного написания таких вещей, переменные нужно экранировать восклицательным знаком, как указано в документации:

To write a dollar sign and curly braces (${}) literally, add an exclamation point (!) after the open curly brace, such as ${!Literal}. AWS CloudFormation resolves this text as ${Literal}.

То есть правильное написание проблемной строки должно быть таким:

CurRegion=${!CurZone:0:${!#CurZone} - 1}

Однако в общем случае стоит избегать подобных сложностей в UserData, а ещё лучше, для конкретного этого примера, использовать встроенную переменную ${AWS::Region}.

#CloudFormation #UserData