GeoServer at PostGIS: ang mahalagang landas ng VPN ay ang sa server

Binubuksan mo ang layer sa QGIS at ito ay nare-render. Ang isang kasamahan sa parehong VPN ay nakakakuha ng error para sa parehong layer. May naghihinuha na sira ang VPN, at ang susunod na oras ay nauubos sa paglipat ng database o pagbukas ng port na hindi kailanman nangailangan ng alinman sa dalawa. Ang kahilingan mula sa desktop at ang query na ipinapadala ng GeoServer sa PostGIS ay umaalis mula sa magkaibang makina, sa magkaibang namespace ng network, na may magkaibang kredensyal. Ang paghihiwalay ng dalawang landas na iyon ay ang malaking bahagi ng diagnosis.

Dalawang koneksyon, dalawang pinagmulan

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

Hindi namamana ng ikalawang arrow ang tunnel ng unang computer. Ang GeoServer sa isang container ay may network stack ng container, hindi ng host, at ang isang container sa bridged network ay maaaring umabot sa database na hindi naaabot ng host, o kabaligtaran. Kaya ang parehong gumagamit ay maaaring magtagumpay at mabigo sa loob ng isang session, depende sa kung ang sagot ay galing sa cache o sa bagong query.

Hanapin ang hakbang na talagang nabigo

Ang pagtanggi sa antas ng serbisyo, isang kahilingan ng imahe na hindi umabot sa sarili nitong imbakan ng datos, at isang problema sa pahintulot sa isang layer ay magkamukha sa tab ng browser at lubos na magkaiba sa log ng server. Hilingin ang partikular na operasyon, pagkatapos ay basahin ang sariling kaganapan ng GeoServer para sa parehong timestamp.

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"

Ang 200 mula sa ikalawang kahilingan na may makatotohanang imahe ay nagpapatunay na sumagot ang imbakan ng datos. Ang 200 na may dokumento ng service exception ay nagpapatunay na hindi ito sumagot, at ang teksto ng exception ay karaniwang pinangalanan ang imbakan at hindi ang kliyente.

Basahin ang imbakan ng datos mula sa panig ng server

Ang PostGIS reference ng GeoServer ay naglilista ng kailangan ng imbakan: host, port, database at kredensyal. Inilalarawan ng lahat ng iyon ang koneksyon na binubuksan ng GeoServer. Wala sa mga iyon ang naglalarawan ng pag-login mula sa desktop client. Basahin ang apat na field na iyon bilang pahayag tungkol sa konteksto ng network ng server, at ang buong uri ng mga ticket na «gumagana sa kanila» ay nagiging kayang harapin.

Iyon ang dahilan kung bakit ang localhost sa isang imbakan ng datos ay napakakaraniwang pagkakamali. Nangangahulugan ito ng konteksto ng network ng proseso ng GeoServer mismo. Kung ang GeoServer ay tumatakbo sa Docker habang ang PostGIS ay tumatakbo sa host, localhost ay tumuturo sa loob ng container at wala itong mahanap, at walang anumang configuration ng VPN ang nagbabago niyon.

Sa server, suriin ang ruta, ang listener at ang patakaran ng authentication sa ganoong pagkakasunod-sunod. Ang host-based na authentication ng PostgreSQL ay tumutugma sa source address na nakikita nito, na maaaring isalin ng isang gateway, kaya ang pagdaragdag ng client VPN pool sa HBA file ay bihirang nag-aayos ng koneksyon sa panig ng server. Subukan gaya ng gagawin ng server: parehong host, parehong port, parehong gumagamit. Kung nagtagumpay ang pagsubok na iyon habang nabigo pa rin ang GeoServer, ang pagkakaiba ay nasa konteksto ng proseso at hindi sa database.

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

Ang mga pool at cache ay nagpapanatili ng estado sa mga pagbabago

Ang mga connection pool ng imbakan ng datos ay nagpapanatili ng mga socket na bukas. Ang isang tunnel na tumaas isang oras pagkatapos malikha ang pool ay hindi laging nagbibigay sa pool ng bagong landas, at ang isang idle na koneksyon ay maaaring maupo sa patay na ruta hanggang sa isang validation o timeout ang magsara nito. Suriin ang mga setting ng validation ng naka-install na imbakan sa halip na ipalagay ang pagbangon, at iwasan ang tukso na i-restart ang buong serbisyo bago mo malaman kung aling layer ang nabigo.

Ang mga tile cache ay lumilikha ng salamin ng problemang iyon: maaari silang maghatid ng mapa na mukhang tama matagal pagkatapos ng koneksyon sa database ay nasira. Ang paglilinis ng cache para «tingnan kung nakakatulong» ay sumisira sa tanging ebidensya na magsasabi sa iyo kung aling landas ang buhay.

Ipasa kasama ang dalawang pinagmulan na pinangalanan

Ang paglalarawan na nakakakuha ng mabilis na pag-aayos ay pinangalanan ang dalawang bagay: ang kahilingan ng kliyente na umabot sa GeoServer, at ang backend na operasyon na hindi natapos ng GeoServer. Sa pareho, maaaring ayusin ng tamang may-ari ang landas na nabigo. Sa una lamang, ang natural na pag-aayos ay ilantad ang database sa publiko, na nilulutas ang ticket sa pamamagitan ng paglikha ng mas masamang problema.

Itala ang layer, ang code ng tugon, ang exception sa panig ng server at ang container o host na gumawa nito. Iyon ay apat na linya, at inaalis nito ang kalabuan nang lubos.