App Engine kin jo VPN-database berikke: wat oerien komme moat

Standert App Engine berikt wol in database fia Cloud VPN, mar allinnich as egress, boarneberik en oanfraachpaad oerienkomme. Dit moat jo ôfstimme.

De bewearing dat App Engine Standard gjin priveedatabase fia Cloud VPN berikke kin, is in oerbliuwsel út in eardere generaasje fan it platfoarm. Standard-eksimplaren krije gjin VPC-eigen adres lykas guon oare útfieromjouwings, mar se kinne egress stjoere fia in Serverless VPC Access-connector dy't yn jo netwurk wennet. Sadree't dat paad bestiet, sjogge Cloud VPN en de fiere firewall it ferkear fan 'e connector as elke oare boarne. Wat mislearret, is selden de kapasiteit sels. It is ien fan trije ynstellings dy't nea ôfstimd binne.

Wêr't it âlde antwurd wei kaam

Foardat connectors bestiene, wie it praktyske antwurd wier dat Standard allinnich mei iepenbiere einpunten prate koe, en teams gongen oer op in proxy-VM of in oare útfieromjouwing om dat te omgean. It platfoarm feroare, de folksferhalen net. In protte advys online wjerspegelt noch it tiidrek doe't der hielendal gjin egress-opsje wie.

De korreksje is smeller as it klinkt. Standard kin it priveenetwurk berikke, mar allinnich fia in stipe egress-yntegraasje, en allinnich foar de bestimmingen dy't dy yntegraasje echt fangt.

Kies earst it egress-paad

In connector oan 'e tsjinst is wat it ferkear yn 'e VPC bringt. De dokumintaasje fan 'e connector listet de regionale foariblette en de egress-ynstellings op; de connector moat yn 'e regio fan 'e tsjinst bestean en te brûken wêze troch de identiteit dy't útset.

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

private-ranges-only stjoert priveebestimmingen de VPC yn en lit al it oare op it normale ynternetpaad, wat in databaseferbining meastentiids nedich hat. all-traffic triuwt útgongferkear breed troch de VPC, sadat gewoane ynternetopropen ek de NAT- en firewall-hâlding fan 'e VPC ervje.

It bestân lokaal bewurkje feroaret neat oant jo útsette. In rinnende ferzje hâldt de konfiguraasje wêrmei't it makke is.

It boarne-adres is de connector, net jo laptop

Hjir giet it measte debugging-tiid hinne. De fiere VPN-gateway en de database-firewall moatte it tawiisde berik fan 'e connector talitte binnen de VPC, net jo kantoaradres en net it iepenbiere egress-adres fan 'e tsjinst. Sykje dat berik op yn 'e konsole foardat jo ien regel skriuwe.

Twa oare plakken moatte oerienkomme. De VPC-routetabel hat in rûte nei it fiere databasenetwurk nedich, en de fiere kant hat in weromrûte foar it connectorberik nedich. As de tunnel ferkearsselektors brûkt, befêstigje dan dat it connectorberik binnen it ûnderhannele berik leit. In rûte dy't allinnich yn 'e rjochting fan fier nei lokaal bestiet, is in faak foarkommende misser, en it lit pings troch sûnder ea in TCP-handshake te foltôgjen.

In tunnel dy't allinnich in VM-subnet talit, smyt pakketten fan 'e connector wei sûnder in nuttige flatermelding, en dêrom liket de timeout fan 'e database op in probleem mei oanmeldgegevens.

DNS reizget in oar paad

In privee database-hostnamme moat oplosse binnen it netwurk dat de connector berikt, fia Cloud DNS-peering of in trochstjoersône dy't de VPC brûke kin. It oplosse op jo wurkstasjon bewiist neat oer de útsette tsjinst, want jo laptop brûkt dy resolver net.

As de namme fan binnen de VPC nei in iepenbier adres oplost, steane jo op it punt de ferkearde firewall te debuggen.

URL Fetch brûkt de connector net

De egress-ynstelling beslacht de normale útgongssockets fan 'e útfieromjouwing, en de âlde URL Fetch-tsjinst is gjin part fan dat paad. In oanfraach fia urlfetch negearret de connector, wat de konfiguraasje ek seit. As de mislearjende oprop yn in âldere biblioteek sit dy't noch URL Fetch brûkt, is de oplossing om dy oprop nei de standert HTTP-klant te ferpleatsen.

Foar in database-stjoerder is dit selden it probleem, mar it is de klassike reden wêrom't ien einpunt wurket en in oar net út deselde tsjinst.

Ferifiearje mei ien smelle query

Set út en rin dan ien tastiene databasebewurking fan 'e útsette ferzje wylst jo de fiere kant besjogge. It boarne-adres dat de database of de VPN-gateway logt, moat dat fan 'e connector wêze. Is dat net sa, dan kaam de oanfraach nea yn 'e VPC en gjin inkelde tunnelkonfiguraasje ferhelpt dat. Fergelykje it mei it berik dat jo yn 'e konsole opsochten; in ôfwiking betsjut meastentiids dat in twadde connector de ferzje betsjinnet.

In suksesfolle query fan in VM binnen de VPC bewiist dat de rûte bestiet. It bewiist net dat de tsjinst dy keas.

Relatearre artikelen