Looker PSC Southbound HTTPS Интернет NEG Gitlab Самоуправляемый,Looker PSC Southbound HTTPS Интернет NEG Gitlab Самоуправляемый,Looker PSC Southbound HTTPS Интернет NEG Gitlab Самоуправляемый,Looker PSC Southbound HTTPS Интернет NEG Gitlab Самоуправляемый

О практической работе

41 минута

Последнее обновление: 2 апреля 2025 г.

Авторы: Deepak Michael

1. Введение

ПРИМЕЧАНИЕ. Looker поддерживает производителей Southbound в любом регионе. Для северного доступа к Looker конечная точка или серверная часть потребителя должна находиться в том же регионе, что и экземпляр Looker PSC.

В этой лабораторной работе вы выполните HTTPS-подключение в южном направлении к вашей самоуправляемой среде GitLab, используя внутренний балансировщик нагрузки tcp-прокси и группу конечных точек интернет-сети (NEG), вызываемую из Looker PSC в качестве потребителя службы.

Private Service Connect — это возможность сети Google Cloud, которая позволяет потребителям получать частный доступ к управляемым сервисам изнутри своей сети VPC. Аналогичным образом, это позволяет производителям управляемых услуг размещать эти услуги в своих отдельных сетях VPC и предлагать своим потребителям частное соединение. Например, когда вы используете Private Service Connect для доступа к Looker, вы являетесь потребителем услуги, а Google — производителем услуги, как показано на рисунке 1.

Рисунок 1.

Южный доступ, также известный как обратный PSC, позволяет потребителю создать опубликованную службу в качестве производителя, чтобы предоставить Looker доступ к конечным точкам локально, в VPC, к управляемым сервисам и Интернету. Южные соединения могут быть развернуты в любом регионе, независимо от того, где развернут Looker PSC, как показано на рисунке 2.

Рисунок 2.

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

• Требования к сети
• Создание службы-производителя Private Service Connect
• Создайте конечную точку Private Service Connect в Looker
• Установите подключение к самоуправляемому экземпляру GitLab.

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

• Проект Google Cloud с разрешениями владельца
• Учетная запись и репозиторий GitLab
• Существующий экземпляр Looker PSC

2. Что вы будете строить

Вы создадите сеть-производитель, Looker-PSC-Demo, для развертывания внутреннего балансировщика нагрузки tcp-прокси и Интернет-NEG, опубликованного как услуга через Private Service Connect (PSC). После публикации вы выполните следующие действия для проверки доступа к службе Producer:

• Создайте конечную точку PSC в Looker, связанную с вложением службы производителя.
• Используйте консоль Looker, чтобы создать новый проект и проверить подключение HTTPS к вашей самоуправляемой среде GitLab.

ПРИМЕЧАНИЕ. Учебное пособие не содержит тестов для развертывания самоуправляемого экземпляра Gitlab.

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

Ниже приводится разбивка сетевых требований для сети Producer, потребителем в этой кодовой лаборатории является экземпляр Looker PSC.

Компоненты	Описание
VPC (просмотрщик-psc-демо)	Пользовательский режим VPC
Подсеть PSC NAT	Пакеты из потребительской сети VPC преобразуются с использованием исходного NAT (SNAT), так что их исходные IP-адреса источника преобразуются в исходные IP-адреса из подсети NAT в сети VPC производителя.
Подсеть правила пересылки PSC	Используется для выделения IP-адреса региональному внутреннему балансировщику нагрузки TCP-прокси.
Подсеть PSC NEG	Используется для выделения IP-адреса для группы конечных точек сети.
Только прокси-подсеть	Каждому из прокси-серверов балансировщика нагрузки назначается внутренний IP-адрес. Пакеты, отправляемые с прокси-сервера на серверную виртуальную машину или конечную точку, имеют исходный IP-адрес из подсети, предназначенной только для прокси-сервера.
Интернет НЕГ	Ресурс, используемый для определения внешнего бэкэнда для балансировщика нагрузки, настроенного как полное доменное имя, обозначающее самоуправляемое локальное полное доменное имя Gitlab. Полное доменное имя Интернета выполняет поиск DNS в VPC для разрешения.
Серверная служба	Серверная служба действует как мост между балансировщиком нагрузки и серверными ресурсами. В руководстве серверная служба связана с Интернетом NEG.

