GeoServer и PostGIS: важният VPN път е този на сървъра

Това, че лаптопът ви стига до GeoServer, не казва нищо за това дали GeoServer стига до PostGIS. Сравнете двата източника, границата на кеша и собствения източник на хранилището с данни.

Отваряте слоя в QGIS и той се изчертава. Колега в същата VPN получава грешка за същия слой. Някой заключава, че VPN-ът е счупен, и следващият час отива за преместване на база данни или за отваряне на порт, който не е имал нужда от нито едно от двете. Заявката от работния плот и заявката, която GeoServer прави към PostGIS, тръгват от различни машини, в различни мрежови пространства от имена, с различни идентификационни данни. Разделянето на тези два пътя е по-голямата част от диагностиката.

Две връзки, два източника

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

Втората стрелка не наследява тунела на първия компютър. GeoServer в контейнер има мрежовия стек на контейнера, не на хоста, и контейнер в мостова мрежа може да достигне база, която хостът не достига, или обратното. Затова един и същ потребител може да успее и да се провали в една сесия, в зависимост от това дали отговорът е дошъл от кеша или от свежа заявка.

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

Намерете стъпката, която наистина се провали

Отказ на ниво услуга, заявка за изображение, която не достига до своето хранилище с данни, и проблем с права в един слой изглеждат сходно в раздел на браузъра и напълно различно в журнала на сървъра. Поискайте конкретната операция и след това прочетете собственото събитие на GeoServer за същия времеви отпечатък.

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 от втората заявка с правдоподобно изображение доказва, че хранилището с данни е отговорило. 200 с документ за изключение на услуга доказва, че не е, и текстът на изключението обикновено посочва хранилището, а не клиента.

Четете хранилището с данни от страната на сървъра

Справочникът PostGIS на GeoServer изброява какво е нужно на хранилището: хост, порт, база данни и идентификационни данни. Всичко това описва връзката, която GeoServer отваря. Нищо от това не описва влизане от клиента на работния плот. Четете тези четири полета като твърдение за мрежовия контекст на сървъра и целият клас заявки „при тях работи” става разрешим.

Затова localhost в хранилище с данни е толкова честа грешка. Означава мрежовия контекст на самия процес на GeoServer. Ако GeoServer работи в Docker, докато PostGIS работи на хоста, localhost сочи във вътрешността на контейнера и не намира нищо, и никаква VPN конфигурация не променя това.

На сървъра проверете маршрута, слушателя и политиката за удостоверяване в този ред. Удостоверяването на PostgreSQL, базирано на хост, сравнява изходния адрес, който вижда, а шлюзът може да го преведе, затова добавянето на клиентски VPN пул в HBA файла рядко поправя връзка от страната на сървъра. Тествайте както би направил сървърът: същият хост, същият порт, същият потребител. Ако този тест успее, докато GeoServer все още се проваля, разликата е в контекста на процеса, а не в базата данни.

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

Пуловете и кешовете пазят състояние през промените

Пуловете за връзки на хранилището с данни държат сокетите отворени. Тунел, който се появи час след създаването на пула, не дава непременно нов път на пула, а неактивна връзка може да остане на мъртъв маршрут, докато валидация или времево ограничение не я затвори. Проверете настройките за валидация на инсталираното хранилище, вместо да предполагате възстановяване, и избягвайте изкушението да рестартирате цялата услуга, преди да знаете кой слой се е провалил.

Кешовете на плочки създават огледален образ на този проблем: могат да сервират правилно изглеждаща карта дълго след като връзката с базата данни се е скъсала. Изчистването на кеша, за да „видим дали помага”, унищожава единственото доказателство, което би ви казало кой път е бил жив.

Предайте със споменати двата източника

Описанието, което получава бърза поправка, назовава две неща: заявката на клиента, която е достигнала до GeoServer, и бекенд операцията, която GeoServer не е успял да завърши. С двете правилният собственик може да поправи пътя, който се е провалил. Само с първата естествената поправка е базата данни да се изложи публично, което решава заявката, създавайки по-лош проблем.

Запишете слоя, кода на отговора, изключението от страната на сървъра и контейнера или хоста, който го е създал. Това са четири реда и те напълно премахват двусмислието.

Подобни статии