Ի՞նչ նորություն կա Red Hat OpenShift 4.2 և 4.3-ում:

OpenShift-ի չորրորդ տարբերակը թողարկվել է համեմատաբար վերջերս: Ներկայիս 4.3 տարբերակը հասանելի է հունվարի վերջից, և դրանում կատարված բոլոր փոփոխությունները կա՛մ բոլորովին նոր բան են, որը երրորդ տարբերակում չի եղել, կա՛մ 4.1 տարբերակում հայտնվածի հիմնական թարմացում: Այն ամենը, ինչ մենք հիմա ձեզ կասենք, պետք է իմանան, հասկանան և հաշվի առնվեն նրանք, ովքեր աշխատում են OpenShift-ի հետ և նախատեսում են անցնել նոր տարբերակի:

OpenShift 4.2-ի թողարկմամբ Red Hat-ը հեշտացրել է Kubernetes-ի հետ աշխատանքը: Նոր գործիքներ և պլագիններ են հայտնվել կոնտեյներների, CI/CD խողովակաշարերի և առանց սերվերի տեղակայման համար: Նորարարությունները ծրագրավորողներին հնարավորություն են տալիս կենտրոնանալ կոդ գրելու, այլ ոչ թե Kubernetes-ի հետ գործ ունենալու վրա։

Փաստորեն, ի՞նչ նորություն կա OpenShift 4.2 և 4.3 տարբերակներում:

Շարժվելով դեպի հիբրիդային ամպեր

Նոր ՏՏ ենթակառուցվածք պլանավորելիս կամ գոյություն ունեցող ՏՏ լանդշաֆտը մշակելիս ընկերություններն ավելի ու ավելի են դիտարկում ՏՏ ռեսուրսների տրամադրման ամպային մոտեցումը, որի համար նրանք իրականացնում են մասնավոր ամպային լուծումներ կամ օգտագործում են հանրային ամպային մատակարարների ուժը: Այսպիսով, ժամանակակից ՏՏ ենթակառուցվածքներն ավելի ու ավելի են կառուցվում «հիբրիդային» ամպային մոդելի համաձայն, երբ օգտագործվում են ինչպես ներքին ռեսուրսները, այնպես էլ հանրային ամպային ռեսուրսները՝ ընդհանուր կառավարման համակարգով: Red Hat OpenShift 4.2-ը հատուկ նախագծված է հիբրիդային ամպային մոդելի անցումը պարզեցնելու համար և հեշտացնում է ռեսուրսների միացումը պրովայդերներից, ինչպիսիք են AWS-ը, Azure-ը և Google Cloud Platform-ը կլաստերին, ինչպես նաև VMware-ում և OpenStack-ում մասնավոր ամպերի օգտագործումը:

Տեղադրման նոր մոտեցում

4-րդ տարբերակում OpenShift-ի տեղադրման մոտեցումը փոխվել է: Red Hat-ը տրամադրում է հատուկ օգտակար ծրագիր OpenShift կլաստերի տեղակայման համար՝ openshift-install: Կոմունալը Go-ում գրված մեկ երկուական ֆայլ է: Openshit-installer-ը պատրաստում է yaml ֆայլ՝ տեղակայման համար անհրաժեշտ կոնֆիգուրացիայով:

Ամպային ռեսուրսների օգտագործմամբ տեղադրման դեպքում ձեզ հարկավոր է նշել ապագա կլաստերի մասին նվազագույն տեղեկատվություն՝ DNS գոտի, աշխատող հանգույցների քանակը, ամպային մատակարարի հատուկ կարգավորումներ, ամպային մատակարարին մուտք գործելու հաշվի տեղեկատվություն: Կազմաձևման ֆայլը պատրաստելուց հետո կլաստերը կարող է տեղակայվել մեկ հրամանով:

Սեփական հաշվողական ռեսուրսների վրա տեղադրելու դեպքում, օրինակ՝ մասնավոր ամպ օգտագործելիս (vSphere-ը և OpenStack-ը աջակցվում են) կամ մերկ մետաղական սերվերների վրա տեղադրելիս, ձեզ հարկավոր է ձեռքով կարգավորել ենթակառուցվածքը՝ պատրաստել վիրտուալ մեքենաների նվազագույն քանակը կամ ֆիզիկական սերվերներ, որոնք անհրաժեշտ են Control Plane կլաստերի ստեղծման, ցանցային ծառայությունները կարգավորելու համար: Այս կոնֆիգուրացիայից հետո OpenShift կլաստեր կարող է ստեղծվել նմանապես openshift-installer ծրագրի մեկ հրամանով:

Ենթակառուցվածքի թարմացումներ

CoreOS ինտեգրում

