სტაბილურობა — ეს არის პროდუქტის პრინციპი, ხოლო არა გონივრული ვარაუდი. AiHummer მისი მიძღვენა SemVer, გამოიყენება ავტომატურად უსაფრთხო მონაცემთა ბაზის მიგრაციის წინსვლისთვის, და შესაძლოა თავადგანახლებაო CDN-ის გამოყენებით — ამიტომ განახლებები რუტინული ხდება და არა რისკიანი.
ვერსიების მართვა (SemVer)
გამოშვებები ეყრდნობა სემანტიკურ ვერსიონირებას. ვერსია აღნიშნულია /healthz და ასევე aihummer version, ასე რომ თქვენ ყოველთვის შეგიძლიათ ზუსტად დაადასტუროთ, რომ მუშაობს განახლების წინ და შემდეგ.
მიგრაციები უსაფრთხოა გამოყენებისთვის მომავალში და ავტომატურია
გეითვეი თვითმიმართულად ახდენს მონაცემთა ბაზის ელოდება მიგრაციების გამოყენებას გაშვების დროს. ამის უსაფრთხოებას ორი თვისება უზრუნველყოფს:
უსაფრთხოდ მიიღე წინ. მიგრაციები დაწერილია ისე, რომ უფრო ახალი ბინარული ვერსია იმუშაოს
სქემა, რომელზეც იგი გადაადგილდება, რაც ანეიტრალებს ავტომატურ გამოყენებას და საფეხუროვან განახლებებს უსაფრთხოს.
ერთი გამოყენებული საკონსულტაციო საკავით. მიგრაციები მიმდინარეობს PostgreSQL
საკონსულტაციო ციხე, ამიტომ როდესაც რამდენიმე კარიბჭე ერთდროულად ირთვება, გამოიყენება მხოლოდ ერთი
და დანარჩენები ელიან — არასოდეს ორმაგი მიგრაცია.
[!NOTE]
მიგრაციები ყოველთვის შესრულდება მფლობელის მონაცემთა ბაზის პოულში. შეზღუდული როლი RLS
(AIHUMMER_DB_APP_URL) განკუთვნილია ტრაფიკის მომსახურებისთვის, არა სქემის ცვლილებისთვის.
განახლება
ახალი ვერსიები მოდის მომწოდებლის სარელიზო CDN-იდან. განახლების სტანდარტული გზა —
ერთი ბრძანება სერვერზე:
aihummer update --check # მხოლოდ იტყობინება, არსებობს თუ არა უფრო ახალი ვერსიაaihummer update # ჩამოტვირთავს და გამოიყენებს
--check არაფერს ცვლის და ამიტომ root-ს არ საჭიროებს. თავად გამოყენება
ცვლის ინსტალაციის ძირს და სერვისს გადატვირთავს, ამიტომ ის sudo-თი უნდა
გაუშვათ.
მოსალოდნელი შედეგი:--check ბეჭდავს მიმდინარე და ხელმისაწვდომ ვერსიას და
სრულდება ისე, რომ არაფერს ცვლის. aihummer update ჩამოტვირთავს არტეფაქტს,
ამოწმებს მის საკონტროლო ჯამს sha256 და cosign ხელმოწერას, ცვლის ბინარულ ფაილს
და გადატვირთავს სერვისს — ამის შემდეგ aihummer version აჩვენებს ახალ ვერსიას.
თუ შემოწმება არ დაემთხვა, განახლება წყდება ფაილის შეცვლამდე მანამდე: მომუშავე
ვერსია ხელუხლებელი რჩება.
[!NOTE]
ავტომატურ განახლებას რთავს მომწოდებელი და არა თქვენ. ავტომატური
განახლების რეჟიმი და განრიგი გამოშვების მომსახურების ნაწილია და დგინდება
მომწოდებლის ხელმოწერილი მითითებით. მათთვის გადამრთველები არც ვებ-ინტერფეისშია
და არც aihummer settings-ში; gateway.env-ში ჩაწერილ ავტომატური განახლების
ცვლადებს კარიბჭე არ კითხულობს — თუ იქ მათ ხედავთ, ისინი არაფერზე
მოქმედებენ. საკუთარი განრიგით განახლებისთვის გამოიყენეთ ზემოთ მოცემული ბრძანება
aihummer update.
დაბრუნება
რა ბრუნდება უკან — ცალ-ცალკე:
ბინარული ფაილი — შეიძლება წინა ვერსიაზე დაბრუნება (წინა გამოშვებების
არტეფაქტები რჩება CDN-ზე; საჭირო ვერსია ხელახლა დააყენეთ).
მონაცემთა ბაზის სქემა — მიგრაციები წინსვლისთვის უსაფრთხოა, ამიტომ წინა
ბინარული ფაილი მუშაობს ახალ სქემასთან; სქემის ცალკე დაბრუნება არ ხდება.
დანამატები — ვერსიები იმართება თითოეული ინსტალაციისთვის ცალკე; საჭიროების
შემთხვევაში დანამატის წინა ვერსია დააბრუნეთ კატალოგიდან.
კონფიგურაცია — განახლებისას არ იცვლება; საჭიროების შემთხვევაში
აღდგება სარეზერვო ასლიდან.
დამონტაჟებები ნულის დროებითი ზარალით
AiHummer შექმნილია მუშაობის შეწყვეტის გარეშე განახლებისთვის:
გაააქტიურეთ 2+ გეიტვეი პროქსის მეშვეობით. გადაიტანეთ ისინი ერთგან; მზადების შემოწმება
(/readyz) იცავს თავიდან გამორთულ კვანძს როტაციაში, სანამ ის არ დაიწყებს მომსახურებას.
ერთ ლიდერთან ერთად შემთხზველი. ფონური დაგეგმარება ირჩევს ერთ ლიდერს
PostgreSQL-ის კონსულტაციური ლოკის საშუალებით, რათა რამდენიმე გეინი ერთდროულად არ გამეორდეს
გეგმიური სამუშაოები.
მიწოდება ინდემპოტენტურია. სანდო მიწოდება პლუს იდემპოტენტობის გასაღებები ნიშნავს
პასუხი არასდროს იგზავნება მეორედ გადატვირთვის შემდეგ, სწორედ ეს აყენებს სისტემას გადატრიალებად
გაიტვირთეთ ისევ თქვენი გაჯეტების საშუალებით უსაფრთხოდ.
სტაბილურობა — ეს არის პროდუქტის პრინციპი, ხოლო არა გონივრული ვარაუდი. AiHummer მისი მიძღვენა **SemVer**, გამოიყენება **ავტომატურად უსაფრთხო მონაცემთა ბაზის მიგრაციის წინსვლისთვის**, და შესაძლოა **თავადგანახლებაო** CDN-ის გამოყენებით — ამიტომ განახლებები რუტინული ხდება და არა რისკიანი.
## ვერსიების მართვა (SemVer)
გამოშვებები ეყრდნობა სემანტიკურ ვერსიონირებას. ვერსია აღნიშნულია `/healthz` და ასევე `aihummer version`, ასე რომ თქვენ ყოველთვის შეგიძლიათ ზუსტად დაადასტუროთ, რომ მუშაობს განახლების წინ და შემდეგ.
## მიგრაციები უსაფრთხოა გამოყენებისთვის მომავალში და ავტომატურია
გეითვეი თვითმიმართულად ახდენს მონაცემთა ბაზის ელოდება მიგრაციების გამოყენებას გაშვების დროს. ამის უსაფრთხოებას ორი თვისება უზრუნველყოფს:
- **უსაფრთხოდ მიიღე წინ.** მიგრაციები დაწერილია ისე, რომ უფრო ახალი ბინარული ვერსია იმუშაოს
სქემა, რომელზეც იგი გადაადგილდება, რაც ანეიტრალებს ავტომატურ გამოყენებას და საფეხუროვან განახლებებს უსაფრთხოს.
- **ერთი გამოყენებული საკონსულტაციო საკავით.** მიგრაციები მიმდინარეობს **PostgreSQL
საკონსულტაციო ციხე**, ამიტომ როდესაც რამდენიმე კარიბჭე ერთდროულად ირთვება, გამოიყენება მხოლოდ ერთი
და დანარჩენები ელიან — არასოდეს ორმაგი მიგრაცია.
> [!NOTE]
> მიგრაციები ყოველთვის შესრულდება მფლობელის მონაცემთა ბაზის პოულში. შეზღუდული როლი RLS
> (`AIHUMMER_DB_APP_URL`) განკუთვნილია ტრაფიკის მომსახურებისთვის, არა სქემის ცვლილებისთვის.
## განახლება
ახალი ვერსიები მოდის მომწოდებლის სარელიზო CDN-იდან. განახლების სტანდარტული გზა —
ერთი ბრძანება სერვერზე:
```bash
aihummer update --check # მხოლოდ იტყობინება, არსებობს თუ არა უფრო ახალი ვერსია
aihummer update # ჩამოტვირთავს და გამოიყენებს
```
`--check` არაფერს ცვლის და ამიტომ **root-ს არ საჭიროებს**. თავად გამოყენება
ცვლის ინსტალაციის ძირს და სერვისს გადატვირთავს, ამიტომ ის `sudo`-თი უნდა
გაუშვათ.
**მოსალოდნელი შედეგი:** `--check` ბეჭდავს მიმდინარე და ხელმისაწვდომ ვერსიას და
სრულდება ისე, რომ არაფერს ცვლის. `aihummer update` ჩამოტვირთავს არტეფაქტს,
ამოწმებს მის საკონტროლო ჯამს sha256 და cosign ხელმოწერას, ცვლის ბინარულ ფაილს
და გადატვირთავს სერვისს — ამის შემდეგ `aihummer version` აჩვენებს ახალ ვერსიას.
თუ შემოწმება არ დაემთხვა, განახლება წყდება ფაილის შეცვლამდე **მანამდე**: მომუშავე
ვერსია ხელუხლებელი რჩება.
> [!NOTE]
> **ავტომატურ განახლებას რთავს მომწოდებელი და არა თქვენ.** ავტომატური
> განახლების რეჟიმი და განრიგი გამოშვების მომსახურების ნაწილია და დგინდება
> მომწოდებლის ხელმოწერილი მითითებით. მათთვის გადამრთველები არც ვებ-ინტერფეისშია
> და არც `aihummer settings`-ში; `gateway.env`-ში ჩაწერილ ავტომატური განახლების
> ცვლადებს კარიბჭე **არ კითხულობს** — თუ იქ მათ ხედავთ, ისინი არაფერზე
> მოქმედებენ. საკუთარი განრიგით განახლებისთვის გამოიყენეთ ზემოთ მოცემული ბრძანება
> `aihummer update`.
### დაბრუნება
რა ბრუნდება უკან — ცალ-ცალკე:
- **ბინარული ფაილი** — შეიძლება წინა ვერსიაზე დაბრუნება (წინა გამოშვებების
არტეფაქტები რჩება CDN-ზე; საჭირო ვერსია ხელახლა დააყენეთ).
- **მონაცემთა ბაზის სქემა** — მიგრაციები წინსვლისთვის უსაფრთხოა, ამიტომ წინა
ბინარული ფაილი მუშაობს ახალ სქემასთან; სქემის ცალკე დაბრუნება არ ხდება.
- **დანამატები** — ვერსიები იმართება თითოეული ინსტალაციისთვის ცალკე; საჭიროების
შემთხვევაში დანამატის წინა ვერსია დააბრუნეთ კატალოგიდან.
- **კონფიგურაცია** — განახლებისას არ იცვლება; საჭიროების შემთხვევაში
აღდგება სარეზერვო ასლიდან.
## დამონტაჟებები ნულის დროებითი ზარალით
AiHummer შექმნილია მუშაობის შეწყვეტის გარეშე განახლებისთვის:
- **გაააქტიურეთ 2+ გეიტვეი პროქსის მეშვეობით.** გადაიტანეთ ისინი ერთგან; მზადების შემოწმება
(`/readyz`) იცავს თავიდან გამორთულ კვანძს როტაციაში, სანამ ის არ დაიწყებს მომსახურებას.
- **ერთ ლიდერთან ერთად შემთხზველი.** ფონური დაგეგმარება ირჩევს ერთ ლიდერს
PostgreSQL-ის კონსულტაციური ლოკის საშუალებით, რათა რამდენიმე გეინი ერთდროულად არ გამეორდეს
გეგმიური სამუშაოები.
- **მიწოდება ინდემპოტენტურია.** სანდო მიწოდება პლუს იდემპოტენტობის გასაღებები ნიშნავს
პასუხი არასდროს იგზავნება მეორედ გადატვირთვის შემდეგ, სწორედ ეს აყენებს სისტემას გადატრიალებად
გაიტვირთეთ ისევ თქვენი გაჯეტების საშუალებით უსაფრთხოდ.
## სად შემდეგ?
- პრობლები, რომლებიც სხრავენ როლინგ რესტარტს:
[systemd და მდგომარეობის შემოწმება](/ka/v1.0/operations/systemd-health).
- შექმენით სასარეზადო კოპია დიდი განახლების წინ:
[ბეკაპი და აღდგენა დარღვევების შემდეგ](/ka/v1.0/operations/backups-dr).
- ნახეთ ვარდნა:
[მოვლენადობის დაკვირვება](/ka/v1.0/operations/observability).
