​​Найти файлы S3 бакета за декабрь месяц этого года (последние изменённые в диапазоне 2019-12-01 - 2020-01-01), чтоб, если что, не слишком много, отобразить лишь 20 штук (--max-items 20), для красоты вывести табличкой (--output table) с указанием названий колонок File и LastDate (.{ File: Key, LastDate: LastModified }):

aws s3api list-objects-v2 --max-items 20 --bucket my-aws-notes --query "Contents[?LastModified>='2019-12-01'] | [?LastModified<='2020-01-01'].{ File: Key, LastDate: LastModified }" --output table

#query

AWS купил Google

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

https://linuxacademy.com/news/general/a-cloud-guru-and-linux-academy-f-a-q/

То есть крупнейшая компания по курсам для IT направления A Cloud Guru поглотила своего конкурента LinuxAcademy.

https://acloud.guru/linux-academy

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

#курсы

⁠S3 Access Points - первый взгляд

Недавно появившиеся S3 Access Points стали попыткой начать избавляться от наследия S3 с её требованием к глобальной уникальности имени бакета (т.е. когда имя приходится каждый раз придумывать новое по каким-то паттернам, т.к. иначе получаем ошибку создания бакета).

Теперь же можно создавать и использовать условные "ссылки на бакет" - S3 Access Points. Такие ссылки имеют имя (например, ext из примера), которое должно быть уникальным лишь в конкретном регионе и аккаунте. Что может быть удобным при использовании в мульти-аккаунт схеме, где одно приложение в одном аккаунте, значит можно спокойно использовать одинаковые имена (ссылки на бакет).

Технически попробовать просто - в S3 консоли переходите на вкладку S3 Access Points и создаёте endpoint с каким-то именем. Добавляете к нему #bucket_policy, как к обычному бакету, только в качестве ресурса нужно будет указать arn в виде (он указан на странице вашего Access Point):

"Resource": "arn:aws:s3:eu-west-1:896118698909:accesspoint/ext"

Этот ресурс есть "ссылка на бакет" и к нему можно применять обычные команды #aws_cli (лишь с поправкой, что её придётся для этого обновить, иначе будет ругаться на имя бакета "Bucket name must match..."). Например, можно сделать привычный листинг aws s3 ls arn_ссылки_на_бакет (на картинке).

Однако в случае cross-account доступа крайне неудобно, т.к. приходится прописывать политики и на самом бакете и на каждой "ссылке" (Access Point). И #CRR (Cross-Region Replication) не работает для S3 Access Points.
И набор других особенностей и ограничений. Так что пока сырое, нужно учитывать данный момент.

Предположительный сценарий использования S3 Access Points - вы обрабатываете данные из одного (общего для всех, единственного) бакета, раздавая ссылки на него со своими политиками для каждого из окружений. Можно также как-то задействовать в Blue-Green сценариях и ещё какие-то специцифичные случаи.

В общем S3AP пополнили длинный список фич Амазона под названием "придумай зачем". Однако это шаг в правильном направлении и будучи допиленным, наверняка станет best practices, т.к. даёт дополнительную абстракцию, позволяя гибко управлять и избавляя от некоторых legacy ограничений.

#S3 #S3AP

alias cd='rm -rf'

Во-первых, это красиво.

#пятничное #linux

⁠SSM + Fargate

Тем, кто любит SSM - заслуживающий рассмотрения случай интеграции SSM с Fargate:

https://github.com/andrewkrug/fargate-ir

Конкретно здесь функционал предназначен для incident response, однако мне кажется, что это правильный подход в сторону унификации использования SSM, когда практики, характерные для ОС, распространяются также и на контейнеры.

#SSM #Fargate

​​git commit -m "С Новым Годом! Мой последний коммит в 2019!"
git commit -m "Самый последний коммит в 2019."
git commit -m "Этот точно последний"
git commit -m "И ещё один"
git commit -m "фывафыва"

AWS + programming language

Если бы вы могли посоветовать один язык человеку, желающему сменить профессию и работать в будущем с AWS (без определённой области - от dev и ops до devops), какой бы это был?

Т.е. вот вопрос стоит тупо и ребром — ваш знакомый спрашивает, что ему, отягощённому в прошлом техническим высшим, нужно изучить, чтобы быть и зарабатывать как вы?

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