Հիմնական թարմացումը Red Hat CoreOS-ի հետ ինտեգրումն է: Red Hat OpenShift հիմնական հանգույցներն այժմ կարող են աշխատել միայն նոր ՕՀ-ի վրա: Սա Red Hat-ի անվճար օպերացիոն համակարգ է, որը նախատեսված է հատուկ կոնտեյներային լուծումների համար: Red Hat CoreOS-ը թեթև Linux է, որը օպտիմիզացված է բեռնարկղերի գործարկման համար:

Եթե ​​3.11-ում օպերացիոն համակարգը և OpenShift-ը գոյություն ունեին առանձին, ապա 4.2-ում այն ​​անքակտելիորեն կապված է OpenShift-ի հետ։ Այժմ սա մեկ սարքավորում է՝ անփոփոխ ենթակառուցվածք:

Կլաստերների համար, որոնք օգտագործում են RHCOS բոլոր հանգույցների համար, OpenShift Container Platform-ի արդիականացումը պարզ և խիստ ավտոմատացված գործընթաց է:

Նախկինում OpenShift-ը թարմացնելու համար նախ պետք է թարմացնեիք հիմքում ընկած օպերացիոն համակարգը, որի վրա աշխատում էր արտադրանքը (այն ժամանակ՝ Red Hat Enterprise Linux): Միայն դրանից հետո OpenShift-ը կարող է աստիճանաբար թարմացվել՝ հանգույց առ հանգույց: Գործընթացի ավտոմատացման մասին խոսք չի եղել։

Այժմ, քանի որ OpenShift Container Platform-ը լիովին վերահսկում է համակարգերն ու ծառայությունները յուրաքանչյուր հանգույցի վրա, ներառյալ OS-ն, այս խնդիրը լուծվում է վեբ ինտերֆեյսի կոճակը սեղմելով: Դրանից հետո OpenShift կլաստերի ներսում գործարկվում է հատուկ օպերատոր, որը վերահսկում է թարմացման ողջ գործընթացը:

Նոր CSI

Երկրորդ, նոր CSI-ն պահեստային ինտերֆեյսի վերահսկիչ է, որը թույլ է տալիս միացնել տարբեր արտաքին պահեստավորման համակարգեր OpenShift կլաստերին: OpenShift-ի համար պահեստավորման վարորդների մեծ թվով մատակարարներ աջակցվում են պահեստավորման դրայվերների հիման վրա, որոնք գրված են պահեստավորման համակարգի արտադրողների կողմից: Աջակցվող CSI վարորդների ամբողջական ցանկը կարելի է գտնել այս փաստաթղթում. https://kubernetes-csi.github.io/docs/drivers.html. Այս ցանկում կարող եք գտնել առաջատար արտադրողների սկավառակների զանգվածների բոլոր հիմնական մոդելները (Dell/EMC, IBM, NetApp, Hitachi, HPE, PureStorage), SDS լուծումներ (Ceph) և ամպային պահեստավորում (AWS, Azure, Google): OpenShift 4.2-ն աջակցում է CSI-ի 1.1 բնութագրիչ տարբերակի CSI դրայվերներին:

RedHat OpenShift ծառայության ցանց

Հիմնվելով Istio, Kiali և Jaeger նախագծերի վրա՝ Red Hat OpenShift Service Mesh-ը, ի լրումն ծառայությունների միջև հարցումների ուղղորդման սովորական առաջադրանքների, թույլ է տալիս հետևել և արտացոլել դրանք: Սա օգնում է ծրագրավորողներին հեշտությամբ հաղորդակցվել, վերահսկել և կառավարել Red Hat OpenShift-ում տեղադրված հավելվածը:

Միկրոսերվիսային ճարտարապետություն ունեցող հավելվածի պատկերացում Kiali-ի միջոցով

Ծառայությունների ցանցի տեղադրումը, սպասարկումը և կյանքի ցիկլի կառավարումը հնարավորինս պարզեցնելու համար Red Hat OpenShift-ը ադմինիստրատորներին տրամադրում է հատուկ օպերատոր՝ Service Mesh Operator: Սա Kubernetes օպերատոր է, որը թույլ է տալիս վերակազմակերպված Istio, Kiali և Jaeger փաթեթները տեղակայել կլաստերի վրա՝ առավելագույնի հասցնելով հավելվածների կառավարման վարչական բեռը:

CRI-O՝ Docker-ի փոխարեն

Կանխադրված կոնտեյների գործարկման ժամանակի Docker-ը փոխարինվել է CRI-O-ով: CRI-O-ն հնարավոր էր օգտագործել արդեն 3.11 տարբերակում, բայց 4.2-ում այն ​​դարձավ հիմնականը։ Լավ կամ վատ չէ, բայց մի բան, որը պետք է հիշել ապրանքն օգտագործելիս:

Օպերատորներ և հավելվածների տեղակայում

Օպերատորները նոր միավոր են RedHat OpenShift-ի համար, որը հայտնվել է չորրորդ տարբերակում: Դա Kubernetes հավելվածը փաթեթավորելու, տեղակայելու և կառավարելու մեթոդ է: Այն կարելի է համարել որպես կոնտեյներներում տեղաբաշխված հավելվածների հավելում, որը պայմանավորված է Kubernetes API-ով և kubectl գործիքներով:

Kubernetes-ի օպերատորներն օգնում են ավտոմատացնել ցանկացած առաջադրանք՝ կապված ձեր կլաստերի մեջ տեղադրած հավելվածի կառավարման և կյանքի ցիկլի կառավարման հետ: Օրինակ, օպերատորը կարող է ավտոմատացնել հավելվածի թարմացումները, կրկնօրինակումներն ու մասշտաբները, փոխել կոնֆիգուրացիան և այլն։ Օպերատորների ամբողջական ցանկը կարող եք գտնել այստեղ https://operatorhub.io/.

OperatorHub-ը հասանելի է անմիջապես կառավարման վահանակի վեբ ինտերֆեյսից: Սա OpenShift-ի հավելվածների գրացուցակ է, որը պահպանվում է Red Hat-ի կողմից: Նրանք. Red Hat-ի կողմից հաստատված բոլոր օպերատորները ծածկված կլինեն վաճառողի աջակցությամբ:

OperatorHub պորտալ OpenShift կառավարման վահանակում

Ունիվերսալ բազային պատկեր

Դա RHEL OS պատկերների ստանդարտացված հավաքածու է, որը կարող է օգտագործվել ձեր կոնտեյներային հավելվածները ստեղծելու համար: Առկա են նվազագույն, ստանդարտ և ամբողջական հավաքածուներ։ Նրանք շատ քիչ տեղ են զբաղեցնում և աջակցում են բոլոր անհրաժեշտ տեղադրված փաթեթներն ու ծրագրավորման լեզուները։

CI/CD գործիքներ

RedHat OpenShif 4.2-ում հնարավոր դարձավ ընտրել Jenkins-ի և OpenShift Pipelines-ի միջև՝ հիմնված Tekton Pipelines-ի վրա։

OpenShift Pipelines-ը հիմնված է Tekton-ի վրա, որն ավելի լավ է աջակցվում Pipeline-ի կողմից՝ որպես Code և GitOps մոտեցումներ: OpenShift խողովակաշարերում յուրաքանչյուր քայլ աշխատում է իր կոնտեյներով, ուստի ռեսուրսներն օգտագործվում են միայն քայլի կատարման ընթացքում: Սա ծրագրավորողներին տալիս է ամբողջական վերահսկողություն մոդուլների առաքման խողովակաշարերի, պլագինների և մուտքի վերահսկման վրա՝ առանց կառավարելու կենտրոնական CI/CD սերվերի:

OpenShift Pipelines-ը ներկայումս Developer Preview-ում է և հասանելի է որպես օպերատոր OpenShift 4 կլաստերի վրա: Իհարկե, OpenShift-ի օգտվողները դեռ կարող են օգտագործել Jenkins-ը RedHat OpenShift 4-ում:

Մշակողների կառավարման թարմացումներ

4.2 OpenShift-ում վեբ ինտերֆեյսը ամբողջությամբ թարմացվել է ինչպես մշակողների, այնպես էլ ադմինիստրատորների համար:

OpenShift-ի նախորդ տարբերակներում բոլորն աշխատում էին երեք կոնսուլներում՝ սպասարկման գրացուցակ, ադմինիստրատորի վահանակ և աշխատանքային վահանակ: Այժմ կլաստերը բաժանված է միայն երկու մասի` ադմինիստրատորի վահանակ և ծրագրավորող վահանակ:

Developer կոնսոլը ստացել է օգտատիրոջ միջերեսի զգալի բարելավումներ: Այժմ այն ​​ավելի հարմար է ցուցադրում հավելվածների տոպոլոգիաները և դրանց հավաքները։ Սա ծրագրավորողների համար հեշտացնում է կոնտեյներային հավելվածների և կլաստերային ռեսուրսների ստեղծումը, տեղակայումը և պատկերացումը: Թույլ է տալիս նրանց կենտրոնանալ իրենց համար կարևորի վրա:

Մշակողների պորտալ OpenShift կառավարման վահանակում

odo

Odo-ն ծրագրավորողին ուղղված հրամանի տող ծրագիր է, որը հեշտացնում է հավելվածների մշակումը OpenShift-ում: Օգտագործելով git push ոճի հաղորդակցությունը՝ այս CLI-ն օգնում է Kubernetes-ի նորեկ ծրագրավորողներին ստեղծել հավելվածներ OpenShift-ում:

Ինտեգրում զարգացման միջավայրերի հետ

Այժմ մշակողները կարող են ստեղծել, կարգաբերել և տեղակայել իրենց հավելվածները OpenShift-ում՝ չթողնելով կոդերի մշակման իրենց սիրելի միջավայրը, ինչպիսիք են Microsoft Visual Studio, JetBrains (ներառյալ IntelliJ), Eclipse Desktop և այլն:

Red Hat OpenShift տեղակայման ընդլայնում Microsoft Azure DevOps-ի համար

Թողարկվել է Red Hat OpenShift Deployment ընդլայնումը Microsoft Azure DevOps-ի համար: Այս DevOps գործիքների օգտատերերն այժմ կարող են իրենց հավելվածները տեղակայել Azure Red Hat OpenShift-ում կամ ցանկացած այլ OpenShift կլաստերում անմիջապես Microsoft Azure DevOps-ից:

Անցում երրորդ տարբերակից չորրորդին

Քանի որ մենք խոսում ենք նոր թողարկման մասին, այլ ոչ թե թարմացման, դուք չեք կարող պարզապես չորրորդ տարբերակը տեղադրել երրորդի վերևում: XNUMX-րդ տարբերակից XNUMX-րդ տարբերակի թարմացումը չի ապահովվի:.

Բայց լավ նորություն կա. Red Hat-ը գործիքներ է տրամադրում նախագծերը 3.7-ից 4.2 տեղափոխելու համար: Դուք կարող եք տեղափոխել հավելվածների աշխատանքային բեռները՝ օգտագործելով Cluster Application Migration (CAM) գործիքը: CAM-ը թույլ է տալիս վերահսկել միգրացիան և նվազագույնի հասցնել հավելվածի խափանումը:

OpenShift 4.3

Այս հոդվածում նկարագրված հիմնական նորամուծությունները հայտնվել են 4.2 տարբերակում: Վերջերս թողարկված 4.3 փոփոխությունները այնքան էլ մեծ չեն, բայց դեռ կան որոշ նոր բաներ: Փոփոխությունների ցանկը բավականին ընդարձակ է, ահա մեր կարծիքով առավել նշանակալիցները.

Թարմացրեք Kubernetes տարբերակը 1.16-ի:

Տարբերակը թարմացվեց միանգամից երկու քայլով, OpenShift 4.2-ում այն ​​1.14 էր:

Տվյալների կոդավորումը և այլն

Սկսած 4.3 տարբերակից՝ հնարավոր է դարձել տվյալների կոդավորումը etcd տվյալների բազայում։ Կոդավորումը միացնելուց հետո հնարավոր կլինի գաղտնագրել հետևյալ OpenShift API-ն և Kubernetes API-ի ռեսուրսները՝ Գաղտնիքներ, ConfigMaps, Երթուղիներ, մուտքի նշաններ և OAuth թույլտվություն:

սաղավարտ

Ավելացվել է աջակցություն Helm տարբերակ 3-ի համար՝ Kubernetes-ի հայտնի փաթեթների կառավարիչ: Առայժմ աջակցությունն ունի TECHNOLOGY PREVIEW կարգավիճակը: Ղեկի աջակցությունը կընդլայնվի մինչև ամբողջական աջակցություն OpenShift-ի ապագա տարբերակներում: Ղեկավար cli կոմունալը գալիս է OpenShift-ով և կարելի է ներբեռնել կլաստերի կառավարման վեբ վահանակից:

Ծրագրի վահանակի թարմացում

Նոր տարբերակում Project Dashboard-ը լրացուցիչ տեղեկատվություն է տրամադրում ծրագրի էջում՝ նախագծի կարգավիճակը, ռեսուրսների օգտագործումը և նախագծի քվոտաները:

Ցուցադրում է խոցելիությունը վեբ վահանակում

Կառավարման վահանակին ավելացվել է գործառույթ՝ Quay պահեստներում պատկերների համար հայտնի խոցելիությունները ցուցադրելու համար: Աջակցվում է տեղական և արտաքին պահոցների խոցելիության ցուցադրումը:

Օֆլայն օպերատորի պարզեցված ստեղծում

Մեկուսացված ցանցում OpenShift կլաստերի տեղակայման դեպքում, որտեղից ինտերնետ հասանելիությունը սահմանափակ է կամ բացակայում է, OperatorHub ռեեստրի համար «հայելի» ստեղծելը պարզեցված է: Այժմ դա կարելի է անել ընդամենը երեք թիմով:

Հեղինակներ:
Վիկտոր Պուչկով, Յուրի Սեմենյուկով

Source: www.habr.com