Размещение веб-приложения в Google Cloud с использованием GCE

Существует множество способов развертывания веб-сайтов в Google Cloud, каждое из которых предлагает различные функции, возможности и уровни контроля. Google Compute Engine, также называемый GCE, предлагает глубокий уровень контроля над инфраструктурой, используемой для запуска веб-сайта, но также требует немного большего оперативного управления по сравнению с такими решениями, как Google Kubernetes Engines (GKE), Google App Engine (GAE). ), или другие. Благодаря Compute Engine у ​​нас есть детальный контроль над аспектами инфраструктуры, включая виртуальные машины, балансировщики нагрузки и многое другое. Сегодня мы развернем пример приложения, веб-сайт электронной коммерции Fancy Store, чтобы показать, как можно легко развернуть и масштабировать веб-сайт с помощью Compute Engine.

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

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

Предпосылки

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

Если у вас еще нет учетной записи Google (Gmail или Google Apps), вы должны создать ее. Войдите в консоль Google Cloud Platform ( console.cloud.google.com ) и создайте новый проект:

Скриншот от 10 февраля 2016 г., 12:45:26.png

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

Затем вам нужно включить выставление счетов в облачной консоли, чтобы использовать ресурсы Google Cloud.

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

Новые пользователи Google Cloud Platform имеют право на бесплатную пробную версию стоимостью 300 долларов США .

Включить API Compute Engine

Затем вам нужно включить API Compute Engine . Включение API требует от вас принятия Условий обслуживания и ответственности за выставление счетов за API.

Облачная оболочка Google

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

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

Чтобы активировать Google Cloud Shell, в консоли разработчика просто нажмите кнопку в правом верхнем углу (подготовка и подключение к среде займет всего несколько минут):

активироватьCloudShell.png

Нажмите кнопку «Запустить Cloud Shell»:

Снимок экрана 14.06.2017, 10.13.43 PM.png

После подключения к облачной оболочке вы должны увидеть, что вы уже прошли аутентификацию и что проект уже настроен на ваш PROJECT_ID :

gcloud auth list

Вывод команды

Credentialed accounts:
 - <myaccount>@<mydomain>.com (active)
gcloud config list project

Вывод команды

[core]
project = <PROJECT_ID>

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

echo $GOOGLE_CLOUD_PROJECT

Вывод команды

<PROJECT_ID>

Если по какой-то причине проект не установлен, просто введите следующую команду:

gcloud config set project <PROJECT_ID>

Ищете свой PROJECT_ID ? Проверьте, какой идентификатор вы использовали на этапах настройки, или найдите его на панели управления консоли:

Project_ID.png

ВАЖНО: Наконец, установите зону по умолчанию и конфигурацию проекта:

gcloud config set compute/zone us-central1-f

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

Создать сегмент GCS

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

gsutil mb gs://fancy-store-$DEVSHELL_PROJECT_ID

Мы будем использовать существующий веб-сайт электронной коммерции Fancy Store, основанный на репозитории монолит-микросервисы, в качестве основы для нашего веб-сайта. Мы клонируем исходный код из нашего репозитория git, чтобы сосредоточиться на аспектах развертывания в GCE. Позже в этой лаборатории мы выполним небольшое обновление кода, чтобы продемонстрировать простоту обновления в GCE.

Нажмите кнопку ниже, чтобы клонировать репозиторий кода в проект, а также открыть Cloud Shell и встроенный редактор кода.

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

./setup.sh

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

cd microservices
npm start

Выход:

Products microservice listening on port 8092!
Frontend microservice listening on port 8090!
Orders microservice listening on port 8091!

Вы можете предварительно просмотреть свое приложение, щелкнув значок веб-просмотра и выбрав «Изменить порт» и введя порт микрослужбы внешнего интерфейса: 8090. Выберите «Изменить и просмотреть».

Это должно открыть новое окно, в котором вы сможете увидеть интерфейс Fancy Store в действии!

Вы можете закрыть это окно после просмотра веб-сайта, а чтобы остановить процесс веб-сервера, нажмите CTRL+C в окне терминала.

