Kubernetes-ում տեղակայվելու առաջին քայլը ձեր հավելվածը կոնտեյների մեջ դնելն է: Այս շարքում մենք կանդրադառնանք, թե ինչպես կարող եք ստեղծել փոքր, ապահով կոնտեյների պատկեր:
Docker-ի շնորհիվ կոնտեյների պատկերների ստեղծումը երբեք ավելի հեշտ չի եղել: Նշեք հիմնական պատկերը, ավելացրեք ձեր փոփոխությունները և ստեղծեք կոնտեյներ:
Թեև այս տեխնիկան հիանալի է սկսելու համար, սակայն լռելյայն բազային պատկերների օգտագործումը կարող է հանգեցնել անապահով աշխատանքի՝ լի մեծ խոցելի պատկերներով:
Բացի այդ, Docker-ի պատկերների մեծ մասը օգտագործում է Debian կամ Ubuntu հիմնական պատկերի համար, և թեև դա ապահովում է գերազանց համատեղելիություն և հեշտ հարմարեցում (Docker ֆայլը պահանջում է ընդամենը երկու տող կոդ), բազային պատկերները կարող են հարյուրավոր մեգաբայթ լրացուցիչ բեռ ավելացնել ձեր կոնտեյների վրա: Օրինակ, Go «hello-world» հավելվածի պարզ node.js ֆայլը կազմում է մոտ 700 մեգաբայթ, մինչդեռ ձեր իրական հավելվածը ընդամենը մի քանի մեգաբայթ է:
Այսպիսով, այս ամբողջ լրացուցիչ ծանրաբեռնվածությունը թվային տարածքի վատնում է և անվտանգության խոցելիության և սխալների համար հիանալի թաքստոց: Այսպիսով, եկեք դիտարկենք կոնտեյների պատկերի չափը նվազեցնելու երկու եղանակ:
Առաջինը բազային փոքր պատկերների օգտագործումն է, երկրորդը՝ Builder Pattern-ի օգտագործումը։ Ավելի փոքր հիմնական պատկերների օգտագործումը, հավանաբար, ձեր տարայի չափը նվազեցնելու ամենահեշտ ձևն է: Ամենայն հավանականությամբ, լեզուն կամ փաթեթը, որը դուք օգտագործում եք, ապահովում է հավելվածի բնօրինակ պատկեր, որը շատ ավելի փոքր է, քան լռելյայն պատկերը: Եկեք նայենք մեր node.js կոնտեյներին:
Լռելյայնորեն Docker-ում հանգույց:8 հիմնական պատկերի չափը 670 ՄԲ է, իսկ հանգույցը՝ 8-ալպիական պատկերի չափը ընդամենը 65 ՄԲ է, այսինքն՝ 10 անգամ փոքր: Օգտագործելով ավելի փոքր Alpine բազային պատկերը, դուք զգալիորեն կնվազեցնեք ձեր տարայի չափը: Alpine-ը Linux-ի փոքր և թեթև բաշխում է, որը շատ տարածված է Docker-ի օգտատերերի շրջանում, քանի որ այն համատեղելի է բազմաթիվ հավելվածների հետ՝ միաժամանակ փոքր կոնտեյներներ պահելով: Ի տարբերություն ստանդարտ Docker «հանգույցի» պատկերի՝ «node:alpine»-ը հեռացնում է բազմաթիվ սպասարկման ֆայլեր և ծրագրեր՝ թողնելով միայն դրանք, որոնք բավարար են ձեր հավելվածը գործարկելու համար:
Ավելի փոքր բազային պատկեր տեղափոխելու համար պարզապես թարմացրեք Dockerfile-ը, որպեսզի սկսեք աշխատել նոր բազային պատկերի հետ.
Այժմ, ի տարբերություն հին onbuild պատկերի, դուք պետք է պատճենեք ձեր կոդը կոնտեյների մեջ և տեղադրեք ցանկացած կախվածություն: Նոր Dockerfile-ում կոնտեյները սկսվում է node:alpine պատկերով, այնուհետև ստեղծում է տեղեկատու կոդի համար, տեղադրում է կախվածություններ՝ օգտագործելով NPM փաթեթի կառավարիչը և վերջապես գործարկում է server.js-ը:
Այս բարելավումը հանգեցնում է կոնտեյների, որը 10 անգամ փոքր է չափսերով: Եթե ձեր ծրագրավորման լեզուն կամ ստեկը չունի հիմնական պատկերի կրճատման գործառույթ, օգտագործեք Alpine Linux-ը: Այն նաև հնարավորություն կտա ամբողջությամբ կառավարել տարայի պարունակությունը: Փոքր բազային պատկերների օգտագործումը հիանալի միջոց է փոքր տարաներ արագ ստեղծելու համար: Բայց նույնիսկ ավելի մեծ կրճատում կարելի է ձեռք բերել՝ օգտագործելով Builder Pattern-ը:
Թարգմանված լեզուներում սկզբնական կոդը սկզբում փոխանցվում է թարգմանչին, այնուհետև ուղղակիորեն գործարկվում։ Կոմպիլացված լեզուներում սկզբնական կոդը սկզբում վերածվում է կոմպիլացված կոդի։ Այնուամենայնիվ, կոմպիլյացիան հաճախ օգտագործում է գործիքներ, որոնք իրականում անհրաժեշտ չեն կոդը գործարկելու համար: Սա նշանակում է, որ դուք կարող եք ամբողջությամբ հեռացնել այս գործիքները վերջնական բեռնարկղից: Դրա համար կարող եք օգտագործել Builder Pattern-ը:
Կոդը ստեղծվում է առաջին կոնտեյներով և կազմվում։ Կազմված կոդը այնուհետև փաթեթավորվում է վերջնական կոնտեյների մեջ՝ առանց այդ կոդը կազմելու համար անհրաժեշտ կոմպիլյատորների և գործիքների: Եկեք գործարկենք Go հավելված այս գործընթացով: Նախ, մենք ներկառուցված պատկերից կտեղափոխվենք Alpine Linux:
Նոր Dockerfile-ում բեռնարկղը սկսվում է golang:alpine պատկերով: Այնուհետև այն ստեղծում է գրացուցակ կոդի համար, պատճենում է այն ելակետային կոդի մեջ, կառուցում է այդ ելակետային կոդը և գործարկում հավելվածը: Այս կոնտեյները շատ ավելի փոքր է, քան onbuild կոնտեյները, բայց այն դեռ պարունակում է կոմպիլյատոր և Go գործիքներ, որոնք մեզ իրականում պետք չեն: Այսպիսով, եկեք պարզապես հանենք կազմված ծրագիրը և տեղադրենք այն իր կոնտեյներով:
Դուք կարող եք նկատել ինչ-որ տարօրինակ բան Docker ֆայլում. այն պարունակում է երկու FROM տող: Առաջին 4 տողերի բաժինը ճիշտ նույն տեսքն ունի, ինչ նախորդ Dockerfile-ը, բացառությամբ, որ այն օգտագործում է AS հիմնաբառը այս փուլը անվանելու համար: Հաջորդ բաժինն ունի նոր FROM տող՝ նոր պատկեր սկսելու համար, որտեղ golang:alpine պատկերի փոխարեն մենք կօգտագործենք Raw alpine որպես հիմնական պատկեր:
Raw Alpine Linux-ը չունի տեղադրված որևէ SSL վկայագիր, ինչը կհանգեցնի HTTPS-ով API-ի զանգերի մեծամասնության ձախողմանը, ուստի եկեք տեղադրենք արմատային CA վկայագրեր:
Այժմ գալիս է զվարճալի մասը՝ կազմված կոդը առաջին կոնտեյներից երկրորդին պատճենելու համար կարող եք պարզապես օգտագործել COPY հրամանը, որը գտնվում է երկրորդ բաժնի 5-րդ տողում։ Այն պատճենելու է միայն մեկ հավելվածի ֆայլ և չի ազդի Go օգտակար գործիքների վրա: Նոր բազմափուլ Docker ֆայլը կպարունակի կոնտեյների պատկեր, որն ունի ընդամենը 12 մեգաբայթ չափ՝ համեմատած 700 մեգաբայթ նախնական կոնտեյների պատկերի հետ, ինչը մեծ տարբերություն է:
Այսպիսով, բազային փոքր պատկերների և Builder Pattern-ի օգտագործումը հիանալի միջոց է շատ ավելի փոքր տարաներ ստեղծելու համար՝ առանց մեծ աշխատանքի:
Հնարավոր է, որ կախված հավելվածի կույտից, կան պատկերի և բեռնարկղերի չափը նվազեցնելու լրացուցիչ եղանակներ, բայց արդյոք փոքր տարաները իսկապես չափելի օգուտ ունեն: Դիտարկենք երկու ոլորտներ, որտեղ փոքր կոնտեյներները չափազանց արդյունավետ են՝ կատարում և անվտանգություն:
Արդյունավետության բարձրացումը գնահատելու համար հաշվի առեք կոնտեյների ստեղծման գործընթացի տևողությունը, այն տեղադրեք գրանցամատյանում (հրում), այնուհետև այն այնտեղից հանեք (քաշեք): Դուք կարող եք տեսնել, որ ավելի փոքր բեռնարկղը հստակ առավելություն ունի ավելի մեծ տարայի նկատմամբ:
Docker-ը կքեշավորի շերտերը, այնպես որ հետագա կառուցումները շատ արագ կլինեն: Այնուամենայնիվ, շատ CI համակարգեր, որոնք օգտագործվում են կոնտեյներներ կառուցելու և փորձարկելու համար, չեն քեշում շերտերը, ուստի ժամանակի զգալի խնայողություն կա: Ինչպես տեսնում եք, մեծ կոնտեյներ կառուցելու ժամանակը, կախված ձեր մեքենայի հզորությունից, 34-ից 54 վայրկյան է, իսկ կոնտեյներ օգտագործելու դեպքում կրճատվում է Builder Pattern-ի միջոցով՝ 23-ից 28 վայրկյան: Այս տեսակի գործառնությունների դեպքում արտադրողականության աճը կկազմի 40-50%: Այսպիսով, պարզապես մտածեք, թե քանի անգամ եք կառուցում և փորձարկում ձեր կոդը:
Կոնտեյների կառուցումից հետո դուք պետք է դրեք դրա պատկերը (հրում կոնտեյների պատկեր) կոնտեյների ռեեստր, որպեսզի այնուհետև կարողանաք օգտագործել այն ձեր Kubernetes կլաստերում: Ես խորհուրդ եմ տալիս օգտագործել Google Container Registry-ը:
Google Container Registry-ի (GCR) միջոցով դուք վճարում եք միայն չմշակված պահեստավորման և ցանցի համար, և բեռնարկղերի կառավարման լրացուցիչ վճարներ չկան: Այն մասնավոր է, ապահով և շատ արագ: GCR-ն օգտագործում է բազմաթիվ հնարքներ՝ արագացնելու ձգման գործողությունը: Ինչպես տեսնում եք, go:onbuild-ի միջոցով Docker Container Image կոնտեյների տեղադրումը կտևի 15-ից 48 վայրկյան՝ կախված համակարգչի աշխատանքից, իսկ ավելի փոքր կոնտեյներով նույն գործողությունը կտևի 14-ից 16 վայրկյան, իսկ ավելի քիչ արտադրողական մեքենաների համար: շահագործման արագության մեջ առավելությունն ավելանում է 3 անգամ։ Ավելի մեծ մեքենաների համար ժամանակը մոտավորապես նույնն է, քանի որ GCR-ն օգտագործում է գլոբալ քեշ՝ պատկերների ընդհանուր տվյալների բազայի համար, ինչը նշանակում է, որ դուք ընդհանրապես պետք չէ դրանք բեռնել: Ցածր էներգիայի համակարգչում պրոցեսորը խցանման խնդիր է, ուստի փոքր կոնտեյներների օգտագործման առավելությունն այստեղ շատ ավելի մեծ է:
Եթե դուք օգտագործում եք GCR, ես խորհուրդ եմ տալիս օգտագործել Google Container Builder (GCB) որպես ձեր կառուցման համակարգի մաս:
Ինչպես տեսնում եք, դրա օգտագործումը թույլ է տալիս շատ ավելի լավ արդյունքների հասնել Build+Push գործողության տևողության կրճատման հարցում, քան նույնիսկ արտադրողական մեքենան. . Բացի այդ, դուք ամեն օր ստանում եք 2 անվճար շինարարական րոպե, որը շատ դեպքերում ծածկում է ձեր կոնտեյներների կառուցման կարիքները:
Հաջորդը գալիս է կատարողականի ամենակարևոր չափանիշը՝ բեռնարկղերի առբերման կամ ներբեռնման արագությունը: Եվ եթե ձեզ շատ չի հետաքրքրում հրում գործողության վրա ծախսված ժամանակը, ապա ձգման գործընթացի երկարությունը լուրջ ազդեցություն է ունենում համակարգի ընդհանուր աշխատանքի վրա: Ենթադրենք, դուք ունեք երեք հանգույցներից բաղկացած կլաստեր, և դրանցից մեկը ձախողվում է: Եթե դուք օգտագործում եք կառավարման համակարգ, ինչպիսին է Google Kubernetes Engine-ը, այն ավտոմատ կերպով կփոխարինի մեռած հանգույցը նորով: Այնուամենայնիվ, այս նոր հանգույցը լիովին դատարկ կլինի, և դուք պետք է քաշեք ձեր բոլոր բեռնարկղերը դրա մեջ, որպեսզի այն սկսի աշխատել: Եթե ձգման գործողությունը բավական երկար տևի, ձեր կլաստերը ամբողջ ժամանակ կաշխատի ավելի ցածր կատարողականությամբ:
Կան բազմաթիվ դեպքեր, երբ դա կարող է տեղի ունենալ՝ կլաստերի մեջ նոր հանգույց ավելացնելը, հանգույցների արդիականացումը կամ նույնիսկ տեղակայման համար նոր կոնտեյների անցնելը: Այսպիսով, ձգման արդյունահանման ժամանակը նվազագույնի հասցնելը դառնում է առանցքային գործոն: Անհերքելի է, որ փոքր կոնտեյները ներբեռնվում է շատ ավելի արագ, քան մեծը: Եթե դուք մի քանի կոնտեյներ եք աշխատում Kubernetes կլաստերում, ժամանակի խնայողությունը կարող է նշանակալի լինել:
Նայեք այս համեմատությանը. փոքր բեռնարկղերի վրա ձգվող գործողությունը 4-9 անգամ ավելի քիչ ժամանակ է պահանջում՝ կախված մեքենայի հզորությունից, քան նույն գործողությունը go:onbuild-ի միջոցով: Համօգտագործվող, փոքր կոնտեյների հիմքի պատկերների օգտագործումը զգալիորեն արագացնում է այն ժամանակը և արագությունը, որով նոր Kubernetes հանգույցները կարող են տեղակայվել և հայտնվել առցանց:
Եկեք նայենք անվտանգության խնդրին։ Փոքր բեռնարկղերը համարվում են շատ ավելի անվտանգ, քան ավելի մեծերը, քանի որ նրանք ունեն ավելի փոքր հարձակման մակերես: Իսկապե՞ս։ Google Container Registry-ի ամենաօգտակար գործառույթներից մեկը ձեր բեռնարկղերի խոցելիության համար ավտոմատ կերպով սկանավորելու հնարավորությունն է: Մի քանի ամիս առաջ ես ստեղծեցի ինչպես onbuild, այնպես էլ բազմաստիճան կոնտեյներներ, այնպես որ եկեք տեսնենք, արդյոք այնտեղ խոցելիություններ կան:
Արդյունքը ապշեցուցիչ է. փոքր տարայի մեջ հայտնաբերվել է ընդամենը 3 միջին խոցելիություն, իսկ մեծ տարայի մեջ՝ 16 կրիտիկական և 376 այլ խոցելիություն։ Եթե նայենք մեծ կոնտեյների պարունակությանը, ապա կտեսնենք, որ անվտանգության խնդիրների մեծ մասը կապ չունեն մեր հավելվածի հետ, այլ կապված են ծրագրերի հետ, որոնք մենք նույնիսկ չենք օգտագործում։ Այսպիսով, երբ մարդիկ խոսում են հարձակման մեծ մակերեսի մասին, դա նկատի ունեն:
Խնդիրը պարզ է. կառուցեք փոքր կոնտեյներներ, քանի որ դրանք ապահովում են իրական արդյունավետություն և անվտանգության առավելություններ ձեր համակարգի համար:
Մի քանի գովազդ 🙂
Շնորհակալություն մեզ հետ մնալու համար: Ձեզ դուր են գալիս մեր հոդվածները: Ցանկանու՞մ եք տեսնել ավելի հետաքրքիր բովանդակություն: Աջակցեք մեզ՝ պատվիրելով կամ խորհուրդ տալով ընկերներին, , մուտքի մակարդակի սերվերների եզակի անալոգ, որը հորինվել է մեր կողմից ձեզ համար. (հասանելի է RAID1 և RAID10-ով, մինչև 24 միջուկով և մինչև 40 ԳԲ DDR4):
Dell R730xd 2 անգամ ավելի էժան Ամստերդամի Equinix Tier IV տվյալների կենտրոնում: Միայն այստեղ Նիդեռլանդներում! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99-ից: Կարդացեք մասին
Source: www.habr.com