GeoServer dan PostGIS: laluan VPN yang penting ialah laluan pelayan
Komputer riba anda mencapai GeoServer tidak berkata apa-apa tentang sama ada GeoServer mencapai PostGIS. Bandingkan kedua-dua asal, sempadan cache dan sumber stor data itu sendiri.
Anda membuka lapisan dalam QGIS dan ia dipaparkan. Rakan sekerja pada VPN yang sama mendapat ralat untuk lapisan yang sama. Seseorang membuat kesimpulan VPN rosak, dan satu jam berikutnya habis untuk memindahkan pangkalan data atau membuka port yang tidak pernah memerlukan kedua-duanya. Permintaan dari desktop dan pertanyaan yang dihantar GeoServer ke PostGIS bertolak dari mesin berbeza, dalam ruang nama rangkaian berbeza, dengan kelayakan berbeza. Memisahkan kedua-dua laluan itu ialah sebahagian besar diagnosis.
Dua sambungan, dua asal
QGIS -> client's permitted path (often the VPN) -> GeoServer listener
GeoServer -> server's permitted path -> PostGIS listener
Anak panah kedua tidak mewarisi terowong komputer pertama. GeoServer dalam kontena mempunyai tindanan rangkaian kontena, bukan hos, dan kontena pada rangkaian jambatan boleh mencapai pangkalan data yang tidak dicapai hos, atau sebaliknya. Oleh itu pengguna yang sama boleh berjaya dan gagal dalam sesi yang sama, bergantung sama ada jawapannya datang dari cache atau dari pertanyaan baharu.
| 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 |
Cari langkah yang benar-benar gagal
Penolakan peringkat perkhidmatan, permintaan imej yang tidak sampai ke stor datanya, dan masalah kebenaran pada satu lapisan kelihatan serupa dalam tab pelayar dan sangat berbeza dalam log pelayan. Minta operasi yang khusus, kemudian baca peristiwa GeoServer sendiri untuk cap masa yang sama.
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 daripada permintaan kedua dengan imej yang munasabah membuktikan stor data menjawab. 200 dengan dokumen pengecualian perkhidmatan membuktikan ia tidak menjawab, dan teks pengecualian biasanya menamakan stor dan bukan klien.
Baca stor data dari sisi pelayan
Rujukan PostGIS GeoServer menyenaraikan apa yang diperlukan stor: hos, port, pangkalan data dan kelayakan. Semua itu menerangkan sambungan yang dibuka GeoServer. Tiada satu pun menerangkan log masuk dari klien desktop. Bacalah keempat-empat medan itu sebagai kenyataan tentang konteks rangkaian pelayan, dan seluruh kelas tiket «di tempat mereka ia berfungsi» menjadi boleh dikendalikan.
Itulah sebabnya localhost dalam stor data menjadi kesilapan yang begitu biasa. Ia bermaksud konteks rangkaian proses GeoServer itu sendiri. Jika GeoServer berjalan dalam Docker manakala PostGIS berjalan pada hos, localhost menunjuk ke dalam kontena dan tidak menemui apa-apa, dan tiada konfigurasi VPN mengubahnya.
Pada pelayan, periksa laluan, pendengar dan dasar pengesahan dalam urutan itu. Pengesahan berasaskan hos PostgreSQL memadankan alamat sumber yang dilihatnya, yang mungkin diterjemahkan oleh get laluan, jadi menambah kumpulan VPN klien ke fail HBA jarang membaiki sambungan sisi pelayan. Uji seperti pelayan akan melakukannya: hos sama, port sama, pengguna sama. Jika ujian itu berjaya manakala GeoServer masih gagal, perbezaannya terletak pada konteks proses, bukan pada pangkalan data.
ip route get 10.20.5.11
ss -tnp | grep 5432
psql "host=10.20.5.11 dbname=gis user=geoserver" -c 'select 1'
Kumpulan dan cache menyimpan keadaan merentasi perubahan
Kumpulan sambungan stor data mengekalkan soket terbuka. Terowong yang timbul sejam selepas kumpulan dicipta tidak semestinya memberi kumpulan laluan baharu, dan sambungan melahu boleh duduk pada laluan mati sehingga pengesahan atau tamat masa menutupnya. Periksa tetapan pengesahan stor yang dipasang dan bukannya menganggap pemulihan, dan elakkan dorongan untuk memulakan semula seluruh perkhidmatan sebelum anda tahu lapisan mana yang gagal.
Cache jubin mencipta imej cermin masalah itu: ia boleh menyajikan peta yang kelihatan betul lama selepas sambungan pangkalan data terputus. Mengosongkan cache untuk «melihat sama ada ia membantu» memusnahkan satu-satunya bukti yang akan memberitahu anda laluan mana yang masih hidup.
Serahkan dengan kedua-dua asal dinamakan
Penerangan yang mendapat pembaikan pantas menamakan dua perkara: permintaan klien yang sampai ke GeoServer, dan operasi bahagian belakang yang tidak dapat diselesaikan GeoServer. Dengan kedua-duanya, pemilik yang betul boleh membaiki laluan yang gagal. Dengan yang pertama sahaja, pembaikan semula jadi ialah mendedahkan pangkalan data secara terbuka, yang menyelesaikan tiket dengan mencipta masalah yang lebih teruk.
Catat lapisan, kod respons, pengecualian sisi pelayan dan kontena atau hos yang menghasilkannya. Itu empat baris, dan ia menghapuskan kekaburan sepenuhnya.