AWS CloudFormation: найкращі практики та способи їх використання

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Що таке сервіс CloudFormation? Як з ним працювати? Порадами з власного досвіду ділиться Роман Банах, Principal DevOps Engineer в Intellias.

Сьогодні Amazon Web Services (AWS) є найбільшим провайдером хмарних сервісів. За даними Amazon кількість активних користувачів AWS перевищує 1 000 000. Їх послугами користуються як величезні гіганти, такі як Netflix, Linkedin, Facebook, Adobe, Twitter, так і стартапи чи маленький бізнес. Підрахувати точну кількість сервісів, які надають AWS, важко. За деякими даними станом на січень 2020 року їх більш, ніж 280. Було би дивно, якщо б AWS не мали нативного механізму, який автоматично створює ресурси. На щастя, такий механізм є, і реалізовний він в такому сервісі, як CloudFormation (CFn).

CloudFormation — потужний сервіс, який допомагає вам створювати і управляти інфраструктурою в AWS. Описувати інфраструктуру в CFn доволі просто, та цього не достатньо. У цій статті я розповім про найкращі практики, запропоновані AWS відносно CloudFormation, і поясню, як їх ефективно використовувати у роботі. Також поділюсь тим, як краще організовувати ваші темплейти, як оновлювати критичні ресурси без простоїв (downtime) та що важливо знати, щоб розширити спектр перевикористання темплейтів, а також, як не втратити критично важливі ресурси, які були створені за допомогою CloudFormation під час видалення чи оновлення стеків.

У цій статті навмисно використовую англіцизм «темплейт», бо для інженерів це більш звично, ніж використовувати слово «шаблон».

Що таке CloudFormation і навіщо він потрібен

CloudFormation — це сервіс Amazon, який дозволяє створити інфраструктуру в Amazon, описавши її текстом у форматі YAML або JSON. У файлі ви описуєте ресурси, які потрібно створити і залежності між ними. Перш за все завдяки CloudFormation вам нічого не потрібно документувати, оскільки все вже задокументовано в коді. Все створюється автоматично, поки ви п’єте каву. А основне — AWS сам знає, в якій послідовності краще створювати та видаляти ресурси. Завдяки цьому у вас не буде таких ситуацій, коли ви видалили якийсь шматок інфраструктури, а про його залежності забули. CloudFormation робить це за вас. Ви пишете код у себе на комп’ютері, далі заливаєте його в S3 bucket або напряму кладете у CloudFormation, і він створює стек із ресурсами, які були описані в темплейті. В результаті у вашій консолі залишається CloudFormation ресурс, який ви можете менеджити. Коли вам потрібно щось оновити, ви йдете у конкретний stack і згодовуєте йому новий темплейт.

З яких секцій складається CloudFormation

1. AWSTemplateFormatVersion.
2. Description.
3. Metadata.
4. Parameters.
5. Mappings.
6. Conditions.
7. Transform.
8. Resources.
9. Output.

Лише одна секція в темплейті CloudFormation є required — це Resources, але якщо користуватись лише нею, то у вас буде величезна купа хардкоду і ваші темплейти будуть, м’яко кажучи, огидними.

Як же деякі із перечислених секцій можуть зробити життя тих, хто ними користується, набагато простішим? У своїй статті про найкращі практики в CloudFormation AWS розділили їх на три блоки: планування та організація (Planning and organizing), створення темплейтів (Creating templates) та управління стеками (Managing stacks). У середині кожного блоку є по 6 пунктів, які ми розглянемо детальніше.

Planning and organizing

Organize Your Stacks by Lifecycle and Ownership

Ви можете запхати все в один CloudFormation Stack — конфігурації мереж, s3 бакети, різного роду кластери і т.д. Однак такий підхід може призвести до певних проблем. Напевно всі, хто колись використовував CloudFormation, стикались із ситуацією, коли створені за допомогою CloudFormation ресурси модифікувались мануально через консоль чи aws cli якимось колегою. Після цього, коли ви намагались оновити стеки, вони зависали, тому їх доводилось видаляти і створювати знову. Так от, якщо у вас все буде в одному стеку, то ймовірність того, що вам доведеться перестворювати стек, дуже висока. Тому варто розділяти критичні ресурси із менш критичними.

