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 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 |
ನಿಜವಾಗಿ ವಿಫಲವಾದ ಹಂತವನ್ನು ಹುಡುಕಿ
ಸೇವಾ ಮಟ್ಟದ ನಿರಾಕರಣೆ, ತನ್ನ ಡೇಟಾ ಸ್ಟೋರ್ ತಲುಪದ ಚಿತ್ರ ವಿನಂತಿ, ಮತ್ತು ಒಂದು ಲೇಯರ್‌ನಲ್ಲಿ ಅನುಮತಿ ಸಮಸ್ಯೆ ಬ್ರೌಸರ್ ಟ್ಯಾಬ್‌ನಲ್ಲಿ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ, ಸರ್ವರ್ ಲಾಗ್‌ನಲ್ಲಿ ಸಂಪೂರ್ಣ ಭಿನ್ನ. ನಿಖರವಾದ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಕೇಳಿ, ನಂತರ ಅದೇ ಸಮಯ ಮುದ್ರೆಗೆ ಸರ್ವರ್‌ನ ಸ್ವಂತ ಘಟನೆಯನ್ನು ಓದಿ.
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 ಉತ್ತರಿಸಿಲ್ಲ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಮತ್ತು ವಿನಾಯಿತಿ ಪಠ್ಯ ಸಾಮಾನ್ಯವಾಗಿ ಕ್ಲೈಂಟ್ ಬದಲು ಸ್ಟೋರ್ ಅನ್ನು ಹೆಸರಿಸುತ್ತದೆ.
ಡೇಟಾ ಸ್ಟೋರ್ ಅನ್ನು ಸರ್ವರ್ ಕಡೆಯಿಂದ ಓದಿ
GeoServer ನ PostGIS ಉಲ್ಲೇಖ ಸ್ಟೋರ್‌ಗೆ ಏನು ಬೇಕು ಎಂಬುದನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ: ಹೋಸ್ಟ್, ಪೋರ್ಟ್, ಡೇಟಾಬೇಸ್ ಮತ್ತು ರುಜುವಾತುಗಳು. ಇವೆಲ್ಲವೂ GeoServer ತೆರೆಯುವ ಸಂಪರ್ಕವನ್ನು ವಿವರಿಸುತ್ತವೆ. ಇವುಗಳಲ್ಲಿ ಯಾವುದೂ ಡೆಸ್ಕ್‌ಟಾಪ್ ಕ್ಲೈಂಟ್‌ನಿಂದ ಲಾಗಿನ್ ಅನ್ನು ವಿವರಿಸುವುದಿಲ್ಲ. ಈ ನಾಲ್ಕು ಕ್ಷೇತ್ರಗಳನ್ನು ಸರ್ವರ್‌ನ ನೆಟ್‌ವರ್ಕ್ ಸಂದರ್ಭದ ಬಗ್ಗೆ ಹೇಳಿಕೆಯಾಗಿ ಓದಿ, «ಅವರಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ» ಟಿಕೆಟ್‌ಗಳ ಇಡೀ ವರ್ಗವು ಪರಿಹರಿಸಬಹುದಾದದ್ದಾಗುತ್ತದೆ.
ಅದಕ್ಕಾಗಿಯೇ localhost ಡೇಟಾ ಸ್ಟೋರ್‌ನಲ್ಲಿ ಇಷ್ಟು ಸಾಮಾನ್ಯ ತಪ್ಪು. ಅದರ ಅರ್ಥ GeoServer ಪ್ರಕ್ರಿಯೆಯ ಸ್ವಂತ ನೆಟ್‌ವರ್ಕ್ ಸಂದರ್ಭ. GeoServer Docker ನಲ್ಲಿ ಚಲಿಸುತ್ತಿದ್ದು PostGIS ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಚಲಿಸುತ್ತಿದ್ದರೆ, localhost ಕಂಟೇನರ್ ಒಳಗೆ ಸೂಚಿಸುತ್ತದೆ ಮತ್ತು ಏನನ್ನೂ ಕಂಡುಕೊಳ್ಳುವುದಿಲ್ಲ, ಮತ್ತು ಯಾವುದೇ VPN ಸಂರಚನೆ ಅದನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ.
ಸರ್ವರ್‌ನಲ್ಲಿ ಮಾರ್ಗ, ಶ್ರೋತ ಮತ್ತು ದೃಢೀಕರಣ ನೀತಿಯನ್ನು ಅದೇ ಕ್ರಮದಲ್ಲಿ ಪರಿಶೀಲಿಸಿ. PostgreSQL ನ ಹೋಸ್ಟ್ ಆಧಾರಿತ ದೃಢೀಕರಣವು ತಾನು ನೋಡುವ ಮೂಲ ವಿಳಾಸವನ್ನು ಹೋಲಿಸುತ್ತದೆ, ಅದನ್ನು ಗೇಟ್‌ವೇ ಅನುವಾದಿಸಬಹುದು, ಆದ್ದರಿಂದ HBA ಕಡತಕ್ಕೆ ಕ್ಲೈಂಟ್ VPN ಪೂಲ್ ಸೇರಿಸುವುದು ಸರ್ವರ್ ಬದಿಯ ಸಂಪರ್ಕವನ್ನು ಅಪರೂಪಕ್ಕೆ ಸರಿಪಡಿಸುತ್ತದೆ. ಸರ್ವರ್ ಮಾಡುವಂತೆ ಪರೀಕ್ಷಿಸಿ: ಅದೇ ಹೋಸ್ಟ್, ಅದೇ ಪೋರ್ಟ್, ಅದೇ ಬಳಕೆದಾರ. ಆ ಪರೀಕ್ಷೆ ಯಶಸ್ವಿಯಾಗಿಯೂ 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 ಪೂರ್ಣಗೊಳಿಸಲಾಗದ ಹಿನ್ನೆಲೆ ಕಾರ್ಯಾಚರಣೆ. ಎರಡೂ ಇದ್ದರೆ ಸರಿಯಾದ ಮಾಲೀಕರು ವಿಫಲವಾದ ಮಾರ್ಗವನ್ನು ಸರಿಪಡಿಸಬಹುದು. ಮೊದಲನೆಯದು ಮಾತ್ರ ಇದ್ದರೆ ಸಹಜ ಪರಿಹಾರ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಸಾರ್ವಜನಿಕವಾಗಿ ತೆರೆಯುವುದು, ಅದು ಟಿಕೆಟ್ ಅನ್ನು ಇನ್ನಷ್ಟು ಕೆಟ್ಟ ಸಮಸ್ಯೆ ಸೃಷ್ಟಿಸಿ ಪರಿಹರಿಸುತ್ತದೆ.
ಲೇಯರ್, ಪ್ರತಿಕ್ರಿಯೆ ಕೋಡ್, ಸರ್ವರ್ ಬದಿಯ ವಿನಾಯಿತಿ ಮತ್ತು ಅದನ್ನು ಸೃಷ್ಟಿಸಿದ ಕಂಟೇನರ್ ಅಥವಾ ಹೋಸ್ಟ್ ಅನ್ನು ಟಿಪ್ಪಣಿ ಮಾಡಿ. ಅವು ನಾಲ್ಕು ಸಾಲುಗಳು, ಮತ್ತು ಅವು ಅಸ್ಪಷ್ಟತೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತೆಗೆದುಹಾಕುತ್ತವೆ.