Թարմացման քաղաքականություն

aihummer update --check   # միայն հայտնում է՝ կա՞ ավելի նոր տարբերակ
aihummer update           # ներբեռնում և կիրառում է այն

Կայունությունը պրոդուկտի սկզբունք է, ոչ թե ենթադրություն: AiHummer-ը հետևում է դրան **SemVer**, կիրառվում է **ավտոմատ կերպով անվտանգ զանգվածային տվյալների բազայի միգրացիայի առաջխաղացման համար**, և կարող է **ինքնաթարմացում** կԾԴՆ-ով — դրա համար թարմացումները սովորական են, ոչ թե ռիսկային։ ## Ավտոմատացված տարբերակավորման (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-ն և վիճակի ստուգումները](/hy/v1.0/operations/systemd-health). - Ստեղծեք նախօրոք պատճեն խոշոր թարմացմանից առաջ: [Պաշտպանիչ պատճենավորում և ձախողումների դեպքում վերականգնում](/hy/v1.0/operations/backups-dr). - Դիտեք իրականացմանը՝ [Հետևելիություն](/hy/v1.0/operations/observability).