Connettiti ai servizi on-prem su rete ibrida utilizzando Private Service Connect e NEG ibrido con bilanciatore del carico HTTP(s) interno

1. Introduzione

Cloud Load Balancing supporta il bilanciamento del carico del traffico verso endpoint che si estendono oltre Google Cloud, ad esempio data center on-premise e altri cloud pubblici che puoi utilizzare con la connettività ibrida.

Una strategia ibrida è una soluzione pragmatica per adattarsi alle mutevoli richieste del mercato e modernizzare gradualmente le applicazioni. Potrebbe trattarsi di un deployment ibrido temporaneo per consentire la migrazione a una moderna soluzione basata sul cloud o di una funzionalità permanente dell'infrastruttura IT della tua organizzazione.

La configurazione del bilanciamento del carico ibrido ti consente anche di sfruttare i vantaggi delle funzionalità di networking di Cloud Load Balancing per i servizi in esecuzione sulla tua infrastruttura esistente al di fuori di Google Cloud.

Se vuoi rendere disponibile il servizio ibrido in altre reti VPC, puoi utilizzare Private Service Connect per pubblicare il servizio. Se posizioni un collegamento di servizio davanti al bilanciatore del carico HTTP(S) interno regionale,puoi consentire ai client in altre reti VPC di raggiungere i servizi ibridi in esecuzione in ambienti on-premise o in altri cloud.

Cosa creerai

In questo codelab, creerai un bilanciatore del carico HTTP(S) interno con connettività ibrida a un servizio on-premise utilizzando un gruppo di endpoint di rete. Il VPC consumer potrà comunicare con il servizio on-premise utilizzando le porte 80, mentre la porta 443 non rientra nell'ambito del codelab.

Nota:Codelab offre passaggi di configurazione e convalida basati sulla topologia illustrata. Modifica la procedura in base alle esigenze della tua organizzazione. Le autorizzazioni IAM non rientrano nell'ambito del codelab.

Cosa imparerai a fare

• Come creare un bilanciatore del carico HTTP(S) interno con un backend NEG ibrido
• Come stabilire un producer (collegamento di servizio) e un consumer (regola di forwarding) Private Service Connect

Nota:questo codelab si concentra sull'implementazione di un bilanciatore del carico HTTP(S) interno con PSC. La configurazione del networking ibrido non è documentata, anche se vengono forniti documentazione di supporto e screenshot.

Che cosa ti serve

• Networking ibrido stabilito, ad es.VPN ad alta affidabilità, Interconnect, SW-WAN
• Progetto Google Cloud

Stabilire la connettività ibrida

I tuoi ambienti Google Cloud e on-premise o di altri cloud devono essere connessi tramite connettività ibrida, utilizzando collegamenti VLAN di Cloud Interconnect o tunnel Cloud VPN con router Cloud. Ti consigliamo di utilizzare una connessione ad alta affidabilità.

Un router Cloud abilitato con il routing dinamico globale apprende l'endpoint specifico tramite BGP e lo programma nella rete VPC di Google Cloud. Il routing dinamico regionale non è supportato. Anche le route statiche non sono supportate.

La rete VPC di Google Cloud che utilizzi per configurare Cloud Interconnect o Cloud VPN è la stessa che utilizzi per configurare il deployment del bilanciamento del carico ibrido. Assicurati che gli intervalli CIDR della subnet della rete VPC non siano in conflitto con gli intervalli CIDR remoti. Quando gli indirizzi IP si sovrappongono, le route di subnet hanno la priorità sulla connettività remota.

Per istruzioni, vedi:

• Documentazione di Cloud VPN
• Documentazione di Cloud Interconnect

Annunci di route personalizzati

Le subnet riportate di seguito richiedono annunci personalizzati dal router Cloud alla rete on-premise, garantendo l'aggiornamento delle regole firewall on-premise.

Subnet	Descrizione
172.16.0.0/23	Subnet proxy utilizzata per comunicare direttamente con il servizio on-premise
130.211.0.0/22, 35.191.0.0/16	Controllo dell'integrità di Google Cloud

2. Prima di iniziare

Aggiorna il progetto per supportare il codelab

