App Engine kan nå VPN-databasen din: kva som må stemme
Standard App Engine når faktisk ein database over Cloud VPN, men berre når egress, kjeldeområde og førespurnadssti stemmer. Her er kva du må justere.
Påstanden om at App Engine Standard ikkje kan nå ein privat database over Cloud VPN, er ein rest frå ein tidlegare generasjon av plattforma. Standard-instansar får ikkje ei VPC-nativ adresse slik nokre andre køyretidsmiljø gjer, men dei kan senda egress gjennom ein Serverless VPC Access-kopling som ligg i nettverket ditt. Når den vegen først finst, ser Cloud VPN og den eksterne brannmuren trafikken til koplinga som kvar annan kjelde. Det som feilar, er sjeldan sjølve evna. Det er éin av tre innstillingar som aldri vart justerte.
Kvar det gamle svaret kom frå
Før koplingar fanst, var det praktiske svaret faktisk at Standard berre kunne snakke med offentlege endepunkt, og team flytta til ein proxy-VM eller eit anna køyretidsmiljø for å omgå det. Plattforma endra seg, folkeminne gjorde det ikkje. Mykje rådgjeving på nettet speglar framleis epoken då det ikkje fanst nokon egress-moglegheit i det heile.
Korreksjonen er smalare enn han høyrest ut. Standard kan nå det private nettverket, men berre gjennom ein støtta egress-integrasjon, og berre for destinasjonane den integrasjonen faktisk fangar.
Vel egress-vegen først
Ei kopling som er knytt til tenesta, er det som bringar trafikken hennar inn i VPC-en. Dokumentasjonen for koplinga listar opp det regionale føresetnadskravet og egress-innstillingane; koplinga må finnast i regionen til tenesta og kunne brukast av identiteten som distribuerer.
vpc_access_connector:
name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME
egress_setting: private-ranges-only
private-ranges-only sender private destinasjonar inn i VPC-en og lèt alt anna bli på den normale internettvegen, som vanlegvis er det ein databaseforbindelse treng. all-traffic pressar utgåande trafikk breitt gjennom VPC-en, så vanlege internettkall arvar òg NAT- og brannmurposisjonen til VPC-en.
Redigering av fila lokalt endrar ingenting før du distribuerer. Ein køyrande versjon held på konfigurasjonen han vart oppretta med.
Kjeldeadressa er koplinga, ikkje laptoppen din
Det er her mesteparten av feilsøkingstida går. Den eksterne VPN-gatewayen og brannmuren til databasen må tillate området som er tildelt koplinga inne i VPC-en, ikkje kontoradressa di og ikkje den offentlege egress-adressa til tenesta. Slå opp området i konsollen før du skriv éin einaste regel.
To andre stader må stemme. VPC-rutetabellen treng ei rute til det eksterne databasenettverket, og den eksterne sida treng ei returrute for området til koplinga. Viss tunnelen brukar trafikkveljarar, stadfest at området til koplinga ligg innanfor det forhandla omfanget. Ei rute som berre finst i retninga frå ekstern til lokal, er ein vanleg feil, og ho slepp ping gjennom utan å nokosinne fullføre eit TCP-handtrykk.
Ein tunnel som berre tillèt eit VM-subnett, vil droppe pakkane til koplinga utan ei nyttig feilmelding, og difor ser tidsavbrotet til databasen ut som eit legitimasjonsproblem.
DNS reiser ein annan veg
Eit privat databasevertsnamn må løysast innanfor nettverket koplinga når, gjennom Cloud DNS-peering eller ei vidaresendingssone som VPC-en kan bruke. Å løyse det på arbeidsstasjonen din provar ingenting om den distribuerte tenesta, fordi laptoppen din brukar ikkje den oppløysaren.
Viss namnet løysest til ei offentleg adresse frå innsida av VPC-en, er du i ferd med å feilsøke feil brannmur.
URL Fetch brukar ikkje koplinga
Egress-innstillinga dekkjer dei normale utgåande sokkane til køyretidsmiljøet, og den eldre URL Fetch-tenesta er ikkje ein del av den vegen. Ein førespurnad som blir send via urlfetch, ignorerer koplinga uansett kva konfigurasjonen seier. Når det feilande kallet ligg i eit eldre bibliotek som framleis brukar URL Fetch, er løysinga å flytte kallet til den standard HTTP-klienten.
For ein databasedrivar er dette sjeldan problemet, men det er den klassiske grunnen til at eitt endepunkt virkar og eit anna ikkje frå same tenesta.
Stadfest med éin smal spørjing
Distribuer, og køyr deretter éin tillaten databaseoperasjon frå den distribuerte versjonen medan du overvakar den eksterne sida. Kjeldeadressa som blir logga av databasen eller VPN-gatewayen, bør vere koplinga si. Viss ikkje, kom førespurnaden aldri inn i VPC-en, og ingen tunnelkonfigurasjon rettar det. Samanlikn ho med området du slo opp i konsollen; eit avvik betyr vanlegvis at ei andre kopling betener versjonen.
Ei vellukka spørjing frå ein VM inne i VPC-en fastslår at ruta finst. Ho fastslår ikkje at tenesta valde henne.