GeoServer ir PostGIS: svarbus VPN kelias yra serverio

Tai, kad jūsų nešiojamasis kompiuteris pasiekia GeoServer, nieko nesako apie tai, ar GeoServer pasiekia PostGIS. Palyginkite abu ištakos taškus, talpyklos ribą ir pačios duomenų saugyklos šaltinį.

Atidarote sluoksnį QGIS ir jis nupiešiamas. Kolega tame pačiame VPN gauna klaidą tam pačiam sluoksniui. Kažkas padaro išvadą, kad VPN sugedo, ir kita valanda praleidžiama perkeliant duomenų bazę arba atveriant prievadą, kurio nereikėjo nė vienam. Užklausa iš darbalaukio ir užklausa, kurią GeoServer siunčia PostGIS, išeina iš skirtingų mašinų, skirtingų tinklo vardų erdvių, su skirtingais prisijungimo duomenimis. Šių dviejų kelių atskyrimas yra didžioji diagnostikos dalis.

Dvi jungtys, du ištakos taškai

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

Antroji rodyklė nepaveldi pirmojo kompiuterio tunelio. GeoServer konteineryje turi konteinerio tinklo steką, o ne prieglobos, ir konteineris tiltiniame tinkle gali pasiekti duomenų bazę, kurios priegloba nepasiekia, arba atvirkščiai. Taigi tas pats naudotojas gali pavykti ir nepavykti toje pačioje sesijoje, priklausomai nuo to, ar atsakymas atėjo iš talpyklos, ar iš naujos užklausos.

What you testedWhat it proves
Portal page or GetCapabilitiesHTTP reachability to GeoServer only
A tile served from cachenothing about the database
GetMap for an uncached layera datastore query had to happen

Raskite žingsnį, kuris tikrai nepavyko

Paslaugos lygio atmetimas, vaizdo užklausa, kuri nepasiekia savo duomenų saugyklos, ir vieno sluoksnio leidimų problema naršyklės skirtuke atrodo panašiai, o serverio žurnale – visiškai kitaip. Paprašykite konkrečios operacijos, tada perskaitykite paties GeoServer įvykį tam pačiam laiko žymeniui.

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"

Antrosios užklausos 200 su tikėtinu vaizdu įrodo, kad duomenų saugykla atsakė. 200 su paslaugos išimties dokumentu įrodo, kad neatsakė, o išimties tekstas paprastai nurodo saugyklą, o ne klientą.

Skaitykite duomenų saugyklą iš serverio pusės

GeoServer PostGIS nuoroda išvardija, ko reikia saugyklai: priegloba, prievadas, duomenų bazė ir prisijungimo duomenys. Visa tai apibūdina ryšį, kurį GeoServer atidaro. Niekas iš to neapibūdina darbalaukio kliento prisijungimo. Skaitykite tuos keturis laukus kaip teiginį apie serverio tinklo kontekstą, ir visa „pas juos tai veikia“ bilietų klasė tampa valdoma.

Štai kodėl localhost duomenų saugykloje yra tokia dažna klaida. Tai reiškia paties GeoServer proceso tinklo kontekstą. Jei GeoServer veikia Docker, o PostGIS veikia priegloboje, localhost nurodo į konteinerio vidų ir nieko neranda, ir jokia VPN konfigūracija to nepakeis.

Serveryje patikrinkite maršrutą, klausytoją ir autentifikavimo politiką ta tvarka. PostgreSQL autentifikavimas pagal prieglobą lygina šaltinio adresą, kurį mato, o tarpinė gali jį išversti, todėl kliento VPN telkinio įtraukimas į HBA failą retai sutaiso serverio pusės ryšį. Testuokite taip, kaip darytų serveris: ta pati priegloba, tas pats prievadas, tas pats naudotojas. Jei šis testas pavyksta, o GeoServer vis tiek nepavyksta, skirtumas yra proceso kontekste, o ne duomenų bazėje.

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

Telkiniai ir talpyklos išlaiko būseną per pakeitimus

Duomenų saugyklos ryšių telkiniai laiko lizdus atidarytus. Tunelis, kuris atsirado valandą po telkinio sukūrimo, nebūtinai suteikia telkiniui naują kelią, o neveiklus ryšys gali likti negyvame maršrute, kol patikra arba skirtasis laikas jo neuždarys. Tikrinkite įdiegtos saugyklos patikros nustatymus, o ne manykite, kad atsistatys, ir venkite pagundos perkrauti visą paslaugą, kol nežinote, kuris sluoksnis nepavyko.

Plytelių talpyklos sukuria atvirkštinį tos problemos vaizdą: jos gali tiekti teisingai atrodantį žemėlapį dar ilgai po to, kai duomenų bazės ryšys nutrūko. Talpyklos išvalymas „pažiūrėti, ar padeda“ sunaikina vienintelį įrodymą, kuris būtų pasakęs, kuris kelias buvo gyvas.

Perduokite įvardydami abu ištakos taškus

Aprašymas, kuris gauna greitą taisymą, įvardija du dalykus: kliento užklausą, kuri pasiekė GeoServer, ir foninę operaciją, kurios GeoServer negalėjo užbaigti. Turint abu, teisingas savininkas gali sutaisyti kelią, kuris nepavyko. Turint tik pirmąjį, natūralus taisymas yra atskleisti duomenų bazę viešai, o tai išsprendžia bilietą sukurdama blogesnę problemą.

Užrašykite sluoksnį, atsakymo kodą, serverio pusės išimtį ir konteinerį arba prieglobą, kuri ją sukūrė. Tai keturios eilutės, ir jos visiškai pašalina dviprasmiškumą.

Susiję straipsniai