ПРИМЕЧАНИЕ. В нашей настройке Internet NEG, настроенный с полным доменным именем, развертывается в потребительском VPC для разрешения IP-адреса самоуправляемого экземпляра GitLab, расположенного локально. По умолчанию Internet NEG выполнит поиск DNS по предоставленному полному доменному имени, поэтому, если полное доменное имя вашего самоуправляемого экземпляра GitLab можно разрешить из экземпляра GCE, дальнейших действий не требуется. Если полное доменное имя невозможно разрешить, вам потребуется развернуть частную зону Cloud DNS вместе с записью A IP-адреса самоуправляемого сервера Gitlab. В этом руководстве мы настроим частную зону DNS для gitlabonprem.com и запись, предназначенную для самоуправляемого сервера Gitlab.

4. Топология Codelab

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

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

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

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

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

Примечание. Если вы используете учетную запись Gmail, вы можете оставить для местоположения по умолчанию значение «Нет организации» . Если вы используете учетную запись Google Workspace, выберите местоположение, подходящее для вашей организации.

2. Затем вам необходимо включить выставление счетов в Cloud Console, чтобы использовать облачные ресурсы/API. Прохождение этой кодовой лаборатории не будет стоить много, если вообще что-то стоить. Чтобы отключить ресурсы и избежать выставления счетов за пределами этого руководства, вы можете удалить созданные вами ресурсы или удалить проект. Новые пользователи Google Cloud имеют право на участие в программе бесплатной пробной версии стоимостью 300 долларов США .

Запустить Cloud Shell

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

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

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

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

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

Включить API

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

gcloud config list project
gcloud config set project [YOUR-PROJECT-ID]
project=[YOUR-PROJECT-ID]
region=[YOUR-REGION]
echo $project
echo $region

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

gcloud services enable compute.googleapis.com

7. Создайте сеть VPC производителя.

Сеть VPC

Внутри Cloud Shell выполните следующие действия:

gcloud compute networks create looker-psc-demo --subnet-mode custom

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

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

Внутри Cloud Shell создайте подсеть PSC NAT:

gcloud compute networks subnets create producer-psc-nat-subnet --network looker-psc-demo --range 172.16.10.0/28 --region $region --purpose=PRIVATE_SERVICE_CONNECT

В Cloud Shell создайте подсеть правила переадресации производителя:

gcloud compute networks subnets create producer-psc-fr-subnet --network looker-psc-demo --range 172.16.20.0/28 --region $region --enable-private-ip-google-access

Внутри Cloud Shell создайте подсеть только для регионального прокси-сервера производителя:

gcloud compute networks subnets create $region-proxy-only-subnet \
  --purpose=REGIONAL_MANAGED_PROXY \
  --role=ACTIVE \
  --region=$region \
  --network=looker-psc-demo \
  --range=10.10.10.0/24

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

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

gcloud compute addresses create internet-neg-lb-ip \
  --region=$region \
  --subnet=producer-psc-fr-subnet

В Cloud Shell просмотрите зарезервированный IP-адрес.

gcloud compute addresses describe internet-neg-lb-ip \
  --region=$region | grep -i address:

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

user@cloudshell$ gcloud compute addresses describe internet-neg-lb-ip   --region=$region | grep -i address:
address: 172.16.20.2

Настроить Интернет NEG

Создайте Internet NEG и установите для параметра –network-endpoint-type значение интернет-fqdn-port (имя хоста и порт, по которым можно получить доступ к вашему внешнему серверу).

Внутри Cloud Shell создайте NEG в Интернете, используемый для доступа к самоуправляемому экземпляру Gitlab, gitlabonprem.com.

gcloud compute network-endpoint-groups create gitlab-self-managed-internet-neg \
    --network-endpoint-type=INTERNET_FQDN_PORT \
    --network=looker-psc-demo \
    --region=$region

ПРИМЕЧАНИЕ. Для проверки сертификата требуется fqdn=gitlabonprem,port=443 для поддержки HTTPS.

В Cloud Shell обновите NEG Интернета gitlab-self-managed-internet-neg, указав полное доменное имя gitlabonprem.com и порт 443.

