Можно ли разделить мой код и инфраструктуру в безсерверной среде? - PullRequest
0 голосов
/ 15 октября 2018

Возможно ли разделить мой код и инфраструктуру в бессерверной среде?

Я использую бессерверную среду (https://serverless.com) для развертывания моих ресурсов AWS. У меня есть лямбда-функции, определенные в безсерверной средеФайл .yml:

functions:
   hello:
   handler: handler.hello
   ...

Теперь я хочу отделить свою инфраструктуру (serverless.yml) от моего кода. Было бы два отдельных проекта git: один для инфраструктуры и один для лямбды (часть кода).

Это будет процесс разработки: изменения, внесенные в лямбда-проект (git merge), приведут к запуску конвейера CI / CD для извлечения кода, выполнения необходимых проверок (подсказка, проверка и т. д.) и развертываниялямбда в ведро s3.

После этого я мог бы включить s3 в качестве источника моей лямбда-функции и обновить стек функцией, которая включает в себя изменения. Что-то вроде этого:

functions:
   hello:
   handler: function-s3-location
   ...

Мои вопросы:

1) Это хороший подход к CI / CD?

2) Это возможно при использовании безсерверной инфраструктуры или возможно только при использовании AWS::Lambda::Function s codАтрибут для указания корзины s3?

Спасибо!

1 Ответ

0 голосов
/ 16 октября 2018

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

Чтобы дать вам немного понимания,Вы можете структурировать свой проект так, чтобы ваши функции находились в папке, а любой другой модуль - в папке diff.Вы должны быть осторожны, чтобы определить «package.include» и / или «package.exclude» в своем конфигурационном файле.

Более того, если под структурой вы подразумеваете все ресурсы CloudFormation, у вас есть разделдля этого в ваших файлах конфигурации serverless.yml.Если он станет слишком большим, вы также можете использовать дополнительный конфигурационный файл и импортировать его в ваш serverless.yml

Пример:

├── config //configs based on your stage
 ├── dev.json
 ├── prod.json
├── functions
 ├── functionsA
  ├── index.js
 ├── functionsB
  ├── index.js
├── tests
 ├── unit.test.js
├── package.json
├── serverless.yml
├── serverless.resources.yml

Преимущества наличия всего в одном репо:

  • Вы сохраняете все ресурсы в одном проекте, что означает, что если вы «sls remove», команда позаботится об удалении всех ваших ресурсов.То же самое для лямбд.
  • Новые члены команды могут легко понять вашу архитектуру.
  • У вас есть весь код, необходимый для запуска локального экземпляра API и выполнения интегрированных тестов.Полезно для CI.
  • У вас будет только один репо для управления во время конвейера.
  • Вам не нужно будет управлять двумя репо, чтобы оценить, что они "гуляют" вместе.
  • Безсерверные функции позволяют использовать / развертывать только функции, если вы не хотите обновлять облачную архитектуру.
  • Поставщик будет управлять связью между всеми вашими ресурсами.Пример: Вам не нужно управлять тем, чтобы apiGateway на этапе DEV вызывал лямбда-выражения, указывающие на DV DB или содержащие переменную среды со значением DEV.
  • По крайней мере, вы держитесь от своего ручного управления,тем лучше.

Надеюсь, этих причин достаточно, чтобы вы приняли решение.

...