Управление лямбда-функциями AWS с помощью dotnet core 2.0 и Terraform - PullRequest
Новая
       8

Управление лямбда-функциями AWS с помощью dotnet core 2.0 и Terraform

0 голосов
/ 23 июня 2018

Настройка

  • VS код
  • Terraform (v0.11)

Проблема

Мне трудно понять, как управлять лямбда-функциями в проекте dotnet core 2.0

Текущий подход (не так, как я думаю, он может работать)

  • Создание структуры функции в Terraform
  • Создание кода функции в основном проекте dotnet, как описано здесь
  • Сжатие папки публикации и загрузка вS3
  • Ссылка на обработчик для функции в определении функции Terraform согласно документации AWS для c # (assembly :: namespace.class-name :: method-name)

Пример лямбда-функции Terraform 

resource "aws_lambda_function" "this" {
  function_name = "test_function"
  role          = "lambda_exec_role"
  s3_bucket     = "my_bucket"
  s3_key        = "object_key/package.zip"

  handler = "MyApp::Example.Hello::MyHandler"
  runtime = "dotnetcore2.0"
}

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

Альтернативный подход

  • Использование CLI ядра dotnet для управления лямбда-функциями вместо Terraform
  • Развертывание каждой функции с использованием CLI ядра dotnet dotnet lambda deploy-function

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

Ранее я использовал NodeJ и Go для создания функций Lambda, каждая из которых кажется более легкой, чемПодход с использованием dotnet (в том смысле, что проще отключить исходный код каждой функции).

Вопрос

Является ли какая-либо из этих настроек оптимальной?

1 Ответ

0 голосов
/ 06 июля 2019

Мне известно, что вопрос был задан около года назад из этого ответа, поэтому я не знаю, насколько все изменилось с тех пор, но вот что сработало для меня:

Я начал использовать dotnet CLI-лямбда-инструменты, как вы и предлагали, и все работает отлично. Он работает из коробки и требует минимальной настройки. Проблема, с которой я столкнулся, заключается в том, что мне нужно было настроить какую-то конкретную конфигурацию, которую Cloudformation не разрешала . Именно тогда я начал использовать Terraform. После некоторых копаний я решил пойти с Terraform, потому что он исправил эту проблему .

Теперь вы упомянули, что ловушкой использования Terraform является то, что вам нужно загрузить весь код в S3 ... но я обнаружил, что инструменты dotnet CLI делают то же самое. Если вы извлечете результат выполнения dotnet lambda deploy-function, вы увидите: 

Zipping publish folder
... zipping: some.dll
... zipping: another.dll
Created publish archive (---)
Uploading to S3. (Bucket: ---)
... Progress: 11%
... Progress: 55%
... Progress: 100%
Creating new Lambda function some_lambda

Итак, в двух словах, я решил придерживаться Terraform и просто разработать собственный сценарий оболочки, который сначала запускает dotnet restore, затем dotnet build и, наконец, terraform apply. И это все, что мне нужно для развертывания моего приложения в AWS. Я считаю, что это более настраиваемый подход, чем использование Serverless Cloudformation с CLI dotnet.

Надеюсь, это помогло!

...