GeoServer ja PostGIS: ratkaiseva VPN-reitti on palvelimen oma

Avaat tason QGISissä ja se piirtyy. Samaan VPN:ään liittynyt kollega saa virheen samasta tasosta. Joku päättelee, että VPN on rikki, ja seuraava tunti kuluu tietokannan siirtämiseen tai portin avaamiseen, jota kumpikaan ei ollut koskaan tarvinnut. Työpöydän pyyntö ja kysely, jonka GeoServer tekee PostGISille, lähtevät eri koneista, eri verkkonimiavaruuksista, eri tunnuksilla. Näiden kahden reitin erottaminen on suurin osa diagnoosista.

Kaksi yhteyttä, kaksi origoa

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

Toinen nuoli ei peri ensimmäisen tietokoneen tunnelia. Kontissa ajettavalla GeoServerillä on kontin verkkopino, ei isännän, ja sillatussa verkossa oleva kontti voi tavoittaa tietokannan, jota isäntä ei tavoita, tai päinvastoin. Niinpä sama käyttäjä voi onnistua ja epäonnistua saman istunnon aikana riippuen siitä, tuliko vastaus välimuistista vai tuoreesta kyselystä.

Löydä vaihe, joka todella epäonnistui

Palvelutason hylkäys, kuvapyyntö, joka ei tavoita datavarastoaan, ja yhden tason käyttöoikeusongelma näyttävät selaimen välilehdellä samalta ja palvelimen lokissa täysin erilaisilta. Pyydä tarkka toiminto ja lue sitten GeoServerin oma tapahtuma samalla aikaleimalla.

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"

Toisen pyynnön 200 uskottavalla kuvalla todistaa, että datavarasto vastasi. 200 palvelupoikkeusasiakirjalla todistaa, ettei vastannut, ja poikkeuksen teksti nimeää yleensä varaston eikä asiakkaan.

Lue datavarastoa palvelimen puolelta

GeoServerin PostGIS-viite luettelee, mitä varasto tarvitsee: isäntä, portti, tietokanta ja tunnukset. Kaikki tämä kuvaa yhteyttä, jonka GeoServer avaa. Mikään siitä ei kuvaa työpöytäasiakkaan kirjautumista. Lue nuo neljä kenttää väitteenä palvelimen verkkoympäristöstä, ja koko luokka «meillä se toimii» -tikettejä tulee käsiteltäväksi.

Siksi localhost datavarastossa on niin yleinen virhe. Se tarkoittaa GeoServer-prosessin omaa verkkoympäristöä. Jos GeoServer ajetaan Dockerissa samalla kun PostGIS ajetaan isännällä, localhost osoittaa kontin sisään eikä löydä mitään, eikä mikään VPN-asetus muuta sitä.

Tarkista palvelimella reitti, kuuntelija ja todennuskäytäntö siinä järjestyksessä. PostgreSQLin isäntäpohjainen todennus vertaa lähdeosoitetta, jonka se näkee, ja yhdyskäytävä voi kääntää sen, joten asiakas-VPN-poolin lisääminen HBA-tiedostoon korjaa harvoin palvelinpuolen yhteyttä. Testaa kuten palvelin tekisi: sama isäntä, sama portti, sama käyttäjä. Jos testi onnistuu, kun GeoServer yhä epäonnistuu, ero on prosessin ympäristössä eikä tietokannassa.

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

Poolit ja välimuistit pitävät tilaa muutosten yli

Datavaraston yhteyspoolit pitävät soketit avoinna. Tunneli, joka nousi tunti poolin luomisen jälkeen, ei välttämättä anna poolille uutta reittiä, ja joutilas yhteys voi jäädä kuolleelle reitille, kunnes validointi tai aikakatkaisu lopettaa sen. Tarkista asennetun varaston validointiasetukset sen sijaan, että olettaisit palautumisen, ja vältä kiusausta käynnistää koko palvelu uudelleen ennen kuin tiedät, mikä taso epäonnistui.

Liitukarttavälimuistit luovat tuon ongelman peilikuvan: ne voivat tarjoilla oikealta näyttävää karttaa kauan sen jälkeen, kun tietokantayhteys katkesi. Välimuistin tyhjentäminen «nähdäkseen auttaako se» tuhoaa ainoan todisteen, joka olisi kertonut, mikä reitti oli elossa.

Luovuta molemmat origot nimettyinä

Kuvaus, joka saa nopean korjauksen, nimeää kaksi asiaa: asiakaspyynnön, joka tavoitti GeoServerin, ja taustatoiminnon, jota GeoServer ei pystynyt suorittamaan. Molemmilla oikea omistaja voi korjata reitin, joka epäonnistui. Vain ensimmäisellä luonnollinen korjaus on paljastaa tietokanta julkisesti, mikä ratkaisee tiketin luomalla pahemman ongelman.

Kirjaa taso, vastauskoodi, palvelinpuolen poikkeus ja kontti tai isäntä, joka sen tuotti. Se on neljä riviä, ja se poistaa epäselvyyden kokonaan.