⁠Least Outstanding Requests (LOR) балансировка для ALB

При распределении запросов за ALB используется обычный Round-Robin. Теперь же можно задать Least Outstanding Requests (LOR) - маршрутизировать запросы сначала к тем, кто лучше пингуется:

https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html#modify-routing-algorithm

То есть запросы будут получать инстансы с учётом значений RequestCount, TargetConnectionErrorCount и TargetResponseTime.

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

Включается в консоли в Target Groups или с помощью #aws_cli:

https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-target-group-attributes.html

Удачных экспериментов!

#ALB

⁠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

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

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

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

#Lambda #aws_cli #tutorial

Работа с 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

⁠Отличный источник примеров работы с #CloudFormation #templates (а также #Terraform и #aws_cli) плюс прямые ссылки на документацию, официальные блоги, всяческие безопасности и различные #best_practices:

https://asecure.cloud/

Однозначно в закладки.

#security #info

AWS CLI v2

Некоторое время назад в preview, а теперь полноценная замена:

https://aws.amazon.com/blogs/developer/aws-cli-v2-is-now-generally-available/

Чтобы поставить поверх текущей - нужно удалить ссылку предыдущей (первой) версии:

aws --version
aws-cli/1.16.300 Python/2.7.16 Linux/4.14.97-90.72.amzn2.x86_64 botocore/1.13.36
which aws
/usr/local/bin/aws
rm -rf /usr/local/bin/aws
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install
aws --version
aws-cli/2.0.0 Python/3.7.3 Linux/4.14.97-90.72.amzn2.x86_64 botocore/2.0.0dev4

Кто ставит не в дефолтную юзеровскую директорию (использует ключики -i и -b), обратите внимание, изменилась логика работы второго параметра -b, его нужно указывать без aws на конце - первая версия предполагает полный путь, а вторая лишь каталог для ссылки. Т.е. для первой нужно было, например:

sudo ./awscli-bundle/install -i /usr/local/aws -b /usr/bin/aws

То для второй версии:

sudo ./aws/install -i /usr/local/aws-cli -b /usr/bin

Иначе (если указать для второй аналогичное /usr/bin/aws) увидите после установки:
You can now run: /usr/bin/aws/aws --version

#aws_cli

Чтобы получить информацию о мастер-аккаунте, необязательно для этого лезть в мастер организации, можно в любом из аккаунтов выполнить:

aws organizations describe-organization

{
 "Organization": {
   "Id": "o-grkq8ea51d",
   "Arn": "arn:aws:organizations::221433848249:organization/o-grkq8ea51d",
   "FeatureSet": "ALL",
   "MasterAccountArn": "arn:aws:organizations::221433848249:account/o-grkq8ea51d/221433848249",
   "MasterAccountId": "221433848249",
   "MasterAccountEmail": "admin@aws.notes",
   "AvailablePolicyTypes": [
     {
       "Type": "SERVICE_CONTROL_POLICY",
       "Status": "ENABLED"
     }
   ]
 }
}

Т.е. это работает и в мастере, и в любом из под-аккаунтов.

А для получения в каком-то скрипте конкретно AWS ID мастера используем #query:

aws organizations describe-organization --query Organization.MasterAccountId --output text

221433848249

#Organizations #aws_cli

CodeBuild и ECS

Когда из CodeBuild нужно работать с другим аккаунтом, и потребуется переключаться в роль с помощью флажка --profile, учтите , что обычный вариант не сработает и будет давать ошибку:

Error when retrieving credentials from Ec2InstanceMetadata: No credentials found in credential_source referenced in profile ***

Это потому, что вместо обычного:

credential_source = Ec2InstanceMetadata

В секции профиля файла ~/.aws/config нужно использовать:

credential_source = EcsContainer

И всё заработает.

Почему? Получается, видимо, потому, что CodeBuild под капотом использует ECS.

В принципе, логично, хоть и не видел подобного в документации (что тоже логично).

#CodeBuild

​​aws --debug

В случае проблем не забывайте, что у AWS CLI есть стандартный ключик --debug, где можно увидеть всё, что происходит под капотом во время выполнения любой команды.

https://docs.aws.amazon.com/cli/latest/reference/index.html

Например, казалось бы, простая команда просмотра имеющихся бакетов aws s3 ls даёт на выходе огромнейший лог (см. картинку и это лишь часть).

Пользы в таком логе в общем случае нет, однако когда у вас какая-то непонятнейшая ошибка — очень может помочь.

Например, непонятно почему, команда отрабатывает не так, как вы планировали и пишет, что нет credentials или не хватает прав. Запустив с ключиком --debug, можно пронаблюдать, как команда aws перебирает источники credentials, на картинке это строчки с:

Looking for credentials via: env
Looking for credentials via: assume-role
Looking for credentials via: shared-credentials-file
Looking for credentials via: custom-process
Looking for credentials via: config-file
Looking for credentials via: ec2-credentials-file
Looking for credentials via: boto-config
Looking for credentials via: container-role
Looking for credentials via: iam-role

В результате наглядно видны приоритеты получения aws-cli credentials, что вполне может навести на мысль, почему не работает как нужно.

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

#aws_cli

​​AWS СLI v.2 в Docker

Теперь не обязательно ставить aws-cli локально и всегда можно быстро попробовать с последней версией. В общем, удобная и важная возможность — запустить aws-cli в докере:

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