gcloud compute network-endpoint-groups update gitlab-self-managed-internet-neg \
    --add-endpoint="fqdn=gitlabonprem.com,port=443" \
    --region=$region

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

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

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

В Cloud Shell создайте правило брандмауэра IAP.

gcloud compute firewall-rules create ssh-iap-looker-psc-demo \
    --network looker-psc-demo \
    --allow tcp:22 \
    --source-ranges=35.235.240.0/20

8. Создать службу продюсера

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

Внутри Cloud Shell выполните следующие действия:

gcloud compute backend-services create producer-backend-svc  --protocol=tcp --region=$region --load-balancing-scheme=INTERNAL_MANAGED

gcloud compute backend-services add-backend producer-backend-svc --network-endpoint-group=gitlab-self-managed-internet-neg --network-endpoint-group-region=$region --region=$region

В Cloud Shell создайте целевой TCP-прокси для маршрутизации запросов к внутренней службе:

gcloud compute target-tcp-proxies create producer-lb-tcp-proxy \
      --backend-service=producer-backend-svc  \
      --region=$region

В следующем синтаксисе создайте правило переадресации (внутренний балансировщик нагрузки TCP-прокси).

В Cloud Shell выполните следующие действия:

gcloud compute forwarding-rules create producer-gitlab-self-managed-fr\
     --load-balancing-scheme=INTERNAL_MANAGED \
     --network-tier=PREMIUM \
     --network=looker-psc-demo \
     --subnet=producer-psc-fr-subnet \
     --address=internet-neg-lb-ip \
     --target-tcp-proxy=producer-lb-tcp-proxy \
     --target-tcp-proxy-region=$region \
     --region=$region \
     --ports=443

Создать служебное приложение

В Cloud Shell создайте вложение службы gitlab-self-managed-svc-attachment-https с автоматическим утверждением, которое позволит Looker Core подключиться к вложению службы. Если вы хотите контролировать доступ к сервисному вложению, поддерживается опция явного одобрения.

gcloud compute service-attachments create gitlab-self-managed-svc-attachment-https --region=$region --producer-forwarding-rule=producer-gitlab-self-managed-fr --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=producer-psc-nat-subnet

Затем получите и запишите вложение службы, указанное в URI selfLink, начиная с проектов, для настройки конечной точки PSC в Looker.

selfLink: projects/<your-project-id>/regions/<your-region>/serviceAttachments/gitlab-self-managed-svc-attachment-https

Внутри Cloud Shell выполните следующие действия:

gcloud compute service-attachments describe gitlab-self-managed-svc-attachment-https --region=$region

Пример:

connectionPreference: ACCEPT_AUTOMATIC
creationTimestamp: '2025-03-04T18:55:42.254-08:00'
description: ''
enableProxyProtocol: false
fingerprint: MlY9GLLGsgE=
id: '9103522880241140673'
kind: compute#serviceAttachment
name: gitlab-self-managed-svc-attachment-https
natSubnets:
- https://www.googleapis.com/compute/v1/projects/$projectid/regions/us-central1/subnetworks/producer-psc-nat-subnet
pscServiceAttachmentId:
  high: '115404658846991336'
  low: '9103522880241140673'
reconcileConnections: false
region: https://www.googleapis.com/compute/v1/projects/$projectid/regions/us-central1
selfLink: https://www.googleapis.com/compute/v1/projects/$projectid/regions/us-central1/serviceAttachments/gitlab-self-managed-svc-attachment-https
targetService: https://www.googleapis.com/compute/v1/projects/$projectid/regions/us-central1/forwardingRules/producer-gitlab-self-managed-fr

В Cloud Console перейдите к:

Сетевые службы → Подключение частных служб → Опубликованные службы

9. Установите соединение с конечной точкой PSC в Looker.

В следующем разделе вы свяжете вложение службы Producers с Looker Core PSC с помощью флагов –psc-service-attachment в Cloud Shell для одного домена.

ПРИМЕЧАНИЕ. Каждый раз, когда вы запускаете команду обновления с флагами –psc-service-attachment, вы должны включать все соединения, которые вы хотите включить, включая соединения, которые уже были включены ранее. Пример можно найти в документации Looker PSC.

ПРИМЕЧАНИЕ. Флаг domain=gitlabonprem.com необходим для установки HTTPS-соединения с gitlabonprem.com.

