App Engine povas atingi vian VPN-datumbazon: kio devas kongrui

La aserto, ke App Engine Standard ne povas atingi privatan datumbazon tra Cloud VPN, estas restaĵo de pli frua generacio de la platformo. Standard-okazoj ne ricevas VPC-naskan adreson kiel kelkaj aliaj rulmedioj, sed ili povas sendi eliron tra konektilo Serverless VPC Access, kiu troviĝas en via reto. Post kiam tiu vojo ekzistas, Cloud VPN kaj la fora fajroŝirmilo vidas la trafikon de la konektilo kiel ajnan alian fonton. Tio, kio malsukcesas, malofte estas la kapablo mem. Ĝi estas unu el tri agordoj, kiuj neniam estis kongruigitaj.

De kie venis la malnova respondo

Antaŭ ol konektiloj ekzistis, la praktika respondo vere estis, ke Standard povas paroli nur kun publikaj finpunktoj, kaj teamoj transiris al prokura VM aŭ alia rulmedio por ĉirkaŭi tion. La platformo ŝanĝiĝis, sed la folkloro ne. Multaj konsiloj en la reto ankoraŭ reflektas la epokon, kiam entute ne ekzistis elira opcio.

La korekto estas pli mallarĝa ol ĝi sonas. Standard povas atingi la privatan reton, sed nur per subtenata elira integriĝo, kaj nur por la celoj, kiujn tiu integriĝo efektive kaptas.

Unue elektu la eliran vojon

Konektilo ligita al la servo estas tio, kio enigas ĝian trafikon en la VPC. La dokumentaro pri la konektilo listigas la regionan antaŭkondiĉon kaj la elirajn agordojn; la konektilo devas ekzisti en la regiono de la servo kaj esti uzebla de la deploja identeco.

vpc_access_connector:
  name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME
  egress_setting: private-ranges-only

private-ranges-only sendas privatajn celojn en la VPC kaj lasas ĉion alian sur la normala interreta vojo, kion kutime bezonas datumbaza konekto. all-traffic pelas elirantan trafikon vaste tra la VPC, do ordinaraj interretaj alvokoj ankaŭ heredas la NAT- kaj fajroŝirmilan sintenon de la VPC.

Redakti la dosieron loke ŝanĝas nenion ĝis vi deplojas. Rulanta versio konservas la agordon, kun kiu ĝi estis kreita.

La fonta adreso estas la konektilo, ne via tekkomputilo

Ĉi tie foriras la plej granda parto de la sencimiga tempo. La fora VPN-pordego kaj la datumbaza fajroŝirmilo devas akcepti la asignitan gamon de la konektilo ene de la VPC, ne la adreson de via oficejo kaj ne la publikan eliran adreson de la servo. Serĉu tiun gamon en la konzolo antaŭ ol skribi eĉ unu regulon.

Du pliaj lokoj devas kongrui. La VPC-enkursigilo bezonas itineron al la fora datumbaza reto, kaj la fora flanko bezonas revenan itineron por la gamo de la konektilo. Se la tunelo uzas trafik-selektilojn, konfirmu, ke la gamo de la konektilo troviĝas ene de la intertraktita amplekso. Itinero, kiu ekzistas nur en la direkto de fora al loka, estas ofta manko, kaj ĝi pasigas pingojn sen iam fini TCP-manpremon.

Tunelo, kiu akceptas nur VM-subreton, forĵetos pakaĵojn de la konektilo sen utila erarmesaĝo, kaj tial la datumbaza tempolimo aspektas kiel problemo pri akreditaĵoj.

DNS vojaĝas per alia vojo

Privata datumbaza gastigantnomo devas esti solvita ene de la reto, kiun la konektilo atingas, per Cloud DNS-peering aŭ plusenda zono, kiun la VPC povas uzi. Solvi ĝin sur via labormaŝino pruvas nenion pri la deplojita servo, ĉar via tekkomputilo ne uzas tiun solvilon.

Se la nomo solviĝas al publika adreso el interne de la VPC, vi baldaŭ sencimigos la malĝustan fajroŝirmilon.

URL Fetch ne uzas la konektilon

La elira agordo kovras la normalajn elirantajn ingojn de la rulmedio, kaj la malnova servo URL Fetch ne estas parto de tiu vojo. Peto eldonita per urlfetch ignoras la konektilon, kion ajn diras la agordo. Kiam la malsukcesa alvoko troviĝas en pli malnova biblioteko, kiu ankoraŭ uzas URL Fetch, la solvo estas movi tiun alvokon al la norma HTTP-kliento.

Por datumbaza pelilo tio malofte estas la problemo, sed ĝi estas la klasika kialo, kial unu finpunkto funkcias kaj alia ne el la sama servo.

Kontrolu per unu mallarĝa peto

Deploju, poste ruligu unu permesitan datumbazan operacion el la deplojita versio dum vi observas la foran flankon. La fonta adreso registrita de la datumbazo aŭ de la VPN-pordego devus esti tiu de la konektilo. Se ne, la peto neniam eniris la VPC-on kaj nenia kvanto da tunela agordo riparos tion. Komparu ĝin kun la gamo, kiun vi serĉis en la konzolo; malkongruo kutime signifas, ke dua konektilo servas la version.

Sukcesa peto de VM ene de la VPC pruvas, ke la itinero ekzistas. Ĝi ne pruvas, ke la servo elektis ĝin.