Легко и просто работает через роль виртуалки, а чтобы прокинуть внутрь credentials или скачать/закачать какие-то файлы, то используем стандартный ключик монтирования -v:

docker run -it -v $(pwd):/aws amazon/aws-cli s3 cp 1.txt s3://my-bucket

#aws_cli

​​Пример query в aws cli с фильтрацией:

aws dynamodb query --table-name jenkins \
--key-condition-expression "Project = :jp" \
--filter-expression "#repo = :ecr" \
--expression-attribute-names '{"#repo": "Repo"}' \
--expression-attribute-values '{
":jp": { "S": "my-service" },
":ecr": { "S": "888888888888.dkr.ecr.eu-central-1.amazonaws.com/my-repo" }
}'

Как-то писал, что подобных конкретных примеров по DynamoDB мало, потому стоит порекомендовать хороший сайт по ней:

https://www.dynamodbguide.com

В частности, добавлю, что его автор, Alex DeBrie (AWS Data Hero), недавно выпустил полноценную книжку:

https://www.dynamodbbook.com/

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

#DynamoDB #aws_cli

Как зашифровать объекты в S3 бакете с помощью aws-cli:

https://aws.amazon.com/blogs/storage/encrypting-existing-amazon-s3-objects-with-the-aws-cli/

Простая и очевидная, но детальная и полезная статья с конкретными командами и подробностями (пере)шифрования ваших файлов на S3.

Запустить несложно, стоит недорого (т.к. лишь за запросы к API) и крайне рекомендуется для того, чтобы привести ваши старые нешифрованные запасы к современному, шифрованному по умолчанию, виду.

#s3 #encryption #aws_cli

Установка AWS CLI v.2 (на самом деле нет):

alias aws='docker run --rm -it -v ~/.aws:/root/.aws -v $(pwd):/aws amazon/aws-cli'

Всё, у нас последняя версия aws-cli.

aws --version
aws-cli/2.0.30 Python/3.7.3 Linux/4.14.158-129.185.amzn2.x86_64 botocore/2.0.0dev34

Понятно, что нужен Docker, однако обычно это сейчас чуть меньше, чем везде.

Чтобы обновить AWS CLI v.2, просто:

docker rmi amazon/aws-cli

Официальная документация:

https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2-docker.html

#aws_cli

​​Версии AWS CLI

Стоит учесть, что когда пользуетесь примерами в документации, то там подразумевается использование последней на текущий момент — второй версии.

В основном она повторяет и расширяет возможности первой версии, но есть и критические отличия:

https://docs.aws.amazon.com/cli/latest/userguide/cliv2-migration.html

Одно из самых заметных — аутентификация в ECR, теперь это не aws ecr get-login, а aws ecr get-login-password:

https://docs.aws.amazon.com/AmazonECR/latest/userguide/Registries.html#registry_auth

В отличие от первой версии возвращает в stdout чисто пароль. Для старых скриптов (где доступна лишь первая версия) можно использовать следующую "замену":

aws ecr get-login --region eu-west-1 | awk '{print $6}'

В любом случае, всё новое уже лучше писать под последнюю версию aws-cli.

#aws_cli

Впечатляющая фича в новых версиях AWS CLI — автодополнение, в том числе для JMESPath (--query).

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

Очень весомый повод обязательно перейти на вторую версию aws-cli.

Подробности в документации:

https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-parameters-prompting.html

#aws_cli

​​Чем отличается вторая версия aws-cli от первой, так это включенным по умолчанию pager-ом, из-за которого приходится нажимать клавиши, чтобы увидеть весь вывод на экран, если он большой.

Чтобы исправить это раздражающее поведение в aws-cli v2, то можно добавить строчку export AWS_PAGER="" в автозагрузку:

https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-output.html#cli-usage-output-pager

#aws_cli

Получить в командной строке время создания текущего AWS аккаунта в формате мм/дд/гг:

AWS_ID=$(aws sts get-caller-identity --query Account --output text)
CREATED=$(aws organizations describe-account --account-id $AWS_ID --query Account.JoinedTimestamp --output text)
date -d $CREATED '+%D'

#aws_cli #query

В конце 2020-го в EKS появились AddOn-ы:

https://aws.amazon.com/blogs/containers/introducing-amazon-eks-add-ons/

С недавнего времени AddOn для VPC-CNI можно поставить в EKS через CloudFormation:

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

eksAddOn:
 Type: AWS::EKS::Addon
 Properties: 
 AddonName: vpc-cni
 AddonVersion: !Ref VpcCniVersion
 ClusterName: !Ref eksCluster
 ResolveConflicts: OVERWRITE

Однако значений AddonVersion в документации на данный момент нет. Чтобы получить доступные варианты, используем describe-addon-versions:

aws eks describe-addon-versions --kubernetes-version 1.19 --addon-name vpc-cni --query addons[].addonVersions[].addonVersion[]
[
  "v1.7.9-eksbuild.1",
  "v1.7.6-eksbuild.1",
  "v1.7.5-eksbuild.1",
  "v1.6.3-eksbuild.1"
]

#CloudFormaion #EKS #aws_cli

Суровый баш для обновления сессионных токенов для AWS CLI при использовании MFA:

https://blog.ivnilv.com/tools/sacc/

#bash #aws_cli