Развертывание конфиденциальной рабочей нагрузки в космическом пространстве с использованием MIG-серверов с автомасштабированием, автовосстановлением и обновлениями образов.

1. Обзор

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

В этом практическом занятии вы узнаете, как развернуть рабочую нагрузку «Конфиденциальное пространство» в группе управляемых экземпляров (MIG). Вы также узнаете, как включить автоматическое восстановление с помощью проверок работоспособности, автоматическое масштабирование на основе загрузки ЦП и поэтапные обновления как для образов ОС, так и для рабочих нагрузок.

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

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

  • Как создать специализированный шаблон экземпляра для конфиденциального пространства.
  • Как использовать Google Compute Engine и как настроить MIG-группы и группы экземпляров.
  • Как создать правило брандмауэра и проверку работоспособности для автоматического восстановления.
  • Как настроить зональный MIG-сварочный аппарат с использованием шаблона и проверки работоспособности.
  • Как настроить автоматическое масштабирование для MIG-съёмника.
  • Как настроить обновление образов ОС в один клик с помощью скриптов на MIG-серверах как для образов рабочих нагрузок, так и для новых версий образов ОС для Confidential Space

Что вам понадобится

  • Проект Google Cloud с включенной функцией выставления счетов.
  • Знание текстовых редакторов, развертывания Docker и написания скриптов на Bash.
  • Инструмент командной строки gcloud установлен и прошёл аутентификацию.
  • Базовое понимание Compute Engine, Confidential Space, IAM, Confidential VMs, контейнерных технологий, удаленных репозиториев, сервисных учетных записей, Cloud Run и Cloud Scheduler.
  • Образ контейнера рабочей нагрузки Confidential Space уже создан и загружен в реестр артефактов.

2. Как работает конфиденциальное пространство с использованием MIG-лазеров

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

Потребности в безопасности и эксплуатации производственного сервиса логически разделены между двумя компонентами. Confidential Space обеспечивает необходимую безопасность, запуская рабочую нагрузку в высокоизолированной, зашифрованной и аттестованной среде, называемой доверенной средой выполнения (TEE). В отличие от этого, MIG обеспечивают основные операционные возможности, необходимые для запуска безопасного приложения в масштабе, аналогично Kubernetes. MIG устраняют риски, присущие запуску критически важной рабочей нагрузки на одной виртуальной машине, что может быть потенциально медленным или подверженным сбоям. Такое сочетание обеспечивает как защиту данных, так и надежность системы. Это решение обеспечивает высокую доступность и автоматическое восстановление, поскольку рабочая нагрузка выполняется на нескольких виртуальных машинах в пуле. Если одна виртуальная машина выходит из строя, сервис остается полностью работоспособным благодаря балансировке нагрузки и наличию оставшихся экземпляров.

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

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

Наконец, MIG-модули обеспечивают обновления без простоев благодаря поэтапным обновлениям. Ключевым преимуществом является возможность обновления «в один клик » базового образа ОС Confidential Space или образа контейнера приложения (или обоих), без простоев в работе сервиса. MIG-модуль управляет этим изменением, постепенно заменяя старые экземпляры новыми, работающими на обновленном образе, обеспечивая постоянную доступность на протяжении всего развертывания. Обратите внимание, что для поддержки такого типа поэтапного обновления ваше приложение может нуждаться в обратной совместимости.

3. Настройка облачных ресурсов

Прежде чем начать

  1. Создайте проект Google Cloud. Для получения дополнительной информации о создании проекта Google Cloud обратитесь к руководству «Создание и работа с вашим первым проектом Google» . Подробную информацию о том, как получить идентификатор проекта и чем он отличается от имени и номера проекта, можно найти в разделе «Создание и управление проектами» .
  2. Включите выставление счетов для ваших проектов.
  3. В одном из ваших проектов Google Cloud Shell установите необходимые переменные среды проекта, как показано ниже. 
export  CURRENT_PROJECT_ID=<Google Cloud project id of current project>
  1. Включите API конфиденциальных вычислений и следующие API для вашего проекта . 
