‏App Engine יכול להגיע למסד הנתונים שלכם ב-VPN: מה חייב להתאים

הטענה ש-App Engine Standard אינו יכול להגיע למסד נתונים פרטי דרך Cloud VPN היא שריד מדור קודם של הפלטפורמה. מופעי Standard אינם מקבלים כתובת ילידית של VPC כפי שסביבות ריצה אחרות מקבלות, אבל הם יכולים לשלוח egress דרך מחבר Serverless VPC Access שנמצא ברשת שלכם. ברגע שהנתיב הזה קיים, 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 באופן רחב, כך שגם קריאות אינטרנט רגילות יורשות את עמדת ה-NAT וחומת האש של ה-VPC.

עריכה מקומית של הקובץ לא משנה דבר עד שתפרסו. גרסה רצה שומרת על התצורה שאיתה נוצרה.

כתובת המקור היא המחבר, לא המחשב הנייד שלכם

לכאן הולך רוב זמן הדיבוג. שער ה-VPN המרוחק וחומת האש של מסד הנתונים צריכים לאשר את הטווח שהוקצה למחבר בתוך ה-VPC, לא את כתובת המשרד שלכם ולא את כתובת ה-egress הציבורית של השירות. חפשו את הטווח הזה בקונסולה לפני שתכתבו ולו כלל אחד.

שני מקומות נוספים חייבים להסכים. טבלת הניתובים של ה-VPC צריכה נתיב אל רשת מסד הנתונים המרוחקת, והצד המרוחק צריך נתיב חזרה לטווח המחבר. אם המנהרה משתמשת בבוררי תעבורה, ודאו שטווח המחבר נמצא בתוך ההיקף המאושר. נתיב שקיים רק בכיוון מהמרוחק למקומי הוא פספוס נפוץ, והוא מעביר pings בלי להשלים לעולם לחיצת יד TCP.

מנהרה שמאשרת רק תת-רשת VM תזרוק את מנות המחבר בלי הודעת שגיאה שימושית, ולכן פקיעת הזמן של מסד הנתונים נראית כמו בעיית אישורים.

DNS נוסע בנתיב אחר

שם מארח של מסד נתונים פרטי חייב להיפתר בתוך הרשת שהמחבר מגיע אליה, דרך עמיתות Cloud DNS או אזור העברה שה-VPC יכול להשתמש בו. פתרון שלו בתחנת העבודה שלכם לא מוכיח דבר על השירות שנפרס, כי המחשב הנייד שלכם לא משתמש באותו פותר.

אם השם נפתר לכתובת ציבורית מתוך ה-VPC, אתם עומדים לדבג את חומת האש הלא נכונה.

URL Fetch לא משתמש במחבר

הגדרת ה-egress מכסה את שקעי היציאה הרגילים של סביבת הריצה, ושירות URL Fetch הישן אינו חלק מהנתיב הזה. בקשה שנשלחת דרך urlfetch מתעלמת מהמחבר יהיה אשר יהיה התצורה. כשהקריאה שנכשלת נמצאת בספרייה ישנה שעדיין משתמשת ב-URL Fetch, התיקון הוא להעביר את הקריאה הזו ללקוח ה-HTTP הסטנדרטי.

עבור דרייבר של מסד נתונים זה לעתים רחוקות הבעיה, אבל זו הסיבה הקלאסית לכך שנקודת קצה אחת עובדת ואחרת לא מאותו שירות.

אמתו בשאילתה צרה אחת

פרסו, ואז הריצו פעולת מסד נתונים אחת מורשית מהגרסה שנפרסה תוך כדי צפייה בצד המרוחק. כתובת המקור שנרשמת על ידי מסד הנתונים או שער ה-VPN אמורה להיות של המחבר. אם לא, הבקשה מעולם לא נכנסה ל-VPC ושום תצורת מנהרה לא תתקן זאת. השוו אותה לטווח שחיפשתם בקונסולה; אי התאמה בדרך כלל אומרת שמחבר שני משרת את הגרסה.

שאילתה מוצלחת מ-VM בתוך ה-VPC מוכיחה שהנתיב קיים. היא לא מוכיחה שהשירות בחר בו.