Կներես, OpenShift, մենք քեզ բավարար չափով չգնահատեցինք և ընդունեցինք քեզ որպես ինքնին

Այս գրառումը գրվել է, քանի որ մեր աշխատակիցները բավականին շատ զրույցներ են ունեցել հաճախորդների հետ Kubernetes-ում հավելվածների մշակման և OpenShift-ում նման զարգացման առանձնահատկությունների մասին։

Մենք սովորաբար սկսում ենք այն թեզից, որ Kubernetes-ը պարզապես Kubernetes է, իսկ OpenShift-ն արդեն Kubernetes հարթակ է, ինչպես Microsoft AKS-ը կամ Amazon EKS-ը: Այս հարթակներից յուրաքանչյուրն ունի իր առավելությունները՝ ուղղված որոշակի թիրախային լսարանին: Եվ սրանից հետո խոսակցությունը անցնում է կոնկրետ հարթակների ուժեղ և թույլ կողմերի համեմատությանը։

Ընդհանրապես, մենք մտածեցինք այս գրառումը գրել հետևյալ եզրակացությամբ, ինչպիսին է «Լսիր, կարևոր չէ, թե որտեղ գործարկել կոդը՝ OpenShift-ում, թե AKS-ում, EKS-ում, որոշ հատուկ Kubernetes-ում կամ ցանկացած Kubernetes-ում: (Հակիրճության համար եկեք այն անվանենք KUK) «Դա իսկապես պարզ է, և՛ այնտեղ, և՛ այնտեղ»:

Այնուհետև մենք նախատեսեցինք վերցնել ամենապարզ «Բարև աշխարհը» և օգտագործել դրա օրինակը՝ ցույց տալու, թե որն է ընդհանուր և որն է տարբերությունը KUC-ի և Red Hat OpenShift կոնտեյներային հարթակի միջև (այսուհետ՝ OCP կամ պարզապես OpenShift):

Այնուամենայնիվ, երբ մենք գրում էինք այս գրառումը, մենք հասկացանք, որ այնքան սովոր էինք օգտագործել OpenShift-ն այնքան երկար, որ մենք պարզապես չհասկացանք, թե ինչպես է այն աճել և վերածվել զարմանալի հարթակի, որը դարձավ շատ ավելին, քան պարզապես Kubernetes բաշխումը: Մենք հակված ենք ընդունել OpenShift-ի հասունությունն ու պարզությունը և կորցնել դրա փայլը:

Ընդհանրապես, եկել է ակտիվ ապաշխարության ժամանակը, և այժմ մենք քայլ առ քայլ կհամեմատենք մեր «Բարև աշխարհ»-ի գործարկումը KUK-ում և OpenShift-ում, և դա կանենք հնարավորինս օբյեկտիվ (լավ, բացառությամբ երբեմն ցույց տալու անձնական վերաբերմունք առարկայի նկատմամբ): Եթե ​​ձեզ հետաքրքրում է զուտ սուբյեկտիվ կարծիք այս հարցում, ապա կարող եք կարդալ այն այստեղ (EN). Իսկ այս գրառման մեջ մենք կառչենք փաստերին և միայն փաստերին։

Կլաստերներ

Այսպիսով, մեր «Բարև աշխարհը» պահանջում է կլաստերներ: Մենք անմիջապես կասենք «ոչ» ցանկացած հանրային ամպին, որպեսզի չվճարենք սերվերների, ռեգիստրների, ցանցերի, տվյալների փոխանցման և այլնի համար: Համապատասխանաբար, մենք ընտրում ենք պարզ մեկ հանգույցի կլաստեր Մինիկուբե (KUK-ի համար) և Կոդ պատրաստ տարաներ (OpenShift կլաստերի համար): Այս երկու տարբերակներն էլ իսկապես հեշտ են տեղադրել, բայց ձեր նոութբուքի վրա բավականին մեծ ռեսուրսներ կպահանջեն:

Ժողով ԿՈՒԿ-է

Այսպիսով, եկեք գնանք:

Քայլ 1 – կառուցել մեր կոնտեյների պատկերը

Եկեք սկսենք մեր «Բարև աշխարհը» տեղակայելով minikube-ում: Դա անելու համար ձեզ հարկավոր է.