Use Cross-Stack References to Export Shared Resources

Тут ми поговоримо про доступ до даних з одного стеку в іншому. Наприклад, коли ми створюємо ресурс SecurityGroup, нам потрібно вказати ідентифікатор VPC, до якої буде прив’язана ця група. У нас є вибір, або хардкодити ці значення, що апріорі не правильно, або зробити Export змінної в батьківському темплейті та імпортувати її в дочірньому за допомогою функції Fn::ImportValue.

# Батківський темплейт в CFn Cross-Stack References
# … SKIP …
Outputs:
  VPC:
    Description: VPC ID
    Value: !Ref VPC
    Export:
     Name: simple-vpc
# … SKIP …

# Дочірній темплейт в CFn Cross-Stack References
# … SKIP …
Resources:
  albSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupName: simple-alb-security-group
      GroupDescription: Application LoadBalancer SG
      VpcId: !ImportValue simple-vpc
# … SKIP …

Як можемо бачити у батьківському темплейті відбувається експорт VPC і цьому експорту присвоюється ім’я simple-vpc, а у дочірньому темплейті робиться імпорт цієї змінної і застосовується для властивості VpcId ресурсу albSecurityGroup.

Use IAM to Control Access

IAM — це сервіс, який дозволяє зробити розмежування доступів для користувачів, ролей та користувацьких груп до ресурсів AWS. Ви можете використовувати IAM з CloudFormation для того, щоб вказати, що саме може робити користувач з CloudFormation: що він може переглядати, створювати, видаляти і т.д. Окрім того, будь-який користувач, який використовує CloudFormation, повинен мати права на створення ресурсів, описаних в його темплейті.

Reuse Templates to Replicate Stacks in Multiple Environments

Щоб ваші темплейти можна було використовувати, користуйтесь такими секціями, як Parameters, Mappings та Conditions. Це дозволить максимально кастомізувати ваші стеки під час їх створення. До прикладу, якщо ви створюєте EC2 інстанси в різних регіонах з одного і того ж образу, то ідентифікаційні номери (ID) Amazon Machine Image (AMI) будуть різні, тому хардкодом тут не обійдешся. Вийти з ситуації допоможе секція Mapping і функція AWS::Region. Також вам, напевно, цікаво мати середовище, наближене до продуктового (production), однак у розробницькому (development) середовищі часто немає великого навантаження, і там не потрібні великі потужності. Тобто в параметрах ви можете задати, AllowedValues, наприклад, prd, stg, dev, а в секції Mapping вказати, що такий-то тип відповідає такому-то значенню середовища.

Verify Quotas for All Resource Types

Це лише офіційна позиція AWS. Насправді, нонсенс ходити і перевіряти, чи достатньо у вас квот, маючи автоматизований процес розгортання. Уже існують підходи, які дозволяють відслідковувати ваші квоти і нотифікувати у разі досягнення певних порогів. З цього приводу рекомендую звернути увагу на утиліту awslimitchecker.

Use Nested Stacks to Reuse Common Template Patterns

Ви можете відокремити загальні компоненти та створити для них виділені темплейти. Таким чином, можна змішувати та співставляти різні темплейти, але використовувати вкладені стеки для створення єдиного об’єднаного стека. Nested стеки — це стеки, які створюють інші стеки. Допустимо, що у вас є конфігурація Load Balancer, яку ви використовуєте для більшості стеків. Замість того, щоб копіювати та вставляти ті самі конфігурації у темплейти, ви можете створити виділений темплейт для Load Balancer. Потім ви використовуєте ресурс AWS::CloudFormation::Stack для посилання на цей темплейт з інших темплейтів. Якщо темплейт балансера оновлений, будь-який стек, на який він посилається, буде використовувати оновлений темплейт. Давайте подивимось на приклад із ресурсом SecurityGroup.

