GeoServer dhe PostGIS: rruga e VPN-së që ka rëndësi është ajo e serverit
Fakti që laptopi juaj arrin GeoServer nuk thotë asgjë për atë nëse GeoServer arrin PostGIS. Krahasoni dy origjinat, kufirin e cache-s dhe vetë burimin e depozitës së të dhënave.
Hapni shtresën në QGIS dhe ajo vizatohet. Një koleg në të njëjtën VPN merr një gabim për të njëjtën shtresë. Dikush arrin në përfundimin se VPN-ja është prishur, dhe ora tjetër harxhohet duke zhvendosur një bazë të dhënash ose duke ekspozuar një port që nuk kishte nevojë për asnjërën. Kërkesa nga desktopi dhe pyetja që GeoServer i bën PostGIS nisen nga makina të ndryshme, në hapësira emrash rrjeti të ndryshme, me kredenciale të ndryshme. Ndarja e këtyre dy rrugëve është pjesa më e madhe e diagnozës.
Dy lidhje, dy origjina
QGIS -> client's permitted path (often the VPN) -> GeoServer listener
GeoServer -> server's permitted path -> PostGIS listener
Shigjeta e dytë nuk trashëgon tunelin e kompjuterit të parë. Një GeoServer në një kontejner ka stivën e rrjetit të kontejnerit, jo atë të hostit, dhe një kontejner në një rrjet urë mund të arrijë një bazë të dhënash që hosti nuk e arrin, ose e kundërta. Kështu i njëjti përdorues mund të ketë sukses dhe dështim brenda të njëjtit sesion, në varësi të faktit nëse përgjigjja erdhi nga cache-i apo nga një pyetje e re.
| 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 |
Gjeni hapin që dështoi vërtet
Një refuzim në nivel shërbimi, një kërkesë imazhi që nuk arrin depozitën e vet të të dhënave, dhe një problem lejeje në një shtresë duken njësoj në një skedë shfletuesi dhe krejt ndryshe në regjistrin e serverit. Kërkoni operacionin konkret, më pas lexoni vetë ngjarjen e GeoServer për të njëjtën vulë kohore.
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"
Një 200 nga kërkesa e dytë me një imazh të besueshëm provon se depozita e të dhënave u përgjigj. Një 200 me një dokument përjashtimi shërbimi provon se nuk u përgjigj, dhe teksti i përjashtimit zakonisht përmend depozitën dhe jo klientin.
Lexoni depozitën e të dhënave nga ana e serverit
Referenca PostGIS e GeoServer rendit atë që i nevojitet depozitës: host, port, bazë të dhënash dhe kredenciale. Të gjitha këto përshkruajnë lidhjen që hap GeoServer. Asnjë prej tyre nuk përshkruan një hyrje nga klienti i desktopit. Lexoni këto katër fusha si një deklaratë për kontekstin e rrjetit të serverit, dhe e gjithë klasa e tiketave «tek ata funksionon» bëhet e trajtueshme.
Kjo është arsyeja pse localhost në një depozitë të dhënash është një gabim kaq i zakonshëm. Do të thotë konteksti i rrjetit të vetë procesit GeoServer. Nëse GeoServer ekzekutohet në Docker ndërsa PostGIS ekzekutohet në host, localhost tregon brenda kontejnerit dhe nuk gjen asgjë, dhe asnjë konfigurim VPN nuk e ndryshon këtë.
Në server, kontrolloni rrugën, dëgjuesin dhe politikën e autentikimit në atë rend. Autentikimi i PostgreSQL i bazuar në host krahason adresën e burimit që sheh, të cilën një portë mund ta përkthejë, prandaj shtimi i një grupi VPN klientësh në skedarin HBA rrallë rregullon një lidhje nga ana e serverit. Testoni siç do të bënte serveri: i njëjti host, i njëjti port, i njëjti përdorues. Nëse ai test ka sukses ndërsa GeoServer ende dështon, ndryshimi është në kontekstin e procesit dhe jo në bazën e të dhënave.
ip route get 10.20.5.11
ss -tnp | grep 5432
psql "host=10.20.5.11 dbname=gis user=geoserver" -c 'select 1'
Grupet dhe cache-t mbajnë gjendjen përgjatë ndryshimeve
Grupet e lidhjeve të depozitës së të dhënave i mbajnë prizat hapur. Një tunel që u ngrit një orë pas krijimit të grupit nuk i jep domosdoshmërisht grupit një rrugë të re, dhe një lidhje boshe mund të qëndrojë në një rrugë të vdekur derisa një validim ose një afat kohor ta mbyllë. Kontrolloni cilësimet e validimit të depozitës së instaluar në vend që të supozoni rikuperim, dhe shmangni tundimin për të rinisur të gjithë shërbimin përpara se të dini cila shtresë dështoi.
Cache-t e pllakave krijojnë imazhin pasqyrë të atij problemi: ato mund të shërbejnë një hartë që duket e saktë shumë kohë pasi lidhja me bazën e të dhënave u prish. Pastrimi i cache-s për «të parë nëse ndihmon» shkatërron provën e vetme që do t'ju kishte thënë se cila rrugë ishte e gjallë.
Kaloni me të dyja origjinat të emërtuara
Përshkrimi që merr një rregullim të shpejtë emërton dy gjëra: kërkesën e klientit që arriti GeoServer, dhe operacionin në sfond që GeoServer nuk mundi ta përfundojë. Me të dyja, pronari i duhur mund të rregullojë rrugën që dështoi. Me vetëm të parën, rregullimi i natyrshëm është ekspozimi publik i bazës së të dhënave, i cili e zgjidh tiketën duke krijuar një problem më të keq.
Shënoni shtresën, kodin e përgjigjes, përjashtimin nga ana e serverit dhe kontejnerin ose hostin që e prodhoi. Janë katër rreshta, dhe e heqin paqartësinë plotësisht.