1. 1. Տեղադրված է Docker:
2. 2. Տեղադրված է Git:
3. 3. Տեղադրված Maven-ը (իրականում այս նախագիծն օգտագործում է mvnw երկուականը, այնպես որ կարող եք անել առանց դրա):
4. 4. Փաստորեն, աղբյուրն ինքնին, այսինքն. պահեստային կլոն github.com/gcolman/quarkus-hello-world.git

Առաջին քայլը Quarkus նախագծի ստեղծումն է: Մի անհանգստացեք, եթե երբեք չեք աշխատել Quarkus.io-ի հետ, դա հեշտ է: Դուք պարզապես ընտրում եք այն բաղադրիչները, որոնք ցանկանում եք օգտագործել նախագծում (RestEasy, Hibernate, Amazon SQS, Camel և այլն), այնուհետև Quarkus-ն ինքը, առանց ձեր մասնակցության, կարգավորում է maven արխետիպը և ամեն ինչ դնում github-ի վրա: Այսինքն, բառացիորեն մկնիկի մեկ սեղմումով, և դուք պատրաստ եք: Ահա թե ինչու ենք մենք սիրում Quarkus-ը:

Մեր «Բարև աշխարհը» կոնտեյների պատկեր ստեղծելու ամենադյուրին ճանապարհը Docker-ի համար quarkus-maven ընդլայնումն է, որը կկատարի բոլոր անհրաժեշտ աշխատանքները: Quarkus-ի գալուստով սա իսկապես հեշտ և պարզ դարձավ. ավելացրեք կոնտեյներ-պատկեր-դոկեր ընդլայնումը և կարող եք պատկերներ ստեղծել՝ օգտագործելով maven հրամանները:

./mvnw quarkus:add-extension -Dextensions=”container-image-docker”

Ի վերջո, մենք կառուցում ենք մեր պատկերը՝ օգտագործելով Maven-ը: Արդյունքում, մեր սկզբնական կոդը վերածվում է պատրաստի կոնտեյների պատկերի, որն արդեն կարող է գործարկվել կոնտեյների գործարկման միջավայրում։

./mvnw -X clean package -Dquarkus.container-image.build=true

Այսքանը, այժմ դուք կարող եք գործարկել կոնտեյները docker run հրամանով, մեր ծառայությունը քարտեզագրելով 8080 նավահանգստում, որպեսզի այն հասանելի լինի:

docker run -i — rm -p 8080:8080 gcolman/quarkus-hello-world

Կոնտեյների օրինակը սկսելուց հետո մնում է միայն ստուգել curl հրամանով, որ մեր ծառայությունն աշխատում է.

Այսպիսով, ամեն ինչ աշխատում է, և դա իսկապես հեշտ և պարզ էր:

Քայլ 2 – ուղարկեք մեր կոնտեյները կոնտեյների պատկերների պահոց

Առայժմ մեր ստեղծած պատկերը պահվում է տեղում՝ մեր տեղական կոնտեյների պահեստում: Եթե ​​մենք ցանկանում ենք օգտագործել այս պատկերը մեր COOK միջավայրում, ապա այն պետք է տեղադրվի որևէ այլ պահեստում: Kubernetes-ը նման հնարավորություններ չունի, ուստի մենք կօգտագործենք dockerhub-ը: Որովհետև, նախ, դա անվճար է, և երկրորդը, դա անում են (գրեթե) բոլորը։

Սա նույնպես շատ պարզ է, և ձեզ հարկավոր է միայն dockerhub հաշիվ:

Այսպիսով, մենք տեղադրում ենք dockerhub և ուղարկում մեր պատկերը այնտեղ:

Քայլ 3 – գործարկել Kubernetes-ը

Կան բազմաթիվ եղանակներ՝ հավաքելու kubernetes կոնֆիգուրացիան՝ մեր «Բարև աշխարհ» գործարկելու համար, բայց մենք կօգտագործենք դրանցից ամենապարզը, այդպիսին ենք մենք…

Նախ, եկեք գործարկենք minikube կլաստերը.

minikube start

Քայլ 4 – տեղակայել մեր կոնտեյների պատկերը

