Статьи

Создание сервисного прокси AWS для Amazon SQS

Июль 27, 2017

На прошлой неделе наша команда решила представить API с помощью API-шлюза API Gateway для использования SQS без использования лямбда-функции. Мы начали изучать Amazon API Gateway и нашли несколько учебных пособий для SNS, DDB, S3 и Kinesis, но я не смог найти что-то хорошее для SQS.

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

В этой части работы я собираюсь показать, как описать 

  1. Создайте очередь Amazon SQS.

  2. Создайте политику и роль Amazon IAM (для доступа к очереди SQS).

  3. Опубликовать API на API-шлюзе.

  4. Отправлять и получать сообщения (одиночные и пакетные) через API-шлюз.

Для этой статьи:

  • Я предполагаю, что вы уже создали учетную запись в Amazon и знаете, как использовать управляемые сервисы AWS, включая API-шлюз и SQS.

  • В конце демонстрации НЕ забывайте удалять API, роль и политику IAM и очередь SQS.

Создание очереди Amazon SQS

Это самый простой шаг, вам просто нужно получить доступ к панели инструментов службы SQS и следовать инструкциям:

Выберите Создать новую очередь и введите имя очереди. Если вам нравится, вы можете изменить настройки очереди на ваши предпочтительные настройки. Здесь я собираюсь установить имя очереди в «demoqueue», и я выбрал значения по умолчанию.

После создания очереди запишите ARN вашей очереди (Amazon Resouce Name). ARN — это уникальный идентификатор ресурса, назначенный AWS, и представляет собой комбинацию am: aws: sqs: YOUR-REGION: ACCOUNT-ID: YOUR-QUEUE-NAME. 

После создания своей очереди мне нужно настроить политику и роль IAM для шлюза Amazon API, чтобы получить доступ к очереди «demoqueue». 

Создание политики и роли Amazon IAM 

Как вы, возможно, знаете, вам нужно настроить разрешения (комбинацию ролей и политик) для управляемых сервисов AWS, таких как API-шлюз и Redshift, чтобы они могли получить доступ к вашей очереди. Следующие шаги описывают, как настроить политику IAM и создать настраиваемую роль для Amazon API Gateway для отправки или получения сообщения из демо-очереди.

Переключитесь на панель управления IAM и выберите  вкладку Policies в меню справа; Вы должны увидеть следующее диалоговое окно, затем выберите « Создать политику » и перейдите к следующему шагу

IAM предоставляет вам несколько вариантов: вы можете выбрать либо Генератор политик, либо Создать собственную политику. Если вы хотите начать с шаблона в качестве основы, то вы можете пойти с первым вариантом. В этом руководстве давайте сделаем его простым, просто скопируйте и вставьте следующий пример политики ниже, но не забудьте заменить YOUR-SQS- ARN значением ARN в очереди.  

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Resource": [
                "YOUR-SQS-ARN"
            ],
            "Action": [
                "sqs:SendMessage",
                "sqs:ReceiveMessage"
            ]
        }
    ]
}

Я назвал свою политику apigateway-sqs-demoqueue-access-policy и добавил описание для нее. 

В конце выберите Create Policy и запишите имя политики для следующих нескольких шагов.

На панели инструментов IAM выберите Роли и выберите Создать новую роль . Чтобы создать роль, нам нужно выбрать  тип роли (Amazon API Gateway) и установить доверие к роли, а затем прикрепить политику, созданную на предыдущем шаге, к роли, как показано ниже.

До сих пор мы создали очередь SQS (demoqueue) и роль IAM. У вас должно быть два ARN следующим образом:

Ресурс ARN                 
Amazon SQS

ARN: AWS: SQS: ар-юго-2: ВАШ СЧЕТ-ID- : YOUR-QUEU-NAME
Роль Amazon IAM

arn: aws: iam :: YOUR-ACCOUNT-ID : роль / YOUR-ROLE-NAME

Публикация API на Amazon API Gateway

Чтобы отправлять и получать сообщения в очередь SQS, я собираюсь показать вам, как опубликовать API в Amazon API Gateway, и определить необходимые ресурсы и методы для этого.

Я решил разделить этот шаг на две части: 

  1. Часть A: Создание ресурсов, подресурсов и связанных с ними HTTP-методов.

  2. Часть B: Настройка интеграции методов HTTP и параметров выполнения для службы SQS.

Давайте начнем с части А сейчас!

Часть A: Создание ресурсов, субресурсов и метода HTTP

Как вы можете видеть ниже, мой путь API начинается с версии (/ v1) и сопровождается подресурсом или действием. Вы можете поинтересоваться другими подресурсами, / batch / и / purge, в определении API. Они используются для отправки пакетных сообщений в очередь и для удаления сообщений из очереди, но они не являются обязательными для этого руководства, и вы можете найти их реализацию в моем репозитории GitHub.

