Private Service Connect — использование бэкэндов PSC для доступа к сервису-производителю

1. Введение

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

В центре внимания этого практического занятия — бэкэнды PSC. Бэкэнды PSC используются совместно с балансировщиками нагрузки прокси-серверов Google Cloud (как для приложений, так и для сети). Использование бэкэндов PSC обеспечивает более детальный контроль на стороне потребителя, например:

  • Более глубокая наблюдаемость и регистрация событий.
  • Интеграция Cloud Armor
  • Пользовательские URL-адреса
  • Расширенное управление дорожным движением
  • Пользовательские TLS-сертификаты

В этом практическом занятии вы узнаете, как создать бэкэнд для подключения к частной службе с использованием глобального внешнего балансировщика нагрузки приложений (Global External Application Load Balancer) для частного доступа к службе-производителю в другой сети.

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

  • Создайте и настройте бэкэнд PSC, связанный с глобальным внешним балансировщиком нагрузки приложений.
  • Настройте управляемый веб-сервис Apache и предоставьте к нему доступ в качестве сервиса PSC через Service Attachment.
  • Создайте SSL-сертификаты для завершения SSL-соединения на внутренних и внешних балансировщиках нагрузки приложений.
  • Настройте общедоступную зону Cloud DNS для доступа к сервису PSC.

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

  • Проект Google Cloud с правами владельца.

2. Тестовая среда

Создаваемая вами среда будет состоять из VPC потребителя и VPC производителя. В VPC производителя вы развернете управляемую группу экземпляров из шаблона экземпляра, который создает веб-сервис Apache с открытым исходным кодом. Вы также развернете тестовую виртуальную машину, чтобы убедиться в правильной локальной работе сервиса. Вы предоставите доступ к сервису Apache как к сервису производителя PSC через Service Attachment.

В потребительской VPC вы развернете глобальный внешний балансировщик нагрузки приложений с бэкэнд-сервисом PSC, указывающим на сервис Apache. Затем вы настроите публичную DNS-зону для доступа к сервису PSC в общедоступном интернете.

31e7497bf3d9035c.png

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

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

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

fbef9caa1602edd0.png

a99b7ace416376c4.png

5e3ff691252acf41.png

  • Название проекта — это отображаемое имя участников данного проекта. Это строка символов, не используемая API Google. Вы всегда можете его изменить.
  • Идентификатор проекта уникален для всех проектов Google Cloud и является неизменяемым (его нельзя изменить после установки). Консоль Cloud автоматически генерирует уникальную строку; обычно вам неважно, какая она. В большинстве практических заданий вам потребуется указать идентификатор вашего проекта (обычно обозначается как PROJECT_ID ). Если сгенерированный идентификатор вас не устраивает, вы можете сгенерировать другой случайный идентификатор. В качестве альтернативы вы можете попробовать свой собственный и посмотреть, доступен ли он. После этого шага его нельзя изменить, и он сохраняется на протяжении всего проекта.
  • К вашему сведению, существует третье значение — номер проекта , которое используется некоторыми API. Подробнее обо всех трех значениях можно узнать в документации .
  1. Далее вам потребуется включить оплату в консоли Cloud для использования ресурсов/API Cloud. Выполнение этого практического задания не потребует больших затрат, если вообще потребует. Чтобы отключить ресурсы и избежать дополнительных расходов после завершения этого урока, вы можете удалить созданные ресурсы или удалить проект. Новые пользователи Google Cloud имеют право на бесплатную пробную версию стоимостью 300 долларов США .

Запустить Cloud Shell

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

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

55efc1aaa7a4d3ad.png

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

7ffe5cbb04455448.png

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

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

Включить API

Внутри Cloud Shell убедитесь, что идентификатор вашего проекта указан правильно.

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
export project=YOUR-PROJECT-NAME
export region=us-central1
echo $project
echo $region

Включите все необходимые службы

gcloud services enable compute.googleapis.com
gcloud services enable servicedirectory.googleapis.com
gcloud services enable dns.googleapis.com