Questo codelab utilizza le variabili $per facilitare l'implementazione della configurazione di gcloud in Cloud Shell.

In Cloud Shell, esegui quanto segue:

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
psclab=YOUR-PROJECT-NAME
echo $psclab

3. Configurazione di Producer

Crea il VPC del produttore

In Cloud Shell, esegui quanto segue:

gcloud compute networks create producer-vpc --project=$psclab --subnet-mode=custom

Crea le subnet del produttore

In Cloud Shell, esegui quanto segue:

gcloud compute networks subnets create subnet-201 --project=$psclab --range=10.10.1.0/24 --network=producer-vpc --region=us-central1

gcloud compute networks subnets create subnet-202 --project=$psclab --range=10.20.1.0/24 --network=producer-vpc --region=us-central1

Prenota un indirizzo IP per il bilanciatore del carico interno

In Cloud Shell esegui le seguenti operazioni. L'utilizzo di SHARED_VIP non è supportato con Private Service Connect, utilizza invece GCE_ENDPOINT

gcloud compute addresses create lb-ip \
    --region=us-central1 \
    --subnet=subnet-202 \
    --purpose=GCE_ENDPOINT

Utilizza il comando compute addresses describe per visualizzare l'indirizzo IP allocato.

gcloud compute addresses describe lb-ip  --region=us-central1 | grep address:

Crea le subnet proxy regionali

L'allocazione dei proxy avviene a livello di VPC, non di bilanciatore del carico. Devi creare una subnet solo proxy in ogni regione di una rete virtuale (VPC) in cui utilizzi bilanciatori del carico basati su Envoy. Se implementi più bilanciatori del carico nella stessa regione e nella stessa rete VPC, questi condividono la stessa subnet solo proxy per il bilanciamento del carico.

1. Un client stabilisce una connessione all'indirizzo IP e alla porta della regola di forwarding del bilanciatore del carico.
2. Ogni proxy è in ascolto sull'indirizzo IP e sulla porta specificati dalla regola di forwarding del bilanciatore del carico corrispondente. Uno dei proxy riceve e termina la connessione di rete del client.
3. Il proxy stabilisce una connessione alla VM o all'endpoint di backend appropriato in un NEG, come determinato dalla mappa URL e dai servizi di backend del bilanciatore del carico.

Devi creare subnet solo proxy indipendentemente dal fatto che la rete sia in modalità automatica o personalizzata. Una subnet solo proxy deve fornire almeno 64 indirizzi IP. Questo requisito corrisponde a una lunghezza del prefisso pari o inferiore a /26. La dimensione consigliata della subnet è /23 (512 indirizzi solo proxy).

Nota:la subnet solo proxy richiede una pubblicità BGP del cliente on-premise, pertanto instradabile alla tua rete on-premise. L'accesso al servizio è reso possibile tramite la subnet proxy fornita.

In Cloud Shell, esegui quanto segue:

gcloud compute networks subnets create proxy-subnet-us-central \
  --purpose=REGIONAL_MANAGED_PROXY \
  --role=ACTIVE \
  --region=us-central1 \
  --network=producer-vpc \
  --range=172.16.0.0/23

Crea le subnet NAT Private Service Connect

Crea una o più subnet dedicate da utilizzare con Private Service Connect. Se utilizzi la console Google Cloud per pubblicare un servizio, puoi creare le subnet durante questa procedura. Crea la subnet nella stessa regione del bilanciatore del carico del servizio. Non puoi convertire una subnet normale in una subnet Private Service Connect.

In Cloud Shell, esegui quanto segue:

gcloud compute networks subnets create psc-nat-subnet --network=producer-vpc --region=us-central1 --range=100.100.10.0/24 --purpose=private-service-connect

Crea le regole firewall del produttore

Configura le regole firewall per consentire il traffico tra gli endpoint Private Service Connect e l'allegato del servizio. Nel codelab, è stata creata una regola firewall in entrata che consente alla subnet NAT 100.100.10.0/24 di accedere al collegamento di servizio Private Service Connect (bilanciatore del carico interno).

In Cloud Shell, esegui quanto segue:

gcloud compute --project=$psclab firewall-rules create allow-to-ingress-nat-subnet --direction=INGRESS --priority=1000 --network=producer-vpc --action=ALLOW --rules=all --source-ranges=100.100.10.0/24

