Docker Cloud Sandboxes-ը գործակալին ամպ է տանում՝ նոութբուքը կարող է քնել

Docker-ը 2026 թվականի սեպտեմբերի 24-ի հայտարարությամբ հասանելի դարձրեց Docker Cloud Sandboxes-ը WeAreDevelopers North America միջոցառման ընթացքում։ Ծառայությունը կոդավորման գործակալին աշխատեցնում է Docker-ի կառավարվող ամպում՝ տեղային Docker Sandboxes-ի microVM մեկուսացման մոդելով։ Երկարատև առաջադրանքը կարող է շարունակվել նաև այն ժամանակ, երբ մշակողը փակում կամ անջատում է նոութբուքը, քանի որ հաշվարկն այլևս այդ սարքից կախված չէ։

Նույն օրվա ցուցադրությունը շոշափելի դարձրեց մեկուսացման հարցը։ The Register-ի ռեպորտաժում նկարագրված փորձի ժամանակ սովորական container-ում աշխատող Claude-ը գտել է համակարգչում պահված գաղտնիքը՝ օգտվելով container-ին միացված host-ի Docker socket-ից, իսկ նույն հանձնարարությունը տեղային sandbox-ում չի հաջողվել. Docker-ի ինժեներ Մայքլ Իրվինը արդյունքը ձևակերպել է «The isolation holds» բառերով։ Սա կոնկրետ ցուցադրության արդյունք է, ոչ բոլոր կարգավորումների անվտանգության չափում։

Ինչ է իրականում տեղափոխվում նոութբուքից ամպ

Տեղային sandbox-ը հարմար է այն պահին, երբ մշակողն աշխատում է նախագծի կողքին և ուզում է արագ տեսնել փոփոխությունը։ Ամպային տարբերակը նույն աշխատանքը տեղափոխում է Docker-ի հաշվարկային միջավայր, որտեղ գործակալը կարող է շարունակել առաջադրանքը առանց նոութբուքի միացված մնալու։ Սա հատկապես վերաբերում է երկարատև վերակառուցմանը, կախվածությունների թարմացմանը կամ թեստերի գործարկմանը, որոնց ավարտին պետք է վերադառնալ ավելի ուշ։

Գործող sandbox-ի համար հրապարակված հրամանը sbx move my-project --to cloud է. այն վերցնում է միջավայրի ֆայլային համակարգի վիճակը և նոր sandbox է ստեղծում ամպում։ Տեղափոխությունը հնարավոր է նաև հակառակ ուղղությամբ, իսկ նոր ամպային sandbox կարելի է ստեղծել անմիջապես հրամանի տողից կամ վեբ վահանակից։ Այս մեխանիզմը պահպանում է աշխատանքի ֆայլերը, սակայն այն չպետք է հասկանալ որպես աշխատող գործընթացի կամ հիշողության անընդհատ փոխանցում. գործակալը գործարկվում է մյուս միջավայրում։

Տեղային և ամպային միջավայրերում կիրառվում են նույն տեսակի մեկուսացումն ու կառավարման գործիքները, բայց դրանց ռեսուրսները տարբեր տեղերում են։ Տեղային գործարկման ժամանակ առաջադրանքը զբաղեցնում է մշակողի սարքը. ամպայինում հաշվարկը կատարվում է Docker-ի ենթակառուցվածքում և կարող է շարունակվել, երբ սարքը քնի կամ ցանցից անջատվի։ Նոր ամպային միջավայրի ընտրությունն էլ թույլ է տալիս առաջադրանքը սկսել անմիջապես այնտեղ՝ առանց նախապես տեղային sandbox ստեղծելու։

Ինչու microVM-ը չի փոխարինում թույլտվություններին

Ցուցադրության մեջ վճռորոշը socket-ի գտնվելու վայրն էր։ Սովորական container-ին տրամադրված host-ի Docker socket-ը գործակալին տվել էր ճանապարհ դեպի host-ի ռեսուրսները. sandbox-ի ներսում գտնված socket-ը նույն մուտքը չէր տվել։ MicroVM-ը մեկուսացնում է գործակալի գործարկման միջավայրը, այդ թվում նրա Docker daemon-ը, համակարգչի հիմնական միջավայրից։ Այդ պատճառով sandbox-ի ներսում Docker-ի առկայությունն ինքնին չի նշանակում, թե գործակալը կարող է կառավարել host-ի Docker-ը։

Այդ պատնեշը վերաբերում է գործարկման միջավայրին, իսկ արտաքին ծառայություններին հասանելիությունը որոշվում է առանձին։ Եթե գործակալին թույլատրվում է դիմել լայն շրջանակի հասցեների, նա կարող է օգտագործել հենց այդ թույլտվությունը՝ անկախ microVM-ի առկայությունից։ Նույն տրամաբանությամբ, լայն իրավունքներով տրամադրված API բանալին շարունակում է լայն իրավունքներ տալ. մեկուսացումը դրա իրավասությունը չի փոքրացնում։

