Часть 5 - Параметры

В этой главе мы поговорим о необходимом для производственного использования шаблоне AWS SAM, параметризации, процессе определения заполнителей для значений вместо конфигураций жесткого кодирования с целью сохранения только одного шаблон для каждой из ваших сред. Параметризация должна быть решена в начале проекта с использованием соглашения об именах, но не будьте слишком параноиками, пытаясь определить все как параметр, в конце где-то вам нужно будет вставить эти значения, попробуйте найти правильные остаток средств. Как всегда, весь код можно найти на моей странице GitHub.

Cloudformation и, следовательно, в SAM уже есть встроенный Parameters раздел, который является хорошей отправной точкой. Например, вы можете легко определить параметр Env с его типом, допустимыми значениями и описанием, который будет использоваться с обычной функцией Ref для переменной среды, передаваемой в лямбда-функцию.

Затем значение параметра можно указать во время развертывания с помощью параметра parameter-overrides с командой CLI или после управляемого развертывания, а затем сохранить конфигурацию в файле toml.

sam deploy --parameter-overrides Env=dev

Теперь, когда вы определили свой первый параметр, мы можем увидеть несколько более сложных вариантов использования для достижения конечной цели - одного шаблона для каждой среды. Часто параметры используются совместно с шаблонами и командами, и здесь может пригодиться SSM Parameter Store - хранилище ключей и значений, оптимизированное для управления данными и паролями, полностью интегрированное с SAM. У вас есть два варианта использования его в шаблоне, но сначала вам нужно создать запись в Parameter Store. В целях тестирования вы можете создать его прямо из консоли, но всегда не забывайте определять какую-то автоматизацию также и для этой задачи.

Конфигурации VPC для лямбда-функции могут выиграть от использования Parameter Store, поскольку создание записи для подсетей и группы безопасности может создать единый источник достоверной информации для этой информации вместо ее жесткого кодирования, поэтому изменение одного из этих значений потребует обновления Parameter Store и нового развертывания приложения, не касаясь шаблона.

На этот раз тип параметра должен AWS::SSM::Parameter::Value<Type> сообщать CloudFormation, что значение, переданное этому параметру, должно интерпретироваться как имя Parameter Store, из которого должно быть получено реальное значение. . Строка между угловыми скобками используется для указания типа параметра, содержащегося в хранилище параметров. Например, для параметра с типом AWS::EC2::SecurityGroup::Id AWS перед применением шаблона проверит наличие группы безопасности в учетной записи и регионе, где будет развернут шаблон.

Мы также можем использовать раздел Default параметра, задав ему значение по умолчанию, которое следует использовать, если во время развертывания не было передано никакого значения, в случае необходимости всегда можно передать новое значение, заменяющее значение по умолчанию, не касаясь шаблона.

Опять же, этот тип параметра можно использовать с обычной конструкцией Ref, мы скоро увидим, что это не всегда так.

После развертывания стека значения параметров можно получить из консоли CloudFormation, а для хранилища параметров SSM будут указаны и значение, и имя для лучшей видимости и отладки. Если вы имеете дело с конфиденциальной информацией, которую не хотите раскрывать в виде обычного текста, к параметру можно добавить запись noEcho, чтобы увидеть скрытое значение из консоли.

Другой способ использовать Parameter Store в AWS SAM - встроить его непосредственно в раздел Resources, не проходя через раздел Parameters. На этот раз параметр будет скрыт в вашем шаблоне, что сделает его менее видимым и недоступным для пользователей. Другое существенное отличие состоит в том, что здесь вы можете указать также версию Parameter Store, которая будет извлечена при использовании раздела Parameters, всегда будет извлекаться последняя доступная версия. Помните, что каждое изменение значения в хранилище параметров приведет к созданию новой версии.

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

Вы можете настроить свой конвейер так, чтобы он передавал значение в соответствии с окружающей средой, но, возможно, было бы лучше сделать что-то более понятное непосредственно из шаблона, и здесь на помощь приходит раздел Mappings. Раздел шаблона, в котором вы можете определить значения, которые будут приниматься параметром на основе другого параметра, но давайте посмотрим в действии, чтобы прояснить это.

Таким образом, когда параметр Env равен dev или test, переменная LogLevelMapping будет DEBUG вместо Env равно prod переменная будет принимать значение INFO. С такими параметрами нельзя использовать обычный оператор Ref, но необходимо использовать функцию FindInMap. Теперь наш шаблон автономно выбирает правильный уровень журнала в зависимости от среды без инструмента конвейера для этого.

Вы также можете использовать раздел Conditions для параметризации уровня журнала. Идея Conditions аналогична Mappings, но на этот раз вы также можете использовать логические условия, такие как оператор and, or, not, для создания более сложных правил.

