«ĂfarĂ« Ă«shtĂ« ndryshimi midis Kubernetes dhe OpenShift?» â ky pyetje shfaqet me njĂ« rregullshmĂ«ri tĂ« admirueshme. MegjithatĂ«, nĂ« tĂ« vĂ«rtetĂ«, Ă«shtĂ« e njĂ«jtĂ« me pyetjen se çfarĂ« e ndan njĂ« makinĂ« nga njĂ« motor. NĂ«se e vazhdojmĂ« analogjinĂ«, makina Ă«shtĂ« njĂ« produkt i gatshĂ«m, mund ta pĂ«rdorĂ«sh menjĂ«herĂ«: hip dhe shko. NĂ« anĂ«n tjetĂ«r, qĂ« motori tĂ« tĂ« çojĂ« diku, duhet fillimisht tĂ« plotĂ«sohet me njĂ« sĂ«rĂ« gjĂ«rash tĂ« tjera, pĂ«r tĂ« pĂ«rfunduar me njĂ« makinĂ«.
Prandaj Kubernetes është një motor, rreth të cilit është ndërtuar makina (platforma) e markës OpenShift, e cila të çon në destinacion.
Në këtë artikull dëshirojmë të kujtojmë dhe të shpjegojmë më në detaje pikat kyçe në vijim:
- Kubernetes është zemra e platformës OpenShift dhe është 100% Kubernetes e certifikuar, me kod të plotë të hapur dhe pa asnjë pronësi. Në shkurt:
- API për klasterin OpenShift është 100% Kubernetes.
- Nëse një kontejner funksionon në çdo sistem tjetër Kubernetes, ai do të funksionojë pa asnjë ndryshim edhe në OpenShift. Nuk nevojiten ndryshime në aplikacione.
- OpenShift jo vetĂ«m qĂ« ploteson Kubernetes me funksione dhe mundĂ«si tĂ« dobishme. Ashtu si makina, OpenShift Ă«shtĂ« gati pĂ«r t'u pĂ«rdorur menjĂ«herĂ«, mund tĂ« vihet menjĂ«herĂ« nĂ« prodhim dhe, siç do tĂ« tregojmĂ« mĂ« poshtĂ«, e thjeshton dukshĂ«m jetĂ«n e zhvilluesit. PikĂ«risht pĂ«r kĂ«tĂ« arsye OpenShift Ă«shtĂ« unik nĂ« dy aspekte. ĂshtĂ« njĂ« platformĂ« PaaS me sukses dhe e njohur nĂ« nivelin e korporatave, nga perspektiva e zhvilluesit. Dhe njĂ«kohĂ«sisht, Ă«shtĂ« njĂ« zgjidhje jashtĂ«zakonisht tĂ« besueshme nĂ« kategorinĂ« Container-as-a-Service nga pikĂ«pamja e operacioneve industriale.
OpenShift është Kubernetes me 100% certifikim nga fondacioni CNCF
Bazat e OpenShift janë . Prandaj, pas një trajnimi përkatës, përdoruesit janë të impresionuar nga fuqia e kubectl. Dhe ata që janë kaluar në OpenShift nga Kubernetes Cluster shpesh thonë se u pëlqen shumë që pas ridrejtimit të kubeconfig në klasterin OpenShift, të gjitha skenaret ekzistuese funksionojnë pa probleme.
Sikur e dëgjuat për ndihmësin e komandës OpenShift të quajtur OC. Ai është plotësisht i përshtatshëm në komandat me kubectl, përveçse ofron disa ndihmës të dobishëm që do të jenë të nevojshëm për të realizuar një sërë detyrash. Por më parë pak më shumë për përputhshmërinë e OC dhe kubectl:
Komandat kubectl
Komandat OC
kubectl get pods
oc get pods
kubectl get namespaces
oc get namespaces
kubectl create -f deployment.yaml
oc create -f deployment.yaml
Këtu janë rezultatet e përdorimit të kubectl në OpenShift API:
âą kubectl get pods â siç pritej, kthen pod-et.
âą kubectl get namespaces â siç pritej, kthen hapesira emri.
Komanda kubectl create -f mydeployment.yaml krijon burime kubernetes ashtu si në çdo platformë tjetër Kubernetes, siç shihet në videon më poshtë:
Me fjalĂ« tĂ« tjera, tĂ« gjithĂ« API-tĂ« e Kubernetes janĂ« plotĂ«sisht tĂ« aksesueshĂ«m nĂ« OpenShift me 100% pĂ«rputhje. Prandaj, .â
OpenShift plotëson Kubernetes me funksionalitete të dobishme
API-të e Kubernetes janë 100% të aksesueshme në OpenShift, por utilita standarde kubectl duket se i mungon funksionaliteti dhe komoditeti. Prandaj, Red Hat ka plotësuar Kubernetes me funksionalitete dhe mjete të linjës komande, si OC (shkurtesë për OpenShift client) dhe ODO (OpenShift DO, kjo utilitë është krijuar për zhvilluesit).
1. Utilita OC â njĂ« variant mĂ« i fuqishĂ«m dhe mĂ« i lehtĂ« pĂ«r t'u pĂ«rdorur sesa Kubectl
Për shembull, përndryshe nga kubectl, ajo lejon krijimin e hapësirave të reja emri dhe lehtëson kalimin mes konteksteve, si dhe ofron një sërë komandash të dobishme për zhvilluesit, për shembull, për ndërtimin e imazheve të kontejnerëve dhe për vendosjen e aplikacioneve direkt nga kodi burimor ose skedarët binarë (Source-to-image, s2i).
Le të shqyrtojmë me shembuj se si ndihmësit e integruar dhe funksionaliteti i zgjeruar i utilitës OC ndihmojnë në thjeshtimin e punës së përditshme.
Shembulli i parĂ« â menaxhimi i hapĂ«sirave emri. NĂ« çdo klaster Kubernetes gjithmonĂ« ka disa hapĂ«sira emri. Zakonisht ato pĂ«rdoren pĂ«r krijimin e mjediseve tĂ« zhvillimit dhe prodhimit, por mund tĂ« pĂ«rdoren edhe pĂ«r t'i dhĂ«nĂ« secilit zhvillues njĂ« 'sandbox' personal. NĂ« praktikĂ«, kjo do tĂ« thotĂ« qĂ« zhvilluesi shpesh duhet tĂ« kalojĂ« mes hapĂ«sirave emri, pasi kubectl punon nĂ« kontekstin e hapĂ«sirĂ«s aktuale. Prandaj, pĂ«r kubectl, pĂ«rdoruesit e pĂ«rdorin aktivisht skriptet ndihmĂ«se pĂ«r kĂ«tĂ« qĂ«llim. NdĂ«rsa me OC, pĂ«r tĂ« kaluar nĂ« hapĂ«sirĂ«n e dĂ«shiruar, mjafton tĂ« thuash 'oc project emri_hapesires'.
Nuk e mbani mend si quhet hapĂ«sira juaj e nevojshme? Nuk ka problem, thjesht shkruani âoc get projectsâ pĂ«r tĂ« marrĂ« njĂ« listĂ« tĂ« plotĂ«. Jeni skeptikĂ« nĂ« lidhje me mĂ«nyrĂ«n se si do tĂ« funksionojĂ« nĂ«se keni qasje vetĂ«m nĂ« njĂ« nĂ«ngrup tĂ« kufizuar tĂ« hapĂ«sirave nĂ« klasĂ«r? Epo, sepse kubectl e bĂ«n kĂ«tĂ« saktĂ«sisht vetĂ«m nĂ«se RBAC ju lejon tĂ« shihni tĂ« gjitha hapĂ«sirat nĂ« klasĂ«r, dhe nĂ« klastrat e mĂ«dha, kĂ«to fuqitĂ« nuk jepen pĂ«r çdo njeri. Pra, kĂ«shtu qĂ«, pĂ«rgjigjja Ă«shtĂ«: pĂ«r OC, kjo nuk Ă«shtĂ« ndonjĂ« problem dhe ajo do tĂ« ofrojĂ« lehtĂ«sisht njĂ« listĂ« tĂ« plotĂ« nĂ« njĂ« situatĂ« tĂ« tillĂ«. KĂ«to detaje e formojnĂ« orientimin korporatist tĂ« Openshift dhe shkallĂ«zueshmĂ«rinĂ« e mirĂ« tĂ« kĂ«saj platforme nĂ« lidhje me pĂ«rdoruesit dhe aplikacionet.
2. ODO â njĂ« version i pĂ«rmirĂ«suar i kubectl pĂ«r zhvilluesit.
Si një shembull tjetër i përmirësimeve të Red Hat OpenShift në krahasim me Kubernetes, mund të përmendim utilitarin e linjës komandës ODO. Kjo është e dizajnuar për zhvilluesit dhe lejon që të shpërndani shpejt kodin lokal në një klasër të largët OpenShift. Për më tepër, me ndihmën e saj, mund të optimizoni proceset e brendshme për të sinkronizuar menjëherë të gjitha ndryshimet e kodit me kontenerët në klastrin e largët OpenShift pa qenë nevoja të rindizni ndërtimin, të vendosni në regjistër dhe të shpërndani përsëri imazhet.
Le të shohim se si OC dhe ODO e lehtësojnë punën me kontenierët dhe Kubernetes.
Thjesht krahasojmë disa proceset e punës, kur ato ndërtohen mbi kubectl, dhe kur përdoren OC ose ODO.
⹠Shpërndarja e kodit në OpenShift për ata që nuk e zotërojnë gjuhën YAML:
Kubernetes / kubectl
$> git clone
1- Krijojmë Dockerfile, duke ndërtuar imazhin nga kodi.
âââââ
FROM node
WORKDIR /usr/src/app
COPY package*.json ./
COPY index.js ./
COPY ./app ./app
RUN npm install
EXPOSE 3000
CMD [ ânpmâ, âstartâ ]
âââââ
2- Kryejmë ndërtimin e imazhit.
$> podman build âŠ
3- Bëjmë log in në regjistër.
podman login âŠ
4- Vendosim imazhin në regjistër.
podman push
5- KrijojmĂ« skedarĂ« yaml pĂ«r shpĂ«rndarjen e aplikacionit (deployment.yaml, service.yaml, ingress.yaml) â kjo Ă«shtĂ« minimumi absolut.
6- Shpërndajmë skedarët manifest:
Kubectl apply -f .
OpenShift / oc
$> oc new-app â emri_i_aplikacionit_tonĂ«
OpenShift / odo
$> git clone
$> odo create component nodejs myapp
$> odo push
⹠Ndërrimi i kontekstit: ndryshimi i hapësirës së punës ose klasrit të punës.
Kubernetes / kubectl
1- KrijojmĂ« njĂ« kontekst nĂ« kubeconfig pĂ«r projektin âmyprojectâ.
2- kubectl set-context âŠ
OpenShift / oc
oc project âmyprojectâ
Kontrolli i cilësisë: «Këtu u shfaq një veçori interesante, për momentin në versionin alfa. A do ta futim në prodhim?»
Imagjinoni qĂ« ju uleni nĂ« njĂ« bolid garash dhe ju thonĂ«: «Ne kemi vendosur frenat e njĂ« lloji tĂ« ri dhe, pĂ«r tĂ« qenĂ« tĂ« sinqertĂ«, pĂ«r momentin nuk janĂ« tĂ« gjitha nĂ« rregull me besueshmĂ«rinë⊠Por mos u shqetĂ«soni, do tâi pĂ«rmirĂ«sojmĂ« gjatĂ« kampionatit». Si ju duket kjo perspektivĂ«? Ne nĂ« Red Hat, ndoshta jo shumĂ«. đ
Prandaj, ne mundohemi të shmangim versionet alfa deri sa ato të mos jenë mjaft të pjekura dhe deri sa të kryejmë teste të kujdesshme dhe të ndiejmë se ato mund të përdoren në siguri. Zakonisht gjithçka kalon fillimisht përmes një faze Dev Preview, pastaj përmes dhe pastaj del në formën e një versioni publik (GA), i cili është aq i qëndrueshëm sa ishin të përshtatshëm për prodhim.
Pse kështu? Sepse, ashtu si në zhvillimin e çdo programi tjetër, jo të gjitha ide të para në Kubernetes arrijnë deri në versionin përfundimtar. Ose arrijnë, madje ruajnë funksionalitetin e menduar, por realizimi i tyre ndryshe nga ai në versionin alfa. Duke qenë se mijëra e mijëra klientë të Red Hat përdorin OpenShift për të mbështetur detyrat kritike, ne fokusoheshim shumë në stabilitetin e platformës tonë dhe në mbështetje të gjatë.
Red Hat qĂ«llimisht lĂ«shon versione tĂ« shpeshta tĂ« OpenShift dhe azhurnon versionin e Kubernetes qĂ« pĂ«rfshihet. PĂ«r shembull, nĂ« versionin GA tĂ« OpenShift 4.3, i cili ishte nĂ« kohĂ«n e shkruajtur kĂ«tĂ« artikull, pĂ«rfshihet Kubernetes 1.16, i cili Ă«shtĂ« vetĂ«m njĂ« version pas versionit upstream tĂ« Kubernetes me numrin 1.17. KĂ«shtu qĂ« ne mundohemi tâi ofrojmĂ« klientĂ«ve Kubernetes tĂ« klasĂ«s korporative dhe tĂ« sigurojmĂ« kontroll tĂ« shtuar tĂ« cilĂ«sisĂ« gjatĂ« lirimeve tĂ« verzioneve tĂ« reja tĂ« OpenShift.
Korrigjimet software: «Në atë version të Kubernetes që kemi në prodhim, u gjet një vrimë. Dhe mund të mbyllet vetëm me një azhurnim për tre versione lart. Apo ka mundësi të tjera?»
Në kuadër të projektit të hapur Kubernetes, korrigjimet software zakonisht dalin si pjesë e versionit të ardhshëm, ndonjëherë ato përfshijnë një ose dy versionet e mëparshme, duke ofruar mbulim për gjithçka deri në 6 muaj më parë.
Red Hat me kren është krenar për të lëshuar korrigjimet kritike më herët se të tjerët dhe për të ofruar mbështetje për një periudhë shumë më të gjatë. Le të marrim, për shembull, dobësinë me shkallëzimin e privilegjeve në Kubernetes (): ajo u zbulua në Kubernetes 1.11, dhe korrigjimet për versionet e mëparshme u lëshuan vetëm deri në versionin 1.10.11, duke lënë këtë vrimë në të gjitha versionet e mëparshme të Kubernetes, nga 1.x deri në 1.9.
Nga ana tjetër, (aty ndodhet Kubernetes 1.2), duke përfshirë nëntë lëshime të OpenShift dhe duke demonstruar qartë kujdesin për klientët (më shumë në ).
Si OpenShift dhe Red Hat e avancojnë Kubernetes
Red Hat zë vendin e dytë për përmasën e kontributeve programore në projektin e hapur Kubernetes, duke u munduar vetëm nga Google, ndërsa 3 nga 5 zhvilluesit më të prodhueshëm janë punonjës të Red Hat. Një fakt tjetër ndoshta i panjohur: shumë funksione kritikisht të rëndësishme u shfaqën në Kubernetes pikërisht nga iniciativat e Red Hat, veçanërisht atëherë kur:
- RBAC. NĂ« Kubernetes nuk kishte funksione RBAC (ClusterRole, ClusterRoleBinding) deri nĂ« momentin qĂ« inxhinierĂ«t e Red Hat vendosĂ«n t'i zbatojmĂ« ato si pjesĂ« tĂ« vetĂ« platformĂ«s, dhe jo si njĂ« funksionalitet shtesĂ« pĂ«r OpenShift. A ka frikĂ« Red Hat tĂ« pĂ«rmirĂ«sojĂ« Kubernetes? Sigurisht qĂ« jo, pasi Red Hat i pĂ«rmbahet rregullave tĂ« kodit tĂ« hapur dhe nuk luan me lojĂ«ra Open Core. PĂ«rmirĂ«simet dhe risitĂ« qĂ« realizohen nĂ« nivelin e komuniteteve tĂ« zhvillimit, dhe jo nĂ« bazĂ« tĂ« pronĂ«sisĂ«, bĂ«hen mĂ« tĂ« qĂ«ndrueshme dhe pĂ«rhapen mĂ« gjerĂ«sisht, gjĂ« qĂ« Ă«shtĂ« plotsisht nĂ« pĂ«rputhje me qĂ«llimin tonĂ« kryesor â tĂ« bĂ«jmĂ« softuerin me kod tĂ« hapur mĂ« tĂ« dobishĂ«m pĂ«r klientĂ«t tanĂ«.
- Politikat e sigurisë për podët (Pod Security Policies). Fillimisht, kjo koncept për ekzekutimin e sigurt të aplikacioneve brenda podëve u realizua në OpenShift me emrin SCC (Security Context Constraints). Si në shembullin e mëparshëm, Red Hat vendosi të integrojë këto zhvillime në projektin e hapur Kubernetes, për ta bërë të mundur që të gjithë që e duan t'i përdorin atë.
Ky rresht shembujsh mund të vazhdojë, por ne thjesht dëshironim të tregojmë se Red Hat me të vërtetë synon të zhvillojë Kubernetes dhe ta bëjë atë më të mirë për të gjithë.
E qartĂ«, OpenShift Ă«shtĂ« Kubernetes. Por çfarĂ« janĂ« dallimet? đ
Shpresojmë që, pasi të keni arritur në këtë pikë, keni kuptuar se Kubernetes është komponenti kryesor i OpenShift. Kryesor, por jo i vetmi. Me fjalë të tjera, thjesht duke instaluar Kubernetes, nuk do të merrni një platformë të klasit të korporatave. Do t'ju duhet të shtoni autentikimin, rrjetin, sigurinë, monitorimin, menaxhimin e të dhënave dhe shumë të tjera. Për më tepër, do të duhet të bëni një zgjedhje të vështirë nga një numër të madh mjetesh të disponueshme (për të vlerësuar ndryshueshmërinë e ekosistemit, thjesht shikoni ) dhe ndonjëherë të siguroheni për koherencën dhe bashkëpunimin që ato të funksionojnë si një tërësi. Për më tepër, do t'ju duhet të bëni përditësime të rregullta dhe teste regresive sa herë që del një version i ri i ndonjë prej komponentëve të përdorur. Pra, përveç krijimit dhe mbështetjes së platformës vetë, do t'ju duhet të punoni gjithashtu me gjithë këtë softuer. Pak gjasa ka që të mbetet shumë kohë për zgjidhjen e detyrave biznesore dhe arritjen e avantazheve konkurruese.
Në rastin e OpenShift, kompania Red Hat merr përsipër të gjitha këto territa të ndërlikuara dhe thjesht ju ofron një platformë funksionalisht të plotë, e cila përfshin jo vetëm Kubernetesin vetë, por edhe të gjithë paketën e mjeteve të nevojshme me kod të hapur, që e kthejnë Kubernetesin në një zgjidhje të vërtetë të klasit korporativ, e cila mund të vihet menjëherë dhe pa shqetësime në prodhim. Dhe sigurisht, nëse keni disa teknologji të tjera të zhvillimit, mund ta integrosh OpenShift në zgjidhjet që tashmë keni.
Shikoni ilustrimin më sipër: gjithçka që ndodhet jashtë drejtkëndshit Kubernetes, është ato zona ku Red Hat shton funksionalitete që nuk ekzistojnë në Kubernetes, siç quhet, me dizajn. Dhe tani do të shqyrtojmë disa nga këto fusha kryesore.
1. Një sistem operativ i besueshëm si bazë: RHEL CoreOS ose RHEL
Red Hat Ă«shtĂ« njĂ« nga ofruesit kryesorĂ« tĂ« distribucioneve Linux pĂ«r aplikacione kritikĂ« tĂ« biznesit, pĂ«r mĂ« shumĂ« se 20 vjet. Ekspertiza e ndĂ«rtuar dhe e rinovuar vazhdimisht nĂ« kĂ«tĂ« fushĂ« na lejon tĂ« ofrojmĂ« njĂ« bazĂ« tĂ« vĂ«rtetĂ« tĂ« besueshme dhe tĂ« qĂ«ndrueshme pĂ«r operimin industrial tĂ« kontejnerĂ«ve. RHEL CoreOS pĂ«rdor tĂ« njĂ«jtin kernel si RHEL, por Ă«shtĂ« optimizuar kryesisht pĂ«r detyra si ekzekutimi i kontejnerĂ«ve dhe funksionimi nĂ« klasterin Kubernetes: madhĂ«sia e saj e reduktuar dhe paprikat (immutability) e saj thjeshton instalimin e klasterĂ«ve, shpĂ«rndarjen automatikisht, patchimin etj. TĂ« gjitha kĂ«to karakteristika e bĂ«jnĂ« atĂ« bazĂ«n ideale pĂ«r tĂ« ofruar njĂ« pĂ«rvojĂ« tĂ« njĂ«jtĂ« pĂ«rdoruesi kur pĂ«rdor OpenShift nĂ« njĂ« gamĂ« tĂ« gjerĂ« mjedisesh kompjuterike, nga âhardueri i pastĂ«râ deri nĂ« re private dhe publike.
2. Automatizimi i Operacioneve IT
Automatizimi i proceseve të instalimit dhe operacioneve të ditës së dytë (dmth, operacioni përditshëm) është pika e fortë e OpenShift, e cila ndihmon shumë në administrimin, përditësimin dhe ruajtjen e operimit të platformës së kontejnerëve në nivele të larta. Kjo arrihet përmes mbështetjes së operatorëve Kubernetes në nivelin thelbësor të OpenShift 4.
OpenShift 4 gjithashtu është një ekosistem i tërë zgjidhjesh të bazuara në operatorë Kubernetes, të zhvilluara si nga Red Hat ashtu edhe nga partnerë të tretë (shiko Red Hat, ose dyqanin e operatorëve , i krijuar nga Red Hat për zhvillues të tretë).
Katalogu e integruar i OpenShift 4 ka më shumë se 180 operatorë Kubernetes
3. Vegla për Zhvilluesit
Që nga viti 2011, OpenShift ka qenë në dispozitë si një platformë PaaS (Platform-as-a-Service), e cila e bën shumë më të lehtë jetën e zhvilluesve, duke i ndihmuar ata të fokusohen në krijimin e kodit dhe duke ofruar mbështetje të integruar për gjuhë programimi si Java, Node.js, PHP, Ruby, Python, Go, si dhe shërbime të integrimit dhe shpërndarjes së vazhdueshme CI/CD, bazat e të dhënave etj. OpenShift 4 ofron , që përfshin më shumë se 100 shërbime të bazuara në operatorë Kubernetes, të zhvilluara nga Red Hat dhe partnerët tanë.
Ndryshe nga Kubernetes, OpenShift 4 ka një ndërfaqe grafike speciale (), që ndihmon zhvilluesit të ndajnë aplikacione nga burime të ndryshme (git, regjistra të jashtëm, Dockerfile etj.) në hapësirat e tyre emërore dhe vizualizon në mënyrë të qartë lidhjet midis komponenteve të aplikacionit.
PĂ«r mĂ« tepĂ«r, OpenShift ofron njĂ« grup mjetesh zhvillimi Codeready, ku pĂ«rfshihet, nĂ« veçanti, , njĂ« IDE e plotĂ« e containerizuar me njĂ« ndĂ«rfaqe nĂ« ueb, qĂ« funksionon direkt mbi OpenShift dhe implementon qasje "IDE-si shĂ«rbim". Nga ana tjetĂ«r, pĂ«r ata qĂ« dĂ«shirojnĂ« tĂ« punojnĂ« nĂ« mĂ«nyrĂ« strikte nĂ« mĂ«nyrĂ« lokale, ekziston Codeready Containers â njĂ« version me karakteristika tĂ« plota tĂ« OpenShift 4, qĂ« mund tĂ« vihet nĂ« operacion nĂ« laptop.
IDE e integruar si shërbim për zhvillim efikas në platformën Kubernetes/OpenShift.
Direkt nga kutia, OpenShift ofron një sistem të plotë CI/CD, ose në bazë të Jenkins i containerizuar dhe plugin-in për punimin me konvjerat, ose një sistem CI/CD të orientuar ndaj Kubernetes (ende në versionin Tech preview). Të dyja këto zgjidhje integrohen plotësisht me konsolën OpenShift, duke lejuar aktivizimin e konvjerëve, shikimin e shpërndarjeve, logëve etj.
4. Mjetet për aplikacionet
OpenShift lejon ndarjen si të aplikacioneve tradicionale stateful ashtu edhe të zgjidhjeve cloud-native të bazuara në arkitektura të reja, të tilla si mikroshërbimet ose pa server. Zgjidhja OpenShift Service Mesh ofron nga kutia mjete kyçe për menaxhimin e mikroshërbimeve, si Istio, Kiali dhe Jaeger. Në anën tjetër, zgjidhja OpenShift Serverless përfshin jo vetëm Knative, por edhe mjete të krijuara në kuadër të iniciativës së përbashkët me Microsoft, si Keda për ofrimin e funksioneve Azure në platformën OpenShift.
Zgjidhja e integruar OpenShift ServiceMesh (Istio, Kiali, Jaeger) është e dobishme në zhvillimin e mikroshërbimeve.
Për të reduktuar diferencën midis aplikacioneve të trashëguara dhe konteinerëve, OpenShift tani lejon migrimin e makinave virtuale në platformën OpenShift duke përdorur Virtualizimin Native të Konteinerëve (ende në versionin TechPreview), duke e bërë të mundur realizimin e aplikacioneve hibride dhe lehtësuar transferimin e tyre midis cloud-eve të ndryshme, si ato private ashtu edhe publike.
Makinë virtuale Windows 2019 Virtual, e cila funksionon në OpenShift përmes Virtualizimit Native të Konteinerëve (ende në versionin Tech preview).
5. Mjetet për klasterat
Ădo platformĂ« me klas tĂ« korporatĂ«s duhet tĂ« ketĂ« shĂ«rbime monitorimi dhe logim tĂ« centralizuar, mekanizma sigurie, autentifikimi dhe autorizimi, mjete pĂ«r menaxhimin e rrjetit. Dhe OpenShift ofron tĂ« gjitha kĂ«to nga kuti, dhe qĂ« tĂ« gjitha janĂ« 100% kod i hapur, duke pĂ«rfshirĂ« zgjidhje si ElasticSearch, Prometheus, Grafana. TĂ« gjitha kĂ«to zgjidhje vijnĂ« me panele informuese, metrika dhe njoftime, tĂ« cilat tashmĂ« janĂ« tĂ« konceptuara dhe tĂ« konfiguruara duke marrĂ« parasysh pĂ«rvojĂ«n e gjerĂ« tĂ« Red Hat nĂ« fushĂ«n e monitorimit tĂ« grupeve, duke lejuar qĂ« qĂ« nga minutat e para tĂ« kontrolloni dhe ndjekni nĂ« mĂ«nyrĂ« efektive mjedisin tuaj tĂ« prodhimit.
Në OpenShift gjithashtu standardisht ka gjëra kaq të rëndësishme për klientët e korporatave si autentifikimi me ofruesin e integruar oauth, integrimi me ofruesit e kredencialeve, përfshirë LDAP, ActiveDirectory, OpenID Connect, dhe shumë më tepër.
Paneli informativ i parainstalueshëm Grafana për monitorimin e grupit OpenShift
Më shumë se 150 metrika dhe njoftime të parainstaluara Prometheus për monitorimin e grupit OpenShift
Vazhdon
Funksionaliteti i pasur i zgjidhjes dhe pĂ«rvoja e gjerĂ« e Red Hat nĂ« fushĂ«n e Kubernetes â kĂ«to janĂ« arsyet pĂ«rse OpenShift ka marrĂ« njĂ« pozicion dominuese nĂ« treg, siç tregohet nĂ« figurĂ«n mĂ« poshtĂ«. ).
«Aktualisht Red Hat udhëheq në treg me një pjesë prej 44%.
Kompania po korr frytet e strategjisë së saj të shitjeve me pjesëmarrje aktive në çështjet e klientëve, në kuadër të së cilës ajo fillimisht këshillon dhe trajnon zhvilluesit e korporatave, dhe më pas kalon në monetizim ndërsa sipërmarrja fillon të implementojë kontejnerët në prodhim».
(Source: )
Shpresojmë që ju pëlqeu ky artikull. Në postimet e ardhshme të kësaj serie ne do të ndalemi më në detaje në avantajet e OpenShift për shkak të Kubernetes në çdo një nga kategoritë e shqyrtuara këtu.
Burimi: habr.com
