«ĂfarĂ« Ă«shtĂ« ndryshimi midis Kubernetes dhe OpenShift?» â ky pyetje shfaqet me njĂ« frekuencĂ« tĂ« admirueshme. NĂ« tĂ« vĂ«rtetĂ«, Ă«shtĂ« si tĂ« pyesĂ«sh se çfarĂ« e ndan njĂ« makinĂ« nga njĂ« motor. NĂ«se vazhdojmĂ« me kĂ«tĂ« krahasim, makina Ă«shtĂ« njĂ« produkt i gatshĂ«m, i cili mund tĂ« pĂ«rdoret menjĂ«herĂ«: u ul dhe nise. Nga ana tjetĂ«r, pĂ«r tĂ« bĂ«rĂ« qĂ« motorri tĂ« tĂ« çojĂ« diku, ai duhet tĂ« plotĂ«sohet me shumĂ« gjĂ«ra tĂ« tjera, nĂ« mĂ«nyrĂ« qĂ« tĂ« kemi atĂ« makinĂ«.
Prandaj, Kubernetes është ai motor, rreth të cilit është mbledhur makina (platforma) e markës OpenShift, e cila të çon drejt qëllimit.
Në këtë artikull, ne duam të kujtojmë dhe të shpjegojmë pak më hollësisht këto pika kyçe:
- Kubernetes është zemra e platformës OpenShift. Dhe kjo është një Kubernetes i certifikuar 100%, me kod tërësisht të hapur dhe pa asnjë element pronësor. Në përmbledhje:
- API për klasterin OpenShift është një Kubernetes 100%.
- Nëse një kontenier funksionon në çdo sistem tjetër Kubernetes, atëherë ai do të funksionojë pa asnjë ndryshim edhe në OpenShift. Nuk është e nevojshme të bëhen ndryshime në aplikacione.
- OpenShift jo vetĂ«m qĂ« plotĂ«son Kubernetes me funksionalitete dhe mundĂ«si tĂ« dobishme. Ashtu si njĂ« makinĂ«, OpenShift Ă«shtĂ« menjĂ«herĂ« i gatshĂ«m pĂ«r t'u pĂ«rdorur, mund tĂ« vendoset nĂ« prodhim menjĂ«herĂ« dhe, siç do tĂ« tregojmĂ« mĂ« poshtĂ«, ndihmon shumĂ« zhvilluesin. Kjo Ă«shtĂ« arsyeja pse OpenShift Ă«shtĂ« i veçantĂ« nĂ« dy mĂ«nyra. ĂshtĂ« njĂ« platformĂ« PaaS e klasĂ«s sipĂ«rmarrĂ«se, e njohur dhe e suksesshme nga perspektiva e zhvilluesve. Dhe njĂ«kohĂ«sisht Ă«shtĂ« njĂ« zgjidhje jashtĂ«zakonisht tĂ« besueshme e tipit Container-as-a-Service nga pikĂ«pamja e funksionimit industrial.
OpenShift është Kubernetes me 100% certifikatë nga fondi CNCF
Në thelb të OpenShift qëndron . Prandaj, pas trajnimit përkatës, përdoruesit admirojnë fuqinë e kubectl. Ata që kanë kaluar në OpenShift nga Kubernetes Cluster shpesh thonë se u pëlqen shumë fakti që pas ridrejtimit të kubeconfig në klusterin OpenShift, të gjithë skriptet ekzistuese funksionojnë pa ndonjë problem.
Sigurisht që keni dëgjuar për mjetin e komandave të OpenShift quajtur OC. Ai është plotësisht i pajtueshëm me komandat e kubectl dhe ofron disa ndihmës të dobishëm që do t'ju nevojiten për një sërë detyrash. Por fillimisht, le të flasim pak më shumë për pajtueshmërinë e OC me 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
Ja si duken rezultatet e përdorimit të kubectl në OpenShift API:
âą kubectl get pods â ktheu qĂ« Ă«shtĂ« e pritshme podâĂ«.
âą kubectl get namespaces â gjithashtu ktheu hapĂ«sirat e emĂ«rtimeve siç u prite.
Komanda kubectl create -f mydeployment.yaml krijon burimet kubernetes në të njëjtën mënyrë si në çdo platformë tjetër Kubernetes, siç tregohet në videon më poshtë:
Me fjalĂ« tĂ« tjera, tĂ« gjitha API-tĂ« e Kubernetes janĂ« plotĂ«sisht tĂ« aksesueshme nĂ« OpenShift me 100% pajtueshmĂ«ri. PĂ«r kĂ«tĂ« arsye .â
OpenShift e plotëson Kubernetes me funksione të dobishme
API të Kubernetes janë 100% në dispozitë në OpenShift, por utilitari standard i Kubernetes, kubectl, i mungon qartë funksionaliteti dhe lehtësia e përdorimit. Prandaj, Red Hat ka plotësuar Kubernetes me funksione të dobishme dhe mjete komandash, si OC (shkurt për OpenShift client) dhe ODO (OpenShift DO, ky utilitar është i dizajnuar për zhvilluesit).
1. Utilitari OC â njĂ« opsion mĂ« i fuqishĂ«m dhe i lehtĂ« pĂ«r t'u pĂ«rdorur sesa Kubectl
Për shembull, në dallim nga kubectl, ai lejon krijimin e hapësirave të reja emërtimi dhe kalimin e lehtë të kontekstit, si dhe ofron një sërë komandash të dobishme për zhvilluesit, si për ndërtimin e imazhve të kontejnerëve dhe për shpërndarjen e aplikacioneve drejtpërdrejt nga kodet burimore ose skedarët binarë (Source-to-image, s2i).
Le të shohim me shembuj se si ndihmuesit e ndërtuar dhe funksionaliteti i zgjeruar i utilitarit OC ndihmojnë për të thjeshtuar punën e përditshme.
Shembuj i parĂ« â menaxhimi i hapĂ«sirave tĂ« emrave. NĂ« çdo klaster Kubernetes gjithmonĂ« ka disa hapĂ«sira emrash. Normalisht ato pĂ«rdoren pĂ«r tĂ« krijuar mjedise zhvillimi dhe prodhimi, por gjithashtu mund tĂ« pĂ«rdoren pĂ«r tĂ« ofruar njĂ« "sandbox" personal pĂ«r çdo zhvillues. NĂ« praktikĂ«, kjo çon nĂ« nevojĂ«n qĂ« zhvilluesi tĂ« kalojĂ« shpesh midis hapĂ«sirave emrash, pasi kubectl funksionon nĂ« kontekstin e hapĂ«sirĂ«s aktuale. Prandaj, pĂ«r kubectl, njerĂ«zit aktivisht pĂ«rdorin skriptet ndihmĂ«se pĂ«r kĂ«tĂ«. NdĂ«rsa pĂ«r pĂ«rdorimin e OC, pĂ«r tĂ« kaluar nĂ« hapĂ«sirĂ«n e nevojshme, mjafton tĂ« thuash "oc project hapĂ«sirĂ«_emri".
Nuk e mbani mend se si quhet hapësira e nevojshme? Asnjë problem, thjesht shkruani "oc get projects" për të shfaqur një listë të plotë. A jeni skeptikë se si do të funksionojë kjo nëse keni akses vetëm në një nëngrup të kufizuar të hapësirave në klaster? Epo, sepse kubectl e bën këtë saktë vetëm nëse RBAC ju lejon të shihni të gjitha hapësirat në klaster, dhe në klasterët më të mëdhenj këto të drejta nuk iu jepen të gjithëve. Pra, për OC kjo nuk është problem fare dhe do të japë lehtësisht një listë të plotë në një situatë të tillë. Këto detaje e formojnë orientimin korporativ të Openshift dhe shkallëzueshmërinë e mirë të kësaj platforme për përdoruesit dhe aplikacionet.
2. ODO â versioni 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ërmendet utilitari ODO. Ai është i destinuar për zhvilluesit dhe lehtëson shpërndarjen e shpejtë të kodit lokal në një klaster të largët OpenShift. Për më tepër, me anë të tij është e mundur të optimizohen proceset e brendshme, duke sinkronizuar menjëherë të gjitha ndryshimet e kodit me kontejnerët në klasterin e largët OpenShift pa nevojën për të ndërtuar përsëri, për të ngarkuar në regjistër dhe për të ribërtuar imazhet.
Le t'i hedhim një sy se si OC dhe ODO lehtësojnë punën me kontejnerë dhe Kubernetes.
Thjesht do të krahasojmë disa punëprona, kur ato ndërtohen mbi bazën e kubectl dhe kur shkarkohen 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- Krijoni Dockerfile që ndërton 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- Ndërmerrni ndërtimin e imazhit
$> podman build âŠ
3- Identifikohuni në regjistër
podman login âŠ
4- Ngarkoni 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 klasterit të punës.
Kubernetes / kubectl
1- KrijojmĂ« kontekstin nĂ« kubeconfig pĂ«r projektin âmyprojectâ
2- kubectl set-context âŠ
OpenShift / oc
oc project âmyprojectâ
Kontrolli i cilësisë: «Këtu u shfaq një tipar interesant, për momentin në versionin alpha. A mund ta shtojmë atë në prodhim?»
Imagjinoni qĂ« ju uleni nĂ« njĂ« makinĂ« gare dhe ju thonĂ«: «Ne vendosĂ«m frenat e njĂ« lloji tĂ« ri dhe, sinqerisht, ato nuk janĂ« ende tĂ« besueshme⊠Por mos u shqetĂ«so, do t'i pĂ«rmirĂ«sojmĂ« ato gjatĂ« kampionatit». Si ju duket kjo perspektivĂ«? PĂ«r ne nĂ« Red Hat nuk Ă«shtĂ« shumĂ« e ngrohtĂ«. đ
Prandaj, ne mundohemi të shmangim versionet alpha derisa ato të mos jenë mjaft të zhvilluara dhe ne të kemi kryer teste të hollësishme dhe të ndiejmë se mund të përdoren në mënyrë të sigurt. Zakonisht, gjithçka kalon fillimisht në fazën Dev Preview, pastaj në dhe vetëm pastaj del si një lëshim i përgjithshëm (GA), që është kaq i stabil sa është i përshtatshëm për prodhim.
Pse kështu? Sepse, ashtu si në zhvillimin e çdo software tjetër, jo të gjitha ideve fillestare në Kubernetes i arrijnë versione përfundimtare. Ose arrijnë, dhe madje ruajnë funksionalitetin e planifikuar, por realizimi i tyre ndryshe shumë nga ai që ishte në versionin alfa. Meqenëse mijëra e mijëra klientë të Red Hat përdorin OpenShift për mbështetje të detyrave kritike, ne themelojmë veçanërisht stabilitetin e platformës tonë dhe mbështetje afatgjatë.
Red Hat qëllimisht lëshon versionet e shpeshta të OpenShift dhe përditëson versionin e tij të Kubernetes. Për shembull, në versionin aktual GA të OpenShift 4.3, është përfshirë Kubernetes 1.16, që është vetëm një hap pas versionit upstream të Kubernetes me numrin 1.17. Kështu, ne përpiqemi të ofrojmë një Kubernetes të klasës enterprise dhe të sigurojmë kontroll dodat mbi cilësinë gjatë lëshimit të versioneve të reja të OpenShift.
Korrigjimet e programit: «Në atë version të Kubernetesit që kemi në prodhim, u gjet një hapësirë. Dhe mund të mbyllet vetëm me një përditësim në tre versione lart. Ose ka mundësi të tjera?»
Në kuadër të projektit të hapur Kubernetes, korrigjimet e programit zakonisht dalin si pjesë e lëshimit të ardhshëm, ndonjëherë ato mbulojnë një ose dy lëshime të mëparshme, duke ofruar mbulim deri në 6 muaj prapa.
Red Hat me të drejtë mburret se lëshon korrigjimet kritike më herët se të tjerët dhe ofron mbështetje për një periudhë shumë më të gjatë. Le të marrim, për shembull, dobësinë me ngritjen e privilegjeve në Kubernetes (): ajo u zbulua në Kubernetes 1.11, ndërsa korrigjimet për lëshimet e mëparshme u lëshuan vetëm deri në versionin 1.10.11, duke lënë këtë hapësirë në të gjitha lëshimet e mëparshme të Kubernetes, nga 1.x deri në 1.9.
Nga ana e saj, (aty njihet Kubernetes 1.2), duke përfshirë nëntë lëshime të OpenShift dhe duke demonstruar qartë kujdesin për klientët (më shumë ).
Si OpenShift dhe Red Hat e çojnë përpara Kubernetesin
Red Hat zë vendin e dytë për kontributin më të madh në projektin e hapur Kubernetes, duke e lënë pas only Google, dhe 3 nga 5 zhvilluesit më produktivë janë punonjës të Red Hat. Një fakt tjetër i njohur: shumë funksione thelbësore u shfaqën në Kubernetes falë iniciativës së Red Hat, në veçanti ato si:
- RBAC. NĂ« Kubernetes nuk kishte funksione RBAC (ClusterRole, ClusterRoleBinding) deri sa inxhinierĂ«t e Red Hat vendosĂ«n t'i implementonin ato si pjesĂ« tĂ« platformĂ«s vetĂ«, dhe jo si njĂ« funksionalitet shtesĂ« pĂ«r OpenShift. A e frikĂ«son Red Hat pĂ«rmirĂ«simi i Kubernetes? Sigurisht qĂ« jo, pasi Red Hat ndiqni rreptĂ«sisht parimet e kodit tĂ« hapur dhe nuk luan lojĂ«ra Open Core. PĂ«rmirĂ«simet dhe novacionet qĂ« realizohen nĂ« nivelin e komuniteteve tĂ« zhvillimit, dhe jo sipas parimit tĂ« pronĂ«sisĂ«, bĂ«hen mĂ« tĂ« jetueshme dhe pĂ«rhapen mĂ« gjerĂ«sisht, e cila pĂ«rputhet mjaft mirĂ« me qĂ«llimin tonĂ« kryesor â tĂ« bĂ«jmĂ« software me kod tĂ« hapur mĂ« tĂ« dobishĂ«m pĂ«r klientĂ«t tanĂ«.
- Politikat e sigurisĂ« pĂ«r podâĂ«t (Politikat e SigurisĂ« tĂ« Pod). Iniciativa pĂ«r sigurimin e aplikacioneve brenda podâĂ«ve fillimisht u realizua nĂ« OpenShift me emrin SCC (KufijtĂ« e Kontekstit tĂ« SigurisĂ«). Ashtu si nĂ« shembullin e mĂ«parshĂ«m, Red Hat vendosi tĂ« integrojĂ« kĂ«to trajtime nĂ« projektin e hapur Kubernetes pĂ«r t'i bĂ«rĂ« ato tĂ« disponueshme pĂ«r tĂ« gjithĂ«.
Ky radhë shembujsh mund të vazhdojë, por ne thjesht dëshironim të tregojmë se Red Hat vërtet po punon për të zhvilluar Kubernetes dhe për ta bërë atë më të mirë për të gjithë.
E qartĂ«, OpenShift Ă«shtĂ« Kubernetes. Por çfarĂ« janĂ« ndryshimet? đ
ShpresojmĂ« se, pasi tĂ« keni lexuar deri nĂ« kĂ«tĂ« pikĂ«, keni kuptuar se Kubernetes Ă«shtĂ« komponenti kryesor i OpenShift. Kryesor, por jo i vetmi. NĂ« tjera fjalĂ«, thjesht duke instaluar Kubernetes, nuk do tĂ« merrni njĂ« platformĂ« tĂ« nivelit tĂ« korporatave. Do t'ju duhet tĂ« shtoni autentifikim, rrjet, siguri, monitorim, menaxhim log-esh dhe shumĂ« mĂ« tepĂ«r. PĂ«r mĂ« tepĂ«r, do tĂ« duhet tĂ« bĂ«ni njĂ« zgjedhje tĂ« vĂ«shtirĂ« nga shumĂ« mjete tĂ« disponueshme (pĂ«r tĂ« vlerĂ«suar larmishmĂ«rinĂ« e ekosistemĂ«s, thjesht shihni) ) dhe si ndihmĂ« qĂ« tĂ« sigurohet koherenca dhe bashkĂ«punimi, qĂ« ato tĂ« punojnĂ« si njĂ« e tĂ«rĂ«. PĂ«rveç kĂ«saj, do t'ju duhet tĂ« kryeni rregullisht azhurnime dhe testime regresioni sa herĂ« qĂ« ndonjĂ« nga komponentĂ«t e pĂ«rdorur lĂ«shohet nĂ« njĂ« version tĂ« ri. KĂ«shtu, pĂ«rveç ndĂ«rtimit dhe mirĂ«mbajtjes sĂ« vetĂ« platformĂ«s, do t'ju duhet tĂ« merret gjithashtu me kĂ«tĂ« softuer. ĂshtĂ« e vĂ«shtirĂ« qĂ« tĂ« mbetet shumĂ« kohĂ« pĂ«r tĂ« zgjidhur detyrat e biznesit dhe arritur avantazhe konkurruese.
Në rastin e OpenShift, kompania Red Hat merr përsipër të gjitha këto vështirësi dhe thjesht ju ofron një platformë funksionale, e cila përfshin jo vetëm Kubernetes-in, por gjithashtu gjithë paketën e nevojshme të mjeteve me kod të hapur, që e kthen Kubernetes-in në një zgjidhje të klasës korporative, e cila mund të fillohet menjëherë dhe me qetësi në prodhim. Sigurisht, nëse keni disa teknologji të tjera, mund ta integroni OpenShift në zgjidhjet që keni tashmë.
Shikoni figurën e mësipërme: çdo gjë që ndodhet jashtë drekatërit Kubernetes është ato fusha ku Red Hat shton funksionalitet që nuk është në Kubernetes, që e quajmë, by-design. Tani do të shqyrtojmë disa nga këto fusha kryesore.
1. Një OS e besueshme si bazë: RHEL CoreOS ose RHEL
Red Hat ka mĂ« shumĂ« se 20 vjet qĂ« Ă«shtĂ« lider nĂ« ofrimin e distribucioneve Linux pĂ«r aplikacionet kritike tĂ« bizneseve. Eksperienca e pĂ«rfituar dhe e pĂ«rditĂ«suar vazhdimisht nĂ« kĂ«tĂ« fushĂ« na lejon tĂ« ofrojmĂ« njĂ« bazĂ« tĂ« vĂ«rtetĂ« tĂ« besueshme dhe tĂ« sigurt pĂ«r operimin e konteinerĂ«ve. RHEL CoreOS pĂ«rdor tĂ« njĂ«jtin bĂ«rthamĂ« si RHEL, por Ă«shtĂ« optimizuar kryesisht pĂ«r detyra si ekzekutimi i konteinerĂ«ve dhe funksionimi nĂ« klasterat Kubernetes: madhĂ«sia e saj e reduktuar dhe pa ndryshime (immutability) e lehtĂ«son instalimin e klasterave, automatikisht shkallĂ«zimin, shpĂ«rndarjen e ndreqjeve etj. TĂ« gjitha kĂ«to funksionalitete e bĂ«jnĂ« atĂ« njĂ« bazĂ« ideale pĂ«r tĂ« ofruar njĂ« pĂ«rvojĂ« tĂ« njĂ«jtĂ« pĂ«rdoruesi kur punoni me OpenShift nĂ« njĂ« gamĂ« tĂ« gjerĂ« ambientesh llogaritĂ«se, nga âmetal i pastĂ«râ deri nĂ« cloud privat dhe publik.
2. Automatizimi i operacioneve IT
Automatizimi i proceseve të instalimit dhe operacioneve të ditës së dytë (pra, funksionimit të përditshëm) është një nga njësitë kryesore të OpenShift, që ndihmon ndjeshëm në administrimin, përditësimin dhe ruajtjen e punës së platformës me konteinerë në nivele të larta. Kjo arrihet përmes mbështetjes për operatorët Kubernetes në nivelin e bërthamës OpenShift 4.
OpenShift 4 është gjithashtu një ekosistem i tërë zgjidhjesh të bazuara në operatorët Kubernetes, të zhvilluara si nga Red Hat ashtu edhe nga partnerët e jashtëm (shih. Red Hat, ose dyqanin e operatorëve , i krijuar nga Red Hat për zhvilluesit e jashtëm).
Katalogu i integruar i OpenShift 4 përmban më shumë se 180 operatorë Kubernetes.
3. Veglat për zhvilluesit
Që nga viti 2011, OpenShift është në dispozicion si një platformë PaaS (Platform-as-a-Service), e cila e lehtëson ndjeshëm jetën e zhvilluesve, ndihmon ata të përqendrohen në krijimin e kodit dhe ofron mbështetje të integruar për gjuhë programimi si Java, Node.js, PHP, Ruby, Python, Go, si dhe shërbime të integrimit dhe dorëzimit të vazhdueshëm CI/CD, baza të të dhënave etj. OpenShift 4 ofron , duke përfshirë mbi 100 shërbime që janë të bazuara në operatorët Kubernetes, të zhvilluar nga Red Hat dhe partnerët tanë.
Ndryshe nga Kubernetes, OpenShift 4 ka një ndërfaqe grafike të veçantë (), e cila ndihmon zhvilluesit të vendosin me lehtësi aplikacione nga burime të ndryshme (git, regjistra të jashtëm, Dockerfile etj.) në hapësirat e tyre të emrit dhe vizualizon qartë lidhjet midis komponenteve të aplikacionit.
PĂ«r mĂ« tepĂ«r, OpenShift ofron njĂ« grup mjetesh zhvillimi Codeready, ku pĂ«rfshihet , njĂ« IDE tĂ« plotĂ« tĂ« containerizuar me ndĂ«rfaqe web, qĂ« punon drejtpĂ«rdrejt mbi OpenShift dhe aplikon qasjen "IDE si shĂ«rbim". Nga ana tjetĂ«r, pĂ«r ata qĂ« duan tĂ« punojnĂ« vetĂ«m nĂ« modu lokal, ka Codeready Containers â njĂ« version i plotĂ« funksional i OpenShift 4, qĂ« mund tĂ« vendoset nĂ« laptop.
IDE e integruar "si shërbim" për zhvillim efikas në platformën Kubernetes/OpenShift.
Menjëherë nga kutia, OpenShift ofron një sistem të plotë CI/CD, ose në bazë të Jenkins të containerizuar dhe pluginin për punimin me konvejerët, ose një sistem CI/CD të orientuar ndaj Kubernetes (aktualisht në versionin Tech preview). Të dyja këto zgjidhje integrohen plotësisht me konsolën OpenShift, duke lejuar aktivizimin e konvejerëve, shikimin e shpërndarjeve, logeve etj.
4. Mjetet për aplikacione
OpenShift lejon shpërndarjen e aplikacioneve tradicionale stateful si dhe zgjidhjeve të orientuara ndaj përmendur në arkitektura të reja, si mikroshërbimet ose serverless. Zgjidhja OpenShift Service Mesh ofron nga kutia mjete të rëndësishme për mbështetje të mikroshërbimeve, si Istio, Kiali dhe Jaeger. Nga ana 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) do të jetë e dobishme gjatë zhvillimit të mikroshërbimeve
Për të reduktuar distancën ndërmjet aplikacioneve të trashëguara dhe kontejnerëve, OpenShift tani lejon migrimin e makinave virtuale në platformën OpenShift përmes Virtualizimit Native të Kontejnerëve (ndërsa ndodhet ende në versionin Tech Preview), duke e bërë realitet transformimin e aplikacioneve hibrid dhe duke e lehtësuar transferimin e tyre midis resurseve të ndryshme, si ato private, ashtu edhe ato publike.
Makinë virtuale Windows 2019 Virtual, e drejtuar në OpenShift përmes Virtualizimit Native të Kontejnerëve (ndërsa ndodhet ende në versionin Tech Preview)
5. Instrumentet për klasterët
Ădo platformĂ« e klasĂ«s korporative duhet tĂ« ketĂ« shĂ«rbime monitorimi dhe regjistrimi tĂ« centralizuar, mekanizma sigurie, autentifikimi dhe autorizimi, si dhe mjete pĂ«r menaxhimin e rrjetit. OpenShift ofron gjithçka nga ky paketim, dhe gjithçka Ă«shtĂ« kod i hapur 100%, duke pĂ«rfshirĂ« zgjidhje si ElasticSearch, Prometheus, dhe Grafana. TĂ« gjitha kĂ«to zgjidhje vijnĂ« me panelet e informacionit, metrikat dhe njoftimet, qĂ« janĂ« pĂ«rgatitur dhe konfiguruar duke marrĂ« parasysh pĂ«rvojĂ«n e gjerĂ« tĂ« Red Hat nĂ« monitorimin e klasterĂ«ve, duke e bĂ«rĂ« tĂ« mundur monitorimin dhe gjurmimin efektiv tĂ« ambientit tuaj tĂ« prodhimit qysh nĂ« minutat e para.
OpenShift ofron gjithashtu funksione të rëndësishme për klientët korporativë, si autentifikimi me ofruesin e integruar oauth, integrimi me ofruesit e kredencialeve, duke përfshirë LDAP, ActiveDirectory, OpenID Connect, dhe shumë më tepër.
Paneli informacioni i para-caktuar Grafana për monitorimin e klasit OpenShift
Më shumë se 150 metrika dhe njoftime të para-caktuara Prometheus për monitorimin e klasit OpenShift
Vazhdon
Funksionaliteti i pasur i zgjidhjes dhe pĂ«rvoja e gjerĂ« e Red Hat nĂ« fushĂ«n e Kubernetes â kĂ«to janĂ« arsyet pse OpenShift ka zĂ«nĂ« njĂ« pozitĂ« dominuese nĂ« treg, siç tregohet nĂ« figurĂ«n mĂ« poshtĂ« (mĂ« shumĂ« ).
Aktualisht Red Hat udhëheq në treg me një pjesë prej 44%.
Kompania po korr frytet e strategjisë së saj të shitjeve me angazhimin aktiv në çështjet e klientit, ku fillimisht këshillon dhe trajnon zhvilluesit korporativë, dhe më pas kalon në monetizim ndërsa ndërmarrja fillon të implementojë kontejnerët në prodhim.
(Burimi: )
Shpresojmë që ju ka pëlqyer ky artikull. Në postimet e ardhshme të kësaj series do të shqyrtojmë më në detaje përparësitë e OpenShift në krahasim me Kubernetes në secilën nga kategoritë e shqyrtuara këtu.
Burimi: habr.com
