Սա Red Hat OpenShift 4.0 պլատֆորմի առաջիկա թարմացման փոփոխությունների, բարելավումների և հավելումների մասին գրառումների շարքից առաջինն է, որը կօգնի ձեզ նախապատրաստվել նոր տարբերակին անցմանը:
Այն պահից, երբ նորաստեղծ Kubernetes համայնքը առաջին անգամ հավաքվեց Google-ի Սիեթլի գրասենյակում 2014 թվականի աշնանը, պարզ էր, որ Kubernetes նախագիծը վիճակված էր հեղափոխություն կատարել ծրագրային ապահովման մշակման և տարածման այսօր: Միևնույն ժամանակ, հանրային ամպային ծառայություններ մատուցողները շարունակեցին ակտիվորեն ներդրումներ կատարել ենթակառուցվածքների և ծառայությունների զարգացման մեջ, ինչը շատ ավելի դյուրին և մատչելի դարձրեց ՏՏ-ի հետ աշխատելը և ծրագրային ապահովման ստեղծումը և դարձրեց դրանք անհավանական հասանելի, ինչը քչերը կարող էին պատկերացնել սկզբում: տասնամյակը։
Իհարկե, յուրաքանչյուր նոր ամպային ծառայության հայտարարությունը ուղեկցվում էր բազմաթիվ քննարկումներով փորձագետների միջև Twitter-ում, և բանավեճեր անցկացվեցին տարբեր թեմաների շուրջ՝ ներառյալ բաց կոդով դարաշրջանի ավարտը, ներտնային ՏՏ անկումը և անխուսափելիությունը: ամպի մեջ ծրագրային ապահովման նոր մենաշնորհի մասին, և ինչպես է X նոր պարադիգմը փոխարինելու բոլոր մյուս պարադիգմներին:
Ավելորդ է ասել, որ այս բոլոր վեճերը շատ հիմար էին
Իրականությունն այն է, որ ոչինչ չի անհետանա, և այսօր մենք կարող ենք տեսնել վերջնական արտադրանքի և դրանց մշակման էքսպոնենցիալ աճ՝ պայմանավորված մեր կյանքում նոր ծրագրային ապահովման անընդհատ ի հայտ գալուց: Եվ չնայած այն հանգամանքին, որ շրջապատում ամեն ինչ փոխվելու է, միեւնույն ժամանակ, ըստ էության, ամեն ինչ կմնա անփոփոխ։ Ծրագրային ապահովման մշակողները դեռ կգրեն սխալներով կոդ, գործառնությունների ինժեներները և հուսալիության մասնագետները դեռ կշրջեն փեյջերներով և կստանան ավտոմատ ծանուցումներ Slack-ում, մենեջերները դեռ կգործեն OpEx-ի և CapEx-ի առումով, և ամեն անգամ, երբ ձախողում է տեղի ունենում, ծրագրավորող ավագը տխուր հառաչիր «ես քեզ այդպես ասացի» բառերով...
Օ, իսկապես պետք է քննարկվի, այն է, թե ինչ գործիքներ կարող ենք ունենալ մեր տրամադրության տակ՝ ավելի լավ ծրագրային արտադրանք ստեղծելու համար, և ինչպես դրանք կարող են բարելավել անվտանգությունը և զարգացումն ավելի հեշտ և հուսալի դարձնել: Քանի որ նախագծերը դառնում են ավելի բարդ, նոր ռիսկեր են առաջանում, և այսօր մարդկանց կյանքն այնքան կախված է ծրագրաշարից, որ մշակողները պարզապես պետք է փորձեն ավելի լավ կատարել իրենց աշխատանքը:
Kubernetes-ը նման գործիքներից մեկն է: Աշխատանքներ են տարվում Red Hat OpenShift-ի հետ համատեղելու այլ գործիքների և ծառայությունների մեկ հարթակ, որը կդարձնի ծրագրակազմն ավելի հուսալի, ավելի հեշտ կառավարվող և ավելի անվտանգ օգտվողների համար:
Այս ասելով, OpenShift թիմը տալիս է մեկ պարզ հարց.
Ինչպե՞ս կարող եք ավելի հեշտ և հարմարավետ դարձնել Kubernetes-ի հետ աշխատանքը:
Պատասխանը զարմանալիորեն ակնհայտ է.
- ավտոմատացնել ամպի վրա կամ ամպից դուրս տեղակայման բարդ ասպեկտները.
- կենտրոնանալ հուսալիության վրա՝ թաքցնելով բարդությունը.
- շարունակել շարունակաբար աշխատել պարզ և անվտանգ թարմացումները թողարկելու համար.
- հասնել վերահսկելիության և աուդիտի հնարավորության;
- ձգտել ի սկզբանե ապահովել բարձր անվտանգություն, բայց ոչ օգտագործելիության հաշվին:
OpenShift-ի հաջորդ թողարկումը պետք է հաշվի առնի ինչպես ստեղծողների, այնպես էլ այլ մշակողների փորձը, ովքեր մեծ մասշտաբով ծրագրային ապահովում են ներդնում աշխարհի խոշորագույն ընկերություններում: Բացի այդ, այն պետք է հաշվի առնի բաց էկոհամակարգերի ամբողջ կուտակված փորձը, որն այսօր ընկած է ժամանակակից աշխարհի հիմքում: Միաժամանակ անհրաժեշտ է հրաժարվել սիրողական ծրագրավորողի հին մտածելակերպից և անցնել ավտոմատացված ապագայի նոր փիլիսոփայության։ Այն պետք է կամրջի ծրագրային ապահովման տեղակայման հին և նոր եղանակների միջև եղած բացը և լիովին օգտվի բոլոր հասանելի ենթակառուցվածքներից՝ անկախ նրանից՝ այն հյուրընկալված է ամենամեծ ամպային մատակարարի կողմից, թե աշխատում է ծայրամասային փոքր համակարգերի վրա:
Ինչպե՞ս հասնել այս արդյունքին:
Red Hat-ում ընդունված է երկար ժամանակ ձանձրալի և անշնորհակալ աշխատանք կատարել՝ ստեղծված համայնքը պահպանելու և նախագծերի փակումը կանխելու համար, որոնցում ներգրավված է ընկերությունը։ Բաց կոդով համայնքը պարունակում է մեծ թվով տաղանդավոր ծրագրավորողներ, ովքեր ստեղծում են ամենաարտասովոր բաները՝ զվարճալի, կրթական, նոր հնարավորություններ բացող և պարզապես գեղեցիկ, բայց, իհարկե, ոչ ոք չի ակնկալում, որ բոլորը շարժվեն նույն ուղղությամբ կամ հետապնդեն ընդհանուր նպատակներ: . Այս էներգիան օգտագործելը և ճիշտ ուղղությամբ ուղղորդելը երբեմն անհրաժեշտ է զարգացնելու ոլորտներ, որոնք օգուտ կբերեն մեր օգտատերերին, բայց միևնույն ժամանակ մենք պետք է հետևենք մեր համայնքների զարգացմանը և սովորենք դրանցից:
2018 թվականի սկզբին Red Hat-ը ձեռք բերեց CoreOS նախագիծը, որն ուներ ապագայի վերաբերյալ նմանատիպ տեսակետներ՝ ավելի անվտանգ և հուսալի, ստեղծված բաց կոդով սկզբունքներով: Ընկերությունն աշխատել է այս գաղափարների հետագա զարգացման և դրանք կյանքի կոչելու ուղղությամբ՝ գործնականում կիրառելով մեր փիլիսոփայությունը՝ փորձելով ապահովել, որ բոլոր ծրագրակազմն ապահով աշխատի: Այս ամբողջ աշխատանքը կառուցված է Kubernetes-ի, Linux-ի, հանրային ամպերի, մասնավոր ամպերի և հազարավոր այլ նախագծերի վրա, որոնք հիմնված են մեր ժամանակակից թվային էկոհամակարգի վրա:
OpenShift 4-ի նոր թողարկումը կլինի պարզ, ավտոմատացված և ավելի բնական
OpenShift պլատֆորմը կաշխատի Linux-ի լավագույն և ամենահուսալի օպերացիոն համակարգերի հետ՝ բաց մետաղական ապարատային աջակցությամբ, հարմար վիրտուալիզացիայի, ավտոմատ ենթակառուցվածքի ծրագրավորման և, իհարկե, կոնտեյներների (որոնք, ըստ էության, պարզապես Linux-ի պատկերներ են):
Պլատֆորմը պետք է ապահով լինի ի սկզբանե, բայց դեռևս թույլ է տալիս ծրագրավորողներին հեշտությամբ կրկնել, այսինքն՝ լինել բավականաչափ ճկուն և ապահով՝ միաժամանակ թույլ տալով ադմինիստրատորներին հեշտությամբ ստուգել և կառավարել այն:
Այն պետք է թույլ տա ծրագրային ապահովումը գործարկել «որպես ծառայություն» և չհանգեցնի օպերատորների համար անկառավարելի ենթակառուցվածքի աճին:
Այն թույլ կտա ծրագրավորողներին կենտրոնանալ օգտատերերի և հաճախորդների համար իրական արտադրանք ստեղծելու վրա: Դուք ստիպված չեք լինի անցնել ապարատային և ծրագրային ապահովման կարգավորումների ջունգլիներում, և բոլոր պատահական բարդությունները կմնան անցյալում:
OpenShift 4. NoOps հարթակ, որը չի պահանջում սպասարկում
В նկարագրեց այն առաջադրանքները, որոնք օգնեցին ձևավորել ընկերության տեսլականը OpenShift 4-ի համար: Թիմի նպատակն է հնարավորինս պարզեցնել ծրագրային ապահովման գործարկման և պահպանման ամենօրյա խնդիրները, որպեսզի այդ գործընթացները դյուրին և անկաշկանդ լինեն՝ ինչպես ներդրման մեջ ներգրավված մասնագետների, այնպես էլ մշակողների համար: Բայց ինչպե՞ս կարող եք ավելի մոտենալ այս նպատակին: Ինչպե՞ս ստեղծել հարթակ ծրագրային ապահովման գործարկման համար, որը պահանջում է նվազագույն միջամտություն: Ի՞նչ է նույնիսկ նշանակում NoOps-ը այս համատեքստում:
Եթե փորձում եք վերացական անել, ապա մշակողների համար «առանց սերվերի» կամ «NoOps» հասկացությունները նշանակում են գործիքներ և ծառայություններ, որոնք թույլ են տալիս թաքցնել «գործառնական» բաղադրիչը կամ նվազագույնի հասցնել այս բեռը մշակողի համար:
- Աշխատեք ոչ թե համակարգերի, այլ կիրառական միջերեսների (API-ների) հետ:
- Մի անհանգստացեք ծրագրային ապահովման ներդրման համար. թույլ տվեք մատակարարին դա անել ձեր փոխարեն:
- Դուք չպետք է անմիջապես ցատկեք մեծ շրջանակ ստեղծելու վրա. սկսեք գրել փոքր կտորներ, որոնք կգործեն որպես «շինանյութ», փորձեք այնպես անել, որ այս կոդը աշխատի տվյալների և իրադարձությունների, այլ ոչ թե սկավառակների և տվյալների բազաների հետ:
Նպատակը, ինչպես նախկինում, ծրագրային ապահովման մշակման մեջ կրկնություններն արագացնելն է, ավելի լավ ապրանքներ ստեղծելու հնարավորությունը, և այնպես, որ մշակողը ստիպված չլինի անհանգստանալ այն համակարգերի մասին, որոնց վրա աշխատում է իր ծրագրաշարը: Փորձառու ծրագրավորողը քաջ գիտակցում է, որ օգտատերերի վրա կենտրոնանալը կարող է արագ փոխել պատկերը, այնպես որ դուք չպետք է շատ ջանք գործադրեք ծրագրակազմ գրելու համար, քանի դեռ լիովին համոզված չեք, որ դրա անհրաժեշտությունը կա:
Սպասարկման և շահագործման մասնագետների համար «NoOps» բառը կարող է մի փոքր սարսափելի հնչել: Բայց դաշտային ինժեներների հետ շփվելիս ակնհայտ է դառնում, որ օրինաչափությունները և մեթոդները, որոնք նրանք օգտագործում են՝ ուղղված հուսալիության և հուսալիության ապահովմանը (Site Reliability Engineering, SRE) շատ նմանություններ ունեն վերը նկարագրված օրինաչափությունների հետ.
- Մի կառավարեք համակարգերը. ավտոմատացրեք դրանց կառավարման գործընթացները:
- Մի կիրառեք ծրագրակազմ, ստեղծեք խողովակաշար այն տեղակայելու համար:
- Խուսափեք ձեր բոլոր ծառայությունները միասին միավորելուց և թույլ տալ, որ մեկի ձախողումը պատճառ դառնա ամբողջ համակարգի ձախողման. դրանք ցրե՛ք ձեր ամբողջ ենթակառուցվածքում՝ օգտագործելով ավտոմատացման գործիքներ, և միացրեք դրանք վերահսկելի և վերահսկվող եղանակներով:
SRE-ները գիտեն, որ ինչ-որ բան կարող է սխալ լինել, և նրանք պետք է հետագծեն և շտկեն խնդիրը, ուստի նրանք ավտոմատացնում են սովորական աշխատանքը և նախօրոք սահմանում սխալների բյուջեները, որպեսզի պատրաստ լինեն առաջնահերթություն տալ և որոշումներ կայացնել, երբ խնդիր առաջանա:
Kubernetes-ը OpenShift-ում հարթակ է, որը նախատեսված է երկու հիմնական խնդիր լուծելու համար. փոխանակ ստիպելու ձեզ հասկանալ վիրտուալ մեքենաները կամ բեռների հավասարակշռող API-ները, այն աշխատում է ավելի բարձր կարգի աբստրակցիաների՝ տեղակայման գործընթացների և ծառայությունների հետ: Ծրագրային գործակալներ տեղադրելու փոխարեն, դուք կարող եք գործարկել կոնտեյներներ և ձեր սեփական մոնիտորինգի փաթեթը գրելու փոխարեն օգտագործել հարթակում արդեն հասանելի գործիքները: Այսպիսով, OpenShift 4-ի գաղտնի սոուսը իսկապես գաղտնիք չէ. պարզապես պետք է վերցնել SRE սկզբունքները և առանց սերվերի հայեցակարգերը և հասցնել դրանք իրենց տրամաբանական ավարտին՝ օգնելու մշակողներին և գործառնական ինժեներներին.
- Ավտոմատացնել և ստանդարտացնել ենթակառուցվածքը, որն օգտագործում են հավելվածները
- Միացրեք տեղակայման և զարգացման գործընթացները՝ առանց սահմանափակելու իրենց մշակողներին
- Ապահովել, որ XNUMX-րդ ծառայության, հատկանիշի, հավելվածի կամ ամբողջ փաթեթի գործարկումը, աուդիտը և ապահովումը ավելի դժվար չէ, քան առաջինը:
Բայց ո՞րն է տարբերությունը OpenShift 4 պլատֆորմի և նրա նախորդների միջև և նման խնդիրների լուծման «ստանդարտ» մոտեցման միջև: Ի՞նչն է խթանում սանդղակը իրականացման և գործառնական թիմերի համար: Պայմանավորված է նրանով, որ թագավորն այս իրավիճակում կլաստերն է։ Այսպիսով,
- Մենք համոզվում ենք, որ կլաստերների նպատակը պարզ է (Սիրելի ամպ, ես վերցրեցի այս կլաստերը, քանի որ կարող էի)
- Մեքենաներ և օպերացիոն համակարգեր գոյություն ունեն կլաստերին ծառայելու համար (Ձերդ Մեծություն)
- Կառավարեք հյուրընկալողների վիճակը կլաստերից, նվազագույնի հասցրեք դրանց վերակառուցումը (դրեյֆը):
- Համակարգի յուրաքանչյուր կարևոր տարրի համար անհրաժեշտ է դայակ (մեխանիզմ), որը կվերահսկի և կվերացնի խնդիրները
- Համակարգի *յուրաքանչյուր* ասպեկտի կամ տարրի ձախողումը և դրա հետ կապված վերականգնման մեխանիզմները կյանքի նորմալ մասն են
- Ամբողջ ենթակառուցվածքը պետք է կազմաձևվի API-ի միջոցով:
- Kubernetes-ը գործարկելու համար օգտագործեք Kubernetes-ը: (Այո, այո, դա տառասխալ չէ)
- Թարմացումները պետք է լինեն հեշտ և առանց դժվարությունների տեղադրման համար: Եթե թարմացումը տեղադրելու համար պահանջվում է մեկից ավելի սեղմում, ապա ակնհայտ է, որ մենք ինչ-որ բան սխալ ենք անում:
- Ցանկացած բաղադրիչի մոնիտորինգը և վրիպազերծումը չպետք է խնդիր լինի, և հետևաբար ամբողջ ենթակառուցվածքում հետևելը և հաշվետվությունը պետք է լինի նաև հեշտ և հարմար:
Ցանկանու՞մ եք տեսնել հարթակի հնարավորությունները գործողության մեջ:
OpenShift 4-ի նախադիտման տարբերակը հասանելի է դարձել մշակողների համար: Հեշտ օգտագործվող տեղադրողի օգնությամբ դուք կարող եք AWS-ի կլաստեր գործարկել Red Had CoreOS-ի վերևում: Նախադիտումն օգտագործելու համար ձեզ միայն անհրաժեշտ է AWS հաշիվ՝ ենթակառուցվածքն ապահովելու համար և մի շարք հաշիվներ՝ նախադիտման պատկերները մուտք գործելու համար:
- Սկսելու համար գնացեք և սեղմեք «Սկսել»:
- Մուտք գործեք ձեր Red Hat հաշիվ (կամ ստեղծեք նորը) և հետևեք հրահանգներին՝ կարգավորելու ձեր առաջին կլաստերը:
Հաջող տեղադրումից հետո ստուգեք մեր ձեռնարկները ավելի խորը պատկերացում կազմելու համակարգերի և հասկացությունների մասին, որոնք OpenShift 4 պլատֆորմը դարձնում են Kubernetes-ի գործարկման այդքան հեշտ և հարմար միջոց:
Փորձեք OpenShift-ի նոր թողարկումը և կիսվեք ձեր կարծիքով: Մենք հավատարիմ ենք Kumbernetes-ի հետ աշխատանքը հնարավորինս մատչելի և հեշտ դարձնելուն. NoOps-ի ապագան սկսվում է այսօր:
Հիմա ուշադրություն!
Գիտաժողովում Ապրիլի 20-ին OpenShift-ի ծրագրավորողներից մեկը՝ Վադիմ Ռուտկովսկին, վարպետության դաս կանցկացնի՝ նա կկոտրի տասը կլաստերներ և կստիպի շտկել դրանք։ Կոնֆերանսը վճարովի է, սակայն #RedHat գովազդային կոդով դուք ստանում եք 37% զեղչ
Վարպետության դաս 17:15 - 18:15, իսկ ստենդը բաց է ամբողջ օրը։ Շապիկներ, գլխարկներ, կպչուն պիտակներ - սովորական:
Դահլիճ թիվ 2
«Այստեղ ամբողջ համակարգը պետք է փոխվի. մենք վերանորոգում ենք կոտրված k8 կլաստերները՝ հավաստագրված մեխանիկայի հետ միասին»:
Source: www.habr.com