gcloud config set project $CURRENT_PROJECT_ID
gcloud services enable \
cloudapis.googleapis.com \
container.googleapis.com \
artifactregistry.googleapis.com \
confidentialcomputing.googleapis.com \
compute.googleapis.com \
logging.googleapis.com \
run.googleapis.com \
cloudscheduler.googleapis.com
  1. В Cloud Shell вашего проекта Google Cloud клонируйте репозиторий Confidential Space Codelab на GitHub и используйте приведенную ниже команду, чтобы получить необходимые скрипты для выполнения этого практического задания. 
git clone https://github.com/GoogleCloudPlatform/confidential-space.git
  1. Перейдите в каталог скриптов для группы экземпляров codelab. 
cd confidential-space/codelabs/mig_cs_codelab/scripts
  1. Обновите строку с идентификатором проекта в файле config_env.sh, указав идентификатор выбранного вами проекта.
  2. Задайте все существующие переменные. Переопределите имена ресурсов, используя эти переменные.
  • Вы можете задать следующие переменные, используя существующие имена облачных ресурсов. Если переменная задана, будут использоваться соответствующие существующие облачные ресурсы из проекта. Если она не задана, имя облачного ресурса будет взято из скрипта config_env.sh.
  1. Запустите скрипт config_env.sh, чтобы установить для остальных переменных проекта значения, основанные на идентификаторе проекта для имен ресурсов. 
source config_env.sh
  1. Добавьте разрешения для проекта. Добавить разрешения можно, следуя инструкциям на странице предоставления роли IAM .

Для этого проекта вам потребуются следующие разрешения.

  • Записывающий модуль в реестр артефактов
  • Администратор облачного планировщика
  • Агент вычислительной службы
  • Конфиденциальный пользователь вычислительной нагрузки
  • Программа для записи логов
  • Разработчик Cloud Run
  • Cloud Run Invoker 
gcloud config set project $CURRENT_PROJECT_ID

# Add Artifact Registry Writer role
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/artifactregistry.writer'

# Add Confidential Space Workload Userd
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/confidentialcomputing.workloadUser'

# Add Logging Log Writer
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/logging.logWriter'

# Add Cloud Run Developer
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/run.developer'

# Add Cloud Run Invoker
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/run.invoker'


# Add Cloud Scheduler Admin
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/cloudscheduler.admin'
  1. Посмотрите файл test_workload.py.
  • Проверьте вывод рабочей нагрузки, просмотрев исходный код; он должен просто вывести текущую версию рабочей нагрузки.
  • Когда мы впервые загрузим нашу рабочую нагрузку в CS и проверим результат, мы должны увидеть сообщение "версия A".

4. Настройка рабочей нагрузки

Сначала вам потребуется создать образ Docker для рабочей нагрузки, используемой в этом практическом задании. Рабочая нагрузка представляет собой простой скрипт, который выводит версию рабочей нагрузки, которая в данный момент запущена. Он выведет сообщение о запуске рабочей нагрузки, затем выведет ее версию, сделает паузу в 5 секунд, а затем выведет сообщение о завершении рабочей нагрузки.

Шаги по созданию рабочей нагрузки

  1. Запустите скрипт create_workload.sh для создания рабочей нагрузки. Этот скрипт:
  • Создает реестр артефактов, принадлежащий проекту, куда будут публиковаться рабочие нагрузки.
  • Создает и упаковывает код в образ Docker. Дополнительную информацию см. в соответствующем файле конфигурации Dockerfile.
  • Публикует образ Docker в реестре артефактов, принадлежащем проекту.
  • Предоставляет учетной записи службы <имя вашей учетной записи службы> права на чтение реестра артефактов <имя репозитория реестра артефактов>.

5. Настройка шаблона экземпляра и MIG

Этапы создания шаблона экземпляра

