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 не зміг завершити. З обома правильний власник може полагодити шлях, що зірвався. З лише першим природне виправлення — відкрити базу даних публічно, що вирішує заявку, створюючи гіршу проблему.

Запишіть шар, код відповіді, виняток на боці сервера і контейнер або хост, який його створив. Це чотири рядки, і вони повністю знімають неоднозначність.

Схожі статті