systemd და ჯანმრთელობის შემოწმებები
AiHummer ჰოსტზე-მშობლიურია: ის განთავსდება როგორც release tarball, რომელიც მუშაობს systemd-ის ქვეშ, და არა კონტეინერებში. ეს გვერდი ფარავს, თუ სად ცხოვრობს ის დისკზე, როგორ შევამოწმოთ მისი ჯანმრთელობა და რა უნდა დავხუროთ მომხმარებლების წინაშე გამოტანამდე.
ინსტალაციის ფესვი და systemd ერთეულები
ყველაფერი ცხოვრობს ერთი ინსტალაციის ფესვის, /home/.aihummer-ის ქვეშ,
განლაგებული bin/ etc/ share/ sidecars/ plugins/ systemd/ state/ data/ logs/-ად.
gateway-ის კონფიგურაციის ფაილი არის /home/.aihummer/etc/gateway.env.
systemd ერთეულის ფაილები ინახება ინსტალაციის ფესვის ქვეშ და
სიმბოლურად დაკავშირებულია /etc/systemd/system/-ში, ასე რომ gateway და
თითოეული sidecar არიან ჩვეულებრივი სერვისები, რომელთა გაშვება, გაჩერება და დათვალიერება
შეგიძლიათ systemctl-ითა და journalctl-ით. თითოეული sidecar მუშაობს საკუთარი
ერთეულის ქვეშ — იხილეთ Sidecars.
ჯანმრთელობისა და მზადყოფნის ზონდები
gateway გამოაჩენს ორ განსხვავებულ ზონდს:
| ზონდი | ბოლოწერტილი | მნიშვნელობა |
|---|---|---|
| სიცოცხლისუნარიანობა | GET /healthz |
პროცესი ცოცხალია; აბრუნებს ვერსიას |
| მზადყოფნა | GET /readyz |
ამოწმებს PostgreSQL-ს; აბრუნებს 503-ს თუ ბაზა გათიშულია |
გამოიყენეთ /healthz “პროცესი ააწეულია თუ არა”-სთვის და /readyz “შეუძლია თუ არა მას
რეალურად მსვლელობის მოწოდება”-სთვის. reverse proxy-ის ან load balancer-ის უკან
მიუთითეთ მზადყოფნის შემოწმება /readyz-ზე, ასე რომ gateway, რომელსაც ბაზა არ აქვს,
როტაციიდან გამოვა.
curl -fsS http://127.0.0.1:8780/healthz # 200 + version
curl -fsS http://127.0.0.1:8780/readyz # 200 ready, 503 if Postgres is unreachable[!NOTE] PostgreSQL ერთადერთი მკაცრი დამოკიდებულებაა. მისაწვდომი ბაზის გარეშე gateway მუშაობს დეგრადირებულ მხოლოდ-ჯანმრთელობის რეჟიმში და
/readyzმოახსენებს 503-ს.
Smoke ტესტი
ინსტალაციის ან განახლების შემდეგ გაუშვით მომზადებული smoke ტესტი, რათა დაადასტუროთ, რომ განთავსება ბოლოდან ბოლომდე სწორად პასუხობს:
deploy/host/smoke.shსერვისების მართვა CLI-ით
aihummer CLI არის მთავარი კარი ყოველდღიური ოპერაციებისთვის — ის მართავს gateway-სა
და sidecar-ებს ნაცვლად იმისა, რომ systemctl ხელით ამუშაოთ:
aihummer up # install / bring services up
aihummer restart # restart the gateway
aihummer stop # stop services
aihummer status # show service status
aihummer logs # tail logs (optionally: aihummer logs <svc>)
aihummer doctor # run diagnosticsბრძანებების სრული ნაკრებისთვის, მათ შორის backup, restore, update და
uninstall, იხილეთ CLI ცნობარი.
Production-ის წინასწარი შემოწმების ჩამონათვალი
AiHummer-ის რეალური ტრაფიკისთვის გამოტანამდე გაიარეთ ეს სია:
- დააყენეთ მთავარი გასაღები. მიაწოდეთ
AIHUMMER_MASTER_KEY(base64, 32 ბაიტი), რათა საიდუმლოების vault და BYOK დაშიფრული იყოს მოსვენებულ მდგომარეობაში. - დააკონფიგურირეთ საწარმოო ავთენტიფიკაცია. შეაერთეთ OIDC, LDAP და/ან SAML, რათა
/v1/admin/*დაცული იყოს. ავთენტიფიკაციის გამცემის გარეშე ადმინ-ზედაპირი ენდობა განვითარების header-ებს. - დააყენეთ შემავალი საიდუმლო. მიაწოდეთ
AIHUMMER_INBOUND_SECRET, რათა კონექტორებმა მოახდინონ ავთენტიფიკაცია/v1/inbound/*-თან. - დახურეთ სარისკო ხელსაწყოები. შეზღუდეთ ან გათიშეთ
code_exec, გაამკაცრეთ გამავალი ტრაფიკი და მოაქციეთdb_queryმხოლოდ-კითხვადი DSN-ის ფარგლებში. - დაასრულეთ TLS reverse proxy-ზე. გაუშვით gateway proxy-ის უკან, რომელიც HTTPS-ს ამუშავებს; თავად gateway ემსახურება უბრალო HTTP-ს.
[!WARNING] OIDC/LDAP/SAML გამცემის კონფიგურაციის გარეშე ადმინ-API უკან იხევს განვითარების header-ებზე ნდობაზე. არასოდეს გამოიტანოთ ასეთი ინსტანცია არასანდო ქსელში — ჯერ დააკონფიგურირეთ საწარმოო ავთენტიფიკაცია.
სად შემდეგ
- მეტყველებისა და ხელსაწყოს სერვისების ტრანსპორტის მოდელი: Sidecars.
- სარეზერვო ასლები, მთავარი გასაღები და კატასტროფიდან აღდგენა: სარეზერვო ასლები და კატასტროფიდან აღდგენა.
- მეტრიკები, კვალები და რას ვადევნოთ თვალი: დაკვირვებადობა.