App Engine तुमच्या VPN डेटाबेसपर्यंत पोहोचू शकते: काय जुळले पाहिजे

App Engine Standard Cloud VPN मार्फत खाजगी डेटाबेसपर्यंत पोहोचू शकत नाही हे विधान प्लॅटफॉर्मच्या आधीच्या पिढीतील अवशेष आहे. Standard इन्स्टन्सेसना काही इतर रनटाइमप्रमाणे VPC-मूळ पत्ता मिळत नाही, पण ते तुमच्या नेटवर्कमधील Serverless VPC Access कनेक्टरमार्फत egress पाठवू शकतात. तो मार्ग अस्तित्वात आल्यावर, Cloud VPN आणि दूरचा फायरवॉल कनेक्टरची रहदारी इतर कोणत्याही स्रोताप्रमाणे पाहतात. अयशस्वी होणे क्वचितच क्षमता स्वतः. हे कधीही जुळवले न गेलेल्या तीन सेटिंग्जपैकी एक आहे.

जुने उत्तर कुठून आले

कनेक्टर अस्तित्वात येण्यापूर्वी, व्यावहारिक उत्तर खरोखर असे होते की Standard फक्त सार्वजनिक एंडपॉइंटशी बोलू शकते, आणि संघ ते टाळण्यासाठी प्रॉक्सी VM किंवा दुसऱ्या रनटाइमकडे गेले. प्लॅटफॉर्म बदलला, लोककथा बदलली नाही. ऑनलाइनच्या अनेक सल्ले अजूनही egress पर्यायच नव्हता त्या युगाचे प्रतिबिंब देतात.

दुरुस्ती ऐकायला वाटते तितकी अरुंद नाही. Standard खाजगी नेटवर्कपर्यंत पोहोचू शकते, पण केवळ समर्थित egress एकत्रीकरणाद्वारे, आणि ते एकत्रीकरण प्रत्यक्षात पकडते त्या गंतव्यांसाठीच.

प्रथम egress मार्ग निवडा

सेवेशी जोडलेला कनेक्टर तिची रहदारी VPC मध्ये टाकतो. कनेक्टरची कागदपत्रे प्रादेशिक पूर्वअट आणि egress सेटिंग्जची यादी देते; कनेक्टर सेवेच्या प्रदेशात असणे आवश्यक आहे आणि तैनात करणाऱ्या ओळखीला तो वापरण्यायोग्य असणे आवश्यक आहे.

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

private-ranges-only खाजगी गंतव्ये VPC मध्ये पाठवते आणि बाकी सर्व सामान्य इंटरनेट मार्गावर ठेवते, जे सहसा डेटाबेस कनेक्शनला आवश्यक असते. all-traffic बाहेर जाणारी रहदारी VPC मधून व्यापकपणे ढकलते, त्यामुळे सामान्य इंटरनेट कॉल्सना VPC ची NAT आणि फायरवॉल स्थिती वारसाहक्काने मिळते.

फाइल स्थानिक पातळीवर संपादित केल्याने तैनात करेपर्यंत काहीही बदलत नाही. चालू असलेली आवृत्ती ती तयार केलेली संरचना राखून ठेवते.

स्रोत पत्ता कनेक्टर आहे, तुमचा लॅपटॉप नाही

डीबगिंगचा बहुतेक वेळ येथेच जातो. दूरचा VPN गेटवे आणि डेटाबेस फायरवॉलने VPC मध्ये कनेक्टरला वाटप केलेली श्रेणी स्वीकारणे आवश्यक आहे, तुमच्या कार्यालयाचा पत्ता नाही आणि सेवेचा सार्वजनिक egress पत्ता नाही. एकही नियम लिहिण्यापूर्वी ती श्रेणी कन्सोलमध्ये शोधा.

आणखी दोन ठिकाणी सहमत व्हावे लागेल. VPC रूट टेबलला दूरच्या डेटाबेस नेटवर्ककडे मार्ग हवा, आणि दूरच्या बाजूला कनेक्टर श्रेणीसाठी परतीचा मार्ग हवा. टनेल रहदारी निवडक वापरत असल्यास, कनेक्टर श्रेणी वाटाघाटी केलेल्या व्याप्तीत आहे याची खात्री करा. केवळ दूरच्या ते स्थानिक दिशेने असलेला मार्ग सामान्य चूक आहे, आणि तो पिंग जाऊ देतो पण TCP हस्तांदोलन कधीही पूर्ण करत नाही.

केवळ VM सबनेट स्वीकारणारी टनेल कनेक्टरची पॅकेट्स उपयुक्त त्रुटी संदेशाशिवाय टाकून देईल, म्हणूनच डेटाबेसचा टाइमआउट क्रेडेन्शियल समस्येसारखा वाटतो.

DNS वेगळ्या मार्गाने प्रवास करते

खाजगी डेटाबेस होस्टनाव कनेक्टर पोहोचतो त्या नेटवर्कमध्ये सोडवले जाणे आवश्यक आहे, Cloud DNS पीअरिंग किंवा VPC वापरू शकते अशा फॉरवर्डिंग झोनद्वारे. ते तुमच्या वर्कस्टेशनवर सोडवणे तैनात सेवेबद्दल काहीही सिद्ध करत नाही, कारण तुमचा लॅपटॉप तो रिझॉल्व्हर वापरत नाही.

नाव VPC च्या आतून सार्वजनिक पत्त्यावर सोडवले गेल्यास, तुम्ही चुकीचा फायरवॉल डीबग करणार आहात.

URL Fetch कनेक्टर वापरत नाही

egress सेटिंग रनटाइमच्या सामान्य बाहेर जाणाऱ्या सॉकेट्सना व्यापते, आणि जुनी URL Fetch सेवा त्या मार्गाचा भाग नाही. urlfetch मार्फत जारी केलेली विनंती कॉन्फिगरेशन काहीही म्हणो, कनेक्टरकडे दुर्लक्ष करते. अयशस्वी कॉल URL Fetch वापरणाऱ्या जुन्या लायब्ररीत असल्यास, उपाय म्हणजे तो कॉल स्टँडर्ड HTTP क्लायंटवर हलवणे.

डेटाबेस ड्रायव्हरसाठी ही क्वचितच समस्या असते, पण एकाच सेवेतून एक एंडपॉइंट चालतो आणि दुसरा चालत नाही याचे हे क्लासिक कारण आहे.

एका अरुंद क्वेरीने पडताळा

तैनात करा, नंतर दूरच्या बाजूचे निरीक्षण करताना तैनात आवृत्तीतून एक परवानगी असलेली डेटाबेस क्रिया चालवा. डेटाबेस किंवा VPN गेटवे नोंदवत असलेला स्रोत पत्ता कनेक्टरचा असावा. नसल्यास, विनंती कधीही VPC मध्ये प्रवेशली नाही आणि कोणतीही टनेल संरचना ती दुरुस्त करणार नाही. कन्सोलमध्ये तुम्ही शोधलेल्या श्रेणीशी त्याची तुलना करा; जुळत नसल्यास सहसा दुसरा कनेक्टर आवृत्तीला सेवा देत आहे असा अर्थ होतो.

VPC मधील VM वरून यशस्वी क्वेरी मार्ग अस्तित्वात असल्याचे सिद्ध करते. सेवेने तो निवडला हे सिद्ध करत नाही.