Как отделить бессерверный код от кода локального сервера - PullRequest
Новая
       17

Как отделить бессерверный код от кода локального сервера

1 голос
/ 08 июня 2019

В настоящее время у меня есть статическое веб-приложение, которое размещено на хостинге AWS S3.Внутренние API работают на Lambda / API Gateway.У меня есть конвейер непрерывной разработки, который автоматически создает (используя CodeBuild) и развертывает (используя CodeDeploy) мой код из моего репозитория GitHub на S3.

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

Например, я хочу, чтобы моя локальная среда вызывала API с localhost, но я хочу, чтобы моя производственная среда вызывала API с сайта, такого как api.example.com.Также есть некоторый код, который отличается для развертывания в Lambda, который не будет работать локально без отмены изменения.

Другой пример: локально API-интерфейсы работают на сервере Express, но в AWS код требуетбыть завернутым в exports.handler = async (event, context, callback) => {...} для запуска без сервера на Lambda.

Мой вопрос заключается в том, как мне справиться с этими различиями между локальным и без сервера в моем Git-репозитории?

Ответы [ 2 ]

0 голосов
/ 08 июня 2019

Мне кажется, что использование Codepipeline, CodeBuild и Cloudformation для этого может быть хорошим вариантом. Вы не указали, что вы уже используете, поэтому я предлагаю это в качестве примера.

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

В конвейере можно было бы сказать 4 этапа: Source (извлечение исходного кода из git), Build (CodeBuild для создания артефактов сборки), среда Dev / Test и, наконец, Production.

Нечувствительная конфигурация, которую вы можете хранить в git-репо в разных файлах параметров (для стеков приложений облачной информации) для каждой отдельной конфигурации разработки и производства. Вы вводите другой файл параметров (json) для разработки и производства (например, из репозитория github) в стек облачной информации как часть этапа развертывания. Некоторые из них вы также можете внедрить с помощью переопределения параметров (это удобно, например, когда вы хотите использовать «теги сборки», такие как идентификатор фиксации или что-то еще).

Подумайте об использовании Secrets Manager для чувствительных битов, таких как пары имя пользователя / пароль и т. Д. (Или, может быть, все настройки - это тоже вариант). Используйте ключ Secrets Manager для каждой среды. Отправьте ключ Secrets Manager (dev или prod) в заданный стек приложений в качестве входного параметра (облачная информация). Извлеките ключ / значения из Secrets Manager из кода приложения (используйте роль IAM для предоставления привилегий для Lambda для определенных ключей Secrets Manager) и используйте секретное кэширование .

Кроме того, в качестве альтернативы - рассмотрите возможность использования AWS SAM (локально), если вы еще этого не сделали.

Цель этого состоит в том, чтобы:

  • Отделение конфигурации от кода
  • Автоматизируйте ваши сборки и развертывания
  • Свести к минимуму вероятность человеческой ошибки
  • Помогите сократить или полностью устранить простои во время развертываний
  • Простой способ отката (например, git revert)
0 голосов
/ 08 июня 2019

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

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

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

...