GeoServer og PostGIS: VPN-vegen som tel, er serveren sin
At laptopen din når GeoServer, seier ingenting om GeoServer når PostGIS. Samanlikn dei to opphavi, cachegrensa og datalageret si eiga kjelde.
Du opnar laget i QGIS, og det blir teikna. Ein kollega på same VPN får ein feil for same lag. Nokon konkluderer med at VPN-en er øydelagd, og den neste timen går med til å flytte ein database eller opne ein port som aldri trong nokon av delane. Førespurnaden frå skrivebordet og spørjinga GeoServer sender til PostGIS, startar på ulike maskinar, i ulike nettverksnamnerom, med ulike påloggingsdetaljar. Å skilje dei to vegane er det meste av diagnosen.
To tilkoplingar, to opphav
QGIS -> client's permitted path (often the VPN) -> GeoServer listener
GeoServer -> server's permitted path -> PostGIS listener
Den andre pila arvar ikkje tunnelen til den første datamaskina. Ein GeoServer i ein container har nettverksstakken til containeren, ikkje verten sin, og ein container på eit brua nettverk kan nå ein database som verten ikkje når, eller omvendt. Dermed kan same brukar lukkast og feile i same økta, avhengig av om svaret kom frå cachen eller frå ei fersk spørjing.
| 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 |
Finn steget som faktisk feila
Ei avvising på tenestenivå, ein bildeførespurnad som ikkje når datalageret sitt, og eit løyveproblem i eitt lag ser like ut i ei nettlesarfane og heilt forskjellige ut i serverloggen. Be om den konkrete operasjonen, og les deretter hendinga til GeoServer for same tidsstempel.
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"
Ein 200 frå den andre førespurnaden med eit plausibelt bilete beviser at datalageret svara. Ein 200 med eit service-exception-dokument beviser at det ikkje gjorde det, og unntaksteksten nemner som regel storen framfor klienten.
Les datalageret frå serveren si side
Den PostGIS-referansen frå GeoServer listar opp kva storen treng: vert, port, database og påloggingsdetaljar. Alt dette skildrar tilkoplinga GeoServer opnar. Ingenting av det skildrar ei innlogging frå skrivebordsklienten. Les dei fire felta som ei utsegn om nettverkskonteksten til serveren, og heile klassen av saker der »det funkar hos dei« blir handterbar.
Derfor er localhost i eit datalager ein så vanleg feil. Det betyr nettverkskonteksten til GeoServer-prosessen sjølv. Viss GeoServer køyrer i Docker medan PostGIS køyrer på verten, localhost peikar inn i containeren og finn ingenting, og ingen VPN-konfigurasjon endrar det.
Sjekk på serveren ruta, lyttaren og autentiseringspolicyen i den rekkjefølgja. Den vertsbaserte autentiseringa til PostgreSQL matchar kjeldeadressa ho ser, som ein gateway kan omsetje, så å leggje til ein klient-VPN-pool i HBA-fila reparerer sjeldan ei tilkopling på serversida. Test som serveren ville gjort: same vert, same port, same brukar. Viss den testen lukkast medan GeoServer framleis feilar, ligg skilnaden i prosesskonteksten og ikkje i databasen.
ip route get 10.20.5.11
ss -tnp | grep 5432
psql "host=10.20.5.11 dbname=gis user=geoserver" -c 'select 1'
Polar og cachar held tilstand på tvers av endringar
Tilkoplingspolar i datalageret held sockets opne. Ein tunnel som kom opp ein time etter at polen vart oppretta, gir ikkje nødvendigvis polen ein ny veg, og ei inaktiv tilkopling kan bli sitjande på ei død rute til ei validering eller ein timeout avsluttar ho. Sjekk valideringsinnstillingane til den installerte storen i staden for å anta at han kjem seg, og unngå freistinga til å starte heile tenesta på nytt før du veit kva lag som feila.
Tile-cachar skaper spegelbiletet av det problemet: dei kan serve eit korrekt utsjåande kart lenge etter at databasetilkoplinga vart broten. Å tømme cachen for å »sjå om det hjelper« øydelegg det eine beviset som ville ha fortalt deg kva veg som var levande.
Overlever med begge opphavi namngjevne
Skildringa som gir ei rask retting, namngjev to ting: klientførespurnaden som nådde GeoServer, og backend-operasjonen GeoServer ikkje kunne fullføre. Med begge kan rett eigar reparere vegen som feila. Med berre den første er den naturlege rettinga å eksponere databasen offentleg, noko som løyser saka ved å skape eit verre problem.
Noter laget, svarkoden, unntaket på serversida og containeren eller verten som produserte det. Det er fire linjer, og det fjernar tvitydigheita heilt.