# Підключення Nested Stack в Root Stack
# … SKIP …
Resources:
  myStackWithParams:
    Type: AWS::CloudFormation::Stack
    Properties:
      TemplateURL: "path_to.template"
      Parameters:
        SGName: "my-security-group"
# … SKIP …

# Nested Stack
#… SKIP …
Parameters:
  SGName:
    Type: String
Resources:
  albSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupName: !Ref SGName
# … SKIP …

У властивість TemplateURL передається шлях до темплейта, ну і відповідно під властивістю Parameters перечислюються усі параметри які ми передаємо у вкладений (Nested) стек. У вкладеному ж темплейті ми як і у будь-якому звичайном, приймаємо параметри ззовні. У прикладі вище, зображено, як передається параметр SGName, який надалі використовується в ресурсі albSecurityGroup для того, щоб дати секюріті групі ім’я.

Creating Templates

Do Not Embed Credentials in Your Templates

Замість того, щоб вставляти в темплейти AWS CloudFormation конфіденційну інформацію, AWS рекомендує використовувати динамічні посилання у темплейтах. Завдяки їм ви можете посилатися на зовнішні значення, які зберігаються та керуються в інших службах, таких як AWS Systems Manager Parameter Store або AWS Secrets Manager. Коли ви використовуєте динамічні посилання, під час операцій зі стеком при необхідності CloudFormation витягує значення зазначеного посилання. Плюсом є те, що CloudFormation ніколи не зберігає фактичне значення.

Якщо вже не хочете використовувати перелічені сервіси, то використовуйте хоча б Parameters із опцією NoEcho встановленою в True.

Use AWS-Specific Parameter Types

У більшості темплейтів, які потрапляли до мене на рев’ю, я бачив лише такі типи параметрів як String, рідше Number, про решту я взагалі не згадую. Таких типів є більше 20-ти:

CloudFormation може швидко валідувати значення параметрів для специфічного AWS ресурсу перед тим, як ви натиснете кнопку submit. Окрім того, якщо ви використовуєте AWS консоль, то CloudFormation підтягне значення існуючих ресурсів, таких як SSH ключ, VPC чи SecurityGroup. Детальніше дізнатись про типи параметрів можна тут.

Use Parameter Constraints

За допомогою обмежень ви можете описати дозволені вхідні значення, щоб AWS CloudFormation відловлював будь-які неправильні значення перед створенням стеку. Ви можете встановити обмеження, такі як мінімальна довжина, максимальна довжина та дозволені патерни. Наприклад, якщо ви все ж задаєте пароль до бази даних через параметри (будь ласка, не робіть цього), то можете вказати його мінімальну довжину і які символи там можуть бути використані:

• Type
• AllowedPattern
• AllowedValues
• ConstraintDescription
• Default
• Description
• MaxLenght
• MaxValue
• MinLenght
• MinValue
• NoEcho

Use AWS::CloudFormation::Init to Deploy Software Applications on Amazon EC2 Instances

Я часто зустрічаю CFn темплейти, в яких дуже багато операцій зі встановлення пакетів, а створення файлів розташоване в UserData. Такі темплейти виглядають дуже незграбно. Окрім того, з часом навігація по такому темплейту ускладнюється. Для таких задач AWS рекомендує використовувати AWS::CloudFormation::Init, який дозволяє все це описати в темплейті без зайвих «костилів».

Use the Latest Helper Scripts

AWS не пояснює нічого з цього приводу, але я підозрюю, що оновлювати їх потрібно не лише тому, що там з’являються нові фічі, але і тому, що вони закривають певні вразливості безпеки.

Validate Templates Before Using Them

Перед тим, як створювати стек, перевірте темплейт, щоб у разі помилки вам не довелось видаляти стек, а потім знову його створювати. Перевірити темплейт допоможуть такі утиліти як:

• cfn-lint
• yaml-validate
• json-validate

