AWS Lambda Dev Рабочий процесс

Question

Я уже некоторое время пользуюсь AWS, но мне интересно узнать, как продолжить разработку с Lambda.Я большой поклонник использования серверных функций, позволяю Amazon заниматься техническим обслуживанием и пользуюсь им некоторое время.Мой вопрос: есть ли рекомендуемый рабочий процесс для контроля версий и разработки?

Я понимаю, что есть возможность публиковать новую версию в Lambda.И что вы можете указывать на конкретные версии в сервисе, который его вызывает, например, API-шлюз.Я вижу, что API Gateway также имеет некоторые хорошие возможности для разделения, кто вызывает какую версию.т.е. наличие тестового API, а также медленное обновление обновлений, скажем, на 10% от производственных вызовов API, и медленное расширение.

Однако для реальной системы управления версиями это выглядит немного неуклюже.Возможно, функции кодируются локально и загружаются с помощью интерфейса командной строки AWS, а затем все управляется с помощью сторонней системы контроля версий (Github, Bitbucket и т. Д.)?Могу ли я выполнить развертывание в новых или существующих версиях функции таким образом?Таким образом я смогу разделить тестовые и производственные функции.

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

Как вы подошли к этой проблеме в своем опыте?

Answer 1

Я думаю Serverless Framework + стандартный рабочий процесс Git - ваш лучший выбор здесь.Каждая ветка Git привязана к совершенно отдельной среде (или стадии).Они также могут быть в разных учетных записях AWS * .

Ваша команда работает в функциональных ветвях или использует рабочий процесс на основе PR, а ваши развертывания связаны с коммитами Git.Это избавит вас от необходимости иметь дело с версией Lambda.

Таким образом, вы можете развернуть локально в определенном наборе ветвей.В то время как для вашей промежуточной и производственной сред вы, возможно, захотите подключить их через процесс CI.

Здесь мы подробно описали аспект рабочего процесса Git - https://seed.run/blog/git-workflow-for-serverless-apps

Answer 2

Я написал примерно дюжину лямбда-функций, которые запускаются на основе события или времени записи файла S3 и делают HTTP-запрос к API для запуска заданий по обработке данных.

Не думаю, что существует какой-либо золотой стандарт,Из моего исследования, существуют различные подходы и структуры.Я решил, что не хочу зависеть от каких-либо фреймворков, таких как Serverless или Apex, потому что я не хотел изучать, как использовать эти вещи в дополнение к изучению Lambda.Вместо этого я разработал улучшения, органично основанные на моих потребностях при разработке функции.

Чтобы ответить на ваш вопрос, вот мой рабочий процесс.

1. Разработка локально и внесение изменений в git commit.
2. Проверка данных теста и локальное тестирование с использованием мокко и чая.
3. Запустите сценарий bash, который создает сжатые файлы zip-файлов для развертывания в лямбда-памяти AWS.
4. Загрузите zip-файл в лямбду AWS.

Answer 3

Я бы посоветовал вам взглянуть на SAM.SAM - это инструмент командной строки и инфраструктура, которая поможет вам в разработке вашего безсерверного приложения.Используя SAM, вы можете протестировать свои приложения локально, прежде чем загружать их в облако.Он также поддерживает сине-зеленое развертывание и рабочие процессы CI / CD, начиная автоматически с github.

https://github.com/awslabs/aws-sam-cli

Answer 4

Вы можете иметь контроль версий на своей лямбде, используя aws CodeCommit (намного проще, чем использование внешней системы git-репозитория, хотя вы можете сделать и то и другое).Вот руководство по настройке CodePipeline для этапов фиксации / сборки / развертывания: https://docs.aws.amazon.com/codepipeline/latest/userguide/tutorials-simple-codecommit.html

В этом примере развертывается экземпляр EC2, поэтому для части развертывания для лямбды см. Здесь

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