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

⁠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

⁠AWS или смерть

На #HighLoad кроме большого количества хороших докладов, есть реально крутая вещь - возможность организовывать свои собственные тематические митапы в специально отведенных для такого аудиториях.

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

Точней не сам митап, а тема, которую подняли новосибирские коллеги из AWS@NSK и которую очень часто приходится слышать в других местах. Она характеризуется популярными тезисами типа: как жить дальше, сколько можно терпеть и прочие доколе - когда же, наконец, AWS придёт и порядок наведёт. В Россию, конечно же. Хотя актуально для всей восточноевропейской части и зауралья.

Если коротко, то ответ на этот животрепещащий вопрос остался на митапе и остаётся здесь всё тем же - типа держитесь там и прочих благ.

Постановка вопроса некорректная, потому и ответ можно расценить злорадным.

Противопоставление или-или некорректно. Любой проект в области IT в современной реальности глобален сам по себе. Если же в вашем случае это не так, то AWS не ваш выбор, ведь его плюсы особо проявляются для активно растущих проектов, в том числе географически.

Если же это так, но важно иметь и локальное присутствие, а до ближайшего датацентра Амазона многие тысячи километров, в то время как сетевые задержки из-за этого недопустимы в вашем проекте — меняйте архитектуру. Используйте для глобальных вещей AWS, а локальные реализуйте другими средствами - своими или локальных провайдеров.

Например, Яндекс.Облако и MCS (Mail.ru Cloud Solutions) имеют полностью S3-совместимый протокол работы со своими сервисами Object Storage. У Яндекс.Облако есть провайдер для Terraform. Все нонче уже имеют свои managed-Kubernetes сервисы.

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

Ещё один подход - грамотно построенная архитектура на Амазоне обязательно должна иметь рабочий в жизни (а не только в документации) DR (Disaster Recovery) план. Имея такой инструмент (DR-plan) и вышеперечисленные средства позволят получить (должны получить) относительно быструю и безболезенную миграцию в облако нового провайдера, чтобы проверить насколько оно удовлетворяет вашим потребностям.

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

Итого, что хотелось бы сказать по этой теме: противопоставление или-или неуместно. Уместно и-и.

#AWS #проповедь

AWS CLI v2 с поддержкой SSO

Новая "беспитонная" версия aws-cli доступна для установки:

https://aws.amazon.com/blogs/developer/aws-cli-v2-installers/

Кроме питононезависимости она умеет работать с SSO:

https://aws.amazon.com/blogs/developer/aws-cli-v2-now-supports-aws-single-sign-on/

Пока данная версия в превью, потому устанавливается как aws2. После отладки она заменит текущую aws и позволит отказаться от набора утилит, реализующих сходный/пересекающийся с SSO функционал.

#aws_cli #SSO

⁠Import existing AWS resources into new or existing CloudFormation Stacks

Этот час настал! Можно будет импортировать ресурсы в существующие стэки!

Release v1.25.32 (2019-11-11)
===
### Service Client Updates
* `service/ce`: Updates service API and documentation
* `service/cloudformation`: Updates service API, documentation, and waiters
* The Resource Import feature enables customers to import existing AWS resources into new or existing CloudFormation Stacks.

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

#CloudFormation #Yes #Yes #Yes

Некоторые подробности к вчерашней новости о импорте существующих ресурсов в стэк

Проблема возникла с самим возникновением CloudFormation, т.е. ей уже 8 лет. Есть уже существующие ("накликанные" в консоли) ресурсы. Чтобы их перевести на CloudFormation - требуется создать шаблон, удалить старые и поднять новые. Это бывает очень болезненная ситуация (пересоздание ресурсов).

Теперь же можно будет "подхватить" имеющиеся ресурсы в шаблон (новый или имеющийся) и далее рулить ими через шаблон - соблюдая все бестпрактиксы и в рамках единого CI/CD процесса.

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

Другой случай - имеющийся Drift можно будет не только "откручивать" (сбрасывать), но и добавлять в шаблон, если это "правильный" дрифт! Т.е. допилил что-то напильником на проде, после запустил дрифт-детект и подкинул разницу в шаблон - далее новая конструкция обслуживается также через шаблон.

#CloudFormation

⁠У кого вчера (2019.11.12) что-то колбасило - это было не только у вас.

Днём кто-то уронил одну из подзон в Германии (eu-central-1), а вечером настала очередь us-east-1 (на картинке - downdetector), где шатало IAM, что на выходе могло давать проблемы с чем угодно - от доступа к биллингу и неполучению каких-то метрик до неработоспособности ваших лямбд и далее по списку.

#происшествия

Bringing Existing Resources Into CloudFormation Management

Теперь официально:

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-import.html

Цеплять можно будет не все ресурсы (раскатали губу), а лишь определённые. Полный идейно правильных ресурсов список здесь:

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-import-supported-resources.html

В списке есть RDS, о котором я только недавно писал, так что на этом можно выдохнуть и ждать дальше тем, кому не так повезло.

#CloudFormation