GeoServer ו-PostGIS: נתיב ה-VPN שקובע הוא זה של השרת
העובדה שהמחשב הנייד שלך מגיע אל GeoServer אינה אומרת דבר על כך ש-GeoServer מגיע אל PostGIS. השווה בין שני המקורות, גבול המטמון והמקור של מאגר הנתונים עצמו.
אתה פותח את השכבה ב-QGIS והיא מצוירת. עמית באותו VPN מקבל שגיאה עבור אותה שכבה. מישהו מסיק שה-VPN מקולקל, והשעה הבאה מוקדשת להעברת מסד נתונים או לחשיפת פורט שמעולם לא היה זקוק לאף אחד מהשניים. הבקשה משולחן העבודה והשאילתה ששולח השרת אל מסד הנתונים יוצאות ממכונות שונות, במרחבי שמות רשת שונים, עם אישורים שונים. הפרדת שני הנתיבים האלה היא רוב האבחון.
שני חיבורים, שני מקורות
QGIS -> client's permitted path (often the VPN) -> GeoServer listener
GeoServer -> server's permitted path -> PostGIS listenerהחץ השני אינו יורש את המנהרה של המחשב הראשון. שרת שרץ בתוך מכולה מקבל את מחסנית הרשת של המכולה, לא זו של המארח, ומכולה ברשת גשרית יכולה להגיע למסד נתונים שהמארח אינו מגיע אליו, או להפך. לכן אותו משתמש יכול גם להצליח וגם להיכשל באותה ישיבה, בהתאם לשאלה אם התשובה הגיעה מהמטמון או משאילתה טרייה.
| What you tested | What it proves |
|---|---|
Portal page or GetCapabilities | HTTP reachability to GeoServer only |
| A tile served from cache | nothing about the database |
GetMap for an uncached layer | a datastore query had to happen |
מצא את השלב שנכשל בפועל
דחייה ברמת השירות, בקשת תמונה שאינה מגיעה למאגר הנתונים שלה ובעיית הרשאות בשכבה אחת נראות דומה בלשונית דפדפן ושונות לגמרי ביומן השרת. בקש את הפעולה המדויקת, ואז קרא את האירוע של השרת עצמו באותה חתימת זמן.
curl -s -o /dev/null -w '%{http_code}\n' \
"https://gis.example.com/geoserver/wms?service=WMS&version=1.3.0&request=GetCapabilities"
curl -s -o /tmp/tile.png -w '%{http_code} %{size_download}\n' \
"https://gis.example.com/geoserver/wms?service=WMS&version=1.3.0&request=GetMap&layers=corp:parcels&bbox=-13650000,4500000,-13600000,4550000&width=256&height=256&srs=EPSG:3857&format=image/png"תשובת 200 מהבקשה השנייה עם תמונה סבירה מוכיחה שמאגר הנתונים ענה. תשובת 200 עם מסמך חריגת שירות מוכיחה שלא, וטקסט החריגה נוקב בדרך כלל בשם המאגר ולא בשם הלקוח.
קרא את מאגר הנתונים מצד השרת
תיעוד ה-PostGIS של GeoServer מפרט מה המאגר צריך: מארח, פורט, מסד נתונים ואישורים. כל אלה מתארים את החיבור שהשרת פותח. דבר מזה אינו מתאר התחברות של לקוח שולחן העבודה. קרא את ארבעת השדות האלה כהצהרה על הקשר הרשת של השרת, וכל סוגיית «אצלם זה עובד» נעשית ניתנת לטיפול.
זו הסיבה ש-localhost במאגר נתונים היא טעות כה נפוצה. פירושו ההקשר הרשתי של תהליך השרת עצמו. אם השרת רץ ב-Docker בעוד מסד הנתונים רץ על המארח, localhost מצביע לתוך המכולה ולא מוצא דבר, וכל תצורת VPN לא תשנה זאת.
בשרת, בדוק את המסלול, את המאזין ואת מדיניות האימות בסדר הזה. אימות מבוסס מארח במסד הנתונים משווה את כתובת המקור שהוא רואה, ונתב עשוי לתרגם אותה, ולכן הוספת מאגר VPN של לקוחות לקובץ ההרשאות רק לעתים רחוקות מתקנת חיבור בצד השרת. בדוק כפי שהשרת היה עושה: אותו מארח, אותו פורט, אותו משתמש. אם הבדיקה מצליחה בעוד השרת עדיין נכשל, ההבדל הוא בהקשר התהליך ולא במסד הנתונים.
ip route get 10.20.5.11
ss -tnp | grep 5432
psql "host=10.20.5.11 dbname=gis user=geoserver" -c 'select 1'מאגרים ומטמונים שומרים מצב לאורך שינויים
מאגרי חיבורים של מאגר הנתונים מחזיקים שקעים פתוחים. מנהרה שעלתה שעה אחרי יצירת המאגר אינה בהכרח נותנת לו נתיב חדש, וחיבור סרק יכול להישאר על מסלול מת עד שבדיקה או פסק זמן יסיימו אותו. בדוק את הגדרות הבדיקה של המאגר המותקן במקום להניח התאוששות, והימנע מהפיתוי להפעיל מחדש את כל השירות לפני שאתה יודע איזו שכבה נכשלה.
מטמוני אריחים יוצרים את תמונת הראי של הבעיה הזאת: הם יכולים להגיש מפה שנראית תקינה זמן רב אחרי שחיבור מסד הנתונים נשבר. ניקוי המטמון כדי «לראות אם זה עוזר» הורס את פיסת הראיות היחידה שהייתה אומרת לך איזה נתיב היה חי.
העבר הלאה עם שני המקורות בשמם
התיאור שמקבל תיקון מהיר נוקב בשני דברים: בקשת הלקוח שהגיעה לשרת, והפעולה בצד השרת שהשרת לא הצליח להשלים. עם שניהם, הבעלים הנכון יכול לתקן את הנתיב שנכשל. עם הראשון בלבד, התיקון הטבעי הוא לחשוף את מסד הנתונים לציבור, מה שפותר את הפנייה ביצירת בעיה חמורה יותר.
רשום את השכבה, את קוד התגובה, את החריגה בצד השרת ואת המכולה או המארח שהפיק אותה. אלה ארבע שורות, והן מסירות את העמימות לגמרי.