GeoServer și PostGIS: calea VPN care contează este cea a serverului

Deschizi stratul în QGIS și acesta se randează. Un coleg din același VPN primește o eroare pentru același strat. Cineva concluzionează că VPN-ul este stricat, iar următoarea oră se duce pe mutarea unei baze de date sau pe expunerea unui port care nu avea nevoie de niciuna. Cererea de pe desktop și interogarea pe care GeoServer o face către PostGIS pleacă de pe mașini diferite, în spații de nume de rețea diferite, cu acreditări diferite. Separarea acestor două căi este cea mai mare parte a diagnosticului.

Două conexiuni, două origini

QGIS  ->  client's permitted path (often the VPN)  ->  GeoServer listener
GeoServer -> server's permitted path  ->  PostGIS listener

A doua săgeată nu moștenește tunelul primului calculator. Un GeoServer într-un container are stiva de rețea a containerului, nu a gazdei, iar un container pe o rețea punte poate ajunge la o bază de date la care gazda nu ajunge, sau invers. Astfel, același utilizator poate reuși și eșua în aceeași sesiune, în funcție de faptul că răspunsul a venit din cache sau dintr-o interogare proaspătă.

Găsește pasul care a eșuat de fapt

Un refuz la nivel de serviciu, o cerere de imagine care nu ajunge la depozitul ei de date și o problemă de permisiuni într-un strat arată similar într-o filă de browser și complet diferit în jurnalul serverului. Cere operația specifică, apoi citește evenimentul propriu al GeoServer pentru aceeași marcă de timp.

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"

Un 200 din a doua cerere cu o imagine plauzibilă dovedește că depozitul de date a răspuns. Un 200 cu un document de excepție de serviciu dovedește că nu a răspuns, iar textul excepției numește de obicei depozitul, nu clientul.

Citește depozitul de date din partea serverului

Referința PostGIS a GeoServer enumeră ce are nevoie depozitul: gazdă, port, bază de date și acreditări. Toate acestea descriu conexiunea pe care GeoServer o deschide. Nimic din toate acestea nu descrie o autentificare de la clientul desktop. Citește aceste patru câmpuri ca pe o afirmație despre contextul de rețea al serverului, iar întreaga clasă de tichete „la ei funcționează” devine tratabilă.

De aceea localhost într-un depozit de date este o greșeală atât de frecventă. Înseamnă contextul de rețea al procesului GeoServer însuși. Dacă GeoServer rulează în Docker în timp ce PostGIS rulează pe gazdă, localhost indică în interiorul containerului și nu găsește nimic, iar nicio configurare VPN nu schimbă asta.

Pe server, verifică ruta, listenerul și politica de autentificare în această ordine. Autentificarea PostgreSQL bazată pe gazdă compară adresa sursă pe care o vede, pe care un gateway o poate traduce, așa că adăugarea unui pool VPN de clienți în fișierul HBA repară rareori o conexiune din partea serverului. Testează așa cum ar face serverul: aceeași gazdă, același port, același utilizator. Dacă testul reușește în timp ce GeoServer tot eșuează, diferența este în contextul procesului, nu în baza de date.

ip route get 10.20.5.11
ss -tnp | grep 5432
psql "host=10.20.5.11 dbname=gis user=geoserver" -c 'select 1'

Poolurile și cache-urile păstrează stare peste schimbări

Poolurile de conexiuni ale depozitului de date țin socketurile deschise. Un tunel care a apărut la o oră după crearea poolului nu îi dă neapărat poolului o cale nouă, iar o conexiune inactivă poate sta pe o rută moartă până când o validare sau un timeout o închide. Verifică setările de validare ale depozitului instalat în loc să presupui o recuperare și evită tentația de a reporni întregul serviciu înainte de a ști ce strat a eșuat.

Cache-urile de tile-uri creează imaginea în oglindă a acestei probleme: pot servi o hartă cu aspect corect mult după ce conexiunea la baza de date s-a rupt. Golirea cache-ului ca să „vezi dacă ajută” distruge singura dovadă care ți-ar fi spus care cale era vie.

Predă mai departe cu ambele origini numite

Descrierea care obține o corectare rapidă numește două lucruri: cererea clientului care a ajuns la GeoServer și operația de backend pe care GeoServer nu a putut-o finaliza. Cu ambele, proprietarul corect poate repara calea care a eșuat. Cu doar prima, corectarea firească este să expui baza de date public, ceea ce rezolvă tichetul creând o problemă mai rea.

Notează stratul, codul de răspuns, excepția din partea serverului și containerul sau gazda care a produs-o. Sunt patru rânduri și elimină complet ambiguitatea.