POST /v1/send          # Sending a single message [You can use GET as well]
GET /v1/receive       # Recieving messages
DELETE /v1/purge         # Purging a message using handler (optional)
POST /v1/batch/send    # Sending batch messages (optional)
DELETE /v1/batch/purge   # Purging batch messages (optional)

1- Из сервисов AWS выберите Amazon API Gateway;  После отображения панели управления API Gateway выберите « Создать новый API», а затем «  Новый API» .

Как только наш API будет готов, мы должны начать создавать ресурсы API, перечисленные во введении к Части А.

Создайте ресурс / v1, как показано здесь:

Затем создайте подресурс для / v1 / send в ресурсе / v1:

Как только вы закончили создание ресурса, нам нужно добавить метод HTTP (POST) к нашим ресурсам, выбрав « Действие»> «Создать метод» . Для создания метода нам нужно указать тип интеграции (сервис AWS), регион AWS (ваш конкретный регион) и сервис AWS (SQS). В дополнение к этому, для доступа к нашей очереди API-шлюзу требуется разрешенная роль IAM (как упоминалось выше, используйте созданную IAM роль ARN). 

Повторите шаги выше для других подресурсов (вы можете пока игнорировать пакетную очистку и очистку), и вы должны получить следующую структуру:

Теперь мы начнем работать над частью B: Настройка выполнения и интеграции HTTP-методов.

Часть B: Настройка интеграции и выполнения методов HTTP для службы SQS

Как вы можете заметить, после создания каждого ресурса и назначения ему надлежащего метода HTTP (например, / v1 / send — POST) на панели мониторинга шлюза API отобразится следующее представление, которое включает потоки запроса-ответа, внутренние службы или конечные точки назначения. и кнопка тестирования.

В этом разделе мы сосредоточимся только на точках 1 и 2 (как показано на скриншоте выше), а затем попробуем использовать кнопку «Тест», чтобы увидеть результат нашей работы. Для получения дополнительной информации о методах интеграции и выполнения я отошлю вас к документации по API Gateway .

Давайте начнем с / v1 / send и HTTP GET, чтобы отправить сообщение в очередь, используя GET и строку запроса. Выберите  Запрос метода,  а затем  Запрос интеграции  и настройте следующие параметры, как показано на скриншотах:

Для нашего запроса на интеграцию вам необходимо указать настройки:

  1. Переопределение пути (AWS ACCOUNT-ID / QUEUE-NAME)

  2. Роль выполнения (ARN роли IAM, созданный на этапах IAM)

  3. Действие SQS, соответствующее этому ресурсу и выбранному методу HTTP (SendMessage). Не забудьте добавить одинарные кавычки вокруг «SendMessage».

Как только это будет сделано, сохраните и выберите Test, и вы увидите панель тестирования:

Для / v1 / send и HTTP POST не будет никакой конфигурации для  запроса метода . Однако нам нужно проделать дополнительную работу в  пути запроса интеграции следующим образом:

Для раздела Body Mapping Template вы можете использовать следующий фрагмент кода:

Action=SendMessage&MessageBody=$util.urlEncode($util.escapeJavaScript($input.json('$')))

Теперь мы собираемся настроить API (/ v1 / receive) для чтения сообщений из очереди SQS. Просматривая документацию по SQS, вы можете направить несколько параметров в службу SQS для сканирования очереди и получения ваших сообщений. Для этой демонстрации я собираюсь передать только их подмножество, включая AttributeName (все), MaxNumberOfMessages (от 1 до 10) и VisibilityTimeout. 

Выберите / v1 / receive, метод GET, а затем запрос метода,  как показано ниже:

После того, как мы настроили запрос метода , выберите метод интеграции  и настройте:

  1. Переопределение пути (AWS ACCOUNT-ID / QUEUE-NAME)

  2. Роль выполнения (ARN роли IAM, созданный на этапах IAM)

  3. Действие SQS, соответствующее этому ресурсу и выбранному методу HTTP ( ReceiveMessage ). Не забудьте добавить одинарные кавычки вокруг «ReceiveMessage».

После настройки интеграции нашего метода для / v1 / receieve теперь вы можете протестировать его и попробовать прочитать сообщения из очереди:

На данный момент вы должны иметь возможность отправлять и получать сообщения из очереди, используя кнопку тестирования. Однако вы не можете удалить (очистить) или отправить пакетные сообщения в свою очередь. Мы также не опубликовали этот API для внешнего мира. 

Публикация API проста: вам просто нужно создать этап и опубликовать ваш API, но вам нужно позаботиться о безопасности вашего API и спланировать механизм аутентификации.

Если вы хотите узнать, как настроить чистку и пакетные запросы, я предлагаю посмотреть на конфигурацию шлюза API и Postman в моем репозитории GitHub . 

То, о чем я все еще думаю и изучаю, — это добавление дополнительных функций в мой API, таких как создание или перечисление моих очередей, а также защита моего API с помощью Amazon Cognito и IAM.

Надеюсь, вам понравился этот урок, и присылайте мне свои отзывы и вопросы.

32
Share: