#машины_aws

Для CloudFormation был разработан линтер cfn-lint, который на базе разных правил проверял шаблон на вшивость. Одной из моих любимых фишек этого линтера была возможность написать свое правило на том же языке, что и сам линтер, т.е. на Python.

А раз для написания правила используется верхнеуровневый язык программирования, то положить в это правило можно буквально все что угодно. Автор помнит времена, когда он злоупотреблял Boto3, чтобы в рамках правила делать вызовы на AWS API и делать более точечные проверки, например, если hardcoded ARN ссылается на существующий ресурс.

У таких свистоплясок есть очевидный недостаток. Например, если линт проходит в рамках CI, то у сборочного агента должен быть доступ в AWS, не говоря уже о том, что мы нагружаем линтер функциональностью, для которой он никогда не предназначался.

И вот я в очередном туре по кишкам CFN, изучая расширения, нашел расширение Hooks. Hooks проверяют разные типы ресурсов на соответствие определенным правилам, но в этот раз правила проверяются на стороне самого CloudFormation. Может показаться, что это бесполезное дело, ресурс дешевле проверить до развертывания, а не во время развертывания.

С другой стороны можно застраховаться от тех, кто катит CFN вручную и не применяет линтер, или если приходящие изменения в вашу инфраструктуру не под вашим контролем. Hooks это такой способ защититься от неприемлемых изменений, поскольку они не допускают абьюза со стороны ленивых девопсов.

Но для этого нужно побороть сначала свою лень и написать много правил на все случаи жизни. 🙂

#анонсы #машины_aws

Лучшая книга по AWS CloudFormation получила второе издание!

В новой версии:
1. Переработаны почти все главы в соответствии с изменениями у самого AWS'а, обновлен весь код, и мне за него даже почти не стыдно
2. В главе Advanced Template Development добавлена секция по работе с Language Extensions
3. Глава про Macros была переписана полностью и теперь включает в себя Nested Stacks и Modules
4. Новая глава, посвященная работе с CloudFormation Registry
5. В главе по CDK используется CDK v2

Отдельная благодарность @VasilyPantyukhin и @patrick239 за то, что заставили меня вылизывать все почти до мельчайшего знака препинания!

#машины_aws

Этой ночью, AWS Kinesis снова отстрелил многим чресла в us-east-1. Практически так же, как 4 года назад. По этому поводу сделаю пару замечаний.

Во-первых - не используйте us-east-1. Это регион-страдалец, там всегда что-то взрывается раз в год. Пощупать экспериментальные сервисы первым того не стоит... Впрочем вы и без меня это знаете.

Во-вторых, давать леща за инциденты нельзя. А вот давать леща за неисполнение incident follow up'ов - вполне себе можно и нужно. Следите за руками.

В 2020, когда случился инцидент, AWS поставил себе задачу разделить Kinesis на две изолированных группых сервисов, иными словами, сделать "внутренний" Kinesis.

We will also move a few large AWS services, like CloudWatch, to a separate, partitioned front-end fleet. (с) из пост-мортема

Делается это для того, чтобы внутренние проблемы сервисов не били по внешним потребителям напрямую, потому что потребители работают с абстракциями - ну давайте честно, кто еще знает, что Cognito использует Kinesis под капотом? - и знать внутренности не должны.

Однако спустя почти 4 года, мы имеем отказ клиентских сервисов по подозрительно схожей причине, более того, "клиентский" Kinesis тоже пятисотил. Это говорит о том, что:
- либо в общей структуре есть большой архитектурный огрех, который не решается дублированием сервиса для внутренних нужд
- либо, что еще хуже, AWS не исполнил обещание после инцидента.

За второе надо бить палками, а так же отдавать айтишников на массовые расстрелы, потому что задача каждого разбора полетов не допустить такой же инцидент в будущем.