Beanstalk + ALB + CloudFormation

По умолчанию в Elastic Beanstalk создаётся ALB, если делать это через консоль:

By default, Elastic Beanstalk creates an Application Load Balancer for your environment when you enable load balancing with the Elastic Beanstalk console or the EB CLI.

А через CloudFormation - с классическим ELB! (Здравствуй, логика.) Из-за этого в документации не найти примеров кода для создания Beanstalk в CloudFormation.

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

Вот главная ссылка, что всегда требуется при создании шаблона для Beanstalk:

https://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/command-options-general.html

А вот пример кода, как заставить создать Beanstalk + ALB через CloudFormation:

- Namespace:  aws:elasticbeanstalk:environment
  OptionName: LoadBalancerType
  Value:      application
- Namespace:  aws:elbv2:listener:443
  OptionName: Protocol
  Value:      HTTPS
- Namespace:  aws:elbv2:listener:443
  OptionName: SSLCertificateArns
  Value: !Ref AcmCertificateArn
- Namespace:  aws:elbv2:listener:443
  OptionName: DefaultProcess
  Value:      default
- Namespace:  aws:elbv2:loadbalancer
  OptionName: SecurityGroups
  Value: !ImportValue sgVpc4Web
- Namespace:  aws:elasticbeanstalk:environment:process:default
  OptionName: Port
  Value: !Ref InstancePort
- Namespace:  aws:elasticbeanstalk:environment:process:default
  OptionName: Protocol
  Value:      HTTP
- Namespace:  aws:elasticbeanstalk:environment:process:default
  OptionName: StickinessEnabled
  Value:      true
- Namespace:  aws:elasticbeanstalk:environment:process:default
  OptionName: HealthCheckPath
  Value: !Ref HealthCheckPath

Переменные нужно поменять на свои, главная оставить LoadBalancerType - application.

#Beanstalk #CloudFormation #templates

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

⁠OrganizationAccountAccessRole

При создании нового аккаунта можно указать роль, через которую можно будет в него переключиться. Если в поле IAM role name ничего не указать, то по умолчанию создастся роль с именем OrganizationAccountAccessRole.

Обычно такое название устраивает и оно уже давно прописано в различных настройках. Но если аккаунты создаются не так часто, то можно забыть - создастся ли эта роль или аккаунт канет в бездну недоступности?

В интерфейсе текущей версии AWS Console для Organizations организации нет чётких подсказок на этот счёт. Потому, в том числе для себя в будущем, напоминаю:

If you don't specify a name, AWS Organizations gives the role a default name of OrganizationAccountAccessRole.

То есть, да, если оставить это поле (IAM role name) пустым, то создастся аккаунт с ролью OrganizationAccountAccessRole.

Просто редко делаю через консоль — всё через скрипты, CloudFormation или командную строку, а там очевидно. Надеюсь, теперь запомню.

#Organizations #AWS_Console

Well-Architected для Serverless

Для сторонников Serverless-подхода, и тех, кто желает к ним переметнуться, теперь можно удобно прямо в консоли поотвечать на вопросы и получить готовые рекомендации, насколько желаемое соответствует #best_practices по части Serverless:

https://aws.amazon.com/blogs/aws/new-serverless-lens-in-aws-well-architected-tool/

Кто не в курсе, что такое AWS Well-Architected Tool - это такая простая возможность провести аудит ваших подходов к дизайну архитектуры, получив консультацию и рекомендацию от самого Амазона. Очень стоит ознакомиться, особенно тем, кто принимает решения по архитектуре ваших приложений и вообще всего окружения.

#design #well_architected

⁠CloudFormation StackSets + AWS Organizations

StackSets получили возможность автодеплоя для всех аккаунтов в организации. До этого был похожий функцилонал (можно было выбирать аккаунты-регионы), но не было возможности именно автодеплоя для вновь добавленных аккаунтов.

https://aws.amazon.com/blogs/aws/new-use-aws-cloudformation-stacksets-for-multiple-accounts-in-an-aws-organization/

Теперь есть возможность применять общие вещи ко всем аккаунтам организации централизованно или к выбранным OU.

Фича как бы относится ко всей организации, но вы не найдёте её на очевидной страничке Organizations → Settings (кстати, почему?? ). Чтобы включить такую возможность, нужно зайти в CloudFormation консоль мастер аккаунта, где на вкладке StackSets появится кнопка Enable trusted access (на картинке), нажав которую, CloudFormation Stacksets получит право деплоя в любой аккаунт организации.

Незаметной и важной фичей тут нужно отметить следующую вещь:

If your stack set targets a parent OU, the stack set also targets any child OUs.

Казалось бы - логично, что вложенные OU и все их аккаунты вы тоже бы хотели обрабатывать автоматически, указав "родительский" OU. Так вот - нет, не логично. Дефолтный функционал AWS Organizations не обрабатывает вложенные OU (и их аккаунты). Этот баг в своё время назвали фичей, а теперь, вот, пришлось тут править, чтобы удобно было пользоваться.

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

