GeoServer un PostGIS: svarīgais VPN ceļš ir servera ceļš

Tas, ka jūsu portatīvais dators sasniedz GeoServer, neko nepasaka par to, vai GeoServer sasniedz PostGIS. Salīdziniet abas izcelsmes, kešatmiņas robežu un pašas datu krātuves avotu.

Jūs atverat slāni QGIS un tas tiek uzzīmēts. Kolēģis tajā pašā VPN saņem kļūdu tam pašam slānim. Kāds secina, ka VPN ir salūzis, un nākamā stunda paiet, pārvietojot datubāzi vai atverot portu, kam nevajadzēja ne vienu, ne otru. Pieprasījums no darbvirsmas un vaicājums, ko GeoServer veic uz PostGIS, iznāk no dažādām mašīnām, dažādās tīkla nosaukumtelpās, ar dažādiem akreditācijas datiem. Šo divu ceļu atdalīšana ir lielākā daļa no diagnostikas.

Divi savienojumi, divas izcelsmes

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

Otrā bultiņa nepārmanto pirmā datora tuneli. GeoServer konteinerā ir konteinera tīkla steks, nevis resursdatora, un konteiners tiltveida tīklā var sasniegt datubāzi, ko resursdators nesasniedz, vai otrādi. Tāpēc viens un tas pats lietotājs vienā sesijā var gan izdoties, gan neizdoties, atkarībā no tā, vai atbilde nāca no kešatmiņas vai no svaiga vaicājuma.

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

Atrodiet soli, kas patiešām neizdevās

Pakalpojuma līmeņa noraidījums, attēla pieprasījums, kas nesasniedz savu datu krātuvi, un viena slāņa atļauju problēma pārlūkprogrammas cilnē izskatās līdzīgi un servera žurnālā pilnīgi citādi. Pieprasiet konkrēto darbību un pēc tam izlasiet paša GeoServer notikumu tam pašam laikspiedolam.

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"

Otrā pieprasījuma 200 ar ticamu attēlu pierāda, ka datu krātuve atbildēja. 200 ar pakalpojuma izņēmuma dokumentu pierāda, ka tā neatbildēja, un izņēmuma teksts parasti nosauc krātuvi, nevis klientu.

Lasīt datu krātuvi no servera puses

GeoServer PostGIS atsauce uzskaita, kas krātuvei nepieciešams: resursdators, ports, datubāze un akreditācijas dati. Tas viss apraksta savienojumu, ko GeoServer atver. Nekas no tā neapraksta darbvirsmas klienta pieteikšanos. Lasiet šos četrus laukus kā apgalvojumu par servera tīkla kontekstu, un visa „pie viņiem tas strādā“ biļešu klase kļūst pārvaldāma.

Tāpēc localhost datu krātuvē ir tik izplatīta kļūda. Tas nozīmē paša GeoServer procesa tīkla kontekstu. Ja GeoServer darbojas Docker, kamēr PostGIS darbojas resursdatorā, localhost norāda konteinera iekšienē un neko neatrod, un neviena VPN konfigurācija to nemaina.

Serverī pārbaudiet maršrutu, klausītāju un autentifikācijas politiku šajā secībā. PostgreSQL autentifikācija pēc resursdatora salīdzina avota adresi, ko tā redz, un vārteja to var pārtulkot, tāpēc klienta VPN pūla pievienošana HBA failam reti salabo savienojumu servera pusē. Testējiet tā, kā to darītu serveris: tas pats resursdators, tas pats ports, tas pats lietotājs. Ja šis tests izdodas, kamēr GeoServer joprojām neizdodas, atšķirība ir procesa kontekstā, nevis datubāzē.

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

Pūli un kešatmiņas saglabā stāvokli pāri izmaiņām

Datu krātuves savienojumu pūli tur ligzdas atvērtas. Tunelis, kas parādījās stundu pēc pūla izveides, ne vienmēr dod pūlam jaunu ceļu, un dīkstāves savienojums var palikt uz miruša maršruta, līdz validācija vai taimauts to beidz. Pārbaudiet instalētās krātuves validācijas iestatījumus, nevis pieņemiet atjaunošanos, un izvairieties no kārdinājuma restartēt visu pakalpojumu, pirms zināt, kurš slānis neizdevās.

Flīžu kešatmiņas rada šīs problēmas spoguļattēlu: tās var pasniegt pareizi izskatīgu karti vēl ilgi pēc tam, kad datubāzes savienojums ir pārtrūcis. Kešatmiņas iztīrīšana, lai „redzētu, vai tas palīdz“, iznīcina vienīgo pierādījumu, kas būtu pateicis, kurš ceļš bija dzīvs.

Nododiet, nosaucot abas izcelsmes

Apraksts, kas iegūst ātru labojumu, nosauc divas lietas: klienta pieprasījumu, kas sasniedza GeoServer, un aizmugures darbību, ko GeoServer nevarēja pabeigt. Ar abiem pareizais īpašnieks var salabot ceļu, kas neizdevās. Tikai ar pirmo dabiskais labojums ir publiski atklāt datubāzi, kas atrisina biļeti, radot ļaunāku problēmu.

Pierakstiet slāni, atbildes kodu, servera puses izņēmumu un konteineru vai resursdatoru, kas to radīja. Tās ir četras rindas, un tās pilnībā novērš neskaidrību.

Saistītie raksti