Смешивание Terraform и Serverless Framework - PullRequest
Новая
       29

Смешивание Terraform и Serverless Framework

3 голосов
/ 18 февраля 2020

Это скорее открытый вопрос, и я просто надеюсь на любые мнения и предложения. Я имею в виду AWS, но, вероятно, это может относиться и к другим облачным провайдерам.

Я хотел бы предоставить решение Iaa C, которое будет легко обслуживаться и будет отвечать всем требованиям современной безсерверной архитектуры. Terraform является отличным инструментом для определения инфраструктуры, имеет много официальных ресурсов и стабильную поддержку со стороны сообщества. Мне очень нравится его синтаксис и концепция модулей. Тем не менее, это очень плохо для работы с Lambdas. Это также поднимает другой вопрос: должно ли изменение кода быть развернуто с использованием того же потока, что и изменение инфраструктуры? Где провести черту между кодом и инфраструктурой?

С другой стороны, Serverless Framework позволяет очень легко разрабатывать и развертывать Lambdas. Это решительно, когда дело доходит до использования ресурсов, но у него есть несколько готовых функций, которые того стоят. Его не следует использовать для определения всей инфраструктуры.

В настоящее время мой подход заключается в определении любых общих ресурсов с использованием Terraform и любых ресурсов, связанных с доменом, с использованием Serverless. Здесь у меня есть еще одна проблема, связанная с моими предыдущими вопросами: зависимость от развертывания. Простой сценарий: Lambda.1 добавляет пользователей в Cognito (общий ресурс), который имеет Lambda.2 в качестве триггера. Мне нужно создать собственное решение для управления порядком развертывания (сначала нужно развернуть Lambda.2 и т. Д. c.). Можно подключить развертывание Serverless Framework к Terraform, но опять же: следует ли смешивать развертывание кода с развертыванием инфраструктуры?

1 Ответ

6 голосов
/ 18 февраля 2020

Полностью возможно смешать два, и мне приходилось делать это несколько раз. То, как это выглядит, на самом деле оказывается проще, чем кажется.

Во-первых, если вы думаете о том, что вы делаете с Serverless Framework, как о разработке микросервисов (без сопутствующего бремени управления инфраструктурой), это делает его одним шагом в правильное направление. Затем вы можете решить, что все, что требуется для внутренней работы этого микросервиса, определено внутри этого микросервиса как часть конфигурации служб в serverless.yml, будь то таблицы DynamoDB, интеграции Auth0, потоки Kinesis, SQS , SNS, IAM-разрешения, назначенные функциям и т. Д. c. Держите все это как часть микросервиса. Terraform не требуется.

Теперь подумайте о том, что может понадобиться тому и другому микросервисам для более широкого взаимодействия. Они не являются критичными для внутренней работы этих служб, но важны для интеграции в остальную инфраструктуру организации. Это включает в себя такие вещи, как роли IAM развертывания, используемые службами Serverless Framework для развертывания в CloudFormation, реляционные базы данных, которые должны совместно использоваться несколькими службами и ресурсами, сетевые элементы (VP C, группы безопасности и т. Д. c), Монолитные c кластеры, такие как ElasticSearch и Redis ... все эти элементы являются отличными кандидатами для определения вне Serverless Framework и отлично работают с Terraform.

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

Надеюсь, что это поможет

...