#CloudFormation #Organizations

⁠DaC - Diagram as Code

Если вы не любите рисовать диаграммы (а нужно) и любите питон (и правильно), то у меня для вас есть выход:

https://diagrams.mingrammer.com/docs/examples

Он же вход, подход и переход.

https://github.com/mingrammer/diagrams

Согласитесь, ведь проще написать:

from diagrams import Diagram
from diagrams.aws.compute import EC2
from diagrams.aws.database import RDS
from diagrams.aws.network import ELB

with Diagram("Web Service", show=False):
    ELB("lb") >> EC2("web") >> RDS("userdb")

...чем рисовать эти дурацкие квадратики и стрелочки (на картинке ниже).

В общем, для тех, кто предпочитает кодить - отличный способ кодить в том числе диаграммы для своих отчётов и презентаций!

#info #python

Встроенный SSM-агент для ECS-Optimized Amazon Linux 2 AMI:

https://aws.amazon.com/about-aws/whats-new/2020/02/amazon-ecs-optimized-linux-2-amis-come-pre-installed-aws-systems-manager-agent/

Теперь можно будет убрать из скриптов ставшую лишней строчку yum install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm (т.к. теперь SSM-агент идёт из коробки).

#SSM #ECS #AMI

ECS task + init container

Часто нужно, чтобы ECS task-а сначала была проиниацилизирована, а уже потом стартовал сервис. Пример, как такое можно сделать с помощью CloudFormation:

https://github.com/applerom/cloudformation-examples/blob/master/ecs/task-with-init-container.yaml

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

ecsTaskWithInit:
 Type: AWS::ECS::TaskDefinition
 Properties:

...

   ContainerDefinitions:
   - Name:      !Ref StdNameInit
     Image:     !Ref DockerImage
     Essential: false

...

     Command:
       - sh
       - '-c'
       - !Sub |
         cd /home/my/app \
           && ./setup.py migrate --noinput \
           && ./setup.py rebuild_index --noinput

...

   - Name:      !Ref StdName
     Image:     !Ref DockerImage
     Essential: true
     Links:
       - !Ref StdNameInit
     Environment:

...

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

Контейнер для инициализации отрабатывает первым и умирает, потому ставим ему:

Essential: false

Он должен выполнить какую-то команду(-ы), запускаем следующим способом:

Command:
 - sh
 - '-c'
 - !Sub |
   cd /home/my/app \
     && ./setup.py migrate --noinput \
     && ./setup.py rebuild_index --noinput

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

Links:
 - !Ref StdNameInit

И ставим главному контейнеру:

Essential: true

Так можно регулировать последовательность запуска и инициализировать что-то перед работой основного сервиса.

#CloudFormation #templates #examples

Кому нужны подробности: bad gateway также переводится как "плохой роутер" (это он слева на картинке).

Также напомню, что спросить, если что (подробности), можно в чате канала (да, такой есть - ссылка лежит в описании канала или кнопка комментировать под постом).

В частности, там недавно был отличный вопрос по подробностям работы SSM в ABAC схеме и другие вещи, которые неудобно спамить сюда.

EBS Volumes + Multi-Attach

Теперь на смешной вопрос новичков, а можно ли примонтировать один EBS диск к двум инстансам, вам придётся сдержать свой сарказм и ответить - да, можно:

https://aws.amazon.com/blogs/aws/new-multi-attach-for-provisioned-iops-io1-amazon-ebs-volumes/

Nitro-based системы продолжают удивлять и даже, вот, как теперь, обескураживать. Действительно, теперь можно элементарно подцепить один диск к нескольким инстансам. Они все смогут туда и писать и читать как на обычный диск. Просто сказка!

Подводные камни EBS io1 Volumes Multi-Attach

Ох, их есть, всё не просто так во всех смыслах.

Цена

Ну, для начала, собственно, это лишь для io1 (Provisioned IOPS дисков), т.е., как минимум, банально дороже (по сравнению с gp2 General Purpose SSD). Как минимум на треть для больших объёмов и в разы для маленьких. Но тут понятно и каждый сможет выбрать и посчитать.

EFS Killer? (спойлер - нет)

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

В том числе поэтому выход данной фичи не заменит (и не убьёт) EFS, которой мы пользовались раньше для реализации подобного функционала. Опять же, EFS это MultiAZ, а диск, понятно, находится в какой-то конкретной одной подзоне. И, наконец, EFS масштабируется по объёму, что не сделает EBS Multi-Attach. Так что, нет, EFS никуда не денется. Хотя, конечно, для простых случаев, его можно будет заменить.

Файловая система

В примере по ссылке выше лихо показывается, как такое делается на файловой системе XFS, которая ничего не знает про кластерность и не заботится о подобных вещах. Если вы озаботитесь - тогда это OCFS или GFS2.

Способы применения

Однако, если мы подцепим диск и настроим, чтобы каждый инстанс писал в свою директорию (например, дружно складывая на такой логи с именем хоста в пути) - получим простую (с той же XFS) и при этом рабочую конструкцию.

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

