Эта страница переведена с помощью Cloud Translation API.

Pic-a-daily: Лабораторная работа 6. Согласование с рабочими процессами

1. Обзор

В предыдущих лабораторных работах вы создали версию приложения Pic-a-daily, управляемую событиями, которая использовала Cloud Function, запускаемую Google Cloud Storage, для службы анализа изображений, контейнер Cloud Run, запускаемый GCS через Pub/Sub, для службы создания миниатюр и Eventarc для запуска службы сборки мусора изображений в Cloud Run. Также существовала служба создания коллажей, запускаемая Cloud Scheduler.

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

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

Что вы узнаете

App Engine
Облачный Firestore
Облачные функции
Cloud Run
Рабочие процессы

2. Настройка и требования

Настройка среды для самостоятельного обучения

Войдите в Cloud Console и создайте новый проект или используйте существующий. (Если у вас еще нет учетной записи Gmail или Google Workspace, вам необходимо ее создать .)

Запомните идентификатор проекта (Project ID) — уникальное имя для всех проектов Google Cloud (указанное выше имя уже занято и вам не подойдёт, извините!). В дальнейшем в этом практическом занятии оно будет обозначаться как PROJECT_ID .

Далее вам потребуется включить оплату в Cloud Console, чтобы использовать ресурсы Google Cloud.

Выполнение этого практического задания не должно стоить дорого, если вообще что-либо. Обязательно следуйте инструкциям в разделе «Очистка», где указано, как отключить ресурсы, чтобы избежать дополнительных расходов после завершения этого урока. Новые пользователи Google Cloud имеют право на бесплатную пробную версию стоимостью 300 долларов США .

Запустить Cloud Shell

Хотя Google Cloud можно управлять удаленно с ноутбука, в этом практическом занятии вы будете использовать Google Cloud Shell — среду командной строки, работающую в облаке.

В консоли GCP щелкните значок Cloud Shell на панели инструментов в правом верхнем углу:

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

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

3. Введение в рабочие процессы

С помощью Workflows можно создавать бессерверные рабочие процессы, которые связывают ряд бессерверных задач в заданном вами порядке. Вы можете объединить возможности API Google Cloud, бессерверных продуктов, таких как Cloud Functions и Cloud Run, и вызовов внешних API для создания гибких бессерверных приложений.

Как и следовало ожидать от оркестратора, Workflows позволяет определять поток бизнес-логики на языке описания рабочих процессов на основе YAML/JSON и предоставляет API выполнения рабочих процессов и пользовательский интерфейс для запуска этих потоков.

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

Гибкая обработка повторных попыток и ошибок между этапами для надежного выполнения шагов.
Парсинг JSON и передача переменных между этапами позволяют избежать использования связующего кода.
Формулы выражений для принятия решений позволяют выполнять шаги в зависимости от условий.
Вспомогательные рабочие процессы для модульного и многократно используемого использования.
Поддержка внешних сервисов позволяет осуществлять оркестрацию сервисов за пределами Google Cloud.
Поддержка аутентификации в Google Cloud и внешних сервисах для безопасного выполнения шагов.
Коннекторы к сервисам Google Cloud, таким как Pub/Sub, Firestore, Tasks, Secret Manager, для упрощения интеграции.

Кроме того, Workflows — это полностью управляемый бессерверный продукт. Не нужно настраивать или масштабировать серверы, и вы платите только за то, что используете.

4. Включите API.

В этой лабораторной работе вы будете подключать сервисы Cloud Functions и Cloud Run к рабочим процессам. Вы также будете использовать App Engine, Cloud Build, Vision API и другие сервисы.

В Cloud Shell убедитесь, что все необходимые службы включены:

gcloud services enable \
  appengine.googleapis.com \
  cloudbuild.googleapis.com \
  cloudfunctions.googleapis.com \
  compute.googleapis.com \
  firestore.googleapis.com \
  run.googleapis.com \
  vision.googleapis.com \
  workflows.googleapis.com \

Через некоторое время вы должны увидеть, что операция успешно завершилась:

Operation "operations/acf.5c5ef4f6-f734-455d-b2f0-ee70b5a17322" finished successfully.

5. Получите код

Если вы еще не получили код в предыдущих практических заданиях, скачайте его:

git clone https://github.com/GoogleCloudPlatform/serverless-photosharing-workshop

Для выполнения этой лабораторной работы у вас будет следующая структура папок:

frontend
 |
workflows
 |
 ├── functions
 ├── |── trigger-workflow
 ├── |── vision-data-transform
 ├── services
 ├── |── collage
 ├── |── thumbnails
 ├── workflows.yaml

Вот соответствующие папки:

В состав frontend входит интерфейс App Engine, который мы будем повторно использовать из лабораторной работы №4.
В functions содержатся облачные функции, созданные для рабочего процесса.
В состав services входят службы Cloud Run, модифицированные для рабочего процесса.
workflows.yaml — это файл определения рабочего процесса.

6. Изучите YAML-файлы рабочих процессов.

Файл workflows.yaml определяет рабочий процесс в виде последовательности шагов. Давайте рассмотрим его подробнее, чтобы лучше понять.

В начале рабочего процесса передаются некоторые параметры. Они будут переданы двумя облачными функциями, запускающими рабочие процессы. Мы рассмотрим эти функции позже, но вот как запускается рабочий процесс:

В формате YAML видно, что эти параметры присваиваются переменным на этапе init , таким как имена файлов и сегментов, запускающих событие, а также URL-адреса некоторых служб Cloud Functions и Cloud Run, которые будут вызываться рабочими процессами:

main:
  params: [args]
  steps:
    - init:
        assign:
          - file: ${args.file}
          - bucket: ${args.bucket}
          - gsUri: ${"gs://" + bucket + "/" + file}
          - projectId: ${sys.get_env("GOOGLE_CLOUD_PROJECT_ID")}
          - urls: ${args.urls}

Далее, рабочие процессы проверяют тип события. Поддерживаются 2 типа событий: object.finalize (срабатывает при сохранении файла в облачном хранилище) и object.delete (срабатывает при удалении файла). Любой другой тип события вызовет исключение "Событие не поддерживается".

Вот шаг в определении рабочего процесса YAML, где мы проверяем тип события сохранения файла:

    - eventTypeSwitch:
        switch:
            - condition: ${args.eventType == "google.storage.object.finalize"}
              next: imageAnalysisCall
            - condition: ${args.eventType == "google.storage.object.delete"}
              next: pictureGarbageCollectionGCS
    - eventTypeNotSupported:
        raise: ${"eventType " + args.eventType + " is not supported"}
        next: end

Обратите внимание, как Workflows поддерживает операторы switch и обработку исключений, используя инструкцию switch с различными условиями, а также инструкцию raise для генерации ошибки, если событие не распознано.

Далее рассмотрим вызов imageAnalysisCall . Это серия вызовов из рабочих процессов для обращения к Vision API с целью анализа изображения, преобразования данных ответа Vision API для сортировки меток объектов, распознанных на изображении, выбора доминирующих цветов, проверки безопасности изображения для отображения, а затем сохранения метаданных в Cloud Firestore.

Обратите внимание, что все операции выполняются в рамках рабочих процессов, за исключением облачных функций Vision Transform (которые мы развернем позже):

Вот как выглядят эти шаги в формате YAML:

    - imageAnalysisCall:
        call: http.post
        args:
          url: https://vision.googleapis.com/v1/images:annotate
          headers:
            Content-Type: application/json
          auth:
            type: OAuth2
          body:
            requests:
            - image:
                source:
                  gcsImageUri: ${gsUri}
              features:
              - type: LABEL_DETECTION
              - type: SAFE_SEARCH_DETECTION
              - type: IMAGE_PROPERTIES
        result: imageAnalysisResponse
    - transformImageAnalysisData:
        call: http.post
        args:
          url: ${urls.VISION_DATA_TRANSFORM_URL}
          auth:
            type: OIDC
          body: ${imageAnalysisResponse.body}
        result: imageMetadata
    - checkSafety:
        switch:
          - condition: ${imageMetadata.body.safe == true}
            next: storeMetadata
        next: end
    - storeMetadata:
        call: http.request
        args:
          url: ${"https://firestore.googleapis.com/v1/projects/" + projectId + "/databases/(default)/documents/pictures/" + file + "?updateMask.fieldPaths=color&updateMask.fieldPaths=labels&updateMask.fieldPaths=created"}
          auth:
            type: OAuth2
          method: PATCH
          body:
            name: ${"projects/" + projectId + "/databases/(default)/documents/pictures/" + file}
            fields:
              color:
                stringValue: ${imageMetadata.body.color}
              created:
                timestampValue: ${imageMetadata.body.created}
              labels:
                arrayValue:
                  values: ${imageMetadata.body.labels}
        result: storeMetadataResponse