5. Настройка VPC для производителей

Создание сети VPC

Из Cloud Shell

gcloud compute networks create producer-vpc --subnet-mode custom

Создание подсетей

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

Из Cloud Shell

gcloud compute networks subnets create service-subnet \
    --network=producer-vpc \
    --range=10.0.0.0/28 \
    --region=$region

Из Cloud Shell

gcloud compute networks subnets create test-client-subnet \
    --network=producer-vpc \
    --range=10.0.1.0/28 \
    --region=us-east4

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

Из Cloud Shell

gcloud compute networks subnets create central-proxy-subnet \
    --network=producer-vpc \
    --range=10.100.101.0/24 \
    --region=$region \
    --purpose=REGIONAL_MANAGED_PROXY \
    --role=ACTIVE

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

Из Cloud Shell

gcloud compute networks subnets create psc-nat-subnet \
    --network=producer-vpc \
    --region=$region \
    --range=10.100.100.0/24 \
    --purpose=PRIVATE_SERVICE_CONNECT

Создать облачный NAT

Для установки необходимых пакетов для наших сервисов-производителей требуется облачный NAT.

Из Cloud Shell

gcloud compute routers create central-cr \
    --network=producer-vpc \
    --region=$region

Из Cloud Shell

gcloud compute routers nats create central-nat \
    --router=central-cr \
    --region=$region \
    --nat-all-subnet-ip-ranges \
    --auto-allocate-nat-external-ips

Создание политики и правил сетевого брандмауэра

Из Cloud Shell

gcloud compute network-firewall-policies create producer-vpc-policy --global

gcloud compute network-firewall-policies associations create \
    --firewall-policy producer-vpc-policy \
    --network producer-vpc \
    --name network-producer-vpc \
    --global-firewall-policy

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

  • Применяется ко всем экземплярам виртуальных машин, к которым вы хотите обеспечить доступ с помощью IAP.
  • Разрешает входящий трафик из диапазона IP-адресов 35.235.240.0/20. Этот диапазон содержит все IP-адреса, которые IAP использует для пересылки TCP-трафика.

Из Cloud Shell

gcloud compute network-firewall-policies rules create 1000 \
    --action ALLOW \
    --firewall-policy producer-vpc-policy \
    --description "SSH with IAP" \
    --direction INGRESS \
    --src-ip-ranges 35.235.240.0/20 \
    --layer4-configs tcp:22  \
    --global-firewall-policy

Для разрешения входящего трафика к бэкэндам балансировщика нагрузки, поступающего только из подсети прокси балансировщика нагрузки (2000), потребуются два дополнительных правила брандмауэра, а также правило, разрешающее проверки работоспособности балансировщика нагрузки на экземплярах бэкэнда (2001).

Из Cloud Shell

gcloud compute network-firewall-policies rules create 2000 \
    --action ALLOW \
    --firewall-policy producer-vpc-policy \
    --description "allow traffic from load balancer proxy subnet" \
    --direction INGRESS \
    --src-ip-ranges 10.100.101.0/24 \
    --layer4-configs tcp:443 \
    --global-firewall-policy


gcloud compute network-firewall-policies rules create 2001 \
    --action ALLOW \
    --firewall-policy producer-vpc-policy \
    --description "allow load balancer health checks" \
    --direction INGRESS \
    --src-ip-ranges 130.211.0.0/22,35.191.0.0/16 \
    --layer4-configs tcp:443 \
    --global-firewall-policy

6. Создайте веб-сервис Apache.

Мы создадим простой веб-сервис Apache, который будет отображать "PSC Service".

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

Из Cloud Shell

gcloud compute instance-templates create apache-service-template \
    --network producer-vpc \
    --subnet service-subnet \
    --region $region \
    --no-address \
    --metadata startup-script='#! /bin/bash
    sudo apt-get update
    apt-get install apache2 -y
    a2enmod ssl
    sudo a2ensite default-ssl
    echo "PSC Service" | \
    tee /var/www/html/index.html
    systemctl restart apache2'