Այժմ մենք պետք է փոխարկենք մեր կոդը և կոնտեյների պատկերը kubernetes կոնֆիգուրացիաների: Այլ կերպ ասած, մեզ անհրաժեշտ է պատիճ և տեղակայման սահմանում, որը ցույց է տալիս մեր կոնտեյների պատկերը dockerhub-ում: Դա անելու ամենահեշտ ձևերից մեկը ստեղծելու տեղակայման հրամանը գործարկելն է՝ մատնանշելով մեր պատկերը.

kubectl create deployment hello-quarkus — image =gcolman/quarkus-hello-world:1.0.0-SNAPSHOT

Այս հրամանով մենք մեր COO-ին ասացինք ստեղծել տեղակայման կոնֆիգուրացիա, որը պետք է պարունակի մեր կոնտեյների պատկերի պատի հստակեցումը: Այս հրամանը նաև կկիրառի այս կոնֆիգուրացիան մեր minikube կլաստերի վրա և կստեղծի տեղակայում, որը կներբեռնի մեր կոնտեյների պատկերը և կգործարկի պատիճը կլաստերի մեջ:

Քայլ 5 – բաց մուտք դեպի մեր ծառայություն

Այժմ, երբ մենք ունենք տեղակայված կոնտեյների պատկեր, ժամանակն է մտածել, թե ինչպես կարգավորել արտաքին մուտքը այս Restful ծառայությանը, որն, ըստ էության, ծրագրավորված է մեր կոդում:

Այստեղ շատ ուղիներ կան: Օրինակ, դուք կարող եք օգտագործել expose հրամանը՝ ավտոմատ կերպով ստեղծելու համապատասխան Kubernetes բաղադրիչները, ինչպիսիք են ծառայությունները և վերջնակետերը: Փաստորեն, սա այն է, ինչ մենք կանենք՝ կատարելով մեր տեղակայման օբյեկտի համար expose հրամանը.

kubectl expose deployment hello-quarkus — type=NodePort — port=8080

Եկեք մի պահ նայենք expose հրամանի «-type» տարբերակին:

Երբ մենք բացահայտում և ստեղծում ենք մեր ծառայությունը գործարկելու համար անհրաժեշտ բաղադրիչները, մենք, ի թիվս այլ բաների, պետք է կարողանանք արտաքինից միանալ hello-quarkus ծառայությանը, որը տեղակայված է մեր ծրագրային ապահովման կողմից սահմանված ցանցի ներսում: Եվ պարամետր տիպ թույլ է տալիս մեզ ստեղծել և միացնել այնպիսի բաներ, ինչպիսիք են բեռի հավասարակշռող սարքերը՝ երթևեկությունը դեպի այս ցանց ուղղորդելու համար:

Օրինակ՝ գրելով type=LoadBalancer, մենք ավտոմատ կերպով տրամադրում ենք բեռի հավասարակշռող հանրային ամպի մեջ՝ մեր Kubernetes կլաստերին միանալու համար: Սա, իհարկե, հիանալի է, բայց դուք պետք է հասկանաք, որ նման կոնֆիգուրացիան խստորեն կապված կլինի կոնկրետ հանրային ամպի հետ և ավելի դժվար կլինի փոխանցել Kubernetes-ի օրինակների միջև տարբեր միջավայրերում:

Մեր օրինակում type=NodePort, այսինքն՝ մեր ծառայությունը հասանելի է հանգույցի IP հասցեով և պորտի համարով։ Այս տարբերակը թույլ է տալիս չօգտագործել որևէ հանրային ամպ, սակայն պահանջում է մի շարք լրացուցիչ քայլեր: Նախ, ձեզ անհրաժեշտ է ձեր սեփական բեռի հավասարակշռիչը, այնպես որ մենք կտեղակայենք NGINX բեռի հավասարակշռիչը մեր կլաստերում:

Քայլ 6 – տեղադրել բեռի հավասարակշռող սարք

minikube-ն ունի մի շարք պլատֆորմի գործառույթներ, որոնք հեշտացնում են արտաքինից հասանելի բաղադրիչների ստեղծումը, ինչպիսիք են մուտքի կարգավորիչները: Minikube-ը փաթեթավորված է Nginx ներթափանցման կարգավորիչով, և մեզ մնում է միայն միացնել այն և կարգավորել այն:

