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 не можел да ја заврши. Со обете, вистинскиот сопственик може да ја поправи патеката што паднала. Со само првото, природната поправка е јавно да се изложи базата на податоци, што барањето го решава со создавање полош проблем.

Забележете го слојот, кодот на одговор, исклучокот на страната на серверот и контејнерот или домаќинот што го создал. Тоа се четири реда и целосно ја отстрануваат двосмисленоста.

Поврзани статии