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

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

1. Обзор

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

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

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

Механизм приложений
Облачный пожарный магазин
Облачные функции
Облачный бег
Рабочие процессы

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

Самостоятельная настройка среды

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

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

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

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

Запустить Cloud Shell

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

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

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

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

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

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

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

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

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

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

4. Включите API

В ходе этой лабораторной работы вы будете подключать облачные функции и службы 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 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}

Затем рабочие процессы проверяют тип события. Поддерживаются два типа событий: 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

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

Далее давайте взглянем на 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. Создайте сегменты

Вам понадобится 2 корзины для изображений: 1 для сохранения оригинальных изображений с высоким разрешением и 1 для сохранения миниатюр изображений.

Создайте общедоступную региональную (в данном случае в Европе) корзину с единым доступом, в которую пользователи смогут загружать изображения, с помощью инструмента 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 Storage в Cloud Console:

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

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

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

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

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

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

Изучите код

Облачная функция называется 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. Подготовьте базу данных

Далее в рабочих процессах необходимо проверить безопасность изображения на основе данных изображения, а затем сохранить информацию об изображении, возвращаемую Vision API, в базу данных 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 поля:

name (строка): имя файла загруженного изображения, которое также является ключом документа.
labels (массив строк): метки элементов, распознанных 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, и рабочие процессы вызывают эту службу на этапе thumbnailCall :

Изучите код

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

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

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

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

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.

Развертывание в Cloud Run

Установите некоторые необходимые переменные и конфигурацию:

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, и рабочие процессы вызывают эту службу на этапе 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}

Развертывание в Cloud Run

Установите некоторые необходимые переменные и конфигурацию:

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 облачной консоли, и шаг collageCall рабочих процессов сможет вызвать эту службу:

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

Мы развернули все внешние зависимости рабочих процессов. Все оставшиеся шаги ( 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 Storage. Это события storage.object.finalize и storage.object.delete соответственно.

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

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

Изучите код

Облачная функция называется 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: Лабораторная работа 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. Поздравляем!

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

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

Механизм приложений
Облачный пожарный магазин
Облачные функции
Облачный бег
Рабочие процессы