minikube addons enable ingress

Այժմ մենք կստեղծենք Nginx մուտքի վերահսկիչ ընդամենը մեկ հրամանով, որը կաշխատի մեր minikube կլաստերի ներսում.

ingress-nginx-controller-69ccf5d9d8-j5gs9 1/1 Running 1 33m

Քայլ 7 - ներթափանցման կարգավորում

Այժմ մենք պետք է կարգավորենք Nginx ingress կարգավորիչը, որպեսզի այն ընդունի hello-quarkus-ի հարցումները:

Եվ վերջապես, մենք պետք է կիրառենք այս կոնֆիգուրացիան:

kubectl apply -f ingress.yml

Քանի որ մենք այս ամենն անում ենք մեր սեփական համակարգչով, մենք պարզապես ավելացնում ենք մեր հանգույցի IP հասցեն /etc/ hosts ֆայլին, որպեսզի http հարցումները ուղղորդենք դեպի մեր minikube դեպի NGINX բեռի հավասարակշռիչ:

192.168.99.100 hello-quarkus.info

Վերջ, այժմ մեր minikube ծառայությունը հասանելի է արտաքինից՝ Nginx ներթափանցման կարգավորիչի միջոցով:

Դե, դա հեշտ էր, չէ՞: Թե՞ ոչ իսկապես:

Աշխատում է OpenShift-ով (Code Ready Containers)

Այժմ տեսնենք, թե ինչպես է այս ամենը արվում Red Hat OpenShift կոնտեյներային հարթակում (OCP):

Ինչպես minikube-ի դեպքում, մենք ընտրում ենք մեկ հանգույց OpenShift կլաստերի ձևավորում՝ Code Ready Containers (CRC) տեսքով: Նախկինում այն ​​կոչվում էր minishift և հիմնված էր OpenShift Origin նախագծի վրա, իսկ այժմ այն ​​CRC է և կառուցված է Red Hat-ի OpenShift կոնտեյներային հարթակի վրա:

Այստեղ մենք, կներեք, չենք կարող չասել. «OpenShift-ը հրաշալի է»:

Սկզբում մտածում էինք գրել, որ OpenShift-ի մշակումը չի տարբերվում Kubernetes-ի մշակումից: Եվ ըստ էության դա այդպես է. Բայց այս գրառումը գրելու գործընթացում մենք հիշեցինք, թե որքան լրացուցիչ շարժումներ պետք է կատարեք, երբ դուք չունեք OpenShift, և այդ պատճառով, կրկին, դա հիանալի է: Մենք սիրում ենք այն, երբ ամեն ինչ հեշտ է արվում, և թե որքան հեշտ է մեր օրինակը OpenShift-ում տեղակայելն ու գործարկելը՝ համեմատած minikube-ի հետ, դա մեզ դրդեց գրել այս գրառումը:

Եկեք անցնենք գործընթացի միջով և տեսնենք, թե ինչ պետք է անենք:

Այսպիսով, minikube-ի օրինակում մենք սկսեցինք Docker-ից... Սպասեք, մեզ այլևս պետք չէ, որ Docker-ը տեղադրված լինի մեքենայի վրա:

Եվ մեզ պետք չէ լոկալ գիթ:
Իսկ Մավենը պետք չէ։
Եվ ձեզ հարկավոր չէ ձեռքով ստեղծել կոնտեյների պատկեր:
Եվ դուք պետք չէ փնտրել կոնտեյների պատկերների որևէ պահեստ:
Եվ ներթափանցման վերահսկիչ տեղադրելու կարիք չկա:
Եվ դուք նույնպես կարիք չունեք կարգավորելու մուտքը:

Հասկանում եք, չէ՞: Մեր հավելվածը OpenShift-ում տեղակայելու և գործարկելու համար վերը նշվածներից որևէ մեկը ձեզ հարկավոր չէ: Եվ գործընթացն ինքնին այսպիսի տեսք ունի.

Քայլ 1 – Գործարկեք ձեր OpenShift կլաստերը

Մենք օգտագործում ենք Code Ready Containers Red Hat-ից, որն ըստ էության նույն Minikube-ն է, բայց միայն ամբողջական մեկ հանգույց Openshift կլաստերով:

