GeoServer กับ PostGIS: เส้นทาง VPN ที่สำคัญคือเส้นทางของเซิร์ฟเวอร์
การที่แล็ปท็อปของคุณเข้าถึง GeoServer ไม่ได้บอกอะไรเลยว่า GeoServer เข้าถึง PostGIS ได้หรือไม่ จงเปรียบเทียบต้นกำเนิดทั้งสอง ขอบเขตของแคช และแหล่งข้อมูลของที่เก็บข้อมูลเอง
คุณเปิดเลเยอร์ใน QGIS แล้วมันก็แสดงผล เพื่อนร่วมงานบน VPN เดียวกันได้รับข้อผิดพลาดสำหรับเลเยอร์เดียวกัน มีคนสรุปว่า VPN เสีย และชั่วโมงถัดมาก็หมดไปกับการย้ายฐานข้อมูลหรือเปิดพอร์ตที่ไม่เคยจำเป็นต้องใช้ทั้งสองอย่าง คำขอจากเดสก์ท็อปและคำสั่งที่ GeoServer ส่งไปยัง PostGIS ออกมาจากเครื่องที่ต่างกัน ในเนมสเปซเครือข่ายที่ต่างกัน ด้วยข้อมูลรับรองที่ต่างกัน การแยกสองเส้นทางนี้ออกจากกันคือหัวใจของการวินิจฉัย
สองการเชื่อมต่อ สองต้นกำเนิด
QGIS -> client's permitted path (often the VPN) -> GeoServer listener
GeoServer -> server's permitted path -> PostGIS listenerลูกศรที่สองไม่ได้สืบทอดอุโมงค์ของคอมพิวเตอร์เครื่องแรก GeoServer ในคอนเทนเนอร์มีสแต็กเครือข่ายของคอนเทนเนอร์ ไม่ใช่ของโฮสต์ และคอนเทนเนอร์บนเครือข่ายบริดจ์อาจเข้าถึงฐานข้อมูลที่โฮสต์เข้าถึงไม่ได้ หรือกลับกัน ดังนั้นผู้ใช้คนเดียวกันอาจสำเร็จและล้มเหลวได้ในเซสชันเดียว ขึ้นอยู่กับว่าคำตอบมาจากแคชหรือจากการสอบถามใหม่
| 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 |
หาขั้นตอนที่ล้มเหลวจริง
การปฏิเสธระดับบริการ คำขอภาพที่ไม่ถึงที่เก็บข้อมูลของตน และปัญหาสิทธิ์ในเลเยอร์หนึ่ง ดูคล้ายกันในแท็บเบราว์เซอร์และต่างกันโดยสิ้นเชิงในบันทึกของเซิร์ฟเวอร์ ขอการดำเนินการที่เฉพาะเจาะจง แล้วอ่านเหตุการณ์ของ GeoServer เองในช่วงเวลาเดียวกัน
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 ระบุสิ่งที่ที่เก็บข้อมูลต้องการ ได้แก่ โฮสต์ พอร์ต ฐานข้อมูล และข้อมูลรับรอง ทั้งหมดนี้อธิบายการเชื่อมต่อที่ GeoServer เปิดขึ้น ไม่มีส่วนใดอธิบายการเข้าสู่ระบบจากไคลเอนต์เดสก์ท็อปเลย เมื่ออ่านสี่ฟิลด์นี้เป็นข้อความเกี่ยวกับบริบทเครือข่ายของเซิร์ฟเวอร์ ตั๋วประเภท «ใช้งานได้ที่ฝั่งเขา» ทั้งหมดก็จัดการได้
นี่คือเหตุผลที่localhostในที่เก็บข้อมูลจึงเป็นความผิดพลาดที่พบบ่อย มันหมายถึงบริบทเครือข่ายของโปรเซส GeoServer เอง หาก GeoServer ทำงานใน Docker ขณะที่ PostGIS ทำงานบนโฮสต์localhostจะชี้เข้าไปในคอนเทนเนอร์และไม่พบสิ่งใด และไม่มีการกำหนดค่า VPN ใดเปลี่ยนสิ่งนั้นได้
บนเซิร์ฟเวอร์ ให้ตรวจเส้นทาง ตัวรับฟัง และนโยบายการพิสูจน์ตัวตนตามลำดับนั้น การพิสูจน์ตัวตนแบบอิงโฮสต์ของ PostgreSQL จะจับคู่ที่อยู่ต้นทางที่มันเห็น ซึ่งเกตเวย์อาจแปลงได้ ดังนั้นการเพิ่มพูล VPN ของไคลเอนต์ลงในไฟล์ HBA จึงแทบไม่เคยแก้การเชื่อมต่อฝั่งเซิร์ฟเวอร์ ทดสอบอย่างที่เซิร์ฟเวอร์จะทำ คือโฮสต์เดียวกัน พอร์ตเดียวกัน ผู้ใช้เดียวกัน หากการทดสอบนั้นสำเร็จขณะที่ GeoServer ยังล้มเหลว ความแตกต่างอยู่ที่บริบทของโปรเซส ไม่ใช่ที่ฐานข้อมูล
ip route get 10.20.5.11
ss -tnp | grep 5432
psql "host=10.20.5.11 dbname=gis user=geoserver" -c 'select 1'พูลและแคชเก็บสถานะข้ามการเปลี่ยนแปลง
พูลการเชื่อมต่อของที่เก็บข้อมูลเก็บซ็อกเก็ตไว้เปิด อุโมงค์ที่ขึ้นมาหนึ่งชั่วโมงหลังสร้างพูลไม่ได้ให้เส้นทางใหม่แก่พูลเสมอไป และการเชื่อมต่อที่ไม่ได้ใช้งานอาจค้างอยู่บนเส้นทางที่ตายแล้วจนกว่าการตรวจสอบหรือเวลาหมดจะปิดมัน ตรวจการตั้งค่าการตรวจสอบของที่เก็บข้อมูลที่ติดตั้งไว้แทนการสันนิษฐานว่าจะฟื้นตัว และหลีกเลี่ยงสิ่งล่อใจที่จะรีสตาร์ตบริการทั้งหมดก่อนรู้ว่าเลเยอร์ใดล้มเหลว
แคชไทล์สร้างภาพสะท้อนกลับของปัญหานั้น คือสามารถให้บริการแผนที่ที่ดูถูกต้องได้นานหลังการเชื่อมต่อฐานข้อมูลขาด การล้างแคชเพื่อ «ดูว่าจะช่วยไหม» ทำลายหลักฐานชิ้นเดียวที่จะบอกคุณว่าเส้นทางใดยังมีชีวิต
ส่งต่อโดยระบุต้นกำเนิดทั้งสอง
คำอธิบายที่ได้รับการแก้ไขอย่างรวดเร็วระบุสองสิ่ง คือคำขอของไคลเอนต์ที่ไปถึง GeoServer และการดำเนินการฝั่งแบ็กเอนด์ที่ GeoServer ทำไม่สำเร็จ เมื่อมีทั้งสอง ผู้ดูแลที่ถูกต้องจะซ่อมเส้นทางที่ล้มเหลวได้ เมื่อมีเพียงอย่างแรก การแก้ตามธรรมชาติคือการเปิดฐานข้อมูลสู่สาธารณะ ซึ่งแก้ตั๋วได้โดยสร้างปัญหาที่แย่กว่า
บันทึกเลเยอร์ รหัสการตอบกลับ ข้อยกเว้นฝั่งเซิร์ฟเวอร์ และคอนเทนเนอร์หรือโฮสต์ที่สร้างมันขึ้นมา นั่นคือสี่บรรทัด และมันขจัดความกำกวมออกไปทั้งหมด