Сначала необходимо создать шаблон экземпляра . Этот шаблон является обязательным образцом, который группа управляемых экземпляров (MIG) будет использовать для подготовки и запуска ваших рабочих нагрузок в конфиденциальном пространстве.

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

  • Тип машины: В этом примере мы используем виртуальную машину конфиденциального типа (например, n2d-standard-2 ), которая поддерживает технологию конфиденциальных вычислений AMD SEV ( --confidential-compute-type=SEV ).
  • Образ ОС виртуальной машины: Мы используем проект confidential-space-images и семейство образов confidential-space-debug для загрузки последнего образа операционной системы Confidential Space.
  • Примечание: В этом руководстве мы используем отладочный образ для упрощения поиска и устранения неисправностей . В отличие от производственного образа, отладочная версия продолжает работу виртуальной машины после завершения рабочей нагрузки и обеспечивает доступ по SSH для тестирования. Для развертывания в производственной среде с использованием реальных конфиденциальных данных необходимо переключиться на семейство производственных образов.
  • Справочная информация о рабочей нагрузке: Обязательная строка tee-image-reference в метаданных содержит конкретный образ контейнера (рабочая нагрузка вашего приложения), который будет запущен виртуальной машиной Confidential Space.

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

Этапы создания группы управляемых экземпляров

Следующий шаг — создание группы управляемых экземпляров (MIG) с использованием только что определенного шаблона. Группа MIG необходима, поскольку она автоматизирует развертывание, управление и масштабирование нескольких идентичных виртуальных машин.

Скрипт create_launch_mig.sh выполняет три основные задачи:

1. Создайте MIG-файл.

  • Команда: gcloud compute instance-groups managed create ${CURRENT_MIG_NAME}
  • Назначение: Эта команда создает группу, которая будет управлять вашими виртуальными машинами.
  • --size 3 : Указывает, что MIG должен изначально создать и поддерживать 3 экземпляра вашей рабочей нагрузки.
  • --template ${TEMPLATE_NAME} : Важно отметить, что он ссылается на созданный ранее шаблон экземпляра , гарантируя, что все 3 экземпляра настроены как виртуальные машины конфиденциального пространства, на которых запущен ваш конкретный контейнер рабочей нагрузки tee-image-reference .
  • --zone ${CURRENT_PROJECT_ZONE} : Указывает место развертывания экземпляров.

2. Получить номер проекта

  • Команда: PROJECT_NUMBER=$(gcloud projects describe ${PROJECT_ID} --format="value(projectNumber)")
  • Назначение: Скрипт получает числовой идентификатор вашего проекта. Этот номер часто требуется для создания ролей и разрешений учетных записей служб, особенно для агентов служб, управляемых Google.

3. Предоставьте разрешения IAM.

  • Команда: gcloud projects add-iam-policy-binding --role="roles/compute.serviceAgent"
  • Назначение: На этом шаге учетной записи службы вашей рабочей нагрузки ( ${SERVICE_ACCOUNT }) предоставляется роль агента службы Compute Engine . Это разрешение важно, поскольку оно позволяет учетной записи службы действовать от имени службы Compute Engine проекта, что часто необходимо для автоматизированных функций MIG, таких как управление экземплярами, настройка сети и взаимодействие с другими службами Google Cloud.

Запустите скрипт create_launch_mig.sh , чтобы создать группу управляемых экземпляров.

6. Шаги для включения автоматического восстановления и автоматического масштабирования.

Настройка автовосстановления

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

# 1. Create Health Check (TCP Port 22)
gcloud compute health-checks create tcp ${HEALTH_CHECK_NAME} \
  --port 22 \
  --check-interval 30s \
  --healthy-threshold 1 \
  --timeout 10s \
  --unhealthy-threshold 3 \
  --global

# 2. Allow Health Check Traffic (Firewall)
gcloud compute firewall-rules create allow-health-check \
    --allow tcp:22 \
    --source-ranges 130.211.0.0/22,35.191.0.0/16 \
    --network default \
    --project="${CURRENT_PROJECT_ID}" \ 

# 3. Apply to MIG
gcloud compute instance-groups managed update ${CURRENT_MIG_NAME} \
    --health-check ${HEALTH_CHECK_NAME} \
    --initial-delay 60 \
    --zone ${CURRENT_PROJECT_ZONE}