Сходу видятся способы применения для Warm DR - это когда основная система трудится, а другая стоит под парами и готова сразу же подхватить знамя, как только упадёт главная (и для этого к ней примонтирован тот же диск, с которым она не работает, пока работает-жива основная).

Опять же кубернетовское общество сейчас возрадуется и наверняка что-то понапридумывает для задействования в качестве Persistent Storage. В общем, применений Multi-Attach for Provisioned IOPS (io1) EBS Volumes наверняка будет не мало - поделитесь своими вариантами в комментариях.

В любом случае - отличная фича, нужно осваивать.

#EBS

Есть ли поддержка IPv6 в вашем AWS-окружении?

#опрос

Понимаю, что уже понедельник, но это прекрасно:

https://twitter.com/ScribblingOn/status/1228758330769903618

Литературный перевод:

Никакой ваш предыдущий жизненный опыт не подготовит вас к использованию AWS консоли. Ни-ка-кой.

#AWS_Console

Отличная шпаргалка для тех, кто готовится к AWS сертификации:

https://tutorialsdojo.com/aws-cheat-sheets/

#AWS_Certification

PCI DSS + Security Hub

В Security Hub реализаована частичная поддержка PCI DSS (стандарта безопасности платёжных карт):

https://aws.amazon.com/blogs/security/how-to-use-the-aws-security-hub-pci-dss-v3-2-1-standard/

Детальное описание реализованных 32 пунктов из PCI DSS 3.2.1 в официальной документации:

https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-pci-controls.html

#security

⁠Zone ID vs Zone Name

Подзоны (Availabilty Zones) имеют свои уникальные имена (Zone Name), например, us-east-1d, us-east-1f, eu-central-1a, eu-central-1b и т.д.

В общем случае для простоты можно считать, что такая подзона — это какой-то датацентр. Однако в реальности у разных аккаунтов какой-то eu-central-1b совсем не обязательно будет один и тот же датацентр — набор соответствий «реальный датацентр – имя (Zone Name)» генерируется случайным образом при создании аккаунта.

Почему так сделано? Всё просто. Если бы не было такой случайности, то ваши скрипты, одинаково настроенные на очевидные по алфавиту us-east-1 и us-east-1b никогда бы не загрузили датацентры us-east-1e и не так давно появившийся us-east-1f. Перемешивание всё решает.

Итого – одна и та же подсеть в us-east-1a у каждого AWS аккаунта в реальности будет своя (может совпасть лишь случайным образом, но скорее нет).

Shared VPC

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

Чтобы решить эту проблему к Zone Name добавили Zone ID - реальные идентификаторы, которые соотносятся с конкретным датацентром. Так и волки остались целы — старые скрипты не нужно переписывать и в общем случае получается случайный порядок. И овцы целы — если мы хотим получить реальное соответствие, смотрим Zone ID и ориентируемся на подсетки у него, а не на Zone Name.

В результате, если вам потребуется автоматизировать что-то для VPC Sharing - ориентируйтесь и закладывайте в свои скрипты именно Zone ID, который всегда можно получить для нужной VPC через стандартную команду describe-availability-zones.

Временное выключение масштабирования AutoScaling Group

Теперь есть удобная возможность отключить на время масштабирование ASG:

https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-enable-disable-scaling-policy.html

И включить полиси масштабирования после, когда потребуется.

#AutoScaling

https://www.youtube.com/watch?v=2zO-zlSjK44

#AWS #Cost_Optimization

При создании ES (Amazon Elasticsearch Service) кластера, выбирая тип инстанса нужно учитывать, что слабые виртуалки под него имеют ограничения по макимальному размеру диска.

Например, поставив слабенькую t2.medium виртуалку - не получится к ней подцепить диск больше 35 GB. И если в консоли это хоть как-то видно (но тоже плохо), то при написании шаблонов или каких-то скриптов, ошибка вылезет лишь при их отработке.

Потому лучше сразу зайти сюда:

https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/aes-limits.html#ebsresource

И выбрать нужно сочетание «тип виртуалки – объём диска».

#ES

Сравнение AWS сервисов:

https://tutorialsdojo.com/comparison-of-aws-services/

Особо актуально для тех, кто готовится к сертификации.

#AWS_Certification

⁠S3 и защита от копирования (обнаружение утечки данных)

Когда в приватном бакете находятся важные данные и вам нужно максимально быстро узнать, если кто-то вдруг получил к ним доступ - такая задача решается с помощью CloudTrail + Events (CloudWatch Events или EventsBridge):

https://darkbit.io/blog/2020/02/18/simple-dlp-for-amazon-s3

Включаем CloudTrail, создаём SNS топик, запускаем в него эвенты на CopyObject с помощью EventsBridge, и прикручиваем лямбду, чтобы слала алерты сразу в Slack.

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

p.s. DLP = Data Loss Prevention

#security #s3 #EventsBridge #DLP