После анализа изображения следующие два шага — создание миниатюры изображения и коллажа из последних изображений. Это делается путем развертывания двух сервисов Cloud Run и выполнения вызовов к ним на этапах thumbnailCall и collageCall :

Этапы работы с YAML:

   - thumbnailCall:
        call: http.post
        args:
          url: ${urls.THUMBNAILS_URL}
          auth:
            type: OIDC
          body:
              gcsImageUri: ${gsUri}
        result: thumbnailResponse
    - collageCall:
        call: http.get
        args:
          url: ${urls.COLLAGE_URL}
          auth:
            type: OIDC
        result: collageResponse

Данная ветвь выполнения завершается возвратом кодов состояния от каждой службы на этапе finalizeCompleted :

    - finalizeCompleted:
        return:
          imageAnalysis: ${imageAnalysisResponse.code}
          storeMetadata: ${storeMetadataResponse.code}
          thumbnail: ${thumbnailResponse.code}
          collage: ${collageResponse.code}

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

Этапы работы с YAML:

    - pictureGarbageCollectionGCS:
        try:
          call: http.request
          args:
            url: ${"https://storage.googleapis.com/storage/v1/b/thumbnails-" + projectId + "/o/" + file}
            auth:
              type: OAuth2
            method: DELETE
          result: gcsDeletionResult
        except:
          as: e
          steps:
              - dummyResultInOutVar:
                  assign:
                      - gcsDeletionResult:
                          code: 200
                          body: "Workaround for empty body response"
    - pictureGarbageCollectionFirestore:
        call: http.request
        args:
          url: ${"https://firestore.googleapis.com/v1/projects/" + projectId + "/databases/(default)/documents/pictures/" + file}
          auth:
            type: OAuth2
          method: DELETE
        result: firestoreDeletionResult

Ветка удаления завершается возвратом результатов/кодов каждого шага:

    - deleteCompleted:
        return:
          gcsDeletion: ${gcsDeletionResult}
          firestoreDeletion: ${firestoreDeletionResult.code}

На следующих этапах мы создадим все внешние зависимости для рабочих процессов: корзины, облачные функции, сервисы Cloud Run и базу данных Firestore.

7. Создайте корзины.

Для хранения изображений вам потребуется два хранилища: одно для сохранения оригинальных изображений высокого разрешения, а другое — для сохранения миниатюр изображений.

Создайте общедоступный региональный (в данном случае, в Европе) сегмент с единым доступом для загрузки изображений пользователями, используя инструмент gsutil :

export BUCKET_PICTURES=uploaded-pictures-${GOOGLE_CLOUD_PROJECT}
gsutil mb -l EU gs://${BUCKET_PICTURES}
gsutil uniformbucketlevelaccess set on gs://${BUCKET_PICTURES}
gsutil iam ch allUsers:objectViewer gs://${BUCKET_PICTURES}

Создайте еще один общедоступный региональный сегмент для миниатюр:

export BUCKET_THUMBNAILS=thumbnails-${GOOGLE_CLOUD_PROJECT}
gsutil mb -l EU gs://${BUCKET_THUMBNAILS}
gsutil uniformbucketlevelaccess set on gs://${BUCKET_THUMBNAILS}
gsutil iam ch allUsers:objectViewer gs://${BUCKET_THUMBNAILS}

Вы можете убедиться в том, что корзины созданы и являются общедоступными, посетив раздел «Облачное хранилище» в Cloud Console:

8. Преобразование визуальных данных (облачная функция)

Файл Workflows.yaml начинается с шагов init , eventTypeSwitch и eventTypeNotSupported . Они гарантируют, что события, поступающие из сегментов, будут направлены на соответствующие шаги.

В обработчике события object.finalize шаг imageAnalysisCall выполняет вызов к API Vision для извлечения метаданных созданного изображения. Все эти шаги выполняются в рамках рабочих процессов:

