AWS CFN: несколько полезных ссылок для изучения CFN

7 Awesome CloudFormation Hacks

19 Best Practices for Creating Amazon Cloud Formation Templates

Continuous Delivery in the Cloud: CloudFormation

Эти 6 уроков работы с cloudformation я усвоил на всю жизнь

AWS CFN: замечание про последовательную выкатку стэка

 Если нам нужно выкатывать набор инстансов, то там можно указать DependsOn и сборка будет ждать готовности инстанса. Но в случае с ASG всё не так просто.

Во-первых, DependsOn на ASG - продолжит развёртывание по готовности самого ASG, но не его машин.

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

В третьих, есть механизмы CreationPolicy и UpdatePolicy (которые так же нужно вешать на инстанс, чтобы стек ждал готовности ноды) и через /opt/aws/bin/cfn-signal на ASG выставлять что нода готова.

Можно сделать внешний счётчик через WaitCondition + WaitConditionHandle.

У него есть нюанс. Если в случае *Policy используется формат --resource (ASGName), то в случае WaitCondition - такой формат не работает! Мы должны применять форму cfn-signal -e 0 !Ref OurWaitCondition, ну или использовать curl. У меня ушло много времени, чтобы найти этот "особый" формат. И да, если мы используем runcmd с блоком Sub - то вместо !Ref надо использовать  формат ${OurWaitCondition}.

Второй нюанс: Anytime you add a WaitCondition resource during a stack update or update a resource with a wait condition, you must associate the wait condition with a new WaitConditionHandle resource. Do not reuse an old wait condition handle that has already been defined in the template. If you reuse a wait condition handle, the wait condition might evaluate old signals from a previous create or update stack command.

И напоследок: Updates are not supported for this resource.

И ещё линки

https://github.com/awslabs/aws-cloudformation-templates/blob/master/aws/services/AutoScaling/AutoScalingRollingUpdates.yaml

https://aws.amazon.com/ru/blogs/mt/signaling-aws-cloudformation-waitconditions-using-aws-privatelink/

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-waitcondition.html

CloudFormation, ASG and Route53

Иногда нужно добавлять домены в Route53 при создании серверов. Для обычных EC2::Instance просто добавляем столько же секций, сколько нам нужно доменов. Всё усложняется, когда нужно делать динамические имена для ASG (Auto Scale Groups).
Вариант "в лоб": делим единый ASG на столько, сколько у нас инстансов, и уже к каждому привязываем конкретный поддомен и всё что нужно. Да, это дублирование как самих ASG, так и связанных LaunchConfiguration, потому что теперь они как минимум содержат номер, поддомен или ещё что-либо. То есть получаем по сути обычный EC::Instance, с небольщим отличием - самовосстановлением, если машина полностью ломается то она будет пересоздана автоматически.
Есть вариант через CloudMap, там уже есть некая гибкость, но нужно внимательно изучить
Есть и такое
https://underthehood.meltwater.com/blog/2020/02/07/dynamic-route53-records-for-aws-auto-scaling-groups-with-terraform/
но тоже надо смотреть, как оно внутри устроено и работает.
Далее, можно в UserData какими-то БД, внешними арбитрами итд вычислять нужные имена и далее через aws route53 манипулировать
Также есть Macro
https://github.com/awslabs/aws-cloudformation-templates/tree/master/aws/services/CloudFormation/MacrosExamples/Count

CloudFormation для VPC Peering

Продолжение https://dragonflybsd.blogspot.com/2020/01/amazon-vpc.html, при настройке через CloudFormation

Казалось бы, настройка элементарна
  VPCPeeringWithMain:
    Type: AWS::EC2::VPCPeeringConnection
    Properties:
      VpcId:
        Fn::ImportValue: !Sub "${AWS::StackName}-VPC"
      PeerVpcId: !Ref VPCMainID

