GeoServer ve PostGIS: önemli olan VPN yolu sunucununki
Dizüstü bilgisayarınızın GeoServer’a ulaşması, GeoServer’ın PostGIS’e ulaşıp ulaşmadığı hakkında hiçbir şey söylemez. İki kaynağı, önbellek sınırını ve veri deposunun kendi kaynağını karşılaştırın.
Katmanı QGIS’te açıyorsunuz ve çiziliyor. Aynı VPN’deki bir meslektaşınız aynı katman için hata alıyor. Biri VPN’in bozuk olduğu sonucuna varıyor ve sonraki saat bir veritabanını taşımakla ya da ikisine de hiç ihtiyaç duymamış bir bağlantı noktasını açmakla geçiyor. Masaüstünden gelen istek ile GeoServer’ın PostGIS’e yaptığı sorgu farklı makinelerden, farklı ağ ad alanlarından, farklı kimlik bilgileriyle çıkıyor. Bu iki yolu ayırmak, teşhisin büyük kısmıdır.
İki bağlantı, iki kaynak
QGIS -> client's permitted path (often the VPN) -> GeoServer listener
GeoServer -> server's permitted path -> PostGIS listener
İkinci ok, ilk bilgisayarın tünelini devralmaz. Bir konteynerdeki GeoServer, konteynerin ağ yığınına sahiptir, ana makinenin değil; köprülü bir ağdaki konteyner, ana makinenin ulaşamadığı bir veritabanına ulaşabilir ya da tersi. Böylece aynı kullanıcı tek bir oturumda hem başarabilir hem başarısız olabilir; yanıtın önbellekten mi yoksa taze bir sorgudan mı geldiğine bağlı olarak.
| 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 |
Gerçekten başarısız olan adımı bulun
Hizmet düzeyinde bir ret, veri deposuna ulaşamayan bir görüntü isteği ve tek bir katmandaki izin sorunu tarayıcı sekmesinde benzer görünür, sunucu günlüğünde ise tamamen farklıdır. Belirli işlemi isteyin, ardından aynı zaman damgası için GeoServer’ın kendi olayını okuyun.
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 isteğin makul bir görüntüyle dönen 200’ü, veri deposunun yanıt verdiğini kanıtlar. Bir hizmet istisnası belgesiyle dönen 200 ise vermediğini kanıtlar ve istisna metni genellikle istemciyi değil depoyu adlandırır.
Veri deposunu sunucu tarafından okuyun
GeoServer PostGIS başvurusu deponun neye ihtiyacı olduğunu listeler: ana makine, bağlantı noktası, veritabanı ve kimlik bilgileri. Bunların hepsi GeoServer’ın açtığı bağlantıyı tanımlar. Hiçbiri masaüstü istemcisinden bir oturum açmayı tanımlamaz. Bu dört alanı sunucunun ağ bağlamı hakkında bir ifade olarak okuyun; «onlarda çalışıyor» denen biletlerin tüm sınıfı da ele alınabilir hale gelir.
Bu yüzden localhost bir veri deposunda çok yaygın bir hatadır. GeoServer sürecinin kendi ağ bağlamı anlamına gelir. GeoServer Docker’da çalışırken PostGIS ana makinede çalışıyorsa, localhost konteynerin içini gösterir ve hiçbir şey bulamaz; hiçbir VPN yapılandırması bunu değiştirmez.
Sunucuda rotayı, dinleyiciyi ve kimlik doğrulama ilkesini bu sırayla kontrol edin. PostgreSQL’in ana makine tabanlı kimlik doğrulaması gördüğü kaynak adresle eşleşir ve bir ağ geçidi bunu çevirebilir; bu yüzden HBA dosyasına istemci VPN havuzu eklemek sunucu tarafındaki bir bağlantıyı nadiren düzeltir. Sunucunun yapacağı gibi test edin: aynı ana makine, aynı bağlantı noktası, aynı kullanıcı. Bu test başarılı olurken GeoServer hâlâ başarısızsa fark veritabanında değil, süreç bağlamındadır.
ip route get 10.20.5.11
ss -tnp | grep 5432
psql "host=10.20.5.11 dbname=gis user=geoserver" -c 'select 1'
Havuzlar ve önbellekler durumu değişiklikler boyunca tutar
Veri deposunun bağlantı havuzları yuvaları açık tutar. Havuz oluşturulduktan bir saat sonra açılan bir tünel havuza mutlaka yeni bir yol vermez ve boşta bir bağlantı, bir doğrulama ya da zaman aşımı onu kapatana kadar ölü bir rotada kalabilir. Kurtarma varsaymak yerine kurulu deponun doğrulama ayarlarını kontrol edin ve hangi katmanın başarısız olduğunu bilmeden tüm hizmeti yeniden başlatma dürtüsünden kaçının.
Döşeme önbellekleri bu sorunun aynadaki görüntüsünü yaratır: veritabanı bağlantısı koptuktan çok sonra doğru görünen bir harita sunmaya devam edebilirler. «Yardımcı oluyor mu» diye önbelleği temizlemek, hangi yolun canlı olduğunu size söyleyecek tek kanıtı yok eder.
Her iki kaynağı da adlandırarak devredin
Hızlı bir düzeltme alan açıklama iki şeyi adlandırır: GeoServer’a ulaşan istemci isteği ve GeoServer’ın tamamlayamadığı arka uç işlemi. İkisiyle birlikte doğru sahip başarısız olan yolu onarabilir. Yalnızca birincisiyle, doğal düzeltme veritabanını herkese açık hale getirmektir; bu da bileti daha kötü bir sorun yaratarak çözer.
Katmanı, yanıt kodunu, sunucu tarafındaki istisnayı ve onu üreten konteyneri ya da ana makineyi not edin. Bu dört satırdır ve belirsizliği tamamen ortadan kaldırır.