Cloud Sandboxes-ում հնարավոր է սահմանել ցանցային վերջնակետերի քաղաքականություն, իսկ գաղտնիքները փոխանցել հարցման պահին proxy-ի միջոցով, որպեսզի գործակալը չտեսնի բանալու իրական արժեքը։ Դա նվազեցնում է բանալու ուղղակի արտահոսքի հնարավորությունը գործակալի միջավայրից, բայց թույլատրված հարցումը դեռ կարող է հասնել արտաքին ծառայությանը։ Ուստի թիմի վերահսկողության առարկաները տարբեր են՝ որտեղ է աշխատում գործակալը, որ հասցեներին է դիմում և ինչ գործողություն է թույլ տալիս նրա օգտագործած բանալին։

Տեղային և ամպային sandbox-ները գաղտնիքները, ձևանմուշներն ու ցանցային քաղաքականությունները պահում են առանձին։ Ֆայլային համակարգի տեղափոխումը, հետևաբար, ինքնաբերաբար չի փոխանցում տեղային միջավայրում սահմանված մուտքի կանոնները կամ պահված գաղտնիքները։ Սա նաև բացատրում է, թե ինչու նույն նախագծի ամպային գործարկումը կարող է այլ կերպ հասնել ռեպոզիտորիային կամ արտաքին API-ին, եթե այնտեղի թույլտվությունները այլ են։

Որքան է արժենում երկարատև գործարկումը

Հաշվարկային ժամանակը չափվում է վայրկյաններով, իսկ չափերի սակագները հրապարակված են ժամային համարժեքով։ Docker-ի գործարկման սակագներով Micro միջավայրը՝ 1 vCPU և 2 GiB հիշողություն, արժե ժամում $0.07, իսկ լռելյայն Small-ը՝ 2 vCPU և 4 GiB հիշողություն, ժամում $0.14։ Այս տարբերությունը կարևոր է, երբ գիշերային առաջադրանքի համար ընտրվում է ռեսուրսի չափը. վայրկյանային հաշվարկը չի նշանակում, թե երկար աշխատող գործակալը վճար չունի։

Դադարեցված sandbox-ի հաշվարկային վճարը զրո է, և հրապարակված պայմաններով ծավալների ու ելքային տրաֆիկի համար առանձին գանձում չկա։ Մեկ գործարկման լռելյայն տևողությունը մեկ ժամ է, առավելագույնը՝ 24 ժամ։ Այդ սահմանը վերաբերում է sandbox-ի նստաշրջանին, ուստի երկար առաջադրանքի ծրագրման ժամանակ կարևոր է ոչ միայն մեքենայի չափը, այլև միջավայրի գործողության ժամկետը։

Մոդելի հաշվարկը առանձին ծախս է, եթե թիմը գործակալին միացնում է իր մատակարարի բանալիով։ Ամպային sandbox-ի սակագինը նկարագրում է Docker-ի հաշվարկային ռեսուրսը, ոչ մոդելի մատակարարի հաշիվը. երկու վճարները նույնացնելը կարող է սխալ պատկեր տալ առաջադրանքի արժեքի մասին։ Գործարկման պահին նոր հաշիվների համար առաջարկվել էր նաև սահմանափակ ժամկետով $250 ամպային վարկ, որի պայմանները պետք է դիտարկել որպես ժամանակավոր առաջարկ։

Փոքր փորձարկումը ցույց է տալիս նաև մուտքի սահմանը

Հայաստանի ծրագրային թիմի համար համեմատելի փորձը կարող է սկսվել ոչ զգայուն փորձնական նախագծից և հստակ սահմանված կոդային փոփոխությունից։ Գործակալը կարող է սկսել տեղային sandbox-ում, հետո ֆայլային վիճակը տեղափոխվել ամպ, որտեղ նույն նախագծի աշխատանքը կշարունակվի փակված նոութբուքից անկախ։ Սա առաջարկվող փորձի սցենար է, ոչ հրապարակված benchmark կամ արդեն ստացված արագության արդյունք։

Նույն փորձի ընթացքում ամպային միջավայրին կարելի է տալ միայն առաջադրանքի համար անհրաժեշտ հասցեներն ու նվազագույն իրավունքներով փորձնական մուտքի տվյալները։ Այդպես հնարավոր է առանձին տեսնել ֆայլերի տեղափոխումը, գործարկման փաստացի տևողությունը և այն գործողությունները, որոնք թույլ է տալիս ամպային քաղաքականությունը։ Եթե նախագիծն ունի արտաքին API-ի կամ մասնավոր ռեպոզիտորիայի կարիք, ամենակարևոր տարբերությունը կերևա հենց այդ մուտքերում. գործակալը կաշխատի հեռու նոութբուքից, բայց միայն այն իրավունքներով, որոնք սահմանված են ամպային sandbox-ի համար։