crc start

Քայլ 2 – Կառուցեք և տեղադրեք հավելվածը OpenShift կլաստերի մեջ

Հենց այս քայլում է, որ բացահայտվում է OpenShift-ի պարզությունն ու հարմարավետությունն իր ողջ փառքով: Ինչպես Kubernetes-ի բոլոր բաշխումների դեպքում, մենք ունենք կլաստերի մեջ հավելված գործարկելու բազմաթիվ եղանակներ: Եվ, ինչպես KUK-ի դեպքում, մենք հատուկ ընտրում ենք ամենապարզը։

OpenShift-ը միշտ ստեղծվել է որպես կոնտեյներային հավելվածներ ստեղծելու և գործարկելու հարթակ: Կոնտեյներների կառուցումը միշտ եղել է այս հարթակի անբաժանելի մասը, ուստի կան մի տոննա լրացուցիչ Kubernetes ռեսուրսներ հարակից առաջադրանքների համար:

Մենք կօգտագործենք OpenShift-ի Source 2 Image (S2I) գործընթացը, որն ունի մի քանի տարբեր եղանակներ՝ վերցնելու մեր աղբյուրը (կոդ կամ երկուականներ) և այն վերածելու կոնտեյներացված պատկերի, որն աշխատում է OpenShift կլաստերի վրա:

Դա անելու համար մեզ անհրաժեշտ է երկու բան.

• Մեր սկզբնական կոդը գտնվում է git պահոցում
• Builder պատկերը, որի հիման վրա կկատարվի շինարարությունը:

Կան բազմաթիվ նման պատկերներ, որոնք պահպանվում են ինչպես Red Hat-ի, այնպես էլ համայնքի մակարդակով, և մենք կօգտագործենք OpenJDK պատկերը, լավ, քանի որ ես Java հավելված եմ կառուցում:

Դուք կարող եք գործարկել S2I կառուցումը ինչպես OpenShift Developer գրաֆիկական վահանակից, այնպես էլ հրամանի տողից: Մենք կօգտագործենք նոր հավելվածի հրամանը՝ նրան ասելով, թե որտեղից ստանալ կառուցողի պատկերը և մեր սկզբնական կոդը:

oc new-app registry.access.redhat.com/ubi8/openjdk-11:latest~https://github.com/gcolman/quarkus-hello-world.git

Վերջ, մեր հավելվածը ստեղծվել է։ Դրանով S2I գործընթացն արեց հետևյալ բաները.

• Ստեղծել է ծառայության build-pod հավելվածի ստեղծման հետ կապված բոլոր տեսակի բաների համար:
• Ստեղծել է OpenShift Build կոնֆիգուրը:
• Ես ներբեռնեցի շինարարի պատկերը ներքին OpenShift դոկերի ռեգիստրում:
• Կլոնավորվել է «Բարև աշխարհ» տեղական պահեստում:
• Ես տեսա, որ այնտեղ maven pom կա, ուստի հավելվածը կազմեցի maven-ի միջոցով։
• Ստեղծել է նոր կոնտեյների պատկեր, որը պարունակում է կազմված Java հավելվածը և տեղադրել այս պատկերը ներքին կոնտեյների ռեեստրում:
• Ստեղծվել է Kubernetes-ի տեղակայում pod, ծառայության և այլնի բնութագրերով:
• Ես սկսեցի տեղակայել կոնտեյների պատկերը:
• Հեռացվել է ծառայության build-pod-ը:

Այս ցուցակում շատ բան կա, բայց գլխավորն այն է, որ ամբողջ կառուցումը տեղի է ունենում բացառապես OpenShift-ի ներսում, ներքին Docker ռեգիստրը գտնվում է OpenShift-ի ներսում, և կառուցման գործընթացը ստեղծում է Kubernetes-ի բոլոր բաղադրիչները և գործարկում դրանք կլաստերի մեջ:

Եթե ​​տեսողականորեն վերահսկեք S2I-ի գործարկումը վահանակում, կարող եք տեսնել, թե ինչպես է գործարկվում build pod-ը, երբ կառուցումն ավարտված է:

