GeoServer és PostGIS: a számító VPN-útvonal a szerveré

Az, hogy a laptopod eléri a GeoServert, semmit sem mond arról, hogy a GeoServer eléri-e a PostGIS-t. Hasonlítsd össze a két origót, a gyorsítótár határát és az adattár saját forrását.

Megnyitod a réteget a QGIS-ben, és megrajzolódik. Egy kolléga ugyanazon a VPN-en hibát kap ugyanarra a rétegre. Valaki arra jut, hogy a VPN elromlott, és a következő óra egy adatbázis mozgatásával vagy egy port megnyitásával telik, amelyre egyiknek sem volt soha szüksége. Az asztali gép kérése és a lekérdezés, amelyet a GeoServer a PostGIS felé indít, különböző gépekről, különböző hálózati névterekből, különböző hitelesítő adatokkal indul. A két útvonal szétválasztása a diagnózis nagy része.

Két kapcsolat, két origó

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

A második nyíl nem örökli az első számítógép alagútját. Egy konténerben futó GeoServer a konténer hálózati veremét kapja, nem a hosztét, és egy áthidalt hálózaton lévő konténer elérhet olyan adatbázist, amelyet a hoszt nem ér el, vagy fordítva. Így ugyanaz a felhasználó egyetlen munkameneten belül is sikerrel és kudarccal járhat, attól függően, hogy a válasz a gyorsítótárból vagy friss lekérdezésből jött-e.

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

Találd meg a lépést, amely valóban elbukott

A szolgáltatási szintű elutasítás, az adattárát el nem érő képkérés és az egy rétegben jelentkező jogosultsági probléma egy böngészőlapon hasonlóan néz ki, a szervernaplóban pedig teljesen másképp. Kérd a konkrét műveletet, majd olvasd el a GeoServer saját eseményét ugyanarra az időbélyegre.

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"

A második kérés 200-a hihető képpel bizonyítja, hogy az adattár válaszolt. A 200 szolgáltatáskivétel-dokumentummal bizonyítja, hogy nem, és a kivétel szövege általában a tárolót nevezi meg, nem az ügyfelet.

Az adattár olvasása a szerver oldaláról

A GeoServer PostGIS-referenciája felsorolja, mire van szüksége a tárolónak: hoszt, port, adatbázis és hitelesítő adatok. Mindez a GeoServer által nyitott kapcsolatot írja le. Semmi ebből nem írja le az asztali kliens bejelentkezését. Olvasd ezt a négy mezőt a szerver hálózati kontextusáról szóló állításként, és a „nekik működik” jegyek egész osztálya kezelhetővé válik.

Ezért localhost egy adattárban olyan gyakori hiba. A GeoServer-folyamat saját hálózati kontextusát jelenti. Ha a GeoServer Dockerben fut, miközben a PostGIS a hoszton fut, localhost a konténer belsejére mutat, és nem talál semmit, és ezen semmilyen VPN-konfiguráció nem változtat.

A szerveren ellenőrizd az útvonalat, a figyelőt és a hitelesítési szabályzatot ebben a sorrendben. A PostgreSQL hosztalapú hitelesítése a látott forráscímet hasonlítja össze, amelyet egy átjáró átírhat, ezért az ügyfél VPN-készlet hozzáadása a HBA-fájlhoz ritkán javít egy szerveroldali kapcsolatot. Tesztelj úgy, ahogy a szerver tenne: ugyanaz a hoszt, ugyanaz a port, ugyanaz a felhasználó. Ha a teszt sikerül, miközben a GeoServer továbbra is elbukik, a különbség a folyamat kontextusában van, nem az adatbázisban.

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

A készletek és gyorsítótárak állapotot tartanak a változásokon át

Az adattár kapcsolatkészletei nyitva tartják a socketeket. Egy alagút, amely egy órával a készlet létrehozása után jött fel, nem feltétlenül ad a készletnek új útvonalat, és egy tétlen kapcsolat halott útvonalon maradhat, amíg egy érvényesítés vagy időtúllépés be nem zárja. Ellenőrizd a telepített tároló érvényesítési beállításait ahelyett, hogy helyreállást feltételeznél, és kerüld a kísértést, hogy az egész szolgáltatást újraindítsd, mielőtt tudod, melyik réteg bukott el.

A csempegyorsítótárak ennek a problémának a tükörképét hozzák létre: helyesnek látszó térképet szolgálhatnak ki jóval azután, hogy az adatbázis-kapcsolat megszakadt. A gyorsítótár törlése, hogy „lássuk, segít-e”, megsemmisíti az egyetlen bizonyítékot, amely megmondta volna, melyik útvonal volt élő.

Átadás mindkét origó megnevezésével

A leírás, amely gyors javítást kap, két dolgot nevez meg: az ügyfélkérést, amely elérte a GeoServert, és a háttérműveletet, amelyet a GeoServer nem tudott befejezni. Mindkettővel a megfelelő tulajdonos meg tudja javítani az elbukott útvonalat. Csak az elsővel a természetes javítás az adatbázis nyilvános közzététele, ami úgy oldja meg a jegyet, hogy rosszabb problémát teremt.

Jegyezd fel a réteget, a válaszkódot, a szerveroldali kivételt és a konténert vagy hosztot, amely előállította. Ez négy sor, és teljesen megszünteti a kétértelműséget.

Kapcsolódó cikkek