Но нет. Элементарно ловится ошибка
VpcPeeringConnection failed to stabilize. State: [failed]
Открываем доку
https://aws.amazon.com/ru/premiumsupport/knowledge-center/cloudformation-vpc-peering-error/
и начинаем читать. Оказывается, там много подводных камней. Если пирятся разные аккаунты - нужно озаботиться ролями, если разные регионы - читаем

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-vpcpeeringconnection.html#cfn-ec2-vpcpeeringconnection-peerregion

The Region code for the accepter VPC, if the accepter VPC is located in a Region other than the Region in which you make the request.

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

И это всё в дополнение к

https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-basics.html#vpc-peering-limitations

7 Awesome CloudFormation Hacks

https://garbe.io/blog/2017/07/17/cloudformation-hacks/

Немного про говнокод в aws

Есть уже рабочий стэк, который трогать не хочется, и нужно задеплоить 1 новую машину, для этого заводим новый VPC. Причём уже есть ASG+LaunchConfig где всё деплоится как надо, но тут задача, где больше 1 сервера точно не понадобится, vpn, jenkins итд, много когда более 1 машины просто не нужно.

Открываем "простой" пример, оф. пример, делаем по аналогии, запускаем cfn. На выходе ошибка

Value () for parameter groupId is invalid. The value cannot be empty (Service: AmazonEC2; Status Code: 400; Error Code: InvalidParameterValue; Request ID: ...

Открываем доку и видим

[EC2-Classic, default VPC] The names of the security groups. For a nondefault VPC, you must use security group IDs instead.

Думаем, при чём тут это, находим пост (2), заменяем 

"SecurityGroups" : [ { "Ref" : "InstanceSecurityGroup" } ],

на

"SecurityGroupIds" : [ { "Fn::GetAtt" : [ "InstanceSecurityGroup", "GroupId" ] }],

Наслаждаемся ошибкой

Security group sg-059f48c4cb6c45ad2 and subnet subnet-8206c0d8 belong to different networks. Потому что в SG у нас корректно замапилась группа и VPC, а тут взят дефолтный параметр (помним, что у нас иной VPC?). Со злости удаляем вообще SecurityGroupIds, запускаем, радуемся что всё создалось. А потом идём в управление серверами.. и видим что VPC - default и SG пустой!

Вообще, если посмотреть в параметры, там есть LaunchTemplate. Но пока продолжать разгребать эти конюшни.

Судя по всему, тут роляет именно SecurityGroupIds + SubnetId, про что нигде внятно не сказано! Если будет SecurityGroups+SubnetId (второе на верхнем уровне) то будет ошибка

The parameter groupName cannot be used with the parameter subnet (Service: AmazonEC2; Status Code: 400; Error Code: InvalidParameterCombination;

 Хотя можно попробовать вынести SubnetId в NetworkInterfaces (с обвязкой, читаем доку),  и с SecurityGroups...

aws: Load Balancer Types

Elastic Load Balancing supports the following types of load balancers: Application Load Balancers, Network Load Balancers, and Classic Load Balancers. Amazon ECS services can use either type of load balancer. Application Load Balancers are used to route HTTP/HTTPS (or Layer 7) traffic. Network Load Balancers and Classic Load Balancers are used to route TCP (or Layer 4) traffic.

https://docs.aws.amazon.com/AmazonECS/latest/developerguide/load-balancer-types.html (и вообще лучше ознакомиться, там подходы разные)
https://docs.aws.amazon.com/elasticloadbalancing/latest/application/

Когда нам нужно обрабатывать http(s) трафик, лучше всего подходит application LB. Чем он лучше классического:
https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html#application-load-balancer-benefits

Моменты, о которых надо помнить
- Требуется минимум 2 AZ. Даже если данные есть только в одной, остальные должны просто быть. А вот 1 сети в каждой AZ будет достаточно.
- Не забыть про security groups
- Желательно добавить Health Checks для сервера

В случае с CloudFormation можно начать отсюда
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-elasticloadbalancingv2-loadbalancer.html
Не путать с почти такой же страницей, но без V2 - так как это classic lb

You can specify the AvailabilityZones or Subnets property, but not both.

CloudFormation и установка ПО после настройки инфраструктуры

Все действия производятся в блоке UserData, так или иначе. А теперь по порядку, что там может быть

Обязательно начинаем с док
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-instance.html#cfn-ec2-instance-userdata

1) Простой баш скрипт где всё нужное. Быстро, но со своими особенностями вроде сложности обработки ошибок.
https://github.com/hashicorp/consul-ec2-auto-join-example/blob/master/templates/consul.sh.tpl#L5

Setup Consul via CloudFormation in aws

Во-первых, у консула есть автонастройка кластера на базе тэгов, подробнее тут
https://www.consul.io/docs/agent/cloud-auto-join.html#amazon-ec2

Во-вторых, информации как это лучше сделать вроде и море, но кусочек тут, кусочек там, а чуть что не так - надо долго гуглить что не так..
Некоторые действия нельзя сделать напрямую, нужно через некие промежуточные шаги, например у IAM (role, policy как часть role или отдельными блоками, profile)
https://aws.amazon.com/ru/premiumsupport/knowledge-center/cloudformation-attach-managed-policy/

aws cloudformation syntax

Несколько слов про синтаксис. cfn умеет yaml и json, и отличия там не такие и большие. Я бы сказал так: json больше подходит тем кто программировал(ует) на С(++) и/или пишет json руками, а для большинства удобнее будет yaml. Но это моё имхо. Или так: одним больше нравится считать пачки скобочек, другим - пробелы. Но без вменяемого IDE можно в обоих вариантах долго искать проблему.

Очень быстрое введение в CloudFormation

CloudFormation, он же cfn - система для быстрой настройки инфрастуктуры, более убогая версия TerraForm'a который умеет не только амазон. Но иногда нужен именно он.
Вариант первый: настройка через веб
https://docs.aws.amazon.com/en_us/AWSCloudFormation/latest/UserGuide/working-with-templates-cfn-designer-walkthrough-createbasicwebserver.html
Без инструкции будет тоже непонятно - есть какая-то форма, куда можно перетягивать квадратики, стрелочки... Поэтому читать.

Вариант второй - писать конфиг с нуля, руками.
Конфиг файл - файл yaml или json формата и состоит из 3 типовых частей:

• Parameters
• Resources
• Output

(это основные, вообще их чуть больше: Description, Metadata, Mappings, Conditions, Transform)

Terraform vs CloudFormation

Очень вкратце - это платформы для настройки инфраструктуры. Создать VPC, сети, гейты, виртуалки, и связать это всё воедино.
Вообще, советую как минимум начинать с terraform - для амазона оно работает поверх cloudformation, но при этом позволяет достаточно просто перейти например на google cloud. Также по cfn очень мало где можно получить помощь, например есть чат https://t.me/aws_ru, так из 1290 человек что-то про cfn может сказать от силы человек 5. В IRC (freenode) мне пока вообще не довелось увидеть людей кто использует cfn. По терраформу народа гораздо больше.
Причём cfn хорошо работает в связке с ansible, в частности - можно настроить виртуалки через UserData, но любое изменение в этих скриптах и машины надо передеплоить, в этом плане ansible гораздо гибче. Но для задач вида "подключить репу, сформировать пару конфигов, запустить сервис" и подобное - сгодится.

А теперь что можно почитать:
https://technology.amis.nl/2019/05/27/differences-between-cloudformation-terraform-and-ansible-in-deployment-of-objects-in-aws/
https://blog.gruntwork.io/why-we-use-terraform-and-not-chef-puppet-ansible-saltstack-or-cloudformation-7989dad2865c
https://stuartsandine.com/terraform-vs-cloudformation-aws-resource-support/

https://www.youtube.com/watch?v=ALsSaPQI504
https://www.youtube.com/watch?v=sYoaOw7yGIc