⁠RDS + доступ по TLS = обновление CA сертификатов

У кого приложения работают с БД по TLS, то стоит озаботиться обновлением амазоновских CA-сертификатов.

Процесс хорошо описан в официальной документации, всё с картинками:

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL-certificate-rotation.html#UsingWithRDS.SSL-certificate-rotation-updating

В качестве альтернативы можно использовать #aws_cli:

aws rds modify-db-instance \
--db-instance-identifier my_db_instance \
--ca-certificate-identifier rds-ca-2019 \
--no-apply-immediately

Стоит учесть, что операция требует перезагрузки сервера баз данных (RDS DB instance).

#RDS #security

​​aws cli + query + table headers + tags

Тема флажка --query в #aws_cli не раз здесь поднималась (её удобно тут искать по тэгу #query, если хотите почитать или просто скопировать и вставить, как я). Конструкции бывают сложные, быстро забываются, а получается красиво, потому залогирую ещё одну.

Одна из самых "отзывчивых" команд:

aws ec2 describe-instances

На выходе бывает вывод на десятки экранов. А вот нужно найти нужные инстансы и их внутренние айпишники. То есть среди этой простыни интересуют лишь следующие строчки:

{
 "Reservations": [
 {
  "Instances": [
   {
...
    "NetworkInterfaces": [
      {
...
       "PrivateIpAddresses": [
        {
         "PrivateDnsName": "ip-10-11-11-211.ec2.internal",
         "PrivateIpAddress": "10.11.11.211",
...
    "InstanceId": "i-09fedeb7686da6be5",
...

Просто табличка

Формируем запрос по ним, учитывая вложенность и добавяем вывод в виде таблицы (флажок --output table):

aws ec2 describe-instances --query "Reservations[].Instances[].[NetworkInterfaces[*].PrivateIpAddresses[*].PrivateIpAddress,InstanceId]" --output table

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

Ещё одна колонка

Будем использовать секретную конструкцию вида {MyTableHeader:JsonItem}. Из-за этого переходим на одинарные кавычки и получаем:

aws ec2 describe-instances --query 'Reservations[*].Instances[*].{IP:NetworkInterfaces[0].PrivateIpAddresses[0].PrivateIpAddress,MyInst:InstanceId}' --output table

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

Вывод тэгов

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

[?Key==`Name`]

Но она на выходе даёт массив, потому добавляем к этому "палку" и вывод первого значения:

|[0].Value

Итоговый запрос

aws ec2 describe-instances --query 'Reservations[*].Instances[*].{IP:NetworkInterfaces[0].PrivateIpAddresses[0].PrivateIpAddress,MyInst:InstanceId,MyName:Tags[?Key==`Name`]|[0].Value}' --output table

Лепота! (см. последний вывод на картинке) Вот теперь полный порядок.

Верите ли вы в AWS vendor lock-in?

Секта какая-то. Здравые и просто счастливо неведующие люди - где же вы?!?

​​Восстановление = удаление удаления

Вы знали, что для восстановления удалённого объекта из #s3 — нужно удалить удаление?

Речь, конечно же, о бакете с включённой #versioning - нужно в AWS Console нажать отображение Versions - Show, найти нужный (удалённый) файл и удалить признак его удаления - нажать Delete Delete marker.

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. Не знаю - без разницы.