Далее нам необходимо преобразовать данные, возвращаемые API Vision, прежде чем мы сможем сохранить их в Firestore. В частности, нам нужно:

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

Это делается в коде в облачной функции, и рабочие процессы просто вызывают эту функцию:

Изучите код

Функция Cloud Function называется vision-data-transform . Полный код можно посмотреть в файле index.js . Как видите, единственная цель этой функции — преобразование JSON в JSON для удобного хранения метаданных изображения в Firestore.

Развертывание в облачных функциях

Перейдите в папку:

cd workflows/functions/vision-data-transform/nodejs

Укажите регион по своему выбору:

export REGION=europe-west1
gcloud config set functions/region ${REGION}

Разверните функцию с помощью:

export SERVICE_NAME=vision-data-transform
gcloud functions deploy ${SERVICE_NAME} \
  --source=. \
  --runtime nodejs10 \
  --entry-point=vision_data_transform \
  --trigger-http \
  --allow-unauthenticated

После развертывания функции шаг transformImageAnalysisData в рабочих процессах сможет вызывать эту функцию для преобразования данных с помощью Vision API.

9. Подготовьте базу данных.

Следующий шаг в рабочих процессах — проверка безопасности изображения на основе данных изображения, а затем сохранение информации об изображении, возвращенной API Vision, в базу данных Cloud Firestore — быструю, полностью управляемую, бессерверную, облачную документоориентированную NoSQL-базу данных:

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

Сначала создайте приложение App Engine в регионе, где вы хотите использовать базу данных Firestore (это обязательное условие для Firestore):

export REGION_FIRESTORE=europe-west2
gcloud app create --region=${REGION_FIRESTORE}

Далее создайте базу данных Firestore в том же регионе:

gcloud firestore databases create --region=${REGION_FIRESTORE}

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

