ინსტალაცია და განახლებები

GET  /v1/admin/modules
POST /v1/admin/modules/{slug}/install

download tarball ─▶ run install[] steps ─▶ render sandboxed systemd unit ─▶ poll /healthz ─▶ active

AiHummer-ში პლაგინის ინსტალაცია არის ერთი დაწკაპუნება ადმინ-UI-ში, მაგრამ ამ დაწკაპუნების უკან დგას დეტერმინისტული, ჰოსტზე-მშობლიური სასიცოცხლო ციკლი. პლატფორმა ჩამოტვირთავს პლაგინს, აწარმოებს მის გამოცხადებულ ინსტალაციის ნაბიჯებს, აგებს **იზოლირებულ systemd ერთეულს** და პლაგინს ჯანმრთელად მხოლოდ მაშინ მიიჩნევს, როცა ის პასუხს გასცემს ჯანმრთელობის შემოწმებას. შემდეგ თითოეული ინსტალაცია თავად ინარჩუნებს საკუთარ თავს განახლებულ მდგომარეობაში. ## ერთი დაწკაპუნებით ინსტალაცია ადმინ-UI-დან პლაგინებს აინსტალირებთ და მართავთ ადმინ-UI-დან, რომელსაც უკან უდგას ადმინ-მოდულის API: ```http GET /v1/admin/modules POST /v1/admin/modules/{slug}/install ``` ხელით არაფრის შეერთება არ არის საჭირო: აირჩიეთ პლაგინი კატალოგიდან, დააწკაპუნეთ install-ზე და დანარჩენს deployer იღებს თავის თავზე. ## SystemdDeployer-ის პროცესი კულისებში **SystemdDeployer** ასრულებს ამ ნაბიჯებს: 1. **ჩამოტვირთავს tarball-ს** არჩეული პლაგინისთვის. 2. **აწარმოებს მანიფესტის `install[]` ნაბიჯებს**, რომლებიც პლაგინს აქვს გამოცხადებული. 3. **აგებს იზოლირებულ systemd ერთეულს** პლაგინისთვის. 4. **გამოკითხავს `/healthz`-ს** სანამ სერვისი ჯანმრთელობას არ მოახსენებს. ```text download tarball ─▶ run install[] steps ─▶ render sandboxed systemd unit ─▶ poll /healthz ─▶ active ``` ინსტალაცია აქტიურად მხოლოდ მაშინ აღინიშნება, როცა `/healthz` წარმატებულია — პლაგინი, რომელიც ვერ აეწყობა, უხმაუროდ არ ჩაითვლება ინსტალირებულად. ## ჰოსტზე-მშობლიური, იზოლირებული systemd — და არა Docker ყოველი პლაგინი მუშაობს როგორც **საკუთარი იზოლირებული systemd სერვისი**. არ არსებობს არანაირი კონტეინერი, არანაირი Docker, არანაირი ორკესტრატორი: პლაგინი არის მართვადი Linux სერვისი საკუთარი ერთეულით, პორტითა და იზოლაციის შეზღუდვებით, რომელსაც systemd აკონტროლებს დანარჩენი ინსტალაციის მსგავსად. > [!WARNING] > AiHummer ჰოსტზე-მშობლიურია. პლაგინები განთავსდება როგორც იზოლირებული systemd > სერვისები release tarball-იდან — **არასოდეს როგორც Docker კონტეინერები.** თუ > სახელმძღვანელო გეუბნებათ, რომ "გაუშვით პლაგინის კონტეინერი", ის არ აღწერს AiHummer-ს. ## ჯანმრთელობის შემოწმება /healthz-ით deployer გამოკითხავს პლაგინის `/healthz` ბოლოწერტილს წარმატების გამოცხადებამდე. ეს ჯანმრთელობის ბარიერია ის, რაც ერთი დაწკაპუნებით ინსტალაციას უსაფრთხოს ხდის: გაფუჭებული ან არასწორად კონფიგურირებული პლაგინი იჭერა ინსტალაციის დროს და არა მოგვიანებით, უკვე production-ში. ## თითო ინსტალაციაზე ავტომატური განახლება განახლებები მუშავდება **თითო ინსტალაციაზე**. თითოეულ ინსტალირებულ პლაგინს შეუძლია ავტომატურად განაახლოს თავი საკუთარი გრაფიკით, ასე რომ პლაგინების მიმდინარე მდგომარეობაში შენარჩუნება არ საჭიროებს ხელით ხელახალ ინსტალაციას ყოველ ჯერზე, როცა ახალი ვერსია მიაღწევს კატალოგს. იგივე ჩამოტვირთვა → ინსტალაციის ნაბიჯები → ერთეულის აგება → ჯანმრთელობის შემოწმების პროცესი მუშაობს განახლებისთვისაც ისევე, როგორც პირველი ინსტალაციისთვის. > [!TIP] > ვინაიდან ავტომატური განახლება თითო ინსტალაციაზეა, შეგიძლიათ ზოგი პლაგინი > ფიქსირებულად შეინარჩუნოთ, ხოლო სხვებს მისცეთ უახლესის თვალყურის დევნება — თითოეული > ინსტალაცია მართავს საკუთარ სასიცოცხლო ციკლს. ## მრავალწყაროიანი კატალოგი კატალოგი აღარ არის მიბმული ერთ URL-ზე. **Plugins → Sources**-ში (ადმინ-UI, ან `POST /v1/admin/modules/catalog/sources`) შეგიძლიათ დაამატოთ დამატებითი წყარო — მაგალითად მესამე მხარის პლაგინების **community catalog**. gateway სინქრონიზებას უკეთებს ყველა ჩართულ წყაროს გაშვებისას და ავტომატური განახლების ინტერვალზე. - **ოფიციალური წყარო** (პირველი მხარის მოდულები) ნაგულისხმევად ფიქსირებული და სანდოა — ცალკე ობიექტი, რომელიც **არ გადაიწერება** სხვა წყაროებით. - **პირადი/საზოგადოების წყაროებს** ამატებს ოპერატორი; ყოველ კატალოგის ჩანაწერს აქვს `origin` და სწორედ ეს `origin` წყვეტს, რომელი წამყვანის მიმართ მოწმდება ხელმოწერა (official → ფიქსირებული გასაღები, private → trust store). საზოგადოების კატალოგში გამოქვეყნებისთვის იხილეთ [პლაგინის გამოქვეყნება](/ka/v1.0/marketplace/publishing). ## ნდობის მოდელი და ფიქსირებული გასაღები ინსტალაცია ამოწმებს პლაგინის ხელმოწერას მისი წყაროს მიხედვით: - **official** → მოწმდება **core-ში ფიქსირებული registry გასაღების** მიმართ. ნაგულისხმევად სანდო, ოპერატორის მოქმედების გარეშე. - **private** (side-load) → მოწმდება **ინსტანციის trust store-ის** მიმართ; ავტორის გასაღებს ოპერატორი ამტკიცებს ატვირთვისას (ერთი დაწკაპუნება). - **unsigned** → უარყოფილია, გარდა dev რეჟიმისა (`AIHUMMER_PLUGIN_DEV_UNSIGNED=1`, მხოლოდ ლოკალური განვითარებისთვის). ## ხელმოწერილი განახლებები განახლება **ხელახლა აწარმოებს იმავე ხელმოწერის ბარიერს**, რასაც პირველი ინსტალაცია: ახალ ვერსიაზე გადასვლისას ხელმოწერა ისევ მოწმდება იმავე ნდობის წამყვანის მიმართ. განახლებას **არ შეუძლია გვერდის ავლა** შემოწმებისთვის — ნდობის ამაღლება განახლების გზით შეუძლებელია. ## Official ბეჯი და რანჟირება Web-UI კატალოგში AiHummer-ის პლაგინებს აქვთ **Official** ბეჯი და პირველ რიგში ლაგდებიან. მესამე მხარის პლაგინები ჩანან ბეჯის გარეშე და დალაგებულია **ჩამოტვირთვების რაოდენობით**. Official დროშა მიიღება ჩანაწერის `origin`-იდან (official) — მისი ხელით დაყენება მანიფესტში შეუძლებელია. ## სად შემდეგ - [Marketplace-ის მიმოხილვა და დონეები](/ka/v1.0/marketplace/overview-tiers) — რა არის სამი პლაგინის დონე. - [Plugin SDK](/ka/v1.0/marketplace/sdk) — `manifest.json`, რომლის `install[]` ნაბიჯებსაც ეს სასიცოცხლო ციკლი აწარმოებს. - [პლაგინის გამოქვეყნება](/ka/v1.0/marketplace/publishing) — პირადი side-load და საჯარო registry. - [უკოდო ინტეგრაციები](/ka/v1.0/marketplace/zero-code) — დაამატეთ OpenAPI/MCP ხელსაწყოები ინსტალირებადი სერვისის გარეშე. </content> </invoke>