Настройка автомасштабирования

Мы настроим группу таким образом, чтобы она автоматически масштабировалась от 1 до 5 экземпляров для обработки пиковых нагрузок.

gcloud compute instance-groups managed set-autoscaling ${CURRENT_MIG_NAME} \
    --max-num-replicas 5 \
    --target-cpu-utilization 0.80 \
    --cool-down-period 90 \
    --zone ${CURRENT_PROJECT_ZONE}

7. Проверка рабочей нагрузки и настройка обновлений образов.

Проверка рабочей нагрузки

После запуска виртуальных машин группой управляемых экземпляров (MIG) нам необходимо убедиться в корректной работе вашей рабочей нагрузки «Конфиденциальное пространство».

Это можно сделать через консоль Google Cloud или командную строку.

gcloud compute instance-groups managed list-instances ${CURRENT_MIG_NAME} \
    --zone ${CURRENT_PROJECT_ZONE}

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

# Replace <INSTANCE_NAME> with one of the names from the previous command
gcloud compute instances get-serial-port-output <INSTANCE_NAME> \
    --zone ${CURRENT_PROJECT_ZONE} \
    --port 1

Настройка обновления образов

В производственной среде необходимо регулярно обновлять группу управляемых экземпляров (MIG) для решения двух различных задач:

  1. Обновление рабочей нагрузки: выпуск новой версии кода вашего приложения (например, обновление файла test_workload.py с версии 1 до версии 2).
  2. Обновления инфраструктуры: Google выпускает патч безопасности или обновление для базовой ОС Confidential Space. Обратите внимание, что рекомендуется устанавливать последнюю версию образа CS как минимум раз в месяц.

Благодаря тому, что мы настроили наш шаблон экземпляра с динамической ссылкой на образ (.../images/family/...) и динамическим тегом контейнера (:latest), мы можем обрабатывать оба этих сценария с помощью одной операции "постепенной замены". Это гарантирует, что ваш парк виртуальных машин всегда будет работать с самой последней версией стека без простоев и без необходимости создания нового шаблона экземпляра для каждого незначительного изменения.

Скрипт поэтапной замены

В директории update_images перейдите к файлу update_images_script.sh. Этот скрипт запускает поэтапную замену , которая постепенно уничтожает и создает заново каждую виртуальную машину в группе. 

#!/bin/bash

# Initialize the template
gcloud compute instance-groups managed set-instance-template "${CURRENT_MIG_NAME}" \
--template=projects/"${PROJECT_ID}"/global/instanceTemplates/"${TEMPLATE_NAME}" \
--zone="${CURRENT_PROJECT_ZONE}" \
--project="${PROJECT_ID}"

# Trigger the rolling replace
gcloud compute instance-groups managed rolling-action replace "${CURRENT_MIG_NAME}" \
    --version=template="${TEMPLATE_NAME}" \
    --project="${PROJECT_ID}" \
    --zone="${CURRENT_PROJECT_ZONE}" \
    --max-surge=1 \
    --max-unavailable=0

# Wait for the update to complete
gcloud compute instance-groups managed wait-until --version-target-reached "${CURRENT_MIG_NAME}" \
    --zone="${CURRENT_PROJECT_ZONE}" \
    --project="${PROJECT_ID}"

Для этого скрипта мы можем использовать команду replace вместо restart.

  • Перезагрузка просто перезагружает компьютер. Она сохраняет существующий диск с операционной системой, а значит, новые обновления ОС не будут установлены.
  • Операция «Замена» удаляет виртуальную машину и создает новую на основе шаблона. Это заставляет систему искать последний образ ОС из семейства Confidential Space, а также загружать последний образ контейнера из реестра.

–max-surge=1 : Эта опция позволяет MIG временно создать на 1 виртуальную машину больше целевого размера. Она запускает новую (обновленную) виртуальную машину и ожидает, пока она станет работоспособной, прежде чем удалить старую (устаревшую) виртуальную машину.

