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

Looker PSC Southbound HTTPS Internet NEG Gitlab Self-Managed,Looker PSC Southbound HTTPS Internet NEG Gitlab Self-Managed

1. Введение

В этом практическом задании вы выполните HTTPS-соединение с вашей средой GitLab Self-Managed, используя внутренний балансировщик нагрузки 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 в Looker.
Установите соединение с самоуправляемым экземпляром GitLab.

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

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

2. Что вы построите

Вам потребуется создать сеть Producer, looker-psc-demo, для развертывания внутреннего балансировщика нагрузки TCP-прокси и Internet NEG, опубликованных в качестве сервиса через Private Service Connect (PSC). После публикации вам необходимо выполнить следующие действия для проверки доступа к сервису Producer:

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

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

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

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

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

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

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

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

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

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

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

Запустить Cloud Shell

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

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

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

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

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

Создайте интернет-сервер NEG и установите параметр –network-endpoint-type в значение internet-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

Внутри Cloud Shell обновите параметр Internet 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, начинающемся с projects, чтобы настроить конечную точку 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 перейдите по следующему пути:

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

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

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

Внутри 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 убедитесь, что connectionStatus службы serviceAttachments имеет значение "ACCEPTED", и обновите его, указав INSTANCE_NAME вашего Looker PSC.

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 перейдите по следующему пути:

Looker → Looker Instance → Details

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

В следующем разделе создайте экземпляр GCE и проверьте разрешение DNS-имен на экземпляр Gitlab Self-Managed, 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

Войдите в пользовательскую виртуальную машину (consumer-vm) через IAP в Cloud Shell, чтобы проверить подключение к сервису производителя, выполнив команду curl. Повторите попытку, если произойдет таймаут.

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"

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 Cloud
В архитектуре типа «звезда» с пирингом VPC, гибридный NEG развертывается в той же VPC, что и облачный маршрутизатор (хаб).
Убедитесь, что локальные межсетевые экраны обновлены для поддержки диапазона подсетей, предназначенных только для прокси-сервера, поскольку эта подсеть служит исходным IP-адресом для связи с локальными рабочими нагрузками.
Разместите объявление подсети, доступной только через прокси, в Cloud Router в качестве объявления пользовательского маршрута.

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

На следующих шагах вы будете использовать Looker Console для создания проекта, который проверит HTTPS-соединение с gitlabonprem.com, используя процедуру, описанную в разделе «Настройка и тестирование соединения с 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 Console на базе Private Service Connect.

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

Cosmopup считает, что Codelabs — это круто!!

Что дальше?

Посмотрите некоторые из этих практических занятий по программированию...

Looker PSC Southbound HTTPS Internet NEG Gitlab Self-Managed,Looker PSC Southbound HTTPS Internet NEG Gitlab Self-Managed

1. Введение

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

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

2. Что вы построите

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

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

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

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

Запустить Cloud Shell

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

Включить API

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

Сеть VPC

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

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

Настройте интернет-NEG

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

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

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

Создать вложение услуги

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

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

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

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

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

13. Гибридная связь

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

15. Уборка

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

Что дальше?

Дополнительная литература и видеоматериалы

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