AWS Secrets — 10KB

Раздражающее ограничение #Secrets в 4КБ, когда положить в секреты нормальный сертификат с промежуточныйми не представлялось возможным, наконец-то растянули до 10КБ:

https://aws.amazon.com/about-aws/whats-new/2019/10/aws-secrets-manager-supports-increased-secret-size-api-request-rate/

Кто хранил в них текстовые данные - также будут рады. Глядишь, пока подожмёт к свежеобъявленному пределу - растянут уже до 64КБ.

#хорошие_новости

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

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

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

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

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

#issue #closed

Академически качественный доклад на #HighLoad по Design for Failure от архитектора AWS Василия Пантюхина.

https://www.youtube.com/watch?v=7cqS4zAlU50&t=19188s

Основные тезисы:
• какое звание было у Э.Мерфи
• known unknowns vs unknown unknowns
• приоритезация эвентлога
• о пользе постоянной работы
• деньги на риски
• о мудрости пчёл
• оптом дешевле
• малый флот рулит большим
• обогрев воздуха с помощью brownout

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

#design #must_see

Кто жал подробности на счёт метадат, официальная документация здесь:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-interruptions.html#spot-instance-termination-notices

Также жавшим подробности по spot + termination-notice - есть и на русском: 🙂

https://habr.com/ru/post/353102/

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

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

UserData:
 Fn::Base64: !Sub |
   #!/bin/bash -xe
   CurZone=$(curl https://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

К сведению пассажиров!

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

#HighLoad

Спрашивать в пунктах выдачи чая и вайфая. Безвозмездно.

⁠Fargate for EKS

На анонсе EKS и Fargate два года назад на re:Invent 2017, мне врезалась в память фраза, что #Fargate будет работать на базе #EKS под капотом. И до этого времени я пребывал в наивной уверенности, что это так и есть - под капотом у Fargate в реальности EKS.

Однако сегодня первый день на #HighLoad прошёл не зря - я заблуждался и с подачи умных людей узнал правду, что это были лишь планы, который оными и остались на сегодняшний день (см. картинку). Мало того, всё идёт к тому, что это (Fargate for EKS) так и останется лишь планами в роадмэпе.

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

#what_i_learned_today

Некоторые подробности по Fargate for EKS:

• Фраза из 2017-го, запомнившаяся мне: "Fargate supports ECS right now, and will support EKS in 2018."

• Одна из недавних (2019.09.30) презентаций, откуда картинка выше

• Недавнее обсуждение AWS Fargate Deep Dive на Hacker News

Академически качественный доклад на #HighLoad по Design for Failure от архитектора AWS Василия Пантюхина.

https://www.youtube.com/watch?v=7cqS4zAlU50&t=19188s

Основные тезисы:
• какое звание было у Э.Мерфи
• known unknowns vs unknown unknowns
• приоретизация эвентлога
• о пользе постоянной работы
• деньги на риски
• о мудрости пчёл
• оптом дешевле
• малый флот рулит большим
• обогрев воздуха с помощью brownout

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

#design #must_see

⁠AWS CodeBuild + Secrets Manager

В CodeBuild завезли родную поддержку секретов:

https://aws.amazon.com/about-aws/whats-new/2019/11/aws-codebuild-adds-support-for-aws-secrets-manager/

Свои секреты можно добавить в раздел env → secrets-manager файла buildspec.yml или через консоль (см. ниже картинку).

#CodeBuild #Secrets

⁠Reserved Spending вместо Reserved Instances

Новая эра в облачном ценостроении - популярность контейнеров привела к смене ценовой парадигмы, постепенно делая устаревшим понятие "виртуалка" или "инстансы". Поэтому и формирование цены для долгосрочных проектов должно учитывать данный тренд.

В результате Амазон представил новый способ серьёзной экономии:

https://aws.amazon.com/savingsplans/

Теперь есть два типа планов (см. текст на картинке) - EC2 Instance Savings Plans и просто Compute Savings Plans. На инстансах можно сэкономить до 72%. Во втором случае вы покупаете не инстансы, а свои гарантированные расходы на вычислительные мощности, получая за это скидку до 68%, что также очень много, учитывая возможность не париться о типах виртуалок ни сейчас ни в будущем.

С одной стороны, наверняка такой поворот может резко переоценить привлекательность ECS и Fargate в свою пользу.

С другой стороны, возможно это просто проявление будущего перехода на новую модель тарификации а-ля Лямбда - за vCPU/память.

В общем, пока сложно оценить, чем это грозит. Одно можно сказать с уверенность - всем, кто изучал Cost Management для сертификации, точно вскоре придётся переучиваться.

#Cost_Management

⁠Notifications в Code* сервисах

В сервисы CodeCommit, CodeBuild, CodeDeploy и CodePipeline были добавлены Notifications, которые шлются через SNS:

https://aws.amazon.com/about-aws/whats-new/2019/11/introducing-notifications-for-aws-codecommit-aws-codebuild-aws-codedeploy-and-asw-codepipeline/

Notifications можно вешать на нужные события — сбилдилось, нет, в процессе и т.п.:

https://docs.aws.amazon.com/codestar-notifications/latest/userguide/concepts.html#events-ref-repositories

В общем, реально полезное дополнение для организации CI/CD процесса.

#CodeCommit #CodeBuild #CodeDeploy #CodePipeline

Уважаемые читатели!

В ближайший месяц количество новостей здесь может (должно) в разы (порядки) подскочить - на носу не только снежинка с Новым Годом, но и очередной re:Invent. А значит много всего, мимо чего не хотелось бы пройти просто так.

Способ документации чего-то в виде поста, позволяет мне это не забыть (а я забуду) и после проще найти (то есть поиск и тэги в канале).

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

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

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

2. Завести отдельный канал для новостей и прочих апдейтов из whats-new - не нужно смешивать, хочется читать заметки в заметках, а новости в новостях.

3. Не знаю - без разницы.

Пока большинство из высказавшихся за то, чтоб здесь всё загадить - это 70%. Хотя в реальности большинство за молчунами - ещё не высказалось 63%.

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

Так вот - именно вы и пострадаете, если так ничего и не нажмёте. Ведь вам листать здесь придётся много чаще. :)

