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 |
იპოვეთ ნაბიჯი, რომელიც ნამდვილად ჩავარდა
სერვისის დონეზე უარი, სურათის მოთხოვნა, რომელიც ვერ აღწევს თავის მონაცემთა საცავს, და ერთი შრის ნებართვის პრობლემა ბრაუზერის ჩანართში მსგავსად გამოიყურება, ხოლო სერვერის ჟურნალში სრულიად განსხვავებულად. მოითხოვეთ კონკრეტული ოპერაცია, შემდეგ წაიკითხეთ 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 სერვისის გამონაკლისის დოკუმენტით ამტკიცებს, რომ არ უპასუხა, და გამონაკლისის ტექსტი ჩვეულებრივ ასახელებს საცავს და არა კლიენტს.
წაიკითხეთ მონაცემთა საცავი სერვერის მხრიდან
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-ს, და backend ოპერაციას, რომელიც GeoServer-მა ვერ დაასრულა. ორივეთი სწორ მფლობელს შეუძლია გააკეთოს ის გზა, რომელიც ჩავარდა. მხოლოდ პირველით ბუნებრივი გასწორებაა მონაცემთა ბაზის საჯაროდ გამოქვეყნება, რაც ბილეთს წყვეტს უარესი პრობლემის შექმნით.
ჩაიწერეთ შრე, პასუხის კოდი, სერვერის მხარეს გამონაკლისი და კონტეინერი ან ჰოსტი, რომელმაც ის შექმნა. ეს ოთხი ხაზია და ისინი სრულად აქრობს გაურკვევლობას.