ПРИМЕЧАНИЕ. Прежде чем продолжить, необходимо включить экземпляр Looker PSC .

В Cloud Shell создайте ассоциацию psc, обновив следующие параметры в соответствии с вашей средой:

• INSTANCE_NAME: имя вашего экземпляра Looker (ядро Google Cloud).
• ДОМЕН_1: gitlabonprem.com
• SERVICE_ATTACHMENT_1: URI, полученный при описании вложения службы, gitlab-self-managed-svc-attachment-https.
• РЕГИОН: регион, в котором размещен ваш экземпляр Looker (ядро Google Cloud).

Внутри Cloud Shell выполните следующие действия:

gcloud looker instances update INSTANCE_NAME \
--psc-service-attachment  domain=DOMAIN_1,attachment=SERVICE_ATTACHMENT_URI_1 \
--region=REGION

Пример:

gcloud looker instances update looker-psc-instance \
--psc-service-attachment  domain=gitlabonprem.com,attachment=projects/$project/regions/$region/serviceAttachments/gitlab-self-managed-svc-attachment-https \
--region=$region

В Cloud Shell убедитесь, что статус подключения serviceAttachments имеет значение «ACCEPTED», обновите его с помощью Looker PSC INSTANCE_NAME.

gcloud looker instances describe [INSTANCE_NAME] --region=$region --format=json

Пример:

gcloud looker instances describe looker-psc-instance --region=$region --format=json

Пример:

{
  "adminSettings": {},
  "createTime": "2024-08-23T00:00:45.339063195Z",
  "customDomain": {
    "domain": "cosmopup.looker.com",
    "state": "AVAILABLE"
  },
  "encryptionConfig": {},
  "lookerVersion": "24.12.28",
  "name": "projects/$project/locations/$region/instances/looker-psc-instance",
  "platformEdition": "LOOKER_CORE_ENTERPRISE_ANNUAL",
  "pscConfig": {
    "allowedVpcs": [

    "projects/$project/global/networks/looker-psc-demo"
    ],
    "lookerServiceAttachmentUri": "projects/t7ec792caf2a609d1-tp/regions/$region/serviceAttachments/looker-psc-f51982e2-ac0d-48b1-91bb-88656971c183",
    "serviceAttachments": [
      {
        "connectionStatus": "ACCEPTED",
        "localFqdn": "gitlabonprem.com",
        "targetServiceAttachmentUri": "projects/$project/regions/$region/serviceAttachments/gitlab-self-managed-svc-attachment-https"
      }
    ]
  },
  "pscEnabled": true,
  "state": "ACTIVE",
  "updateTime": "2024-08-30T17:47:33.440271635Z"
}

Проверьте конечную точку PSC в Cloud Console.

В Cloud Console вы можете проверить соединение PSC.

В Cloud Console перейдите к:

Looker → Экземпляр Looker → Подробности

10. Разрешение DNS

В следующем разделе создайте экземпляр GCE и проверьте разрешение DNS для самоуправляемого экземпляра Gitlab, gitlabonprem.com, выполнив PING. Как и ожидалось, разрешение не удастся, и для gitlabonprem.com потребуется частная зона DNS.

11. Создайте экземпляр GCE

Внутри Cloud Shell создайте экземпляр GCE, используемый для проверки разрешения DNS.

gcloud compute instances create gce-dns-lookup \
    --project=$projectid \
    --machine-type=e2-micro \
    --image-family debian-11 \
    --no-address \
    --image-project debian-cloud \
    --zone us-central1-a \
    --subnet=producer-psc-fr-subnet

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

gcloud compute ssh gce-dns-lookup --project=$projectid --zone=us-central1-a --tunnel-through-iap

Из ОС выполните PING на gitlabonprem.com, ожидается сбой.

ping gitlabonprem.com

Пример:

user@gce-dns-lookup:~$ ping gitlabonprem.com
ping: gitlabonprem.com: Name or service not known

Выйдите из ОС, вернув вас обратно в терминал Cloud Shell.

exit

12. Создайте частную зону DNS

Внутри Cloud Shell создайте частную зону Cloud DNS.

gcloud dns --project=$projectid managed-zones create gitlab-self-managed --description="" --dns-name="gitlabonprem.com." --visibility="private" --networks="https://compute.googleapis.com/compute/v1/projects/$projectid/global/networks/looker-psc-demo"