имя (строка): имя файла загруженного изображения, которое также является ключом документа.
метки (массив строк): метки распознанных элементов в Vision API.
цвет (строка): шестнадцатеричный код доминирующего цвета (например, #ab12ef)
дата создания : метка времени сохранения метаданных этого изображения.
миниатюра (логическое значение): необязательное поле, которое будет присутствовать и иметь значение true, если для этого изображения было сгенерировано миниатюрное изображение.

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

gcloud firestore indexes composite create --collection-group=pictures \
  --field-config field-path=thumbnail,order=descending \
  --field-config field-path=created,order=descending

Обратите внимание, что создание индекса может занять до 10 минут.

После создания индекса вы сможете увидеть его в Cloud Console:

Теперь шаг storeMetadata в рабочих процессах сможет сохранять метаданные изображений в Firestore.

10. Сервис создания миниатюр (Cloud Run)

Следующий шаг — создание миниатюры изображения. Это делается программно в службе Cloud Run, и Workflows вызывает эту службу на шаге thumbnailCall :

Изучите код

Сервис Cloud Run называется thumbnails . Полный код можно посмотреть в файле index.js .

Создайте и опубликуйте образ контейнера.

Cloud Run запускает контейнеры, но сначала необходимо создать образ контейнера (определенный в Dockerfile ). Для создания образов контейнеров и их последующего размещения в Google Container Registry можно использовать Google Cloud Build.

Перейдите в папку:

cd workflows/services/thumbnails/nodejs

Строить:

export SERVICE_SRC=thumbnails
export SERVICE_NAME=${SERVICE_SRC}-service
gcloud builds submit \
  . \
  --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/${SERVICE_NAME}

Через минуту-две сборка должна завершиться успешно, и контейнер будет развернут в Google Container Registry.

Развертывание в облаке. Запуск.

Установите необходимые переменные и выполните следующие действия с настройками:

export BUCKET_THUMBNAILS=thumbnails-${GOOGLE_CLOUD_PROJECT}
export REGION=europe-west1
gcloud config set run/region ${REGION}
gcloud config set run/platform managed

Развертывание выполните с помощью следующей команды:

gcloud run deploy ${SERVICE_NAME} \
    --image gcr.io/${GOOGLE_CLOUD_PROJECT}/${SERVICE_NAME} \
    --no-allow-unauthenticated \
    --memory=1Gi \
    --update-env-vars BUCKET_THUMBNAILS=${BUCKET_THUMBNAILS}

После развертывания сервиса шаг thumbnailCall в рабочих процессах сможет вызывать этот сервис.

11. Сервис создания коллажей (Cloud Run)

Следующий шаг — создание коллажа из последних изображений. Это делается программно в службе Cloud Run, и Workflows вызывает эту службу на шаге collageCall :

Изучите код

Сервис Cloud Run называется collage . Полный код можно посмотреть в файле index.js .

Создайте и опубликуйте образ контейнера.

Перейдите в папку:

cd services/collage/nodejs

Строить:

export SERVICE_SRC=collage
export SERVICE_NAME=${SERVICE_SRC}-service
gcloud builds submit \
  . \
  --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/${SERVICE_NAME}

Через минуту-две сборка должна завершиться успешно, и контейнер будет развернут в Google Container Registry.

Развертывание в облаке. Запуск.

Установите необходимые переменные и выполните следующие действия с настройками:

export BUCKET_THUMBNAILS=thumbnails-${GOOGLE_CLOUD_PROJECT}
export REGION=europe-west1
gcloud config set run/region ${REGION}
gcloud config set run/platform managed

Развертывать:

gcloud run deploy ${SERVICE_NAME} \
    --image gcr.io/${GOOGLE_CLOUD_PROJECT}/${SERVICE_NAME} \
    --no-allow-unauthenticated \
    --memory=1Gi \
    --update-env-vars BUCKET_THUMBNAILS=${BUCKET_THUMBNAILS}

После развертывания сервиса вы можете проверить, работают ли оба сервиса, в разделе Cloud Run в Cloud Console, и шаг collageCall в Workflows сможет вызывать этот сервис:

12. Развертывание рабочих процессов

Мы развернули все внешние зависимости Workflows. Все оставшиеся шаги ( finalizeCompleted , pictureGarbageCollectionGCS , pictureGarbageCollectionFirestore , deleteCompleted ) могут быть выполнены самим Workflows.

Пришло время развернуть рабочие процессы!

Перейдите в папку, содержащую файл workflows.yaml , и разверните его с помощью следующей команды:

export WORKFLOW_REGION=europe-west4
export WORKFLOW_NAME=picadaily-workflows
gcloud workflows deploy ${WORKFLOW_NAME} \
  --source=workflows.yaml \
  --location=${WORKFLOW_REGION}

Через несколько секунд рабочий процесс должен развернуться, и вы сможете увидеть его в разделе «Рабочие процессы» в Cloud Console:

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

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

13. Триггеры рабочих процессов (Cloud Functions)

Рабочий процесс развернут и готов. Теперь нам нужно запускать рабочие процессы при создании или удалении файла в хранилище Cloud Storage. Это события storage.object.finalize и storage.object.delete соответственно.

В Workflows есть API и клиентские библиотеки для создания, управления и выполнения рабочих процессов, которые вы можете использовать. В данном случае вы будете использовать API выполнения рабочих процессов , а точнее, его клиентскую библиотеку Node.js для запуска рабочего процесса.

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

Изучите код

Функция Cloud Function называется trigger-workflow . Полный код можно посмотреть в файле index.js .

Развертывание в облачных функциях

Перейдите в папку:

cd workflows/functions/trigger-workflow/nodejs

Установите необходимые переменные и выполните следующие действия с настройками:

export BUCKET_PICTURES=uploaded-pictures-${GOOGLE_CLOUD_PROJECT}
export REGION=europe-west1
export WORKFLOW_NAME=picadaily-workflows
export WORKFLOW_REGION=europe-west4
export COLLAGE_URL=$(gcloud run services describe collage-service --format 'value(status.url)')
export THUMBNAILS_URL=$(gcloud run services describe thumbnails-service --format 'value(status.url)')
export VISION_DATA_TRANSFORM_URL=$(gcloud functions describe vision-data-transform --format 'value(httpsTrigger.url)')
gcloud config set functions/region ${REGION}

Разверните функцию, которая будет реагировать на события завершения:

export SERVICE_NAME=trigger-workflow-on-finalize
gcloud functions deploy ${SERVICE_NAME} \
  --source=. \
  --runtime nodejs10 \
  --entry-point=trigger_workflow \
  --trigger-resource=${BUCKET_PICTURES} \
  --trigger-event=google.storage.object.finalize \
  --allow-unauthenticated \
  --set-env-vars GOOGLE_CLOUD_PROJECT=${GOOGLE_CLOUD_PROJECT},WORKFLOW_REGION=${WORKFLOW_REGION},WORKFLOW_NAME=${WORKFLOW_NAME},THUMBNAILS_URL=${THUMBNAILS_URL},COLLAGE_URL=${COLLAGE_URL},VISION_DATA_TRANSFORM_URL=${VISION_DATA_TRANSFORM_URL}

Разверните вторую функцию, реагирующую на события удаления:

export SERVICE_NAME=trigger-workflow-on-delete
gcloud functions deploy ${SERVICE_NAME} \
  --source=. \
  --runtime nodejs10 \
  --entry-point=trigger_workflow \
  --trigger-resource=${BUCKET_PICTURES} \
  --trigger-event=google.storage.object.delete \
  --allow-unauthenticated \
  --set-env-vars GOOGLE_CLOUD_PROJECT=${GOOGLE_CLOUD_PROJECT},WORKFLOW_REGION=${WORKFLOW_REGION},WORKFLOW_NAME=${WORKFLOW_NAME},THUMBNAILS_URL=${THUMBNAILS_URL},COLLAGE_URL=${COLLAGE_URL},VISION_DATA_TRANSFORM_URL=${VISION_DATA_TRANSFORM_URL}

После завершения развертывания обе функции будут доступны в Cloud Console:

14. Фронтенд (App Engine)

На этом этапе вы создадите веб-интерфейс в Google App Engine на основе Pic-a-daily: Лабораторная работа 4 — Создайте веб-интерфейс , который позволит пользователям загружать изображения из веб-приложения, а также просматривать загруженные изображения и их миниатюры.

Подробнее об App Engine и описание кода можно прочитать в Pic-a-daily: Lab 4 — Создание веб-интерфейса .

Изучите код

Приложение App Engine называется frontend . Полный код можно посмотреть в файле index.js .

Развернуть в App Engine

Перейдите в папку:

cd frontend

Укажите регион по своему выбору, а также замените GOOGLE_CLOUD_PROJECT в файле app.yaml на фактический идентификатор вашего проекта:

export REGION=europe-west1
gcloud config set compute/region ${REGION}
sed -i -e "s/GOOGLE_CLOUD_PROJECT/${GOOGLE_CLOUD_PROJECT}/" app.yaml

Развертывать:

gcloud app deploy app.yaml -q

Через минуту-две вам сообщат, что приложение обрабатывает трафик:

Beginning deployment of service [default]...
╔════════════════════════════════════════════════════════════╗
╠═ Uploading 8 files to Google Cloud Storage                ═╣
╚════════════════════════════════════════════════════════════╝
File upload done.
Updating service [default]...done.
Setting traffic split for service [default]...done.
Deployed service [default] to [https://GOOGLE_CLOUD_PROJECT.appspot.com]
You can stream logs from the command line by running:
  $ gcloud app logs tail -s default
To view your application in the web browser run:
  $ gcloud app browse

Вы также можете перейти в раздел App Engine в Cloud Console, чтобы убедиться, что приложение развернуто, и изучить такие функции App Engine, как версионирование и разделение трафика:

15. Протестируйте рабочие процессы.

Для проверки перейдите по стандартному URL-адресу приложения в App Engine ( https://<YOUR_PROJECT_ID>.appspot.com/ ), и вы должны увидеть работающий пользовательский интерфейс!

Загрузите изображение. Это должно запустить рабочие процессы, и вы сможете увидеть выполнение рабочего процесса в Active состоянии в консоли Cloud Console:

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

Загрузите еще 3 изображения. Вы также должны увидеть обновленные миниатюры и коллаж изображений в хранилищах Cloud Storage и на интерфейсе App Engine:

16. Уборка (необязательно)

Если вы не планируете сохранять приложение, вы можете освободить ресурсы, чтобы сэкономить средства и в целом ответственно относиться к облачным сервисам, удалив весь проект:

gcloud projects delete ${GOOGLE_CLOUD_PROJECT}

17. Поздравляем!

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

Что мы рассмотрели

App Engine
Облачный Firestore
Облачные функции
Cloud Run
Рабочие процессы