Флаги бессерверных функций 🚀
При работе с конфигурацией в Serverless World в облаке AWS у вас обычно есть несколько вариантов хранения и доступа к вашей конфигурации, в частности, при работе с динамическими флагами функций. В этом сообщении блога обсуждаются преимущества использования AWS AppConfig вместе с AWS AppConfig Lambda Extension, чтобы получить мощь флагов функций без использования сторонних сервисов. Репо с базовым кодом можно найти здесь. 🙇♂️
Во-первых, что такое «флаг функции»?
Флаги / переключатели функций обсуждаются в статье Мартина Фаулера следующим образом:
Переключатели функций ( часто также называемые флагами функций ) - мощный метод, позволяющий группам изменять поведение системы без изменения кода. Они подразделяются на различные категории использования, и важно учитывать эту категоризацию при реализации переключателей и управлении ими.
Конечно, есть много сторонних поставщиков программного обеспечения, предоставляющих флаги функций в качестве услуги, основным из которых является Launch Darkly. В этой статье рассказывается, как сделать это изначально, используя Serverless Framework и собственные сервисы AWS.
Флаги функций обычно используются для динамического включения или отключения функции в коде, чтобы повысить скорость разработки и снизить риски развертывания, поэтому вы можете развернуть свой код и включить / отключить функцию независимо друг от друга. Вот некоторые варианты использования:
- Новая функция, ориентированная на клиентов.
- Рефакторинг существующей бизнес-логики.
- Новая функция, не ориентированная на клиента.
Это очень часто позволяет командам незаметно проводить A / B-тестирование и постепенное развертывание новых функций, чтобы получить уверенность в производственной среде перед полным развертыванием.
Это делает откат очень простым без необходимости повторного развертывания кода / инфраструктуры, что снижает риск отказа от развертываний. Это также позволяет командам развертывать неполные функции в производственной среде с течением времени (особенно в различных бессерверных службах) и принимать решения на основе данных на основе небольших выпусков, а не на основе подхода большого взрыва.
Чем помогает AWS AppConfig?
Обычно при доступе к данным конфигурации в лямбдах вы выполняете одно из следующих действий:
- Используйте собственный вызов
ssm:ссылочной переменной бессерверной платформы для извлечения конфигурации из хранилища параметров во время сборки. Проблема с этим подходом заключается в том, что конфигурация статична (встроена во время сборки пакета), и хотя она может быть применима для конфигурации, которая очень редко изменяется, это не очень хорошо для флагов функций. - Используйте Parameter Store, но вытягивайте конфигурацию каждый раз, когда лямбда вызывает через код (без кеширования). Конфигурация больше не статична; однако извлечение конфигурации из хранилища параметров AWS требует больших затрат.
- Как указано выше, но с использованием S3 для хранения деталей конфигурации. Опять же, это означает, что вам нужно читать из S3 при каждом вызове. На мой взгляд, конфигурацию в S3 также не так просто изменить по сравнению с Parameter Store.
- В большинстве случаев вы можете использовать переменные среды в лямбда-выражении, однако они подвержены человеческим ошибкам, не требуют аудита того, что изменилось, их нелегко изменить за пределами консоли и подвержены человеческим ошибкам при изменении значений.
AppConfig Lambda Layer Extension спешит на помощь!
AWS AppConfig позволяет хранить конфигурацию в одном из четырех мест:
- AWS Parameter Store.
- AWS AppConfig размещен.
- AWS S3.
- AWS CodePipeline.
Кроме того, вы можете создавать приложения с набором конфигураций и развертываний, позволяя группам очень легко развертывать обновленную конфигурацию для набора целевых объектов (а также возвращаться к предыдущей конфигурации развертывания).
Расширение AppConfig Lambda Extension делает интеграцию между Lambda и AppConfig бесшовной за счет использования Lambda Extensions. AppConfig Lambda Extension автоматически создаст кеш вашей конфигурации вместе с запущенной Lambda, только извлекая последнюю конфигурацию из AppConfig в настраиваемой временной последовательности. Это означает, что конфигурация обновляется для всех вызываемых лямбда-функций очень быстро, без накладных расходов и ограничений, подробно описанных в предыдущем разделе, и без необходимости повторного развертывания какого-либо кода!
AWS описывает службу расширения лямбда как (8 октября 2020 г.):
AWS Lambda объявляет о предварительной версии Lambda Extensions, нового способа простой интеграции Lambda с вашими любимыми инструментами мониторинга, наблюдения, безопасности и управления. В этом посте я объясню, как работают расширения Lambda, как вы можете начать их использовать, а также о расширениях от партнеров AWS Lambda Ready, которые доступны сегодня.
Расширения помогают решить распространенные запросы клиентов, чтобы упростить интеграцию существующих инструментов с Lambda. Ранее клиенты сообщали нам, что интеграция Lambda с предпочитаемыми ими инструментами требует дополнительных задач по эксплуатации и настройке. Кроме того, такие инструменты, как агенты журналов, которые представляют собой длительные процессы, не могут легко работать на Lambda.
https://aws.amazon.com/blogs/compute/introduction-aws-lambda -расширения в предварительном просмотре /
Хорошо, покажи мне код! 😜
В следующем serverless.yml фрагменте ниже показана базовая конфигурация для добавления флага функции с использованием AppConfig и Lambda Extensions, а также первое значение конфигурации:
Как видно из файла выше, расширение AppConfig Lambda Extension добавлено через уровень лямбда, а в разделе ресурсов есть построение профиля приложения, стратегии развертывания и конфигурации для AppConfig (, включая саму конфигурацию ). Этот объект JSON может содержать все ваши флаги функций для конкретного приложения, по сути, набор логических значений.
Теперь внутри фактического обработчика лямбда мы можем получить доступ к конфигурации из расширения, которое работает вместе с лямбда локально (localhost), которое показано ниже в базовой версии:
В приведенном выше коде показано извлечение последней конфигурации локально в кеш при вызове из расширения, причем конфигурация в файле serverless.yml означает, что каждые 30 секунд он проверяется на наличие обновлений для службы AWS AppConfig.
Вместо того, чтобы регистрировать и возвращать значение из шлюза API в ответе, вы должны использовать значение, чтобы определять, была ли функция включена или нет.
Конфигурация также может быть извлечена непосредственно из CodePipeline, что означает, что изменение фактических значений конфигурации может быть выполнено в вашем конвейере CI / CD, даже не выполняя бессерверное развертывание.
Следующие шаги..
Было бы очень просто создать функцию промежуточного программного обеспечения для получения конфигурации с локального хоста, как показано выше, которую можно было бы добавить к любой лямбда-функции с возможностью многократного использования по умолчанию (можно было установить из NPM после упаковки или монорепозиторий).
Это означает, что вы можете деструктурировать конфигурацию из возвращенного значения из промежуточного программного обеспечения и просто использовать его, если он был предоставлен.
Также было бы очень просто создать бессерверный плагин для генерации CloudFormation в разделе ресурсов файла serverless.yml (Я добавлю это в свой список задач!) 🤓
Если бы вы были организацией, которая думала, что описанный выше подход может сэкономить много денег по сравнению с использованием стороннего продукта, было бы несложно создать веб-клиент с API, используя AWS SDK на лямбде под капотом для создания небольшой собственный продукт с очень простой функциональностью, предоставляемой поставщиками услуг. (Думаю, для развлечения я создам бесплатную версию с открытым исходным кодом, которую можно будет развернуть в любой учетной записи AWS!) 😎
Подведение итогов
Если вам понравилось это читать, давайте подключимся к любому из следующих вопросов:
Https://www.linkedin.com/in/lee-james-gilmore/
https://twitter.com/LeeJamesGilmore
Если вы нашли статьи вдохновляющими или полезными, не стесняйтесь поддержать меня виртуальным кофе https://www.buymeacoffee.com/leegilmore, и в любом случае давайте подключимся и пообщаемся! ☕️
Если вам понравились публикации, подпишитесь на мой профиль Ли Джеймс Гилмор, чтобы получать дальнейшие сообщения / серии, и не забудьте подключиться и сказать Привет 👋
Обо мне
“ Привет, я Ли, технический архитектор, сертифицированный AWS, и главный инженер-программист-полиглот из Великобритании, работающий техническим облачным архитектором и ведущим специалистом по бессерверным технологиям. JavaScript на AWS за последние 5 лет.
Я считаю себя проповедником бессерверных технологий и люблю все, что связано с AWS, инновациями, архитектурой программного обеспечения и технологиями. ”
** Представленная информация является моим личным мнением, и я не беру на себя ответственности за ее использование.