Ну і звісно, у цьому списку також має бути aws cloudformation validate-template. Окрім того, все вище перелічене можна і навіть варто використовувати у випадку, якщо у вас є процес CI/CD для самого CloudFormation. Наприклад, заборонити злиття гілки, в якій розроблявся новий функціонал, в головну гілку, якщо тести в cfn-lint не пройдуть.

Managing Stacks

Manage All Stack Resources Through AWS CloudFormation

Якщо ви створили ресурси за допомогою CloudFormation, то управляйте ними лише за допомогою цього сервісу. Однак на всіх ви вплинути не можете. Трапляється, що на проєкті є колега, якого не цікавить, як було створено ресурс. Автоматичне і мануальне редагування може зашкодити збудованим процесам, однак, якщо йому потрібно, цей колега він все одно змінить конфігурацію мануально. Допомогти виявити незадекларовані зміни в ресурсах, створених за допомогою CloudFormation, може така функція, як DriftDetection. DriftDetection допоможе ідентифікувати, чи консистентні ваші ресурси з поточним стеком/темплейтом.

На рис. вище зображено, як ресурс, який був створений за допомогою CFn, було змінено поза CFn. Як видно властивість SecurityGroupIngress.0.CidrIp було модифіковано і CFn повідомляє про це.

Create Change Sets Before Updating Your Stacks

Використовуйте change set-и, щоб перевірити, як ваші зміни можуть впливати на запущені ресурси, особливо, на критичні ресурси. Наприклад, якщо ви зміните ім’я екземпляра бази даних Amazon RDS, AWS CloudFormation створить нову базу даних і видалить стару. У результаті, якщо ви не забекапили дані у старій вазі, ви їх втратите.

Якщо використаєте change set, то побачите, що ваша зміна вплине на базу даних. Це може допомогти спланувати оновлення стеку.

Use Stack Policies

Stack Policy допомагає захистити критичні ресурси стеку від ненавмисних оновлень, які можуть призвести до видалення або заміни ресурсів. Stack Policy — це документ у форматі JSON. Він описує, які дії з оновлення можна виконувати на визначених ресурсах. Вказуйте політику стеку щоразу, коли створюєте стек, який має критичні ресурси. Під час оновлення стека потрібно чітко вказати захищені ресурси, які ви хочете оновити, в іншому випадку вони не будуть захищені. Ось як виглядає така політика:

{
  "Statement" : [
    {
      "Effect": "Allow",
      "Action": "Update:*",
      "Principal": "*",
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Action": "Update:*",
      "Principal": "*",
      "Resource": "LogicalResourceId/ProductionDatabase"
    }
  ]
}

Use AWS CloudTrail to Log AWS CloudFormation Calls

AWS каже, що треба логувати усі API Calls до CloudFormation. На мою думку, треба логувати усі calls до AWS. Так легше буде знайти, хто і де зробив помилку.

Use Code Reviews and Revision Controls to Manage Your Templates

На одному з моїх попередніх проєктів у нас було 200 стеків, 180 з них — це мікросервіси для різних середовищ, як то production, staging та development. Спершу ми хотіли перевірити зміни на dev, stg, а лише тоді — на prd. Але з часом ми почали плутатись, який стек ми вже оновлювали, а який — ні. Нам допомогла, здавалось б, така не потрібна секція як Description. У ній ми прописували версію, наприклад v0.0.1. Основна зручність полягала в тому, що в консолі AWS було видно, яку версію темплейту використовують конкретні стеки. Ось приклад того, як велась розробка в нашому репозиторії.

Процес роботи над CFn темплейтом у системі керування версіями

Update Your Amazon EC2 Linux Instances Regularly

На одному із проєктів, де я працював, час від часу треба було оновлювати секцію Mapping із ідентифікаторами образів по регіонах. Ця робота мені не подобалась більш за все. Уже після того, як я пішов з цього проєкту, я написав, «приблуду», якій ти згодовуєш ID в певному регіоні або її ім’я, а вона натомість автоматично будує карту. Ви можете її встановити за допомогою python-pip. У випадку, якщо вам цікаво, що там під капотом, можете зібрати її власноруч. Знайти її можна у моєму Github-репозиторії.

