لایه را در 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 testedWhat it proves
Portal page or GetCapabilitiesHTTP reachability to GeoServer only
A tile served from cachenothing about the database
GetMap for an uncached layera datastore query had to happen

گامی را پیدا کنید که واقعاً شکست خورد

رد شدن در سطح سرویس، درخواست تصویری که به انبار دادهٔ خود نمی‌رسد، و مشکل مجوز در یک لایه در زبانهٔ مرورگر شبیه هم به نظر می‌رسند و در گزارش کارساز کاملاً متفاوت‌اند. عملیات مشخص را بخواهید، سپس رویداد خودِ GeoServer را برای همان برچسب زمانی بخوانید.

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 با سند استثنای سرویس ثابت می‌کند که پاسخ نداده، و متن استثنا معمولاً نام انبار را می‌آورد نه نام کارخواه را.

انبار داده را از سمت کارساز بخوانید

مرجع PostGIS در GeoServer آنچه انبار لازم دارد را فهرست می‌کند: میزبان، پورت، پایگاه داده و اعتبارنامه‌ها. همهٔ این‌ها اتصالی را توصیف می‌کند که GeoServer باز می‌کند. هیچ‌یک از آن‌ها ورود از کارخواه رومیزی را توصیف نمی‌کند. این چهار فیلد را بیانیه‌ای دربارهٔ بافت شبکهٔ کارساز بخوانید، و آنگاه کل دستهٔ تیکت‌های «پیش آن‌ها کار می‌کند» قابل رسیدگی می‌شود.

به همین دلیل localhost در انبار داده چنان خطای رایجی است. معنایش بافت شبکهٔ خودِ فرایند GeoServer است. اگر GeoServer در Docker اجرا شود در حالی که PostGIS روی میزبان اجرا می‌شود، localhost به درون کانتینر اشاره می‌کند و چیزی نمی‌یابد، و هیچ پیکربندی VPN این را تغییر نمی‌دهد.

روی کارساز، مسیر، شنونده و سیاست احراز هویت را به همین ترتیب بررسی کنید. احراز هویت میزبان‌محور PostgreSQL نشانی مبدأیی را که می‌بیند تطبیق می‌دهد، و دروازه ممکن است آن را ترجمه کند، پس افزودن استخر VPN کارخواهان به پروندهٔ HBA به‌ندرت اتصال سمت کارساز را درست می‌کند. مانند کارساز بیازمایید: همان میزبان، همان پورت، همان کاربر. اگر آن آزمون موفق شود و 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 نتوانست کامل کند. با هر دو، مالک درست می‌تواند مسیری را که شکست خورد تعمیر کند. با تنها اولی، اصلاح طبیعی افشای عمومی پایگاه داده است، که تیکت را با ساختن مشکلی بدتر حل می‌کند.

لایه، کد پاسخ، استثنای سمت کارساز و کانتینر یا میزبانی که آن را تولید کرد را یادداشت کنید. این چهار خط است، و ابهام را کاملاً برمی‌دارد.

مقالات مرتبط