GeoServer a PostGIS: rozhoduje VPN cesta serveru

To, že se váš notebook dostane na GeoServer, nic neříká o tom, zda se GeoServer dostane na PostGIS. Porovnejte dva zdroje, hranici mezipaměti a samotný zdroj úložiště dat.

Otevřete vrstvu v QGIS a vykreslí se. Kolega na stejné VPN dostane u stejné vrstvy chybu. Někdo usoudí, že je VPN rozbitá, a následující hodina padne na přesun databáze nebo na otevření portu, který nikdy nepotřeboval ani jedno. Požadavek z počítače a dotaz, který GeoServer posílá do PostGIS, vycházejí z různých strojů, v různých síťových jmenných prostorech, s různými přihlašovacími údaji. Rozdělit tyto dvě cesty je většina diagnózy.

Dvě připojení, dva zdroje

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

Druhá šipka nedědí tunel prvního počítače. GeoServer v kontejneru má síťový stack kontejneru, ne hostitele, a kontejner v přemostěné síti může dosáhnout databáze, na kterou hostitel nedosáhne, nebo naopak. Stejný uživatel tak může v jedné relaci uspět i selhat podle toho, zda odpověď přišla z mezipaměti, nebo z čerstvého dotazu.

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

Najděte krok, který skutečně selhal

Odmítnutí na úrovni služby, požadavek na obrázek, který nedosáhne svého úložiště dat, a problém s oprávněními v jedné vrstvě vypadají na kartě prohlížeče podobně a v logu serveru úplně jinak. Vyžádejte konkrétní operaci a potom si přečtěte vlastní událost GeoServeru pro stejný časový údaj.

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"

200 z druhého požadavku s věrohodným obrázkem dokazuje, že úložiště dat odpovědělo. 200 s dokumentem výjimky služby dokazuje, že neodpovědělo, a text výjimky obvykle jmenuje úložiště, nikoli klienta.

Čtěte úložiště dat ze strany serveru

Referenční příručka PostGIS GeoServeru uvádí, co úložiště potřebuje: hostitele, port, databázi a přihlašovací údaje. To vše popisuje připojení, které GeoServer otevírá. Nic z toho nepopisuje přihlášení z klientského počítače. Čtěte tato čtyři pole jako tvrzení o síťovém kontextu serveru a celá třída tiketů „u nich to funguje“ se stane zvládnutelnou.

Proto je localhost v úložišti dat tak častou chybou. Znamená síťový kontext samotného procesu GeoServeru. Pokud GeoServer běží v Dockeru, zatímco PostGIS běží na hostiteli, localhost ukazuje dovnitř kontejneru a nic nenajde, a žádná konfigurace VPN to nezmění.

Na serveru zkontrolujte trasu, naslouchající proces a zásady ověřování v tomto pořadí. Ověřování PostgreSQL založené na hostiteli porovnává zdrojovou adresu, kterou vidí, a brána ji může přeložit, takže přidání klientského VPN poolu do souboru HBA zřídka opraví připojení na straně serveru. Testujte tak, jak by to udělal server: stejný hostitel, stejný port, stejný uživatel. Pokud tento test uspěje, zatímco GeoServer stále selhává, rozdíl je v kontextu procesu, ne v databázi.

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 a mezipaměti drží stav napříč změnami

Connection pooly úložiště dat drží sockety otevřené. Tunel, který vznikl hodinu po vytvoření poolu, nemusí poolu dát novou cestu a nečinné připojení může zůstat na mrtvé trase, dokud ho validace nebo časový limit neukončí. Zkontrolujte nastavení validace nainstalovaného úložiště, místo abyste předpokládali obnovení, a vyhněte se pokušení restartovat celou službu, dokud nevíte, která vrstva selhala.

Mezipaměti dlaždic vytvářejí zrcadlový obraz tohoto problému: mohou vydávat správně vypadající mapu dlouho poté, co se připojení k databázi přerušilo. Vymazání mezipaměti, abychom „viděli, jestli to pomůže“, ničí jediný důkaz, který by vám řekl, která cesta byla živá.

Předejte případ s oběma zdroji

Popis, který přinese rychlou opravu, jmenuje dvě věci: požadavek klienta, který dorazil do GeoServeru, a backendovou operaci, kterou GeoServer nedokázal dokončit. S oběma může správný vlastník opravit cestu, která selhala. S pouze prvním je přirozenou opravou veřejné vystavení databáze, což tiket vyřeší vytvořením horšího problému.

Poznamenejte vrstvu, kód odpovědi, výjimku na straně serveru a kontejner nebo hostitele, který ji vytvořil. Jsou to čtyři řádky a zcela odstraní nejednoznačnost.

Související články