Лайфхаки для роботи з CloudFormation

Старайтесь використовувати Fn::Sub замість Fn::Join

За можливості старайтесь використовувати Fn::Sub замість Fn::Join, оскільки Sub є більш читабельним. Допустимо, що нам потрібно сформувати стрічку arn:aws:execute-api:us-east-1:123456789012:/*/* (звичайно за умови, що ви знаходитесь в регіоні us-east-1 і ID вашого акаунта 123456789012) в CloudFormation темплейті. За допомогою Fn::Join це можна зробити так:

  !Join:
  - ''
  - - 'arn:'
    - Ref: AWS::Partition
    - ':execute-api:'
    - Ref: AWS::Region
    - ':'
    - Ref: AWS::AccountId
    - ':'
    - Ref: ApiGatewayRestApi
    - '/*/*'

У цьому прикладі є багато символів :, які виступають як об’єднувачами двох стрічок, так і просто присутні в стрічках на початку і в кінці. Це можна виправити, додавши в Join в Join:

!Join:
  - ''
  - - !Join
    - ':'
    - - 'arn'
      - Ref: AWS::Partition
      - execute-api
      - Ref: AWS::Region
      - Ref: AWS::AccountId
      - Ref: ApiGatewayRestApi
    - '/*/*'

Виглядає правильніше, аніж у попередньому прикладі, але для розуміння важче. А тепер давайте поглянемо, як те ж саме виглядатиме в Fn::Sub:

SourceArn: !Sub
  - 'arn:${AWS::Partition}:execute-api:${AWS::Region}:${AWS::AccountId}:${RestApi}/*/*'
  - { RestApi: Ref: ApiGatewayRestApi }

Елегантніше, простіше і зрозуміліше. Звичайно, Fn::Sub не замінить вам Fn::Join у випадку, коли ви працюєте з UserData, тому використовуйте Fn::Sub з розумом.

Використовуйте YAML замість JSON

1. YAML дозволяє залишати коментарі в коді.
2. Розмір темплейту, записаному на YAML, буде меншим за рахунок відсутності великої кількості надлишкових символів, таких як кома, лапки, фігурні та квадратні дужки. Це також важливо для тих, хто створює CFn стеки за допомогою aws cli, оминаючи s3, оскільки ваш темплейт не може бути більшим за ~52Kb.
3. Окрім того, я вважаю YAML читабельнішим за JSON.

Використовуйте Rollback Trigger для критичних ресурсів

На одному з моїх попередніх проєктів треба було впевнитись, що ресурс правильно оновився, навіть у випадку зі staging середовищем. Тоді ми оперували ECS кластерами, і якщо розробники розпочинали оновлення певного сервісу, а код був неробочий, кластер швидко забивався мертвими контейнерами. Тут на допомогу прийшли rollback тригери і CloudWatch Events. Якщо CloudWatch event бачив, що йому починають прилітати певні повідомлення, то викликалась Rollback процедура і повертала сервіс до попередньої версії. Ось приклад такого CloudWatch Event.

Виклик Rollback процедури за допомогою CloudWatch Alert

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

Як бути впевненим, що темплейт можна перевикористати на інших акаунтах і в інших регіонах? Ніколи не хардкодьте ідентифікатор акаунта, регіон та інші службові змінні. Використовуйте наступні псевдопараметри, щоб формувати стрічки:

• AWS::AccountId
• AWS::Partition
• AWS::Region
• AWS::UrlSuffix

Використовуйте секцію Metadata

Якщо ваші темплейти використовують консоль через AWS, то Metadata з ключем Interface — must have. Це допоможе згрупувати дані на сторінці для введення параметрів, а також присвоїти опис кожному полю. Таким чином, ви збережете час, який однозначно витратите на те, щоб пояснювати значення кожної змінної вашим колегам.

