Внедрение бесконтактного триггера по запросу для облака

Используйте электронную почту, чтобы держать людей подальше от вашей инфраструктуры

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

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

Предстоящий шаблон удовлетворяет два основных функциональных требования:

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

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

Примечание. Проверка домена в AWS выходит за рамки этой статьи, но она необходима для использования почтовых сервисов AWS. См. Здесь и здесь для получения информации о том, как это сделать.

Общая архитектура

Чтобы удовлетворить требования, нам необходимо реализовать три функции:

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

Каждая из этих функций превращается в один сервис в экосистеме AWS:

  • Простая служба электронной почты (SES) принимает сообщения извне и пересылает их. Для этого нам нужно реализовать соответствующее правило.
  • Темы Simple Notification Service (SNS) принимают пересылаемую почту и передают ее. Поскольку социальная сеть рассылает сообщения всем подписчикам, нам не нужно внедрять механизм опроса.
  • Бессерверные функции Lambda обрабатывают все, что мы хотим запустить с помощью нашей архитектуры.

Вот графический обзор этой простой архитектуры:

Принимающая сторона и логика обработки соединяются через тему SNS. Темы социальных сетей работают через парадигму публикации / подписки. То есть SES публикует входящую почту в тему SNS; функция Lambda автоматически получает их через свою подписку на нее.

В этом сообщении блога я показываю реализацию в Terraform, но вы также можете реализовать эту архитектуру через веб-интерфейс или CloudFormation. Если у вас нет опыта работы с Terraform, ознакомьтесь с их вводным материалом или не обращайте внимания на подробности. Имейте в виду, что AWS настраивает некоторые детали в фоновом режиме при использовании веб-интерфейса. Это удобно, но может вызвать проблемы, если вам потребуется отладить инфраструктуру.

Детали реализации

Прежде чем мы сможем приступить к определению ресурсов, нам необходимо предоставить Terraform сведения о провайдере. То есть нам нужно определить профиль и регион. На момент написания только три региона позволяют получать электронные письма через SES.

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

Давайте углубимся в каждую из трех служб нашей архитектуры.

Простая электронная почта (SES)

Для работы SES необходимы два компонента: набор правил и правило. Думайте о наборе правил как о зонтике для всех правил, которые использует система. В качестве примечания убедитесь, что набор правил активен. В зависимости от ваших настроек может быть уже установлен набор правил по умолчанию. Terraform имеет два разных ресурса, поэтому убедитесь, что вы используете правильный, то есть тот, в названии которого есть active.

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

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

Как можно понять из аргумента position, в одном правиле можно применять несколько различных действий.

Простая служба уведомлений (SNS)

Наш дизайн работает с двумя темами социальных сетей. SES использует первый для публикации входящих писем. Второй уведомляет команду разработчиков о том, кто инициировал новое вычисление. Единственный необходимый параметр для их создания - это название темы:

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

Примечание: вы не можете использовать Terraform для подписки адресов электронной почты на темы социальных сетей, так как они должны быть проверены (подробности).

Лямбда

Для наших целей достаточно одной лямбда-функции. Бессерверные функции имеют ограничения с точки зрения вычислительной мощности, поэтому вы можете подумать о переходе на другие варианты. Однако использование их в качестве отправной точки для рабочих процессов, как правило, является хорошей практикой. Имея это в виду, давайте посмотрим на разные части, чтобы запустить функцию.

Мы предоставляем код функции в виде ZIP-файла. К счастью, в Terraform есть тип данных, который покрывает это. Все, что нам нужно сделать, это определить исходный и целевой файл. Я предоставляю элементарную функцию в репозитории GitHub.

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

Спецификация функционального ресурса может выглядеть довольно устрашающе. Позвольте мне провести вас по каждому параметру по очереди:

  • имя файла указывает на ZIP-файл, содержащий код.
  • Terraform сравнивает хэш исходного кода, чтобы обнаружить изменения в кодовой базе. К счастью, ресурс data предоставляет этот хэш автоматически.
  • обработчик - это имя функции в коде, которую функция лямбда выполняет при запуске. Здесь информация о Python, но документация охватывает также Node.js, Ruby, Java и другие.
  • Роль - это роль исполнения, которую мы определили выше.
  • Среда выполнения сообщает AWS, какой язык программирования и версию хочет использовать ваш код. идентификаторы для всех доступных сред выполнения перечислены в официальной документации.
  • Переменные среды предоставляют дополнительную информацию к вашему коду функции. В нашем примере мы используем такую ​​переменную для передачи ARN темы SNS для мониторинга.

Комбинация всех этих параметров выглядит так:

Все, что осталось, - это связь между запускающей темой SNS и функцией Lambda. Чтобы установить эту ссылку, нам необходимо реализовать два ресурса: разрешение для SNS на выполнение Lambda и подписку функции Lambda на тему SNS. Разрешение является предварительным условием для того, чтобы Lambda могла подписаться на тему SNS. Подумайте о разрешении как о специализированном типе политики.

Разрешение - это уникальный ресурс, который в Terraform выглядит так:

С другой стороны, подписка - это общий ресурс, который мы определяем для применения к Lambda в этом случае. То есть мы настраиваем лямбда-функцию как ее конечную точку и соответственно корректируем протокол:

Эти ресурсы охватывают всю архитектуру. Вы можете клонировать нужный код отсюда. Если вы зарегистрировали домен в AWS, на раскрутку уйдет несколько секунд. Теперь вы можете запускать процессы, отправив электронное письмо на указанный адрес. Не забудьте потом все снести, чтобы не тратить деньги.

Если вы ищете другие примеры реализации архитектур на AWS, мои предыдущие сообщения в блоге о бессерверной архитектуре Fargate могут вас заинтересовать:

Поделитесь своими мыслями и опытом в комментариях. Я также рад подключиться к Twitter и LinkedIn. Спасибо за чтение!