App Engine-ന് നിങ്ങളുടെ VPN ഡാറ്റാബേസിൽ എത്താനാകും: എന്ത് പൊരുത്തപ്പെടണം
സ്റ്റാൻഡേർഡ് App Engine Cloud VPN വഴി ഡാറ്റാബേസിൽ എത്തുന്നു, എന്നാൽ egress, സ്രോതസ്സ് ശ്രേണി, അഭ്യർത്ഥന പാത എന്നിവ പൊരുത്തപ്പെടുമ്പോൾ മാത്രം. എന്താണ് ക്രമീകരിക്കേണ്ടതെന്ന് ഇതാ.
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-ൽ നിന്ന് വിജയകരമായ ക്വറി പാത നിലവിലുണ്ടെന്ന് തെളിയിക്കുന്നു. സേവനം അത് തിരഞ്ഞെടുത്തുവെന്ന് തെളിയിക്കുന്നില്ല.