Внутри Cloud Shell создайте запись A, содержащую IP-адрес самоуправляемого экземпляра Gitlab: 192.168.10.4.

gcloud dns --project=$projectid record-sets create gitlabonprem.com. --zone="gitlab-self-managed" --type="A" --ttl="300" --rrdatas="192.168.10.4"

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

gcloud compute ssh gce-dns-lookup --project=$projectid --zone=us-central1-a --tunnel-through-iap

Из ОС выполните PING на gitlabonprem.com, который разрешит адрес 192.168.10.4.

ping gitlabonprem.com

Пример:

user@gce-dns-lookup:~$ ping gitlabonprem.com
PING gitlabonprem.com (192.168.10.4) 56(84) bytes of data

Выйдите из ОС, вернув вас обратно в терминал Cloud Shell.

exit

13. Гибридное подключение

Полное доменное имя gitlabonprem.com теперь можно разрешить с помощью частного IP-адреса, размещенного локально. Затем необходимо настроить гибридную сеть (например, Interconnect, HA-VPN) между VPC Looker-psc-demo и локальной сетью, чтобы обеспечить возможность подключения.

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

• Выбор продукта для сетевых подключений | Google Облако
• В звездообразной архитектуре с пирингом VPC гибридный NEG развертывается в том же VPC, что и облачный маршрутизатор (концентратор).
• Убедитесь, что локальные брандмауэры обновлены для соответствия диапазону подсетей только для прокси-сервера, поскольку эта подсеть служит исходным IP-адресом для связи с локальными рабочими нагрузками.
• Объявите подсеть только для прокси- сервера из Cloud Router как объявление настраиваемого маршрута.

14. Проверка подключения

На следующих шагах вы будете использовать консоль Looker для создания проекта для проверки подключения HTTPS к gitlabonprem.com, используя процедуру, описанную в разделе «Настройка и тестирование соединения Git».

ПРИМЕЧАНИЕ. Обязательно настройте соединение Git с локальным полным доменным именем, определенным при применении вложения службы к Looker Core. Если на этапе настройки git не будет использовано одно и то же локальное полное доменное имя, это приведет к сбою соединения.

15. Очистка

Удаление компонентов лаборатории из одного терминала Cloud Shell

gcloud compute service-attachments delete gitlab-self-managed-svc-attachment-https --region=$region -q

gcloud compute forwarding-rules delete producer-gitlab-self-managed-fr --region=$region -q

gcloud compute target-tcp-proxies delete producer-lb-tcp-proxy --region=$region -q

gcloud compute backend-services delete producer-backend-svc --region=$region -q

gcloud compute network-endpoint-groups delete gitlab-self-managed-internet-neg --region=$region -q

gcloud compute instances delete gce-dns-lookup --zone=us-central1-a -q

gcloud compute networks subnets delete producer-psc-fr-subnet producer-psc-nat-subnet $region-proxy-only-subnet --region=$region -q

gcloud dns --project=$projectid record-sets delete gitlabonprem.com. --zone="gitlab-sel
f-managed" --type="A"

gcloud dns --project=$projectid managed-zones delete gitlab-self-managed 

gcloud compute networks delete looker-psc-demo -q

16. Поздравления

Поздравляем, вы успешно настроили и проверили подключение к самоуправляемому экземпляру GitLab с помощью консоли Looker на базе Private Service Connect.

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

Cosmopup считает, что кодлабы — это здорово!!

Что дальше?

Посмотрите некоторые из этих кодовых лабораторий...

• Использование Private Service Connect для публикации и использования сервисов
• Подключайтесь к локальным службам через гибридную сеть с помощью Private Service Connect и внутреннего балансировщика нагрузки TCP-прокси.
• Доступ ко всем опубликованным лабораториям кода Private Service Connect.

Дальнейшее чтение и видео

• Настройка и тестирование соединения с Git | Смотритель | Google Облако
• Обзор частного сервиса Connect

Справочная документация

• Настройте региональный внутренний прокси-сервер Network Load Balancer с внешним сервером.
• Создайте экземпляр Looker (ядро Google Cloud) Private Service Connect.
• Как опубликовать службу с помощью Private Service Connect