⁠CloudWatch dashboards + cross-region & cross-account

Теперь простой ответ "ну, понятно - Prometheus+Grafana" придётся давать с оговоркой "или настроить CloudWatch - он уже может кросс-аккаунт-кросс-регион". Не прошло и... А, нет, прошло. И ещё не раз прошло.

Однако теперь это возможно - в одном месте можно настроить полезные CloudWatch дашборды, где можно увидеть метрики из ваших Dev-Test-Stage-etc аккаунтов и/или разбросанных по разным регионам:

https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Cross-Account-Cross-Region.html

В CloudWatch консоли в разделе Settings добавляете нужные аккаунты, в которые добавляете роль CloudWatch-CrossAccountSharingRole (можно сделать самому в каждом аккаунте или с помощью Cloudformation шаблона, который там сразу предлагается запустить - в нём только создание роли) с нужным вариантом политик доступа.

Вместо перечисления в трастовых всех аккаунтов организации (речь о Trust relationships), можно использовать, как указано в документации, конструкцию типа:

"Condition": {
 "StringEquals": {
   "aws:PrincipalOrgID": "org-id"
 }
}

Лишь напомню, что org-id это не айдишник аккаунта вида 123456789012, а организации типа o-dtj1bor777, как было здесь.

#cross_account #cross_region #CloudWatch

Лайфхак - напиши 4 статьи по AWS на медиуме и получи значок!

Я думаю, вы достаточно начитались впечатлений от участников HL++, так что мне нет особой необходимости рассказывать о своих.
Из хороших новостей - мне сообщили, что в течение месяца у меня должна быть запись моего доклада, которым я смогу поделиться со своей дорогой аудиторией.

Ну а мне на Highload стоило попасть хотя бы ради этого прекрасного значка от @aws_notes ;)

⁠Автообновление SSM-агента

Отличная новость - можно включить автообновление для всех ранее настроенных SSM-агентов:

https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-automatic-updates.html

Например, здесь приходилось проверять, чтобы агент был последним - теперь же любую новую фичу он будет подхватывать сразу!

#ssm