In Cloud Shell, crea la regola fw-allow-health-check per consentire ai controlli di integrità di Google Cloud di raggiungere il servizio on-premise (servizio di backend) sulla porta TCP 80.

gcloud compute firewall-rules create fw-allow-health-check \
    --network=producer-vpc \
    --action=allow \
    --direction=ingress \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --rules=tcp:80

Crea una regola firewall di autorizzazione in entrata per la subnet solo proxy per consentire al bilanciatore del carico di comunicare con le istanze di backend sulla porta TCP 80

gcloud compute firewall-rules create fw-allow-proxy-only-subnet \
    --network=producer-vpc \
    --action=allow \
    --direction=ingress \
    --source-ranges=172.16.0.0/23 \
    --rules=tcp:80

Configura il NEG di connettività ibrida

Quando crei il NEG,utilizza una ZONA che riduca al minimo la distanza geografica tra Google Cloud e il tuo ambiente on-premise o un altro ambiente cloud. Ad esempio, se ospiti un servizio in un ambiente on-premise a Francoforte, in Germania, puoi specificare la zona europe-west3-a di Google Cloud quando crei il gruppo di elenchi di esclusione.

Inoltre, se utilizzi Cloud Interconnect, la ZONA utilizzata per creare il NEG deve trovarsi nella stessa regione in cui è stato configurato il collegamento di interconnessione Cloud Interconnect.

Per le regioni e le zone disponibili, consulta la documentazione di Compute Engine: regioni e zone disponibili.

In Cloud Shell, crea un NEG di connettività ibrida utilizzando il comando gcloud compute network-endpoint-groups create.

gcloud compute network-endpoint-groups create on-prem-service-neg \
    --network-endpoint-type=NON_GCP_PRIVATE_IP_PORT \
    --zone=us-central1-a \
    --network=producer-vpc

In Cloud Shell aggiungi l'endpoint IP:Port on-premise al NEG ibrido.

gcloud compute network-endpoint-groups update on-prem-service-neg \
    --zone=us-central1-a \
    --add-endpoint="ip=192.168.1.5,port=80"

Configura il bilanciatore del carico

Nei passaggi seguenti configurerai il bilanciatore del carico (regola di forwarding) e lo assocerai al gruppo di endpoint di rete.

In Cloud Shell crea il controllo di integrità regionale passato al servizio on-premise

gcloud compute health-checks create http http-health-check \
    --region=us-central1 \
    --use-serving-port

In Cloud Shell crea il servizio di backend per il backend on-premise che utilizza il NEG ibrido

 gcloud compute backend-services create on-premise-service-backend \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --protocol=HTTP \
      --health-checks=http-health-check \
      --health-checks-region=us-central1 \
      --region=us-central1

In Cloud Shell, aggiungi il backend NEG ibrido al servizio di backend. Per RATE, inserisci il valore massimo di RATE che deve gestire il backend.

gcloud compute backend-services add-backend on-premise-service-backend \
    --region=us-central1 \
    --balancing-mode=RATE \
    --max-rate-per-endpoint=100 \
    --network-endpoint-group=on-prem-service-neg \
    --network-endpoint-group-zone=us-central1-a

In Cloud Shell, crea la mappa URL per instradare le richieste in entrata al servizio di backend.

gcloud compute url-maps create on-prem-svc-url-map \
    --default-service on-premise-service-backend \
    --region=us-central1

Crea il proxy HTTP di destinazione

gcloud compute target-http-proxies create proxy-subnet-us-central\
    --url-map=on-prem-svc-url-map \
    --url-map-region=us-central1 \
    --region=us-central1

Crea una regola di forwarding per indirizzare le richieste in entrata al proxy. Non utilizzare la subnet solo proxy per creare la regola di forwarding.

 gcloud compute forwarding-rules create http-hybrid-neg-fwd-rule \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --network=producer-vpc \
      --subnet=subnet-202 \
      --address=lb-ip \
      --ports=80 \
      --region=us-central1 \
      --target-http-proxy=proxy-subnet-us-central \
      --target-http-proxy-region=us-central1