Теперь, когда у вас есть рабочая среда разработки, пора приступить к развертыванию нескольких экземпляров Compute Engine! Следующие шаги будут:

  1. Создайте сценарий запуска для настройки экземпляров
  2. Клонировать исходный код и загрузить в Google Cloud Storage
  3. Разверните экземпляр Compute Engine для размещения серверных микросервисов.
  4. Перенастройте внешний код для использования внутреннего экземпляра микросервисов.
  5. Разверните экземпляр Compute Engine для размещения внешнего микросервиса.
  6. Настройте сеть, чтобы разрешить связь

Создать сценарий запуска

Чтобы экземпляры автоматически настраивались так, как мы хотим, мы будем использовать сценарий запуска, который будет указывать экземпляру, что делать при каждом его запуске. В редакторе кода внутри Cloud Shell перейдите в папку monolith-to-microservices и создайте файл с именем « startup-script.sh ».

В этот новый файл вставьте следующий код. Мы отредактируем часть кода после вставки.

#!/bin/bash

# Install logging monitor. The monitor will automatically pick up logs sent to
# syslog.
curl -s "https://storage.googleapis.com/signals-agents/logging/google-fluentd-install.sh" | bash
service google-fluentd restart &

# Install dependencies from apt
apt-get update
apt-get install -yq ca-certificates git build-essential supervisor psmisc

# Install nodejs
mkdir /opt/nodejs
curl https://nodejs.org/dist/v8.12.0/node-v8.12.0-linux-x64.tar.gz | tar xvzf - -C /opt/nodejs --strip-components=1
ln -s /opt/nodejs/bin/node /usr/bin/node
ln -s /opt/nodejs/bin/npm /usr/bin/npm

# Get the application source code from the Google Cloud Storage bucket.
mkdir /fancy-store
gsutil -m cp -r gs://fancy-store-[DEVSHELL_PROJECT_ID]/monolith-to-microservices/microservices/* /fancy-store/

# Install app dependencies.
cd /fancy-store/
npm install

# Create a nodeapp user. The application will run as this user.
useradd -m -d /home/nodeapp nodeapp
chown -R nodeapp:nodeapp /opt/app

# Configure supervisor to run the node app.
cat >/etc/supervisor/conf.d/node-app.conf << EOF
[program:nodeapp]
directory=/fancy-store
command=npm start
autostart=true
autorestart=true
user=nodeapp
environment=HOME="/home/nodeapp",USER="nodeapp",NODE_ENV="production"
stdout_logfile=syslog
stderr_logfile=syslog
EOF

supervisorctl reread
supervisorctl update

Теперь в редакторе найдите текст [DEVSHELL_PROJECT_ID] и замените его выводом следующей команды:

echo $DEVSHELL_PROJECT_ID

Пример вывода:

my-gce-codelab-253520

Строка кода в startup-script.sh теперь должна быть похожа на следующую:

gs://fancy-store-my-gce-codelab-253520/monolith-to-microservices/microservices/* /fancy-store/

Сценарий запуска выполняет следующие задачи:

  • Устанавливает агент ведения журнала. Агент автоматически собирает журналы из системного журнала.
  • Устанавливает Node.js и Supervisor. Supervisor запускает приложение как демон.
  • Клонирует исходный код приложения из GCS Bucket и устанавливает зависимости.
  • Настраивает Supervisor для запуска приложения. Супервизор обеспечивает перезапуск приложения, если оно неожиданно закрывается или останавливается администратором или процессом. Он также отправляет stdout и stderr приложения в системный журнал для сбора агентом ведения журнала.

Теперь скопируйте созданный файл startup-script.sh в нашу ранее созданную корзину GCS:

gsutil cp startup-script.sh gs://fancy-store-$DEVSHELL_PROJECT_ID

Теперь он будет доступен по адресу: https://storage.googleapis.com/[BUCKET_NAME]/startup-script.sh . [BUCKET_NAME] представляет собой имя корзины Cloud Storage. По умолчанию это будет доступно для просмотра только авторизованным пользователям и учетным записям служб, поэтому оно будет недоступно через веб-браузер. Экземпляры Google Compute Engine автоматически смогут получить к нему доступ через свою учетную запись службы.

Скопируйте код в корзину GCS

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

Скопируйте клонированный код в корзину GCS:

cd ~
rm -rf monolith-to-microservices/*/node_modules
gsutil -m cp -r monolith-to-microservices gs://fancy-store-$DEVSHELL_PROJECT_ID/

Развернуть серверный экземпляр

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

Выполните следующую команду в Cloud Shell, чтобы создать экземпляр f1-micro, который настроен на использование нашего ранее созданного сценария запуска, а также помечен как экземпляр «бэкэнд», чтобы мы могли применить к нему определенные правила брандмауэра позже:

gcloud compute instances create backend \
    --machine-type=f1-micro \
    --image=debian-9-stretch-v20190905 \
    --image-project=debian-cloud \
    --tags=backend \
    --metadata=startup-script-url=https://storage.googleapis.com/fancy-store-$DEVSHELL_PROJECT_ID/startup-script.sh

Настроить подключение к серверной части

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

Получите внешний IP-адрес серверной части, который можно просмотреть с помощью следующей команды на вкладке EXTERNAL_IP для экземпляра серверной части:

gcloud compute instances list

Пример вывода:

NAME     ZONE           MACHINE_TYPE  PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP   STATUS
backend  us-central1-a  f1-micro                   10.128.0.2   34.68.223.88  RUNNING

Вернувшись в редактор кода Cloud Shell, перейдите в папку monolith-to-microservices → react-app. В меню «Редактор кода» выберите « Просмотр» → «Переключить скрытые файлы» , чтобы увидеть файл « .env ».

Отредактируйте файл .env, чтобы он указывал на внешний IP-адрес серверной части. [BACKEND_ADDRESS] ниже представляет собой внешний IP-адрес внутреннего экземпляра, определенный с помощью приведенной выше команды gcloud .

REACT_APP_ORDERS_URL=http://[BACKEND_ADDRESS]:8091/api/orders
REACT_APP_PRODUCTS_URL=http://[BACKEND_ADDRESS]:8092/api/products

Пересоберите react-app, который обновит код внешнего интерфейса:

npm install && npm run-script build

Скопируйте код приложения обратно в корзину GCS:

cd ~
rm -rf monolith-to-microservices/*/node_modules
gsutil -m cp -r monolith-to-microservices gs://fancy-store-$DEVSHELL_PROJECT_ID/

Развернуть экземпляр внешнего интерфейса

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

gcloud compute instances create frontend \
    --machine-type=f1-micro \
    --image=debian-9-stretch-v20190905 \
    --image-project=debian-cloud \
    --tags=frontend \
    --metadata=startup-script-url=https://storage.googleapis.com/fancy-store-$DEVSHELL_PROJECT_ID/startup-script.sh 

Настройка сети

Создайте правила брандмауэра, чтобы разрешить доступ к порту 8090 для интерфейса и портам 8091-8092 для сервера. Эти команды брандмауэра используют теги, назначенные при создании экземпляра для приложения.

gcloud compute firewall-rules create fw-fe \
    --allow tcp:8090 \
    --target-tags=frontend
gcloud compute firewall-rules create fw-be \
    --allow tcp:8091-8092 \
    --target-tags=backend

Теперь сайт должен работать. Перейдите к внешнему IP-адресу интерфейса. Этот адрес можно определить, выполнив поиск EXTERNAL_IP экземпляра внешнего интерфейса:

gcloud compute instances list

Пример вывода:

NAME      ZONE           MACHINE_TYPE  PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP      STATUS
backend   us-central1-a  f1-micro                   10.128.0.2   104.198.235.171  RUNNING
frontend  us-central1-a  f1-micro                   10.128.0.3   34.69.141.9      RUNNING

Перейдите по адресу http://[FRONTEND_ADDRESS]:8090, чтобы получить доступ к веб-сайту, где [FRONTEND_ADDRESS] — это EXTERNAL_IP, определенный выше. Запуск и настройка экземпляра может занять пару минут.

Попробуйте перейти на страницы «Продукты» и «Заказы»; они также должны успешно работать.

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

Группа управляемых экземпляров (MIG) содержит идентичные экземпляры, которыми можно управлять как единым объектом в одной зоне. Управляемые группы экземпляров поддерживают высокую доступность ваших приложений, заранее поддерживая доступность ваших экземпляров, то есть в состоянии РАБОТАЕТ. Мы будем использовать управляемые группы экземпляров для наших внешних и внутренних экземпляров, чтобы обеспечить автоматическое восстановление, балансировку нагрузки, автоматическое масштабирование и последовательные обновления.