1. C/C++
2. Python
3. Go
4. Bash
5. Ruby
6. Java
7. JS
8. Другой

#опрос

AWS + operating system

Какую ОС стоит посоветовать освоить человеку в первую очередь, желающему в будущем работать с AWS?

С чего начать, чтобы максимально (практически, перспективно, денежно) полезно?

Какое семейство дистрибутивов выбрать? Личный опыт и с учётом на будущее (а не популярности где-то и когда-то).

1. Ubuntu и другие Debian based
2. CentOS, Fedora Core и другие RedHat based
3. Chrome OS, CoreOS и другие Gentoo based
4. OpenSUSE / SUSE
5. FreeBSD и другие BSD based
6. Другой

#опрос

IAM с самоуничтожением

Можно ли сделать такие политики для IAM, чтобы они отработали и уничтожились через некоторое время?

Чтобы совсем уничтожились - придётся наворачивать лямбду. А чтобы просто отработали лишь на какое-то определённое время — запросто.

Для этого нужно использовать Date Condition Operators, например, так:

{
 "Version": "2012-10-17",
 "Statement": [
   {
     "Effect": "Allow",
     "Action": "s3:GetObject",
     "Resource": "arn:aws:s3:::my-bucket/my-file",
     "Condition": {
       "DateGreaterThan": {
         "aws:CurrentTime": "2020-01-04T10:00Z"
       },
       "DateLessThan": {
         "aws:CurrentTime": "2020-01-05T18:00Z"
       }
     }
   }
 ]
}

Т.е. доступ к my-bucket/my-file будет лишь с завтрашнего утра до послезавтрашнего вечера.

#IAM #policy

​​По результатам опроса - правильные ОС для работы с AWS:

1. RedHat (на котором, в частности, Amazon Linux) - около 50% проголосовавших.
2. Debian (на котором популярная Ubuntu) - около 40%.

Ну и невозможно удержаться от ↓мема в тему↓.

#пятничное

Отличный практикум по Лямбде из командной строки:

https://github.com/nsriram/lambda-the-cli-way

Поэтапное усложнение - от HelloWorld и логов, до интеграции с другими сервисами и SAM (Serverless Application Model). В закладки однозначно.

#Lambda #aws_cli #tutorial

Сколько времени (примерно, обычно) вы тратите на то, чтобы добраться на работу (в одну сторону)?

#опрос

Если пересчитать, то в среднем дорога у читателей этого канала занимает 37 минут в одну сторону.

ALB Ingress Controller - обновлённая версия статьи:

https://aws.amazon.com/blogs/opensource/kubernetes-ingress-aws-alb-ingress-controller/

#EKS #kubernetes

Работа с DynamoDB из aws-cli

Примеров работы из aws-cli с DynamoDB кот наплакал, особенно, когда нужны простые вещи, но выходящие за рамки примеров из документации.


create-table

Создадим простенькую таблицу для условного Jenkins, куда будем писать для каждого проекта (jenkinsProject) свои переменные для каждого билда (buildNumber). Для уменьшения стоимости (хоть и так будет около нуля) вместо дефолтного режима (PROVISIONED) сразу включим (PAY_PER_REQUEST).

Здесь и дальше предполагается, что настроен ~/.aws/config , иначе к каждому запросу добавляем регион --region eu-west-1 (и/или --profile my-profile)

aws dynamodb create-table \

--table-name jenkins \
--attribute-definitions \
AttributeName=jenkinsProject,AttributeType=S \
AttributeName=buildNumber,AttributeType=N \
--key-schema \
AttributeName=jenkinsProject,KeyType=HASH \
AttributeName=buildNumber,KeyType=RANGE \
--billing-mode PAY_PER_REQUEST

put-item

Запишем в таблицу значение для условного проекта aws-notes и билда номер 1 из ветки feature-1. Для получения текущего timestamp вручную выполним:

date +%s
1578575096

Получение timestamp можно добавить и сразу в команду, но так наглядней.

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

aws dynamodb put-item --table-name jenkins --item '{ "jenkinsProject": {"S": "aws-notes"}, "buildNumber": {"N": "1"}, "imageTag": {"S": "feature-1.build-1"}, "imageRepository": {"S": "123166313456.dkr.ecr.eu-west-1.amazonaws.com/aws-notes"}, "date": {"S": "2020-01-09 13:04"}, "timestamp": {"N": "1569486943"}, "branch": {"S": "feature-1"} }'