4. Convalida il bilanciatore del carico

Nella console Cloud, vai a Servizi di rete → Bilanciamento del carico → Bilanciatori del carico. Tieni presente che 1 NEG è "Verde", a indicare un controllo di integrità riuscito per il servizio on-premise

Se selezioni ‘on-premise-svc-url-map', viene visualizzato l'indirizzo IP front-end e viene identificato il servizio di backend

5. Visualizzare le route apprese da on-premise

Vai a Rete VPC → Route. Tieni presente che la subnet del servizio on-premise appresa è 192.168.1.0/27

6. Convalida la connettività al servizio on-premise

Dalla VPC dei producer creeremo una VM per testare la connettività al servizio on-premise, dopodiché la configurazione successiva sarà il collegamento al servizio.

In Cloud Shell, crea l'istanza di test nel VPC producer

gcloud compute instances create test-box-us-central1 \
    --zone=us-central1-a \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --subnet=subnet-201 \
    --no-address

Per consentire a IAP di connettersi alle tue istanze VM, crea una regola firewall che:

• Si applichi a tutte le istanze VM a cui vuoi accedere tramite IAP.
• Consente il traffico in entrata dall'intervallo IP 35.235.240.0/20. Questo intervallo contiene tutti gli indirizzi IP che utilizzati da IAP per l'inoltro TCP.

In Cloud Shell, crea l'istanza di test nel VPC producer

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

Accedi a test-box-us-central1 utilizzando IAP in Cloud Shell per convalidare la connettività al servizio on-premise eseguendo un comando curl sull'indirizzo IP del bilanciamento del carico. Riprova se si verifica un timeout.

gcloud compute ssh test-box-us-central1 --project=$psclab --zone=us-central1-a --tunnel-through-iap

Esegui un comando curl per convalidare la connettività al servizio on-premise. Una volta convalidata, esci dalla VM e torna al prompt di Cloud Shell. Sostituisci l'IP del bilanciatore del carico interno in base all'output identificato nel passaggio 4.