Создать шаблон экземпляра из исходного экземпляра

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

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

gcloud compute instances stop frontend
gcloud compute instances stop backend

Затем мы можем создать шаблон экземпляра из исходных экземпляров:

gcloud compute instance-templates create fancy-fe \
    --source-instance=frontend \
    --source-instance-zone=us-central1-a
gcloud compute instance-templates create fancy-be \
    --source-instance=backend \
    --source-instance-zone=us-central1-a

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

gcloud compute instance-templates list

Пример вывода:

NAME      MACHINE_TYPE  PREEMPTIBLE  CREATION_TIMESTAMP
fancy-be  f1-micro                   2019-09-12T07:52:57.544-07:00
fancy-fe  f1-micro                   2019-09-12T07:52:48.238-07:00

Создать группу управляемых экземпляров

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

gcloud compute instance-groups managed create fancy-fe-mig \
    --base-instance-name fancy-fe \
    --size 2 \
    --template fancy-fe
gcloud compute instance-groups managed create fancy-be-mig \
    --base-instance-name fancy-be \
    --size 2 \
    --template fancy-be

Для нашего приложения внешний микросервис работает на порту 8090, а внутренние микросервисы работают на порту 8091 для заказов и порте 8092 для продуктов. Поскольку это нестандартные порты, мы укажем именованные порты для их идентификации. Именованные порты — это метаданные пары ключ:значение, представляющие имя службы и порт, на котором она работает. Именованные порты могут быть назначены группе экземпляров, что означает, что служба доступна для всех экземпляров в группе. Эта информация используется службой балансировки нагрузки HTTP, которая будет настроена позже.

gcloud compute instance-groups set-named-ports fancy-fe-mig \ 
    --named-ports frontend:8090
gcloud compute instance-groups set-named-ports fancy-be-mig \
    --named-ports orders:8091,products:8092

Настроить автолечение

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

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

Создайте проверку работоспособности, которая восстанавливает экземпляр, если он возвращается как неработоспособный 3 раза подряд для внешнего и внутреннего интерфейса:

gcloud compute health-checks create http fancy-fe-hc \
    --port 8090 \
    --check-interval 30s \
    --healthy-threshold 1 \
    --timeout 10s \
    --unhealthy-threshold 3
gcloud compute health-checks create http fancy-be-hc \
    --port 8091 \
    --request-path=/api/orders \
    --check-interval 30s \
    --healthy-threshold 1 \
    --timeout 10s \
    --unhealthy-threshold 3

Создайте правило брандмауэра, чтобы разрешить зондам проверки работоспособности подключаться к микросервисам через порты 8090-8091:

gcloud compute firewall-rules create allow-health-check \
    --allow tcp:8090-8091 \
    --source-ranges 130.211.0.0/22,35.191.0.0/16 \
    --network default

Примените проверки работоспособности к соответствующим службам:

gcloud compute instance-groups managed update fancy-fe-mig \
    --health-check fancy-fe-hc \
    --initial-delay 300
gcloud compute instance-groups managed update fancy-be-mig \
    --health-check fancy-be-hc \
    --initial-delay 300

Имитация отказа

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

gcloud compute instance-groups list-instances fancy-fe-mig

Оттуда защитите оболочку в один из экземпляров, где INSTANCE_NAME — один из экземпляров из списка:

gcloud compute ssh [INSTANCE_NAME]

Внутри экземпляра используйте supervisorctl для остановки приложения:

sudo supervisorctl stop nodeapp; sudo killall node

Выйдите из экземпляра:

exit

Контролировать ремонтные работы:

watch -n 5 gcloud compute operations list \
--filter='operationType~compute.instances.repair.*'

Найдите следующий пример вывода:

NAME                                                  TYPE                                       TARGET                                 HTTP_STATUS  STATUS  TIMESTAMP
repair-1568314034627-5925f90ee238d-fe645bf0-7becce15  compute.instances.repair.recreateInstance  us-central1-a/instances/fancy-fe-1vqq  200          DONE    2019-09-12T11:47:14.627-07:00

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

