GeoServer en PostGIS: it VPN-paad dat der ta docht, is dat fan de tsjinner

Dat dyn laptop GeoServer berikt, seit neat oer oft GeoServer PostGIS berikt. Ferlykje de twa oarsprongen, de cachegrins en de eigen boarne fan de datastore.

Do iepenest it laach yn QGIS en it wurdt tekene. In kollega op deselde VPN krijt in flater foar itselde laach. Immen konkludearret dat de VPN stikken is, en it folgjende oere giet op oan it ferpleatsen fan in databank of it bleatstellen fan in poarte dy’t dêr neat fan nedich hie. It fersyk fan de desktop en de query dy’t GeoServer nei PostGIS docht, fertsjutskje fan ferskillende masines, yn ferskillende netwurk-nammeruimten, mei ferskillende oanmeldgegevens. Dy twa paden skiede is it grutste part fan de diagnoaze.

Twa ferbiningen, twa oarsprongen

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

De twadde pyl erft net de tunnel fan de earste kompjûter. In GeoServer yn in container hat de netwurkstapel fan de container, net dy fan de host, en in container op in brêge netwurk kin in databank berikke dy’t de host net berikt, of oarsom. Sa kin deselde brûker yn ien sesje slagje en misse, ôfhinklik fan oft it antwurd út de cache kaam of út in farske query.

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

Fyn de stap dy’t echt mislearre

In ôfwizing op tsjinstnivo, in byldfersyk dat syn datastore net berikt, en in tastimmingsprobleem yn ien laach lykje yn in browser-tab itselde en binne yn it tsjinnerlog hiel oars. Freegje om de spesifike operaasje en lês dan de eigen barren fan GeoServer foar deselde tiidstimpel.

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"

In 200 fan it twadde fersyk mei in leauweardich byld bewist dat de datastore antwurde. In 200 mei in service-exception-dokumint bewist dat it dat net die, en de tekst fan de útsûndering neamt meast de store ynstee fan de klant.

Lês de datastore fan de tsjinnerkant

De PostGIS-referinsje fan GeoServer listet op wat de store nedich hat: host, poarte, databank en oanmeldgegevens. Dat alles beskriuwt de ferbining dy’t GeoServer iepenet. Neat dêrfan beskriuwt in oanmelding troch de desktopklant. Lês dy fjouwer fjilden as in útspraak oer de netwurk-kontekst fan de tsjinner, en de hiele klasse fan «by harren wurket it»-tickets wurdt behannelber.

Dêrom is localhost yn in datastore sa’n algemiene flater. It betsjut de netwurk-kontekst fan it GeoServer-proses sels. As GeoServer yn Docker draait wylst PostGIS op de host draait, localhost wiist binnen de container en fynt neat, en gjin inkelde VPN-konfiguraasje feroaret dat.

Kontrolearje op de tsjinner de rûte, de listener en it autentikaasjebelied yn dy folchoarder. De host-basearre autentikaasje fan PostgreSQL ferliket it boarneadres dat it sjocht, dat in gateway oersetten kin, dus in klant-VPN-pool tafoegje oan it HBA-bestân reparearret selden in ferbining oan de tsjinnerkant. Test sa’t de tsjinner it dwaan soe: deselde host, deselde poarte, deselde brûker. As dy test slagget wylst GeoServer noch misse, sit it ferskil yn de proseskontekst en net yn de databank.

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

Pools en caches hâlde steat oer feroaringen hinne

Ferbiningspools fan de datastore hâlde sockets iepen. In tunnel dy’t in oere nei it oanmeitsjen fan de pool omheech kaam, jout de pool net needsaaklik in nij paad, en in idle ferbining kin op in dea rûte sitte oant in falidaasje of in timeout dy beëiniget. Kontrolearje de falidaasje-ynstellings fan de ynstallearre store ynstee fan herstel oan te nimmen, en mije de ferlieding om de hiele tsjinst opnij te starten foardat jo witte hokker laach mislearre.

Tile-caches meitsje it spegelbyld fan dat probleem: se kinne in korrekt útsjende kaart noch lang tsjinje nei’t de databankferbining bruts. De cache leegje om «te sjen oft it helpt» fernielt it iene bewiis dat jo ferteld hie hokker paad libben wie.

Oerdrage mei beide oarsprongen neamd

De beskriuwing dy’t in flugge repaaraasje krijt, neamt twa dingen: it klantfersyk dat GeoServer berikte, en de backend-operaasje dy’t GeoServer net foltôgje koe. Mei beide kin de goede eigner it paad reparearje dat mislearre. Mei allinnich de earste is de natuerlike repaaraasje de databank iepenbier bleatstelle, wat it ticket oplost troch in slimmer probleem te meitsjen.

Notearje it laach, de antwurdkoade, de útsûndering oan de tsjinnerkant en de container of host dy’t it produsearre. Dat binne fjouwer rigels, en it hellet de dûbelsinnigens hielendal fuort.

Relatearre artikelen