user@test-box-us-central1:~$ curl -v 10.20.1.2
* Expire in 0 ms for 6 (transfer 0x55b7725c10f0)
*   Trying 10.20.1.2...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55b7725c10f0)
* Connected to 10.20.1.2 (10.20.1.2) port 80 (#0)
> GET / HTTP/1.1
> Host: 10.20.1.2
> User-Agent: curl/7.64.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< content-type: text/html; charset=utf-8
< accept-ranges: bytes
< etag: "3380914763"
< last-modified: Mon, 05 Dec 2022 15:10:56 GMT
< expires: Mon, 12 Dec 2022 03:17:20 GMT
< cache-control: max-age=0
< content-length: 37
< date: Mon, 12 Dec 2022 03:17:20 GMT
< server: lighttpd/1.4.53
< via: 1.1 google
< 
Welcome to my on-premise service!!

7. Crea il collegamento del servizio Private Service Connect

Nei passaggi successivi creeremo il collegamento al servizio. Una volta accoppiato a un endpoint consumer, l'accesso al servizio on-premise viene ottenuto senza la necessità del peering VPC.

Crea il collegamento al servizio

In Cloud Shell, crea il collegamento al servizio

gcloud compute service-attachments create service-1 --region=us-central1 --producer-forwarding-rule=http-hybrid-neg-fwd-rule --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=psc-nat-subnet

(Facoltativo) Se utilizzi un VPC condiviso, crea il collegamento del servizio nel progetto di servizio

gcloud compute service-attachments create service-1 --region=us-central1 --producer-forwarding-rule=http-hybrid-neg-fwd-rule --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=projects/<hostproject>/regions/<region>/subnetworks/<natsubnet>

Convalidare l'allegato del servizio TCP

gcloud compute service-attachments describe service-1 --region us-central1

(Facoltativo) Vai a Servizi di rete → Private Service Connect per visualizzare il collegamento del servizio appena stabilito.

Selezionando Service-1 vengono visualizzati maggiori dettagli, tra cui l'URI del collegamento al servizio utilizzato dal consumer per stabilire una connessione Private Service Connect. Prendi nota dell'URI, poiché verrà utilizzato in un passaggio successivo.

Dettagli collegamento di servizio: projects/<projectname>/regions/us-central1/serviceAttachments/service-1

8. Configurazione consumatore

Crea il VPC consumer

In Cloud Shell, esegui quanto segue:

gcloud compute networks create consumer-vpc --project=$psclab --subnet-mode=custom

Crea le subnet consumer

In Cloud Shell crea la subnet GCE

gcloud compute networks subnets create subnet-101 --project=$psclab --range=10.100.1.0/24 --network=consumer-vpc --region=us-central1

In Cloud Shell, crea la subnet dell'endpoint consumer

gcloud compute networks subnets create subnet-102 --project=$psclab --range=10.100.2.0/24 --network=consumer-vpc --region=us-central1

Crea l'endpoint consumer (regola di forwarding)

In Cloud Shell, crea l'indirizzo IP statico che verrà utilizzato come endpoint consumer

gcloud compute addresses create psc-consumer-ip-1 --region=us-central1 --subnet=subnet-102 --addresses 10.100.2.10

Utilizziamo l'URI del collegamento al servizio generato in precedenza per creare l'endpoint consumer

In Cloud Shell, crea l'endpoint consumer

gcloud compute forwarding-rules create psc-consumer-1 --region=us-central1 --network=consumer-vpc --address=psc-consumer-ip-1 --target-service-attachment=projects/$psclab/regions/us-central1/serviceAttachments/service-1

9. Convalida di Private Service Connect consumer - VPC consumer

Dalla VPC consumer, verifica che la connessione Private Service Connect sia stata creata correttamente andando su Servizi di rete → Private Service Connect → Endpoint connessi. Prendi nota della connessione psc-consumer-1 stabilita e dell'indirizzo IP corrispondente che abbiamo creato in precedenza.

Quando selezioni psc-consumer-1, vengono forniti i dettagli, incluso l'URI del collegamento al servizio

10. Convalida di Private Service Connect consumer - VPC producer

Dalla VPC del producer, verifica che la connessione Private Service Connect sia riuscita andando a Servizi di rete → Private Service Connect → Servizio pubblicato. Tieni presente che la connessione service-1 pubblicata ora indica una regola di forwarding (endpoint di connessione).

11. Crea una zona DNS privata e un record A

Crea la zona DNS privata mappata all'endpoint di connessione PSC, consentendo l'accesso senza problemi al producer da qualsiasi host all'interno del VPC.

Nota:l'accesso a un endpoint consumer tramite il peering VPC non è supportato

Da Cloud Shell

gcloud dns --project=$psclab managed-zones create codelab-zone --description="" --dns-name="codelab.net." --visibility="private" --networks="consumer-vpc"

gcloud dns --project=$psclab record-sets create service1.codelab.net. --zone="codelab-zone" --type="A" --ttl="300" --rrdatas="10.100.2.10"

12. Convalidare l'accesso del consumer al servizio Producer utilizzando la VM

Dalla VPC consumer creeremo una VM per testare la connettività al servizio on-premise accedendo al servizio endpoint consumer service1.codelabs.net

In Cloud Shell, crea l'istanza di test nel VPC consumer

gcloud compute instances create consumer-vm \
    --zone=us-central1-a \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --subnet=subnet-101 \
    --no-address

Per consentire a IAP di connettersi alle tue istanze VM, crea una regola firewall che:

• Si applichi a tutte le istanze VM a cui vuoi accedere tramite IAP.
• Consente il traffico in entrata dall'intervallo IP 35.235.240.0/20. Questo intervallo contiene tutti gli indirizzi IP che utilizzati da IAP per l'inoltro TCP.

In Cloud Shell, crea l'istanza di test nel VPC consumer

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

Accedi a consumer-vm utilizzando IAP in Cloud Shell per convalidare la connettività al servizio on-premise eseguendo un comando curl sul servizio FQDN DNS service1.codelab.net. Riprova se si verifica un timeout.

gcloud compute ssh consumer-vm --project=$psclab --zone=us-central1-a --tunnel-through-iap

Esegui un comando curl per convalidare la connettività al servizio on-premise. Una volta convalidata, esci dalla VM e torna al prompt di Cloud Shell.

In Cloud Shell esegui un comando curl

$ curl -v service1.codelab.net
*   Trying 10.100.2.10...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x5650fc3390f0)
* Connected to service1.codelab.net (10.100.2.10) port 80 (#0)
> GET / HTTP/1.1
> Host: service1.codelab.net
> User-Agent: curl/7.64.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Accept-Ranges: bytes
< ETag: "3380914763"
< Last-Modified: Mon, 05 Dec 2022 15:10:56 GMT
< Expires: Mon, 05 Dec 2022 15:15:41 GMT
< Cache-Control: max-age=0
< Content-Length: 37
< Date: Mon, 05 Dec 2022 15:15:41 GMT
< Server: lighttpd/1.4.53
< 
Welcome to my on-premise service!!

Di seguito è riportato un esempio di acquisizione dal servizio on-premise. Tieni presente che l'indirizzo IP di origine 172.16.0.13 proviene dall'intervallo di subnet proxy 172.16.0.0/23.

13. Liberare spazio di Producer

Eliminare i componenti di Producer

In Cloud Shell, elimina le istanze di test nel VPC del producer

gcloud compute instances delete test-box-us-central1 --zone=us-central1-a --quiet

gcloud compute service-attachments delete service-1 --region=us-central1 --quiet 

gcloud compute forwarding-rules delete http-hybrid-neg-fwd-rule --region=us-central1 --quiet

gcloud compute target-http-proxies delete proxy-subnet-us-central --region=us-central1 --quiet

gcloud compute url-maps delete on-prem-svc-url-map --region=us-central1 --quiet

gcloud compute backend-services delete on-premise-service-backend --region=us-central1 --quiet

gcloud compute network-endpoint-groups delete on-prem-service-neg --zone=us-central1-a --quiet

gcloud compute addresses delete lb-ip --region=us-central1 --quiet

gcloud compute networks subnets delete psc-nat-subnet subnet-201 subnet-202 proxy-subnet-us-central --region=us-central1 --quiet

gcloud compute firewall-rules delete ssh-iap fw-allow-proxy-only-subnet allow-to-ingress-nat-subnet fw-allow-health-check --quiet

gcloud compute health-checks delete http-health-check --region=us-central1 --quiet

gcloud compute networks delete producer-vpc --quiet

14. Liberare spazio per i consumatori

Eliminare i componenti di Consumer

In Cloud Shell elimina le istanze di test nel VPC consumer

gcloud compute instances delete consumer-vm --zone=us-central1-a --quiet

gcloud compute forwarding-rules delete psc-consumer-1 --region=us-central1 --quiet

gcloud compute addresses delete psc-consumer-ip-1 --region=us-central1 --quiet

gcloud compute networks subnets delete subnet-101 subnet-102 --region=us-central1 --quiet

gcloud compute firewall-rules delete ssh-iap-consumer --quiet

gcloud dns record-sets delete service1.codelab.net --type=A --zone=codelab-zone --quiet

gcloud dns managed-zones delete codelab-zone --quiet 

gcloud compute networks delete consumer-vpc --quiet 

15. Complimenti

Congratulazioni, hai configurato e convalidato correttamente Private Service Connect con un bilanciatore del carico HTTP(S) interno.

Hai creato l'infrastruttura del producer e hai aggiunto un collegamento del servizio nel VPC producer che punta a un servizio on-premise. Hai imparato a creare un endpoint consumer nel VPC consumer che consentiva la connettività al servizio on-premise.

Passaggi successivi

Dai un'occhiata ad alcuni di questi codelab...

• Utilizzo di Private Service per pubblicare e consumare servizi con GKE
• Utilizzo di Private Service Connect per pubblicare e utilizzare servizi
• Connettiti ai servizi on-prem tramite networking ibrido utilizzando Private Service Connect e un bilanciatore del carico proxy TCP interno

Ulteriori letture e video

• Panoramica di Private Service Connect
• Che cos'è Private Service Connect?
• Tipi di bilanciatori del carico supportati

Documentazione di riferimento

• Panoramica del bilanciatore del carico HTTP(S) interno
• Panoramica dei controlli di integrità
• Come pubblicare un servizio utilizzando Private Service Connect