AWS CFn консоль без та з використанням AWS::CloudFormation::Interface

Функції для організації мереж, які дозволять зробити темплейти гнучкішими

Якщо ви створюєте VPC і мережі за допомогою CloudFormation, то старайтесь не хардкодити значення. З цим вам допоможуть функції GetAZs і CIDR.

Fn::GetAZs: Ref: "AWS::Region" поверне список значень зон доступності (Availability Zone) в регіоні, в якому був запущений стек. Станом на день публікації функція Fn::GetAZs: us-east-1 поверне наступні значення ["us-east1-a", "us-east1-b", "us-east1-c", "us-east1-d", "us-east1-e", "us-east1-f"].

Fn::Cidr відіграє роль, такого собі, IP калькулятора. У випадку Fn::Cidr:[10.0.0.0/8, 256, 8] він поверне список з 256 мереж із маскою. Fn::Cidr приймає три значення на вхід. Перший — це ipBlock, блок адрес CIDR, який потрібно розділити на менші блоки, count — кількість CIDR, які потрібно генерувати, діапазон становить від 1 до 256, і cidrBits — кількість бітів підмережі для CIDR, наприклад, якщо вказати значення «8» для цього параметра, буде створено CIDR з маскою «/24». Звідки береться /24? 32 — 8 = 24, де 32 — це повний розмір адреси в бітах, 8 — розмір маски хоста, 24 — відповідно розмір підмережі.

Використовуйте Create, Update, Delete Policies

Буває, що потрібно створити якийсь ресурс, але видаляти його не потрібно. Дехто через це не використовує CFn, оскільки думає, що при видаленні стеку важливий ресурс також видалиться. Такими ресурсами можуть бути RDS інстанси, S3 бакети з важливою інформацією, KMS ключі та ін. На щастя, в CFn є такі атрибути, як UpdatePolicy та DeletePolicy, які дозволять вам вказати, що саме ви можете зробити з ресурсом після його оновлення чи видалення.

Якщо ви використовуєте CFn всередині CI/CD, використовуйте wait з вашою командою.

Одного разу мені потрібно було додати CloudFormation в мій CD Pipeline. Я додав команду aws cloudformation create-stack --stack-name my-stack --change-set-name my-change-set, але одразу ж стало зрозуміло, що вона не дає змоги слідувати за виконанням, а просто посилає команду на створення/оновлення стеку. Отже, я спробував знайти, чи дозволяє AWS CLI це робити, але відповіді не знайшов. Зрештою, я реалізував такий сценарій на Python, який допомагав слідувати за виконанням і відображати кожну подію під час створення/оновлення/видалення стеку. Потім я зрозумів, що потрібно було всього лиш додати команду wait. Я вирішив нікому про це не розповідати, бо мені було соромно за це, але за деякий час, рев’юваючи код на іншому проєкті, я побачив таку ж ситуацію, тобто такий же скрипт, який я написав приблизно за два роки до цього.

Отже, ваша команда повинна виглядати так: aws cloudformation wait create-stack --stack-name my-stack --change-set-name my-change-set. Тому не пишіть свої «костилі» використовуйте wait.

Висновок

Більшість практик, описаних в документі AWS, є дуже доречними. Завдяки їм ваші темплейти будуть читабельними, а інфраструктура — в порядку. Однак цих практик лиш 18 і, як на мене, у них все ще є прогалини. Саме тому я написав дану статтю та поділився своїми лайфками по роботі з CloudFormation, буду радий, якщо вони стануть вам у пригоді. І наостанок, читайте документацію та не пишіть «костилів».

Корисні посилання

1. AWS CloudFormation Best Practices.
2. Six unknown CloudFormation features you should know about.
3. AWS CloudFormation Parameters.
4. Воркшоп з CloudFormation від автора.
5. Утиліта для автоматичної організації секції в Mapping.
6. Приклад розгортання інфраструктури із застосуванням Rollback-процедури.
7. Приклад розгортання додатку в ECS із застосуванням Rollback процедури.