Чтобы дополнить наши управляемые группы экземпляров, мы будем использовать балансировщики нагрузки HTTP(S) для обслуживания трафика к внешним и внутренним микросервисам, а также использовать сопоставления для отправки трафика в соответствующие внутренние службы на основе правил маршрутизации. Это предоставит единый IP-адрес с балансировкой нагрузки для всех служб.

https://cloud.google.com/load-balancing/docs/load-balancing-overview .

Создать балансировщик нагрузки HTTP(S)

Google Cloud Platform предлагает множество различных типов балансировщиков нагрузки, но мы будем использовать балансировщик нагрузки HTTP(S) для нашего трафика. Балансировщик нагрузки HTTP устроен следующим образом:

  1. Правило переадресации направляет входящие запросы на целевой HTTP-прокси.
  2. Целевой прокси-сервер HTTP сверяет каждый запрос с сопоставлением URL-адресов, чтобы определить соответствующую серверную службу для запроса.
  3. Бэкэнд-сервис направляет каждый запрос соответствующему бэкэнду в зависимости от мощности обслуживания, зоны и работоспособности экземпляров подключенных к нему бэкэндов. Работоспособность каждого серверного экземпляра проверяется с помощью проверки работоспособности HTTP. Если серверная служба настроена на использование проверки работоспособности HTTPS или HTTP/2, запрос будет зашифрован на пути к экземпляру серверной части.
  4. Сеансы между балансировщиком нагрузки и экземпляром могут использовать протокол HTTP, HTTPS или HTTP/2. Если вы используете HTTPS или HTTP/2, каждый экземпляр внутренних служб должен иметь сертификат SSL.

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

gcloud compute http-health-checks create fancy-fe-frontend-hc \
  --request-path / \
  --port 8090
gcloud compute http-health-checks create fancy-be-orders-hc \
  --request-path /api/orders \
  --port 8091
gcloud compute http-health-checks create fancy-be-products-hc \
  --request-path /api/products \
  --port 8092

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

gcloud compute backend-services create fancy-fe-frontend \
  --http-health-checks fancy-fe-frontend-hc \
  --port-name frontend \
  --global
gcloud compute backend-services create fancy-be-orders \
  --http-health-checks fancy-be-orders-hc \
  --port-name orders \
  --global
gcloud compute backend-services create fancy-be-products \
  --http-health-checks fancy-be-products-hc \
  --port-name products \
  --global

Добавьте серверные службы:

gcloud compute backend-services add-backend fancy-fe-frontend \
  --instance-group fancy-fe-mig \
  --instance-group-zone us-central1-a \
  --global
gcloud compute backend-services add-backend fancy-be-orders \
  --instance-group fancy-be-mig \
  --instance-group-zone us-central1-a \
  --global
gcloud compute backend-services add-backend fancy-be-products \
  --instance-group fancy-be-mig \
  --instance-group-zone us-central1-a \
  --global

Создайте карту URL. Карта URL-адресов определяет, какие URL-адреса направлены на какие серверные службы.

gcloud compute url-maps create fancy-map \
  --default-service fancy-fe-frontend

Создайте средство сопоставления путей, чтобы пути «/api/orders» и «/api/products» направлялись к соответствующим службам:

gcloud compute url-maps add-path-matcher fancy-map \
   --default-service fancy-fe-frontend \
   --path-matcher-name orders \
   --path-rules "/api/orders=fancy-be-orders,/api/products=fancy-be-products"

Создайте прокси, который привязывается к созданной карте URL.

gcloud compute target-http-proxies create fancy-proxy \
  --url-map fancy-map

Создайте глобальное правило переадресации, которое связывает общедоступный IP-адрес и порт с прокси-сервером.

gcloud compute forwarding-rules create fancy-http-rule \
  --global \
  --target-http-proxy fancy-proxy \
  --ports 80

Обновить конфигурацию

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

В Cloud Shell перейдите в папку react-app, в которой находится файл .env, содержащий конфигурацию:

cd ~/monolith-to-microservices/react-app/

Найдите IP-адрес балансировщика нагрузки:

gcloud compute forwarding-rules list --global

Пример вывода:

NAME                    REGION  IP_ADDRESS     IP_PROTOCOL  TARGET
fancy-http-rule          34.102.237.51  TCP          fancy-proxy

Отредактируйте .env с помощью предпочитаемого вами текстового редактора (например, nano), чтобы он указывал на публичный IP-адрес Load Balancer. [LB_IP] представляет собой внешний IP-адрес серверного экземпляра, определенный выше.

REACT_APP_ORDERS_URL=http://[LB_IP]/api/orders
REACT_APP_PRODUCTS_URL=http://[LB_IP]/api/products

Пересоберите react-app, который обновит код внешнего интерфейса:

npm install && npm run-script build

Скопируйте код приложения обратно в корзину GCS:

cd ~
rm -rf monolith-to-microservices/*/node_modules
gsutil -m cp -r monolith-to-microservices gs://fancy-store-$DEVSHELL_PROJECT_ID/

Обновите экземпляры внешнего интерфейса

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

gcloud compute instance-groups managed rolling-action restart fancy-fe-mig \
    --max-unavailable 100%

Протестируйте веб-сайт

Проверяйте состояние группы управляемых экземпляров, пока экземпляры не появятся в списке:

watch -n 5 gcloud compute instance-groups list-instances fancy-fe-mig

Как только элементы появятся в списке, выйдите из команды наблюдения, нажав Ctrl+C.

Подтвердите, что служба указана как работоспособная:

gcloud compute backend-services get-health fancy-fe-frontend --global

Пример вывода:

---
backend: https://www.googleapis.com/compute/v1/projects/my-gce-codelab/zones/us-central1-a/instanceGroups/fancy-fe-mig
status:
  healthStatus:
  - healthState: HEALTHY
    instance: https://www.googleapis.com/compute/v1/projects/my-gce-codelab/zones/us-central1-a/instances/fancy-fe-x151
    ipAddress: 10.128.0.7
    port: 8090
  - healthState: HEALTHY
    instance: https://www.googleapis.com/compute/v1/projects/my-gce-codelab/zones/us-central1-a/instances/fancy-fe-cgrt
    ipAddress: 10.128.0.11
    port: 8090
  kind: compute#backendServiceGroupHealth

Затем приложение будет доступно через http://[LB_IP], где [LB_IP] — это IP_ADDRESS, указанный для балансировщика нагрузки, который можно найти с помощью следующей команды:

gcloud compute forwarding-rules list --global

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

Автоматически изменять размер при использовании

Чтобы создать политику автомасштабирования, выполните следующие действия в Cloud Shell. Эти команды создают средство автомасштабирования в управляемых группах экземпляров, которое автоматически добавляет экземпляры, когда загрузка превышает 60 %, а также удаляет экземпляры, когда загрузка балансировщика нагрузки ниже 60 %.

gcloud compute instance-groups managed set-autoscaling \
  fancy-fe-mig \
  --max-num-replicas 5 \
  --target-load-balancing-utilization 0.60
gcloud compute instance-groups managed set-autoscaling \
  fancy-be-mig \
  --max-num-replicas 5 \
  --target-load-balancing-utilization 0.60

Включить сеть доставки контента

Еще одна функция, которая может помочь в масштабировании, — включить Cloud CDN, который является службой сети доставки контента, для обеспечения кэширования для внешнего интерфейса. Для этого мы можем выполнить следующую команду в нашем внешнем сервисе:

gcloud compute backend-services update fancy-fe-frontend \
    --enable-cdn --global

Теперь, когда пользователь запрашивает контент из балансировщика нагрузки HTTP(S), запрос поступает на внешний интерфейс Google (GFE), который сначала ищет ответ на запрос пользователя в кэше Cloud CDN. Если GFE находит кэшированный ответ, GFE отправляет кэшированный ответ пользователю. Это называется попаданием в кеш.

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

Обновление шаблона экземпляра

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

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

Запустите экземпляр внешнего интерфейса , если он еще не запущен:

gcloud compute instances start frontend

Безопасная оболочка в экземпляре:

gcloud compute ssh frontend

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

echo "Updated" > ~/updated_proof

Выйдите из экземпляра:

exit

Выключите экземпляр:

gcloud compute instances stop frontend

Создайте новый шаблон экземпляра:

gcloud compute instance-templates create fancy-fe-new \
    --source-instance=frontend \
    --source-instance-zone=us-central1-a

Разверните обновленный шаблон экземпляра в группе управляемых экземпляров:

gcloud compute instance-groups managed rolling-action start-update fancy-fe-mig \
    --version template=fancy-fe-new

Следите за статусом обновления:

gcloud compute instance-groups managed list-instances fancy-fe-mig

Как только экземпляр находится в статусе RUNNING с INSTANCE_TEMPLATE, для которого установлено значение fancy-fe-new , войдите в только что созданный экземпляр и проверьте, есть ли там файл «updated_proof», где [VM_NAME] — это вновь созданный экземпляр:

gcloud compute ssh [VM_NAME]

Если файл «updated_proof» теперь находится в экземплярах управляемой группы, обновление успешно отправлено.

Внесение изменений на веб-сайты

Ваша маркетинговая команда попросила вас изменить домашнюю страницу вашего сайта. Они считают, что это должно быть более информативно о том, кто ваша компания и что вы на самом деле продаете. В этом разделе мы добавим текст на главную страницу, чтобы порадовать команду маркетинга! Похоже, что один из наших разработчиков уже внес изменения с именем файла index.js.new . Мы можем просто скопировать этот файл в index.js и наши изменения должны быть отражены. Следуйте приведенным ниже инструкциям, чтобы внести соответствующие изменения.

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

cd ~/monolith-to-microservices/react-app/src/pages/Home
mv index.js.new index.js
cat ~/monolith-to-microservices/react-app/src/pages/Home/index.js

Результирующий код должен выглядеть так:

/*
Copyright 2019 Google LLC

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    https://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
*/