Создать проверку работоспособности для MIG

Из Cloud Shell

gcloud compute health-checks create https service-mig-healthcheck \
    --port=443 \
    --global

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

Из Cloud Shell

gcloud compute instance-groups managed create psc-service-mig \
    --region $region \
    --size=2 \
    --template=apache-service-template \
    --health-check=service-mig-healthcheck

gcloud compute instance-groups managed set-named-ports psc-service-mig \
    --named-ports=https:443 \
    --region=$region

7. Создайте самоподписанный сертификат.

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

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

Из Cloud Shell

gcloud compute ssl-certificates create producer-service-cert \
    --certificate=<your-producer-certfile.cert> \
    --private-key=<your-producer-keyfile.pem> \
    --region=$region

8. Создайте внутренний региональный балансировщик нагрузки приложений.

Далее мы создадим компоненты балансировки нагрузки для сервиса. Мы используем внутренний региональный балансировщик нагрузки приложений, но у вас есть возможность использовать любой внутренний балансировщик нагрузки Google Cloud. Для обработки TLS следуйте соответствующей документации по балансировщику нагрузки.

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

Из Cloud Shell

gcloud compute addresses create apache-service-ip \
 --region=$region \
 --subnet=service-subnet

gcloud compute addresses describe apache-service-ip \
   --format="get(address)" \
   --region=$region

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

Из Cloud Shell

gcloud compute health-checks create https lb-apache-service-hc \
    --region=$region \
    --port-name=https

Создайте серверную службу.

Из Cloud Shell

gcloud compute backend-services create apache-bes\
  --load-balancing-scheme=INTERNAL_MANAGED \
  --protocol=HTTPS \
  --port-name=https \
  --health-checks=lb-apache-service-hc \
  --health-checks-region=$region \
  --region=$region


gcloud compute backend-services add-backend apache-bes \
  --balancing-mode=UTILIZATION \
  --instance-group=psc-service-mig \
  --region=$region

Создайте карту URL-адресов.

Из Cloud Shell

gcloud compute url-maps create producer-url-map \
  --default-service=apache-bes \
  --region=$region

Создайте целевые HTTPS-прокси.

Из Cloud Shell

gcloud compute target-https-proxies create https-proxy \
  --url-map=producer-url-map \
  --region=$region \
  --ssl-certificates=producer-service-cert

Создайте правило пересылки.

Из Cloud Shell

gcloud compute forwarding-rules create apache-fr \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=producer-vpc \
  --subnet=service-subnet \
  --address=apache-service-ip \
  --ports=443 \
  --region=$region \
  --target-https-proxy=https-proxy \
  --target-https-proxy-region=$region \
  --allow-global-access

9. Создайте тестовую виртуальную машину и протестируйте службу локально.

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

Из Cloud Shell

gcloud compute instances create vm-client \
    --zone=us-east4-a \
    --subnet=test-client-subnet \
    --no-address

Подождите около минуты, пока завершится процесс инициализации, а затем подключитесь к экземпляру по SSH.

Из Cloud Shell

gcloud compute ssh \
    --zone "us-east4-a" "vm-client" \
    --tunnel-through-iap \
    --project $project

Проверьте работу службы Apache, подключившись через порт 443 с помощью балансировщика нагрузки. Внутренний IP-адрес — это тот, который вы зарезервировали и записали ранее.

curl https://example.com:443 -k --connect-to example.com:443:<YOUR-INTERNAL-IP>:443

ОЖИДАЕМЫЙ РЕЗУЛЬТАТ

PSC Service

Выйти из виртуальной машины.

Из vm-клиента

exit

10. Создайте приложение к услуге.

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

Из Cloud Shell

gcloud compute service-attachments create apache-service-attachment \
    --region=$region \
    --producer-forwarding-rule=apache-fr \
    --connection-preference=ACCEPT_MANUAL \
    --consumer-accept-list=$project=5 \
    --nat-subnets=psc-nat-subnet

Запишите URI подключения сервиса ( selfLink ), так как он понадобится вам на следующем шаге для настройки бэкэнда PSC. Получить его можно, выполнив следующую команду в Cloud Shell.