Այժմ եկեք նայենք builder pod տեղեկամատյաններին. նախ՝ այն ցույց է տալիս, թե ինչպես է Maven-ը կատարում իր աշխատանքը և ներբեռնում է կախվածությունը մեր java հավելվածը ստեղծելու համար:

Maven build-ն ավարտվելուց հետո սկսվում է կոնտեյների պատկերի կառուցումը, այնուհետև այս կառուցված պատկերն ուղարկվում է ներքին պահոց:

Վերջ, կառուցման գործընթացը ավարտված է: Այժմ եկեք համոզվենք, որ մեր հավելվածի պատիճներն ու ծառայություններն աշխատում են կլաստերում:

oc get service

Այսքանը: Եվ միայն մեկ թիմ: Մեզ մնում է միայն բացահայտել այս ծառայությունը դրսից մուտք գործելու համար:

Քայլ 3 – ցուցադրեք ծառայությունը դրսից մուտք գործելու համար

Ինչպես KUC-ի դեպքում, OpenShift հարթակում մեր «Բարև աշխարհ»-ը նույնպես երթուղիչի կարիք ունի՝ արտաքին երթևեկությունը դեպի կլաստերի ծառայությանը ուղղորդելու համար: OpenShift-ը դա շատ հեշտ է դարձնում: Նախ, HAProxy երթուղավորման բաղադրիչը լռելյայն տեղադրվում է կլաստերում (այն կարող է փոխվել նույն NGINX-ի): Երկրորդ, կան հատուկ և բարձր կարգավորելի ռեսուրսներ, որոնք կոչվում են Routes և հիշեցնում են Ingress օբյեկտները հին լավ Kubernetes-ում (իրականում OpenShift-ի երթուղիները մեծ ազդեցություն են ունեցել Ingress օբյեկտների ձևավորման վրա, որոնք այժմ կարող են օգտագործվել OpenShift-ում), բայց մեր «Բարև աշխարհ» , և գրեթե բոլոր մյուս դեպքերում ստանդարտ Route-ը մեզ բավական է առանց լրացուցիչ կոնֆիգուրացիայի։

«Բարև աշխարհ»-ի համար երթուղային FQDN ստեղծելու համար (այո, OpenShiift-ն ունի իր սեփական DNS-ը ծառայությունների անուններով երթուղղելու համար), մենք պարզապես կբացահայտենք մեր ծառայությունը.

oc expose service quarkus-hello-world

Եթե ​​նայեք նորաստեղծ երթուղուն, կարող եք գտնել FQDN-ը և երթուղային այլ տեղեկություններ այնտեղ.

oc get route

Եվ վերջապես, մենք մուտք ենք գործում մեր ծառայություն բրաուզերից.

Բայց հիմա դա իսկապես հեշտ էր:

Մենք սիրում ենք Kubernetes-ը և այն ամենը, ինչ թույլ է տալիս մեզ անել այս տեխնոլոգիան, ինչպես նաև սիրում ենք պարզությունն ու հեշտությունը: Kubernetes-ը ստեղծվել է բաշխված, մասշտաբային բեռնարկղերի աշխատանքը աներևակայելիորեն պարզեցնելու համար, սակայն դրա պարզությունն այլևս բավարար չէ հավելվածներն այսօր արտադրության մեջ դնելու համար: Հենց այստեղ է գործում OpenShift-ը, որը ժամանակին համընթաց է և առաջարկում է Kubernetes-ը, որն ուղղված է հիմնականում ծրագրավորողին: Մեծ ջանք է ներդրվել OpenShift հարթակը հատուկ մշակողի համար հարմարեցնելու համար, ներառյալ գործիքների ստեղծումը, ինչպիսիք են S2I, ODI, Developer Portal, OpenShift Operator Framework, IDE ինտեգրում, Developer Catalogues, Helm ինտեգրում, մոնիտորինգ և շատ ուրիշներ:

Հուսով ենք, որ այս հոդվածը հետաքրքիր և օգտակար էր ձեզ համար: Դուք կարող եք գտնել լրացուցիչ ռեսուրսներ, նյութեր և զարգացման համար օգտակար այլ բաներ OpenShift հարթակում պորտալում Red Hat Developers.

Source: www.habr.com