GeoServer və PostGIS: vacib olan VPN yolu serverinkidir
Noutbukunuzun GeoServer-ə çatması, GeoServer-in PostGIS-ə çatıb-çatmaması barədə heç nə demir. İki mənbəyi, keş sərhədini və məlumat anbarının öz mənbəyini müqayisə edin.
Layı QGIS-də açırsınız və o çəkilir. Eyni VPN-də olan həmkarınız eyni lay üçün xəta alır. Kimsə VPN-in xarab olduğu qənaətinə gəlir və növbəti saat ya məlumat bazasını köçürməklə, ya da heç birinə ehtiyacı olmayan portu açmaqla keçir. Masaüstündən gələn sorğu və GeoServer-in PostGIS-ə etdiyi sorğu müxtəlif maşınlardan, müxtəlif şəbəkə ad məkanlarından, müxtəlif etimadnamələrlə çıxır. Bu iki yolu ayırmaq diaqnozun böyük hissəsidir.
İki bağlantı, iki mənbə
QGIS -> client's permitted path (often the VPN) -> GeoServer listener
GeoServer -> server's permitted path -> PostGIS listenerİkinci ox birinci kompüterin tunelini miras almır. Konteynerdəki GeoServer konteynerin şəbəkə yığınına malikdir, hostun deyil, və körpü şəbəkəsindəki konteyner hostun çata bilmədiyi məlumat bazasına çata bilər, ya da əksinə. Beləliklə eyni istifadəçi bir sessiyada həm uğur qazana, həm də uğursuz ola bilər; cavabın keşdən, yoxsa təzə sorğudan gəlməsindən asılı olaraq.
| What you tested | What it proves |
|---|---|
Portal page or GetCapabilities | HTTP reachability to GeoServer only |
| A tile served from cache | nothing about the database |
GetMap for an uncached layer | a datastore query had to happen |
Həqiqətən uğursuz olan addımı tapın
Xidmət səviyyəsində rədd, məlumat anbarına çatmayan şəkil sorğusu və bir layda icazə problemi brauzer sekmesinde oxşar görünür, server jurnalında isə tamamilə fərqlidir. Konkret əməliyyatı istəyin, sonra həmin vaxt damğası üçün GeoServer-in öz hadisəsini oxuyun.
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"İkinci sorğunun inandırıcı şəkillə qaytarılan 200-ü məlumat anbarının cavab verdiyini sübut edir. Xidmət istisnası sənədi ilə qaytarılan 200 isə vermədiyini sübut edir və istisna mətni adətən müştərini deyil, anbarı adlandırır.
Məlumat anbarını server tərəfindən oxuyun
GeoServer PostGIS istinadı anbarın nəyə ehtiyacı olduğunu sadalayır: host, port, məlumat bazası və etimadnamələr. Bütün bunlar GeoServer-in açdığı bağlantını təsvir edir. Heç biri masaüstü müştərisindən girişi təsvir etmir. Bu dörd sahəni serverin şəbəkə konteksti haqqında bəyanat kimi oxuyun və «onlarda işləyir» biletlərinin bütün sinfi idarəolunan olur.
Buna görə localhost məlumat anbarında bu qədər geniş yayılmış səhvdir. Bu, GeoServer prosesinin öz şəbəkə kontekstini bildirir. GeoServer Docker-də işləyirsə, PostGIS isə hostda işləyirsə, localhost konteynerin içini göstərir və heç nə tapmır, və heç bir VPN konfiqurasiyası bunu dəyişmir.
Serverdə marşrutu, dinləyicini və autentifikasiya siyasətini bu sıra ilə yoxlayın. PostgreSQL-in host əsaslı autentifikasiyası gördüyü mənbə ünvanını müqayisə edir, şlüz onu tərcümə edə bilər, ona görə HBA faylına müştəri VPN hovuzu əlavə etmək server tərəfindəki bağlantını nadir hallarda düzəldir. Serverin edəcəyi kimi sınaqdan keçirin: eyni host, eyni port, eyni istifadəçi. Bu sınaq keçərsə, GeoServer isə hələ də uğursuz olursa, fərq məlumat bazasında deyil, proses kontekstindədir.
ip route get 10.20.5.11
ss -tnp | grep 5432
psql "host=10.20.5.11 dbname=gis user=geoserver" -c 'select 1'Hovuzlar və keşlər dəyişikliklər boyu vəziyyəti saxlayır
Məlumat anbarının bağlantı hovuzları soketləri açıq saxlayır. Hovuz yaradıldıqdan bir saat sonra qalxan tunel hovuza mütləq yeni yol vermir və boş bağlantı doğrulama və ya vaxt aşımı onu bağlayana qədər ölü marşrutda qala bilər. Bərpanı fərz etmək əvəzinə quraşdırılmış anbarın doğrulama parametrlərini yoxlayın və hansı layın uğursuz olduğunu bilməzdən əvvəl bütün xidməti yenidən başlatmaq istəyindən çəkinin.
Plitə keşləri bu problemin güzgü görüntüsünü yaradır: məlumat bazası bağlantısı qopduqdan çox sonra belə düzgün görünən xəritə təqdim edə bilərlər. «Kömək edirmi» görmək üçün keşi təmizləmək, hansı yolun canlı olduğunu sizə deyəcək yeganə sübutu məhv edir.
Hər iki mənbəni adlandıraraq təhvil verin
Sürətli düzəliş alan təsvir iki şeyi adlandırır: GeoServer-ə çatan müştəri sorğusu və GeoServer-in tamamlaya bilmədiyi backend əməliyyatı. İkisi ilə düzgün sahib uğursuz olan yolu təmir edə bilər. Yalnız birincisi ilə təbii düzəliş məlumat bazasını hamıya açmaqdır, bu da bileti daha pis bir problem yaradaraq həll edir.
Layı, cavab kodunu, server tərəfindəki istisnanı və onu yaradan konteyneri və ya hostu qeyd edin. Bu dörd sətirdir və qeyri-müəyyənliyi tamamilə aradan qaldırır.