import React from "react";
import { makeStyles } from "@material-ui/core/styles";
import Paper from "@material-ui/core/Paper";
import Typography from "@material-ui/core/Typography";
const useStyles = makeStyles(theme => ({
  root: {
    flexGrow: 1
  },
  paper: {
    width: "800px",
    margin: "0 auto",
    padding: theme.spacing(3, 2)
  }
}));
export default function Home() {
  const classes = useStyles();
  return (
    <div className={classes.root}>
      <Paper className={classes.paper}>
        <Typography variant="h5">
          Fancy Fashion &amp; Style Online
        </Typography>
        <br />
        <Typography variant="body1">
          Tired of mainstream fashion ideas, popular trends and societal norms?
          This line of lifestyle products will help you catch up with the Fancy trend and express your personal style.
          Start shopping Fancy items now!
        </Typography>
      </Paper>
    </div>
  );
}

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

cd ~/monolith-to-microservices/react-app
npm install && npm run-script build

Затем мы повторно отправляем этот код в нашу корзину GCS:

cd ~
rm -rf monolith-to-microservices/*/node_modules
gsutil -m cp -r monolith-to-microservices gs://fancy-store-$DEVSHELL_PROJECT_ID/

Отправка изменений с последовательными обновлениями

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

gcloud compute instance-groups managed rolling-action restart fancy-fe-mig

Этот скользящий перезапуск теперь будет перезапускать экземпляры, оставляя буфер, чтобы не влиять на доступ. Отслеживайте цикличность экземпляров через консоль. При обновлении статус будет трансформироваться; после завершения управляемая группа экземпляров будет отображаться как готовая в Compute Engine -> Instance Groups:

Когда все будет готово, самый простой способ очистить все выполненные действия — это удалить проект. При удалении проекта удаляются все балансировщики нагрузки, экземпляры, шаблоны и т. д., созданные в рамках этой лаборатории Codelab, чтобы исключить непредвиденные повторяющиеся расходы. Выполните следующее в Cloud Shell, где PROJECT_ID — это полный идентификатор проекта, а не только имя проекта.

gcloud projects delete [PROJECT_ID]

Подтвердите удаление, введя «Y» при появлении запроса.

Вы успешно развернули, масштабировали и обновили свой веб-сайт на GCE. Теперь у вас есть опыт работы с Compute Engine, управляемыми группами экземпляров, балансировщиками нагрузки и проверками работоспособности!