–max-unavailable=0 : Это гарантирует нулевое время простоя. Это сообщает MIG, что ему не разрешается отключать какое-либо оборудование, если он еще не успешно не заменил его на более мощное.

Сценарий поэтапной перезагрузки

В каталоге update_images также находится еще один скрипт update_workload_image_script.sh. Этот скрипт запускает последовательный перезапуск (Rolling Restart) , это более быстрый метод, используемый исключительно для обновления рабочей нагрузки. Поскольку Confidential Space загружает образ контейнера из реестра при каждой загрузке, перезапуска достаточно для обновления вашего приложения до :latest версии без изменения базового хоста. 

#!/bin/bash
# Reboots the existing VMs to refresh the container
gcloud compute instance-groups managed rolling-action restart "${CURRENT_MIG_NAME}" \
    --project="${PROJECT_ID}" \
    --zone="${CURRENT_PROJECT_ZONE}" \
    --max-surge=1 \
    --max-unavailable=0

# Wait for the update to complete
gcloud compute instance-groups managed wait-until --stable "${CURRENT_MIG_NAME}" \
    --zone="${CURRENT_PROJECT_ZONE}" \
    --project="${CURRENT_PROJECT_ID}"

Проверьте обновленную рабочую нагрузку.

Мы можем протестировать функцию «Обновление в один клик», имитируя реальный запуск приложения. Мы изменим код рабочей нагрузки, отправим его в реестр артефактов, обновим MIG и убедимся, что новая версия работает без простоев.

Шаг 1: Развертывание новой версии рабочей нагрузки

Для начала нам нужно создать «новую» версию вашего приложения.

  1. Откройте локальный файл test_workload.py.
  2. Измените оператор вывода версии с print("Версия рабочей нагрузки A") на print("Версия рабочей нагрузки B")
  3. Пересоберите и загрузите образ контейнера в реестр артефактов, запустив скрипт create_workload.sh. Обратите внимание, что мы загружаем образ в один и тот же тег (:latest).

Шаг 2: Выполните поэтапное обновление.

Запустите скрипт обновления, созданный в предыдущем разделе. Это заставит MIG заменить все виртуальные машины, получив новый хэш контейнера, связанный с :latest. 

# Run your update script
./update_images/update_images_script.sh

Дождитесь завершения выполнения скрипта.

Шаг 3: Проверьте обновление через последовательный порт.

После завершения обновления мы проверяем, работают ли обновленные виртуальные машины на новых машинах. 

# Replace <INSTANCE_NAME> with one of the names from the previous command
gcloud compute instances get-serial-port-output <INSTANCE_NAME> \
    --zone ${CURRENT_PROJECT_ZONE} \
    --port 1

Получите имя нового экземпляра: 

gcloud compute instance-groups managed list-instances ${CURRENT_MIG_NAME} --zone ${CURRENT_PROJECT_ZONE}

Проверьте журналы: 

# Replace <NEW_INSTANCE_NAME> with one of the names of the running VMs
gcloud compute instances get-serial-port-output <NEW_INSTANCE_NAME> \
    --zone ${CURRENT_PROJECT_ZONE} \
    --port 1

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

Ожидаемый результат: Вы должны увидеть обновленное сообщение в журнале, подтверждающее успешное развертывание:

...Версия рабочей нагрузки B ...

Шаг 4: Проверка конфигурации инфраструктуры (необязательно)

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

Выполните следующую команду, чтобы увидеть справочник по динамическим контейнерам: 

gcloud compute instance-templates describe ${TEMPLATE_NAME} \
    | grep -A 1 tee-image-reference

Результат: Вы должны увидеть образ вашего контейнера, заканчивающийся на :latest.

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

(Необязательно) Автоматические обновления

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

Мы можем автоматизировать процесс «поэтапной замены», упаковав наш скрипт обновления в задание Cloud Run. В рамках этого практического занятия мы будем запускать его каждые 15 минут. В производственной среде он должен запускаться гораздо реже. В зависимости от потребностей пользователя, он может настроить его на еженедельную или ежемесячную периодичность.