В этом случае мы определили условие HasDebugEnabled, которое будет true только тогда, когда параметр Env отличается на prod, теперь вы можете использовать функцию If для выбора значения DEBUG или INFO в зависимости от условия. Вы можете комбинировать и выбирать спецификацию параметров, которая в основном соответствует вашему варианту использования, одно решение может дать вам больше гибкости, а другое дает вам удобочитаемость, это свойство, которое, я думаю, всегда следует учитывать при использовании yaml.

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

Одним из способов может быть получение параметров непосредственно из кода с помощью AWS SDK, но я рекомендую вам взглянуть на lambda power tools или ssm cache, которые также предоставляют возможность кэширования параметров. Обратите внимание на то, что API хранилища параметров по умолчанию имеет ограничение пропускной способности 40 транзакций в секунду. Этот лимит можно увеличить до 1000 транзакций в секунду, но вы понесете дополнительные расходы. Если у вас есть особые требования к безопасности, этот подход будет лучше, поскольку параметры будут извлекаться только при необходимости.

Например, вы можете увидеть следующий код Python для получения параметра из Parameter Store с помощью упомянутых выше библиотек.

На этот раз в шаблон не нужно добавлять никаких параметров, но нам нужно добавить разрешения для получения значений Parameter Store. Для этой задачи используются предопределенные политики, которыми управляет SAM, что значительно упрощает управление ролями.

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

Еще один полезный раздел SAM - это Globals, раздел, в котором вы можете поместить общие конфигурации для некоторого типа ресурса, например, вы можете указать тайм-аут по умолчанию для лямбда-функции. Каждый ресурс типа AWS::Serverless::Function будет иметь это значение по умолчанию, но его всегда можно переопределить. Найдите время, чтобы проверить документацию о поведении переопределения параметров, например, списки добавляются, а карты объединяются.

Также ознакомьтесь с документацией о том, какие свойства можно добавить в раздел Globals. Например, вы могли заметить, что нет возможности определить Policies в Globals. Поначалу это кажется ограничением, вынуждающим вас дублировать большой объем кода, но если подумать, использование Globals политики может привести к утечке безопасности вопреки принципу с наименьшими привилегиями. Рассматривайте его как своего рода строгого помощника для обеспечения только необходимых разрешений для каждой функции, и если у вас действительно одинаковые разрешения для каждой функции, вы все равно можете создать роль и прикрепить ее к каждой функции.

Если у вас был опыт работы с CloudFormation, когда я объяснял параметры VPC, вы, возможно, подумали, почему бы не использовать функцию импорта / экспорта? И вы точно правы. Это допустимый вариант, но при условии, что ваша сеть была создана с помощью CloudFormation, с помощью Parameter Store вы можете разделить два шаблона. Но для полноты картины вы можете увидеть эквивалентное управление с Export функциональностью. Здесь вы также можете найти полный пример конфигурации VPC из CloudFormation

Export функциональность использует Outputs раздел, место, где вы помещаете информацию о созданных ресурсах, которую хотите раскрыть. В частности, в разделе Export эта информация не только отображается внутри стека, но и для другого стека CloudFormation, дающего возможность импортировать эти значения. Вы можете проверить консоль CloudFormation в разделе Exports, чтобы просмотреть значения.

Теперь с помощью функции ImportValue на значения можно ссылаться прямо в шаблоне:

Вместо этого, если у вас есть опыт работы с хранилищем параметров, вы можете знать, что его можно определить как безопасные параметры, но этот тип параметра не поддерживается напрямую SAM или, что еще лучше, его поддерживают только некоторые ресурсы. Правильный способ использования секретов в CloudFormation должен заключаться в использовании AWS Secret Manager, который, как следует из названия, является сервисом, который следует использовать для хранения секретов. Вы по-прежнему можете использовать защищенный параметр внутри своей лямбда-функции, если хотите.

Как видите, очень похоже на управление хранилищем параметров с функцией resolve.

Другой способ управления параметрами, который, я обещаю, будет последним и очень быстрым, - это использование возможностей SAM конфигурационного файла toml для хранения именованной среды. С помощью этого метода вы можете использовать раздел configuration environment управляемого развертывания для создания нескольких версий значений ваших параметров. Это больше связано с управлением средой, но, конечно, лучше иметь в виду, что есть и этот вариант.

Как вы можете видеть, файл toml содержит значение параметра Env для двух сред, dev, которое в нашем случае совпадает со средой по умолчанию SAM и test.

Извините за то, что на этот раз побеспокоил вас этим yaml кодом, но я хотел выделить большинство (да, их больше) способов использования параметров в шаблоне AWS SAM. Я знаю, что существует бесконечное количество способов сделать то же самое, и очень сложно выбрать один. Но прелесть Serverless и AWS в том, что некоторые изменения не будут столь разрушительными. Увидимся в следующей главе.

Больше контента на plainenglish.io