1. Введение
Cloud Tasks — это полностью управляемый сервис очередей для управления выполнением, отправкой и доставкой большого количества задач.
Облачные задачи позволяют отделять части работы, называемые задачами , которые можно выполнять независимо (например, задача обновления записи базы данных) вне основного потока приложения, и отправлять их на обработку асинхронно, используя обработчики, которые ты создаешь.
Выгруженная задача добавляется в очередь , в которой задача сохраняется до тех пор, пока она не будет успешно выполнена или не произойдет сбой. В зависимости от конфигурации очередь также может действовать как элемент управления потоком отправки. Вы создаете и настраиваете очередь, которой затем управляет служба Cloud Tasks. После добавления задач очередь отправляет задачи и обеспечивает их надежную обработку рабочими процессами.
Некоторые из основных функций Cloud Tasks:
- Цели HTTP: добавляйте задачи, предназначенные для любой службы HTTP, работающей в Compute Engine, Google Kubernetes Engine, Cloud Run, Cloud Functions или локальных системах, безопасным способом, используя стандартную аутентификацию OAuth/OIDC.
- Дедупликация задач . Задачи, добавленные несколько раз, будут отправлены только один раз.
- Гарантированная доставка : задачи гарантированно будут доставлены хотя бы один раз, и большинство задач доставляются ровно один раз.
- Элементы управления скоростью и повторами. Управляйте выполнением, устанавливая скорость отправки задач, максимальное количество попыток и минимальное время ожидания между попытками.
- Планирование на будущее: контролируйте время выполнения задачи.
В этой лабораторной работе вы сначала узнаете, как создавать и использовать обычную очередь облачных задач для целевых задач HTTP. Затем вы узнаете, как использовать переопределение URI HTTP на уровне очереди и новый API BufferTask, чтобы упростить буферизацию HTTP-запросов с помощью Cloud Tasks.
Что вы узнаете
- Как создавать целевые задачи HTTP.
- Как создавать целевые задачи HTTP с новым переопределением URI HTTP на уровне очереди.
- Как изменить ожидающие задачи с помощью нового переопределения URI HTTP на уровне очереди.
- Как упростить буферизацию HTTP-запросов с помощью нового API BufferTask.
2. Настройка и требования
Самостоятельная настройка среды
- Войдите в Google Cloud Console и создайте новый проект или повторно используйте существующий. Если у вас еще нет учетной записи Gmail или Google Workspace, вам необходимо ее создать .
- Имя проекта — это отображаемое имя для участников этого проекта. Это строка символов, не используемая API Google. Вы всегда можете обновить его.
- Идентификатор проекта уникален для всех проектов Google Cloud и является неизменяемым (нельзя изменить после его установки). Cloud Console автоматически генерирует уникальную строку; обычно тебя не волнует, что это такое. В большинстве лабораторий кода вам потребуется указать идентификатор проекта (обычно идентифицируемый как
PROJECT_ID
). Если вам не нравится сгенерированный идентификатор, вы можете создать другой случайный идентификатор. Альтернативно, вы можете попробовать свой собственный и посмотреть, доступен ли он. Его нельзя изменить после этого шага и он сохраняется на протяжении всего проекта. - К вашему сведению, есть третье значение — номер проекта , которое используют некоторые API. Подробнее обо всех трех этих значениях читайте в документации .
- Далее вам необходимо включить выставление счетов в Cloud Console, чтобы использовать облачные ресурсы/API. Прохождение этой лаборатории кода не будет стоить много, если вообще что-то стоить. Чтобы отключить ресурсы и избежать выставления счетов за пределами этого руководства, вы можете удалить созданные вами ресурсы или удалить проект. Новые пользователи Google Cloud имеют право на участие в программе бесплатной пробной версии стоимостью 300 долларов США .
Запустить Cloud Shell
Хотя Google Cloud можно управлять удаленно с вашего ноутбука, в этой лаборатории вы будете использовать Google Cloud Shell , среду командной строки, работающую в облаке.
В Google Cloud Console щелкните значок Cloud Shell на верхней правой панели инструментов:
Подготовка и подключение к среде займет всего несколько минут. Когда все будет готово, вы должны увидеть что-то вроде этого:
Эта виртуальная машина оснащена всеми необходимыми инструментами разработки. Он предлагает постоянный домашний каталог объемом 5 ГБ и работает в Google Cloud, что значительно повышает производительность сети и аутентификацию. Всю работу в этой лаборатории кода можно выполнять в браузере. Вам не нужно ничего устанавливать.
3. Создайте регулярную очередь для целевых задач HTTP.
На этом первом этапе вы узнаете, как создать обычную очередь облачных задач и добавить в нее задачи HTTP для целевой службы Cloud Run.
Что такое целевые задачи HTTP?
Целевые задачи HTTP могут быть ориентированы на любую службу HTTP, работающую в Compute Engine, Google Kubernetes Engine, Cloud Run, Cloud Functions или локальных системах, безопасным способом с использованием стандартной аутентификации OAuth/OIDC.
Развертывание службы Cloud Run
Сначала убедитесь, что необходимые API включены:
gcloud services enable \ cloudtasks.googleapis.com \ run.googleapis.com
Разверните службу Cloud Run, которая будет служить целью задач HTTP:
SERVICE1=hello1 REGION=us-central1 gcloud run deploy $SERVICE1 \ --allow-unauthenticated \ --image=gcr.io/cloudrun/hello \ --region=$REGION
Создайте очередь облачных задач
Создайте обычную очередь облачных задач:
QUEUE1=http-queue LOCATION=us-central1 gcloud tasks queues create $QUEUE1 --location=$LOCATION
Временно приостановите очередь, чтобы вы могли наблюдать за созданием задач HTTP:
gcloud tasks queues pause $QUEUE1 --location=$LOCATION
4. Создайте и протестируйте задачу HTTP.
На этом этапе вы создадите задачу HTTP для созданной ранее очереди.
Создайте задачу HTTP
Вы можете создавать задачи HTTP с помощью gcloud
:
gcloud tasks create-http-task \ --queue=$QUEUE1 \ --location=$LOCATION \ --url=$SERVICE1_URL \ --method=GET
Необязательно: вы также можете создать задачу HTTP с клиентскими библиотеками. Например, вы можете просмотреть Program.cs
для примера C#, где HTTP-запрос оборачивается в Task
и TaskRequest
перед отправкой в Cloud Tasks с помощью CloudTasksClient
:
var taskRequest = new CreateTaskRequest { Parent = new QueueName(projectId, location, queue).ToString(), Task = new Task { HttpRequest = new HttpRequest { HttpMethod = HttpMethod.Get, Url = url } } }; var client = CloudTasksClient.Create(); var response = client.CreateTask(taskRequest);
Вы можете запустить его следующим образом, чтобы создать и добавить задачу в очередь:
dotnet run $PROJECT_ID $LOCATION $QUEUE1 $SERVICE1_URL
Проверьте задачу HTTP
На этом этапе задача создана, но еще не выполнена, так как очередь приостановлена. Убедиться в этом можно, перечислив очереди:
gcloud tasks queues list --location=$LOCATION
Вы должны увидеть очередь в состоянии PAUSED
:
QUEUE_NAME STATE http-queue PAUSED
Возобновить очередь:
gcloud tasks queues resume $QUEUE --location=$LOCATION
Проверьте логи сервиса Cloud Run:
gcloud logging read "resource.type=cloud_run_revision AND resource.labels.service_name=$SERVICE1" --limit 1
Вы должны увидеть, что служба Cloud Run получила HTTP-запрос GET от Cloud Tasks:
httpRequest: latency: 0.227597158s protocol: HTTP/1.1 remoteIp: 35.243.23.192 requestMethod: GET requestSize: '415' requestUrl: https://hello1-idcwffc3yq-uc.a.run.app/ responseSize: '5510' serverIp: 216.239.32.53 status: 200 userAgent: Google-Cloud-Tasks
5. Создайте очередь с настройкой маршрутизации.
На этом этапе вы узнаете, как создать очередь облачных задач с конфигурацией маршрутизации для добавления переопределения URI HTTP с помощью функции настройки маршрутизации задач на уровне очереди . Затем вы добавите к нему задачи HTTP, чтобы нацелиться на первую службу Cloud Run, и увидите, что конфигурация маршрутизации переопределяет URI для маршрутизации задач во вторую службу Cloud Run.
Что такое конфигурация маршрутизации задач на уровне очереди?
Конфигурация маршрутизации задач на уровне очереди изменяет маршрутизацию задач HTTP для всей очереди для всех ожидающих и новых задач. Это упрощает создание задач, поскольку цель HTTP не требуется задавать на уровне задачи, а также передает больше контроля поставщику услуг, поскольку он может установить цель для всех задач в очереди (например, направить трафик на другой бэкэнд). если исходный бэкэнд не работает).
На уровне очереди можно задать следующую конфигурацию:
- Заголовки : заголовки уровня очереди, если они указаны на уровне очереди, будут добавлять заголовки для всех задач в очереди.
- Метод HTTP : метод HTTP, если он указан на уровне очереди, будет переопределять метод HTTP для всех задач в очереди.
- Целевой URI : хост, путь, запрос, порт, схема (HTTP или HTTPS) могут быть переопределены индивидуально.
- Авторизация : конфигурация OIDC/OAuth, если она указана на уровне очереди, переопределяет конфигурацию OIDC/OAuth уровня задачи.
Развертывание второго сервиса Cloud Run
Разверните вторую службу Cloud Run, которая позже будет служить целью переопределения URI HTTP:
SERVICE2=hello2 REGION=us-central1 gcloud run deploy $SERVICE2 \ --allow-unauthenticated \ --image=gcr.io/cloudrun/hello \ --region=$REGION
Сохраните хост URL-адреса службы на будущее:
SERVICE2_URL=$(gcloud run services describe $SERVICE2 --region $REGION --format 'value(status.url)') SERVICE2_HOST=$(echo $SERVICE2_URL | sed 's,http[s]*://,,g')
Создайте очередь облачных задач с настройкой маршрутизации.
Создайте очередь с конфигурацией маршрутизации с переопределением URI HTTP ко второй службе Cloud Run.
QUEUE2=http-queue-uri-override gcloud beta tasks queues create $QUEUE2 \ --http-uri-override=host:$SERVICE2_HOST \ --location=$LOCATION
Обратите внимание, что переопределение URI относится ко второй службе Cloud Run. Для любой задачи HTTP, добавленной в очередь, будет переопределен исходный узел URI. Вы можете увидеть конфигурацию очереди:
gcloud beta tasks queues describe $QUEUE2 --location=$LOCATION
Вы должны увидеть, что httpTarget
имеет uriOverride
, указывающий на хост второй службы:
httpTarget: uriOverride: host: hello2-idcwffc3yq-uc.a.run.app pathOverride: {} queryOverride: {} ...
Временно приостановите очередь, чтобы вы могли наблюдать за созданием задач HTTP:
gcloud tasks queues pause $QUEUE2 --location=$LOCATION
6. Создайте и протестируйте задачу HTTP для очереди с конфигурацией маршрутизации.
На этом этапе вы создадите задачу HTTP для первой службы и увидите, что ее URI переопределяется очередью, чтобы указать на вторую службу.
Создайте HTTP-задачу
Создайте задачу HTTP с URL-адресом первой службы:
gcloud tasks create-http-task \ --queue=$QUEUE2 \ --location=$LOCATION \ --url=$SERVICE1_URL \ --method=GET
Проверьте задачу HTTP
Возобновить очередь:
gcloud tasks queues resume $QUEUE2 --location=$LOCATION
Вы должны увидеть, что второй (не первый) сервис Cloud Run получил HTTP-запрос GET от Cloud Tasks из-за переопределения:
gcloud logging read "resource.type=cloud_run_revision AND resource.labels.service_name=$SERVICE2" --limit 1
--- httpRequest: latency: 0.228982142s protocol: HTTP/1.1 remoteIp: 35.187.132.84 requestMethod: GET requestSize: '426' requestUrl: https://hello2-idcwffc3yq-uc.a.run.app/ responseSize: '5510' serverIp: 216.239.34.53 status: 200 userAgent: Google-Cloud-Tasks
7. Измените ожидающие задачи с помощью конфигурации маршрутизации.
Вы также можете использовать конфигурацию маршрутизации для изменения URI HTTP всех ожидающих задач в очереди. Это полезно, если серверная служба выходит из строя и вы хотите быстро переключиться на другую службу. Давайте посмотрим, как это работает на этом этапе.
Приостановите очередь еще раз:
gcloud tasks queues pause $QUEUE2 --location=$LOCATION
Создайте задачу HTTP с google.com
в качестве URL-адреса задачи:
gcloud tasks create-http-task \ --queue=$QUEUE2 \ --location=$LOCATION \ --url=https://www.google.com \ --method=GET
Задача находится в состоянии ожидания, поскольку очередь приостановлена.
Теперь обновите переопределение HTTP URI, чтобы оно указывало на первую службу. Это приведет к переопределению хоста ожидающей задачи с google.com
на хост первой службы:
SERVICE1_URL=$(gcloud run services describe $SERVICE1 --region $REGION --format 'value(status.url)') SERVICE1_HOST=$(echo $SERVICE1_URL | sed 's,http[s]*://,,g') gcloud beta tasks queues update $QUEUE2 \ --http-uri-override=host:$SERVICE1_HOST \ --location=$LOCATION
Возобновить очередь:
gcloud tasks queues resume $QUEUE2 --location=$LOCATION
Вы должны увидеть, что первая служба Cloud Run получила HTTP-запрос GET от Cloud Tasks из-за переопределения (вместо google.com
):
gcloud logging read "resource.type=cloud_run_revision AND resource.labels.service_name=$SERVICE1" --limit 1 --- httpRequest: latency: 0.228982142s protocol: HTTP/1.1 remoteIp: 35.187.132.84 requestMethod: GET requestSize: '426' requestUrl: https://hello1-idcwffc3yq-uc.a.run.app/ responseSize: '5510' serverIp: 216.239.34.53 status: 200 userAgent: Google-Cloud-Tasks
8. Создайте очередь для BufferTask API.
Обычно вы создаете задачи с помощью Tasks API из клиентских библиотек gcloud
или Tasks. Это обременяет приложения переносом HTTP-запросов в задачи с использованием клиентских библиотек, а также создает зависимость между приложениями и клиентскими библиотеками задач.
На этом этапе вы увидите, как воспользоваться переопределением URI HTTP на уровне очереди и новым API BufferTask, чтобы упростить создание целевых задач HTTP, просто отправив HTTP-запрос. Любое приложение, которое может отправлять HTTP-запросы, теперь может создавать целевые задачи HTTP.
Что такое API BufferTask?
API CreateTask — это старый способ создания задач, требующий от клиента отправки объекта Task в API со всеми установленными необходимыми полями.
BufferTask API — это новая функция, которая позволяет пользователям создавать HTTP-задачи без необходимости предоставления какой-либо конфигурации задачи (URL-адрес HTTP, заголовки, авторизация), позволяя вам просто отправлять сообщение или тело вашего запроса в Buffer API.
Это упрощает интеграцию со службами, поскольку облачные задачи теперь можно развертывать перед вашей службой без каких-либо изменений кода на стороне клиента. Любой произвольный HTTP-запрос, отправленный в API BufferTask, будет упакован как объект Task и доставлен в пункт назначения, установленный на уровне очереди.
Чтобы использовать API BufferTask, в очереди должна быть установлена конфигурация Target URI, или, другими словами, функция настройки маршрутизации на уровне очереди является обязательным условием для использования API BufferTask.
Создайте очередь облачных задач с настройкой маршрутизации.
Создайте очередь с конфигурацией маршрутизации, указывающей на первую службу, которую мы развернули на предыдущем шаге:
SERVICE1=hello1 SERVICE1_URL=$(gcloud run services describe $SERVICE1 --region $REGION --format 'value(status.url)') SERVICE1_HOST=$(echo $SERVICE1_URL | sed 's,http[s]*://,,g') QUEUE3=http-queue-uri-override-buffer gcloud beta tasks queues create $QUEUE3 \ --http-uri-override=host:$SERVICE1_HOST \ --location=$LOCATION
Временно приостановите очередь, чтобы вы могли наблюдать за созданием задач HTTP:
gcloud tasks queues pause $QUEUE3 --location=$LOCATION
9. Буферизация HTTP-запросов с помощью BufferTask API.
На этом этапе вы буферизуете простые HTTP-запросы GET или POST с помощью BufferTask API. Под обложкой Cloud Tasks преобразует эти HTTP-запросы в HTTP-задачи с настройками конфигурации маршрутизации по умолчанию для очереди.
Сначала войдите в систему, чтобы получить токен доступа и установите некоторые переменные:
gcloud auth application-default login ACCESS_TOKEN=$(gcloud auth application-default print-access-token) PROJECT_ID=$(gcloud config get-value project) TASKS_QUEUES_API="https://cloudtasks.googleapis.com/v2beta3/projects/$PROJECT_ID/locations/$LOCATION/queues"
Создайте HTTP-задачу
Создайте задачу HTTP с помощью API BufferTask. Обратите внимание, что это простой HTTP-запрос GET без необходимости создания задачи:
curl -X GET "$TASKS_QUEUES_API/$QUEUE3/tasks:buffer" \ -H "Authorization: Bearer $ACCESS_TOKEN"
Создайте еще одну задачу HTTP с HTTP POST и телом:
curl -X POST "$TASKS_QUEUES_API/$QUEUE3/tasks:buffer" \ -H "Authorization: Bearer $ACCESS_TOKEN" \ -d "{'message': 'Hello World'}"
Необязательно: вы также можете создать задачу HTTP с клиентскими библиотеками. Например, вы можете проверить Program.cs
для примера C#, где HTTP-запрос GET отправляется непосредственно в API BufferTask без необходимости оборачивать его в Task
или использовать клиентскую библиотеку для облачных задач:
var BufferTaskApiUrl = $"https://cloudtasks.googleapis.com/v2beta3/projects/{ProjectId}/locations/{Location}/queues/{Queue}/tasks:buffer"; using (var client = new HttpClient()) { client.DefaultRequestHeaders.Add("Authorization", $"Bearer {AccessToken}"); var response = await client.GetAsync(BufferTaskApiUrl); var content = await response.Content.ReadAsStringAsync(); Console.WriteLine($"Response: {content}"); }
Вы можете запустить его следующим образом:
dotnet run $PROJECT_ID $LOCATION $QUEUE3 $ACCESS_TOKEN
API BufferTask заботится о создании задачи из HTTP-запросов и добавляет URL-адрес из настроек конфигурации маршрутизации очереди для URI.
Проверьте задачу HTTP
Возобновить очередь:
gcloud tasks queues resume $QUEUE3 --location=$LOCATION
Вы должны увидеть, что служба Cloud Run получила запросы HTTP GET и POST от Cloud Tasks:
gcloud logging read "resource.type=cloud_run_revision AND resource.labels.service_name=$SERVICE1" --limit 4
--- httpRequest: latency: 0.002279292s protocol: HTTP/1.1 remoteIp: 35.243.23.42 requestMethod: POST requestSize: '777' requestUrl: https://hello1-idcwffc3yq-uc.a.run.app/ responseSize: '5450' serverIp: 216.239.32.53 status: 200 userAgent: Google-Cloud-Tasks ... httpRequest: latency: 0.228982142s protocol: HTTP/1.1 remoteIp: 35.187.132.84 requestMethod: GET requestSize: '426' requestUrl: https://hello1-idcwffc3yq-uc.a.run.app/ responseSize: '5510' serverIp: 216.239.34.53 status: 200 userAgent: Google-Cloud-Tasks
10. Поздравления
Поздравляем, вы завершили работу над кодом!
В качестве продолжения вы можете попробовать Cloud Tasks в качестве буфера между Pub/Sub и Cloud Run, чтобы увидеть реальный пример того, как эти новые функции Cloud Tasks могут помочь легко создать буферную очередь между сервисами.
Очистка (необязательно)
Чтобы избежать расходов, рекомендуется очистить ресурсы.
Если проект вам не нужен, вы можете просто удалить его:
gcloud projects delete $PROJECT_ID
Если вам нужен проект, вы можете удалить ресурсы по отдельности.
Удалите службы Cloud Run:
gcloud run services delete $SERVICE1 --region $REGION gcloud run services delete $SERVICE2 --region $REGION
Удалите очереди облачных задач:
gcloud tasks queues delete $QUEUE1 --location=$LOCATION gcloud tasks queues delete $QUEUE2 --location=$LOCATION gcloud tasks queues delete $QUEUE3 --location=$LOCATION
Что мы рассмотрели
- Как создавать целевые задачи HTTP.
- Как создавать целевые задачи HTTP с новым переопределением URI HTTP на уровне очереди.
- Как изменить ожидающие задачи с помощью нового переопределения URI HTTP на уровне очереди.
- Как упростить буферизацию HTTP-запросов с помощью нового API BufferTask.