Из Cloud Shell

gcloud compute service-attachments describe apache-service-attachment \
    --region $region

Скопируйте URI, начиная с проектов.

Пример: projects/$project/regions/$region/serviceAttachments/apache-service-attachment

11. Настройка потребительской VPC

Создание сети VPC

Из Cloud Shell

gcloud compute networks create consumer-vpc --subnet-mode custom

Создать подсеть

На стороне потребителя необходима подсеть, в которой будет развернута группа конечных точек сети Private Service Connect (NEG).

Из Cloud Shell

gcloud compute networks subnets create consumer-subnet \
    --network=consumer-vpc \
    --region=$region \
    --range=10.0.0.0/28

12. Зарезервируйте внешний IP-адрес и создайте самоподписанный сертификат на стороне потребителя.

Внешний IP-адрес

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

Из Cloud Shell

gcloud compute addresses create external-psc-ip \
    --network-tier=PREMIUM \
    --ip-version=IPV4 \
    --global

export externalip=$(gcloud compute addresses describe external-psc-ip \
    --format="get(address)" \
    --global)

echo $externalip

Сертификат, подписанный самим потребителем

Повторите шаг 1 инструкций, чтобы создать самоподписанный сертификат. Все команды можно выполнить в Cloud Shell. Вернитесь сюда после завершения шага 1. Вместо собственной публичной DNS-зоны мы будем использовать общедоступный DNS-сервис с открытым исходным кодом nip.io. Публичный URL-адрес вашего сервиса PSC будет использовать внешний IP-адрес, который вы только что настроили. ВАШЕ ОБЩЕЕ ИМЯ ДОЛЖНО БЫТЬ НАСТРОЕНО С <ВАШ-ВНЕШНИЙ-IP.nip.io>

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

Из Cloud Shell

gcloud compute ssl-certificates create consumer-service-cert \
    --certificate=<your-consumer-certfile.cert> \
    --private-key=<your-consumer-keyfile.pem> \
    --global

13. Создайте компоненты балансировщика нагрузки.

Мы создадим глобальный внешний балансировщик нагрузки приложений с PSC NEG, указывающим на наше недавно созданное приложение к сервису в качестве бэкэнд-сервиса.

Держите под рукой URI для подключения сервиса, который мы записали на предыдущем шаге. Замените psc-target-service ниже на ваш URI.

Из Cloud Shell

gcloud compute network-endpoint-groups create apache-psc-neg \
--network-endpoint-type=private-service-connect \
--psc-target-service=projects/$project/regions/$region/serviceAttachments/apache-service-attachment \
--region=$region \
--network=consumer-vpc \
--subnet=consumer-subnet

Создайте серверную службу.

Из Cloud Shell

gcloud compute backend-services create apache-pscneg-bes \
    --load-balancing-scheme=EXTERNAL_MANAGED \
    --protocol=HTTPS \
    --global

gcloud compute backend-services add-backend apache-pscneg-bes \
    --network-endpoint-group=apache-psc-neg \
    --network-endpoint-group-region=$region \
    --global

Создать карту URL-адресов

Из Cloud Shell

gcloud compute url-maps create consumer-url-map \
    --default-service=apache-pscneg-bes \
    --global

Создайте целевые HTTPS-прокси.

Из Cloud Shell

gcloud compute target-https-proxies create psc-https-proxy \
    --url-map=consumer-url-map \
    --ssl-certificates=consumer-service-cert

Создайте правило пересылки.

Из Cloud Shell

gcloud compute forwarding-rules create external-fr \
  --load-balancing-scheme=EXTERNAL_MANAGED \
  --network-tier=PREMIUM \
  --address=external-psc-ip \
  --global \
  --target-https-proxy=psc-https-proxy \
  --ports=443

14. Создайте публичную DNS-зону.

Из Cloud Shell

gcloud dns managed-zones create "psc-service" \
    --dns-name=$externalip.nip.io. \
    --description="public dns for psc service" \
    --visibility=public