Шаг 1: Контейнеризация скрипта обновления

Во-первых, нам нужно упаковать наш скрипт update_images_script.sh (который содержит логику замены с помощью gcloud ... rolling-action) в контейнер Docker, чтобы он мог работать в облаке.

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

Выполните следующую команду: 

# Build and Push the "Updater" Container
# This packages your update logic into a docker image
./update_images/deploy_docker_script_image.sh

Что это делает:

  • Эта программа берет файл update_images_script.sh из каталога update_images/.
  • Это создаст образ Docker, содержащий Google Cloud SDK и ваш скрипт.
  • Это отправляет образ в ${CURRENT_PROJECT_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY}/update-script:latest.

Шаг 2: Развертывание и планирование задания

Теперь нам нужно указать Google Cloud периодически запускать этот контейнер. Для выполнения контейнера мы используем Cloud Run Jobs , а для его запуска — Cloud Scheduler .

Запустите скрипт настройки расписания: 

# Create the Cloud Run Job and the Scheduler Trigger
./create_configs/create_schedule_job.sh

Внутри скрипта: Этот скрипт выполняет два важных действия:

  1. Создает задание Cloud Run: определяет задание с именем mig-updater-job, которое выполняет только что загруженный контейнер.
  2. Создает триггер планировщика: настраивает задание Cloud Scheduler для обращения к API Cloud Run Job каждые 15 минут. 
# (Snippet from create_schedule_job.sh for reference)
# The schedule is set to run every 15 minutes for testing purposes
gcloud scheduler jobs create http ${SCHEDULER_NAME} \
    --schedule "*/15 * * * *" \
    --uri "https://${CURRENT_PROJECT_REGION}-run.googleapis.com/apis/run.googleapis.com/v1/namespaces/${PROJECT_ID}/jobs/${JOB_NAME}:run" \
    --http-method POST \
    --oauth-service-account-email ${SERVICE_ACCOUNT}

Шаг 3: Проверка автоматизации

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

  1. Принудительное выполнение задания: 
gcloud scheduler jobs run ${SCHEDULER_NAME} --location ${CURRENT_PROJECT_REGION}
  1. Проверка выполнения: перейдите в консоль Cloud Run > Задания . Вы должны увидеть начало нового выполнения.
  2. Проверьте MIG: выполните команду gcloud compute instance-groups managed list-instances ${CURRENT_MIG_NAME}. Вы увидите, что экземпляры переходят в состояние RECREATING, поскольку задание запускает поэтапное обновление.

Почему 15 минут? Мы установили расписание на */15 * * * * для этого практического задания, чтобы вы могли быстро увидеть результаты. В реальной производственной среде вы, вероятно, изменили бы это время на ежедневное (например, 0 3 * * * для 3 утра) или еженедельное.

8. Уборка

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

  • Группа управляемых экземпляров (${CURRENT_MIG_NAME}) и лежащие в её основе виртуальные машины.
  • Шаблон экземпляра (${TEMPLATE_NAME}).
  • Правила проверки состояния здоровья и брандмауэра (${HEALTH_CHECK_NAME}).
  • Репозиторий реестра артефактов (${REPOSITORY}).
  • Служебная учетная запись (если вы создали отдельную учетную запись для этой лабораторной работы).

Если вы завершили изучение проекта, пожалуйста, удалите его, следуя этим инструкциям: Завершение (удаление) проектов .

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

Поздравляем, вы успешно завершили практическое занятие!

Вы научились безопасно масштабировать рабочие нагрузки Confidential Space с помощью управляемых групп экземпляров (MIG). Вы успешно настроили автоматическое восстановление после сбоев, автоматическое масштабирование для обработки пиковых нагрузок и выполнили обновления без простоя как для образа ОС Confidential Space, так и для контейнера рабочей нагрузки.

Что дальше?

Ознакомьтесь с другими практическими занятиями по проектированию в рамках проекта Confidential Space:

Дополнительная информация