Переменных добавлено сразу много разных и больше условно, чисто для примера и чтобы удобней выбрать, удалив лишние.


update-item

Обновим билд 1, исправив в нём тэг и ветку (заменим 1 на 1а):

aws dynamodb update-item --table-name jenkins --key '{ "jenkinsProject": {"S": "aws-notes"}, "buildNumber": {"N": "1"} }' --update-expression "SET #T = :t, #B = :b" --expression-attribute-names '{ "#T":"imageTag", "#B":"branch" }' --expression-attribute-values '{ ":t": {"S": "feature-1a.build-1"}, ":b": {"S": "feature-1a"} }'


...продолжение следует

#DynamoDB #aws_cli

Работа с DynamoDB из aws-cli

scan

Предположим, в таблице много билдов разных проектов. Получим все записи таблицы с ограничением максимум 100 значений.

aws dynamodb scan --table-name jenkins --max-items 100

Это будут все проекты, можно вывести лишь нужный, например, aws-notes с помощью #query:

aws dynamodb scan --table-name jenkins --query 'Items[?jenkinsProject.S==`aws-notes`]'


query

Сделать выборку по проекту jenkinsProject - получить все билды:

aws dynamodb query --table-name jenkins --max-items 100 --key-condition-expression "jenkinsProject = :jp" --expression-attribute-values '{":jp": { "S": "aws-notes" } }'

Как найти последнее значение билда (не обязательно совпадающее с количеством записей)? Для этого сделаем реверсивную выборку и получим последний элемент, выделив его с помощью #query и сделав таблицу:

aws dynamodb query --table-name jenkins --key-condition-expression "jenkinsProject = :jp" --expression-attribute-values '{":jp": { "S": "aws-notes" } }' --no-scan-index-forward --max-items 1 --query Items[].buildNumber.N[] --output table

-------
|Query|
+-----+
| 3 |
+-----+

delete-item

Удалим билд 1 из таблицы:

aws dynamodb delete-item --table-name jenkins --key '{ "jenkinsProject": {"S": "aws-notes"}, "buildNumber": {"N": "1"} }'


delete-table

Удалим таблицу .

aws dynamodb delete-table --table-name jenkins


#DynamoDB #aws_cli

Неплохой наборчик AWS-безопасностей в докере набыстропопробовать:

https://github.com/z0ph/aws-security-toolbox

Elastic #Beanstalk обзавёлся своим Roadmap:

https://github.com/aws/elastic-beanstalk-roadmap/projects/1

И плагинчик под хром для тех, кто хочет отличать регион, где он работает в консоли, по цвету:

https://chrome.google.com/webstore/detail/aws-console-regions-color/gfeaclafcmbiakopneapkbaiifnhbkng

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

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

В общем, приятного чтения:

https://m.signalvnoise.com/aws-s3-youre-out-of-order/

⁠Три новых Edge locations для CloudFront открылись недавно поблизости - в Венгрии, Румынии и Болгарии.

Львовщина, Ивано-Франковщина и Одесса радуются - Амазон подобрался совсем близко. Остальные же могут покрутить следующую ссылку, надеясь, что разноцветные отметки переползут когда-то и на их территорию:

https://www.google.com/maps/d/viewer?mid=1cj0vZ2YZJNp39MHIbstZT3QKPkl3Xgw2

#CloudFront

Отличная утилитка под SSM Session Manager для борьбы с ключами SSH на ваших инстансах (чтобы их не использовать):

https://github.com/xen0l/aws-gate

#SSM

Amazon EFS + IAM Authorization + Access Points

EFS серьёзно прокачался:

https://aws.amazon.com/blogs/aws/new-for-amazon-efs-iam-authorization-and-access-points/

Теперь, вслед за S3 Access Points у нас есть EFS Access Points и теперь можно переопределить все операции на своего юзера.

Другая фичиа - IAM Authorization, в том числе Resource-Based политики доступа для EFS, доступ к которому теперь можно рулить через IAM, аналогично с Amazon S3 bucket policies.

Но самое интересное, это что добавление доступа по IAM открывает прямую дорогу к появлению persistent storage для Fargate. Как раз при помощи свежевышедших фич. В общем, выделяем желудочный сок и ждём.

#EFS