Из Cloud Shell

gcloud dns record-sets transaction start \
   --zone="psc-service"

gcloud dns record-sets transaction add $externalip \
   --name=$externalip.nip.io \
   --ttl=300 \
   --type=A \
   --zone="psc-service"

gcloud dns record-sets transaction execute \
   --zone="psc-service"

15. Проверьте подключение потребительского PSC.

Подождите от 7 до 10 минут перед тестированием, чтобы публичные DNS-серверы успели распространиться.

Из Cloud Shell

curl https://$externalip.nip.io -k

Вы также можете проверить это в своем браузере, введя https://<ВАШ-ВНЕШНИЙ-IP>.nip.io в адресную строку браузера или терминала на компьютере.

ОЖИДАЕМЫЙ РЕЗУЛЬТАТ

PSC Service

16. Этапы очистки

Из одного терминала Cloud Shell удалите компоненты лаборатории.

gcloud dns record-sets delete $externalip.nip.io --zone="psc-service" --type=A -q

gcloud dns managed-zones delete "psc-service" -q

gcloud compute forwarding-rules delete external-fr --global -q 

gcloud compute target-https-proxies delete psc-https-proxy -q

gcloud compute url-maps delete consumer-url-map --global -q

gcloud compute backend-services delete apache-pscneg-bes --global -q

gcloud compute network-endpoint-groups delete apache-psc-neg --region=$region -q

gcloud compute ssl-certificates delete consumer-service-cert --global -q

gcloud compute addresses delete external-psc-ip --global -q

gcloud compute networks subnets delete consumer-subnet --region $region -q

gcloud compute networks delete consumer-vpc -q

gcloud compute instances delete vm-client --zone=us-east4-a -q

gcloud compute service-attachments delete apache-service-attachment --region $region -q

gcloud compute forwarding-rules delete apache-fr --region $region -q

gcloud compute target-https-proxies delete https-proxy --region $region -q

gcloud compute url-maps delete producer-url-map --region $region -q

gcloud compute backend-services delete apache-bes --region $region -q

gcloud compute health-checks delete lb-apache-service-hc --region $region -q

gcloud compute addresses delete apache-service-ip --region $region -q

gcloud compute ssl-certificates delete producer-service-cert --region $region -q

gcloud compute instance-groups managed delete psc-service-mig --region $region -q

gcloud compute health-checks delete service-mig-healthcheck --global -q

gcloud compute instance-templates delete apache-service-template -q

gcloud compute network-firewall-policies rules delete 2001 --firewall-policy producer-vpc-policy --global-firewall-policy -q

gcloud compute network-firewall-policies rules delete 2000 --firewall-policy producer-vpc-policy --global-firewall-policy -q

gcloud compute network-firewall-policies rules delete 1000 --firewall-policy producer-vpc-policy --global-firewall-policy -q

gcloud compute network-firewall-policies associations delete --firewall-policy=producer-vpc-policy  --name=network-producer-vpc --global-firewall-policy -q

gcloud compute network-firewall-policies delete producer-vpc-policy --global -q

gcloud compute routers nats delete central-nat --router=central-cr --region $region -q

gcloud compute routers delete central-cr --region $region -q

gcloud compute networks subnets delete psc-nat-subnet --region $region -q

gcloud compute networks subnets delete service-subnet --region $region -q

gcloud compute networks subnets delete test-client-subnet --region us-east4 -q 

gcloud compute networks subnets delete central-proxy-subnet --region $region -q

gcloud compute networks delete producer-vpc -q

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

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

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

  • Создайте и настройте бэкэнд PSC, связанный с глобальным внешним балансировщиком нагрузки приложений.
  • Настройте управляемый веб-сервис Apache и предоставьте к нему доступ в качестве сервиса PSC через Service Attachment.
  • Создайте SSL-сертификаты для завершения SSL-соединения на внутренних и внешних балансировщиках нагрузки приложений.
  • Настройте общедоступную зону Cloud DNS для доступа к сервису PSC.