GeoServer dan PostGIS: Jalur VPN yang penting adalah jalur server

Anda membuka layer di QGIS dan layer itu terender. Rekan di VPN yang sama mendapat galat untuk layer yang sama. Seseorang menyimpulkan VPN rusak, dan satu jam berikutnya habis untuk memindahkan basis data atau membuka port yang tidak pernah membutuhkan keduanya. Permintaan dari desktop dan kueri yang dikirim GeoServer ke PostGIS berangkat dari mesin berbeda, dalam ruang nama jaringan berbeda, dengan kredensial berbeda. Memisahkan kedua jalur itu adalah sebagian besar diagnosis.

Dua koneksi, dua asal

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

Panah kedua tidak mewarisi terowongan komputer pertama. GeoServer di dalam kontainer memiliki tumpukan jaringan kontainer, bukan milik host, dan kontainer pada jaringan jembatan bisa menjangkau basis data yang tidak dijangkau host, atau sebaliknya. Karena itu pengguna yang sama bisa berhasil dan gagal dalam satu sesi, tergantung apakah jawabannya datang dari cache atau dari kueri baru.

Temukan langkah yang benar-benar gagal

Penolakan tingkat layanan, permintaan gambar yang tidak mencapai penyimpanan datanya, dan masalah izin pada satu layer tampak serupa di tab peramban dan sangat berbeda di log server. Mintalah operasi yang spesifik, lalu baca peristiwa GeoServer sendiri untuk stempel waktu 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 dari permintaan kedua dengan gambar yang masuk akal membuktikan penyimpanan data menjawab. 200 dengan dokumen pengecualian layanan membuktikan tidak menjawab, dan teks pengecualian biasanya menyebut penyimpanan, bukan klien.

Baca penyimpanan data dari sisi server

Referensi PostGIS GeoServer mencantumkan apa yang dibutuhkan penyimpanan: host, port, basis data, dan kredensial. Semua itu menggambarkan koneksi yang dibuka GeoServer. Tidak satu pun menggambarkan login dari klien desktop. Bacalah keempat bidang itu sebagai pernyataan tentang konteks jaringan server, dan seluruh kelas tiket «di tempat mereka berjalan» menjadi bisa ditangani.

Itulah sebabnya localhost di dalam penyimpanan data menjadi kesalahan yang begitu umum. Artinya konteks jaringan proses GeoServer itu sendiri. Jika GeoServer berjalan di Docker sementara PostGIS berjalan di host, localhost menunjuk ke dalam kontainer dan tidak menemukan apa pun, dan tidak ada konfigurasi VPN yang mengubahnya.

Di server, periksa rute, pendengar, dan kebijakan autentikasi dalam urutan itu. Autentikasi berbasis host PostgreSQL mencocokkan alamat sumber yang dilihatnya, yang mungkin diterjemahkan gateway, sehingga menambahkan kumpulan VPN klien ke berkas HBA jarang memperbaiki koneksi sisi server. Ujilah seperti server akan melakukannya: host sama, port sama, pengguna sama. Jika uji itu berhasil sementara GeoServer masih gagal, perbedaannya ada pada konteks proses, bukan pada basis 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 koneksi dan cache menyimpan status melintasi perubahan

Kumpulan koneksi penyimpanan data menjaga soket tetap terbuka. Terowongan yang muncul satu jam setelah kumpulan dibuat tidak otomatis memberi kumpulan jalur baru, dan koneksi menganggur bisa bertahan di rute yang mati sampai validasi atau waktu tunggu menutupnya. Periksa pengaturan validasi penyimpanan yang terpasang alih-alih menganggap pemulihan, dan hindari hasrat memulai ulang seluruh layanan sebelum tahu layer mana yang gagal.

Cache petak membuat bayangan cermin dari masalah itu: mereka bisa menyajikan peta yang tampak benar jauh setelah koneksi basis data terputus. Mengosongkan cache untuk «melihat apakah membantu» menghancurkan satu-satunya bukti yang akan memberi tahu Anda jalur mana yang masih hidup.

Serahkan dengan kedua asal disebutkan

Deskripsi yang mendapat perbaikan cepat menyebutkan dua hal: permintaan klien yang mencapai GeoServer, dan operasi backend yang tidak bisa diselesaikan GeoServer. Dengan keduanya, pemilik yang benar dapat memperbaiki jalur yang gagal. Dengan hanya yang pertama, perbaikan alaminya adalah mengekspos basis data ke publik, yang menyelesaikan tiket dengan menciptakan masalah yang lebih buruk.

Catat layer, kode respons, pengecualian sisi server, dan kontainer atau host yang menghasilkannya. Itu empat baris, dan itu menghapus ambiguitas sepenuhnya.