⁠#наболевшее #CloudFormation

Telegram + Devops

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

(Кому важно знать популярность - в скобках текущее кол-во участников/подписчиков.)

DevOps&SRE Library (4668)
Качественные ссылки на материалы по девопсу, кратко, регулярно и по теме.

CatOps (3186)
Разнообразные ссылки на статьи по околодевопсовой тематики.

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

Записки админа (6932)
Отличный ресурс по администрированию Linux, позволяет постоянно повышать bash-skill.

DevOops World (195)
Для расширения кругозора (и/или тренировки английского) - хорошая подборка импортного девопса.

DevOps Deflope News (3825)
Ссылки на видео с прошедших девопс-конференций, анонсы будущих - в общем, новости девопс-конференций.

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

AWS_ru (993)
Самый популярный чат по Амазону, must subscribe. У него, кстати, есть "зеркала" в Казахстане (113) и Беларуси (75).

terraform_ru (386)
Активный чат по Терраформу.

jenkins_ru (731)
(Гипер)Активный чат по Jenkins.

ru_freeswitch (505)
Кто связан с VoIP - тут сидят гуру этой области (а не только по Freeswitch). Материалов в интернете по VoIP на русском минимум, а тут можно просто читать логи и немеряно прокачаться.

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

noTieinIT (2132)
Редко обновляемый, но весьма полезный канал, не (с)только про девопс, но мне интересно.

ДевОпс Инженер (3427)
Не самый регулярно обновляемый, но местами интересный канал по девопсу.

aws_notes (559)
Канал по AWS - новости, подсказки, жалобы и прочие личные заметки по Амазону и девопсу.

aws_history (41)
Канал по истории Амазона - древний девопс на AWS, интересные факты и материалы из далёкого (по меркам IT) прошлого.

#devops #info

⁠Amazon status

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

В общем, стоит добавить в закладки популярный ресурс с чатом, где по жалобам страждущих можно судить о проблемах, которые совсем не обязательно, что появятся на официальных дашбордах проблем Амазона:

https://downdetector.com/status/amazon

Кроме того, стоит помнить, что, как писалось по результатам последнего масштабного падения S3 в 2017-м, в результате падения не представлялось возможным написать про падение:

we were unable to update the individual services’ status on the AWS Service Health Dashboard (SHD) because of a dependency the SHD administration console has on Amazon S3

#info #status

⁠ECR Image Scanning

По многочисленным просьбам трудящихся в ECR добавили фичу сканирования docker-образов на предмет известных уязвимостей:

https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-scanning.html

Это можно делать как через консоль (на картинке), так и писать своё через ECR API:

https://aws.amazon.com/blogs/containers/amazon-ecr-native-container-image-scanning/

#security

⁠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