Использование уровня общих утилит lambda в локальном развитии

#node.js #aws-lambda #aws-cdk #aws-lambda-layers

Вопрос:

Я использую Typescript, Nodejs и sam-бета-cdk для разработки инфраструктуры бессерверных приложений. Я хотел бы разделить служебные функции между моими лямбдами, чтобы мне не приходилось писать один и тот же код снова и снова.

Структура файла выглядит примерно так:

 lambdas > feature > lambda-name > lambda.js

layers > layer-name > nodejs > utils.js
 

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

Как я могу импортировать утилиты со слоя, чтобы они работали как в aws, так и в моем локальном env?

Ответ №1:

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

 utilities_layer
    mkdir node_modules
    cp -R utilities node_modules
    zip -r utilities-layer.zip node_modules
    (clean up if you want to here)
 

Затем в ваших лямбдах вы можете ссылаться на этот каталог как на часть инструкций импорта.

Тогда, например, у вас есть такая структура:

 |
|-utilities
   |-aws
      |-s3.js
   |-api
|-myLambda
   |-index.js
   |-myLambdaUtil.js
 

Затем в своем коде вы бы сделали что-то вроде

 import s3 from utilities.aws
import myLambdaUtil
 

Обратите внимание, что, если предположить, что у каждого из ваших лямбд есть свой собственный каталог, и вы ссылаетесь на этот каталог в своем решении для развертывания (CDK, SAM, шаблоны Cloudformation), то файл, находящийся в том же каталоге, не включает базовый корневой каталог, но ваши утилиты включают.

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

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

Комментарии:

1. Это отличная идея! В настоящее время я не использую конвейер для развертывания моего cdk — просто делаю это с помощью cli, который выполняет для меня сжатие, — но я определенно попробую это. Звучит вполне законно. Спасибо!

2. Учитывая, что вы все еще можете использовать файл makefile в своем локальном env, он также может быть очень полезен для интерфейса командной строки. У меня в репозитории команд есть несколько сценариев, которые активируют файл make, а затем активируют командную строку CDK для развертывания тестового env в облаке с их текущим локальным кодом. Для радикальных изменений или для новых ресурсов это может быть действительно полезно в качестве заключительного уровня ручного тестирования перед объединением. (или потому, что вы просто не уверены, чем облако будет отличаться от вашего локального!)