Versioni i katërt i OpenShift u lëshua relativisht kohët e fundit. Versioni aktual 4.3 është i disponueshëm që nga fundi i janarit dhe të gjitha ndryshimet në të janë ose diçka krejtësisht e re që nuk ishte në versionin e tretë, ose një përditësim i madh i asaj që u shfaq në versionin 4.1. Gjithçka që do t'ju tregojmë tani duhet të njihet, kuptohet dhe merret parasysh nga ata që punojnë me OpenShift dhe planifikojnë të kalojnë në një version të ri.
Me lëshimin e OpenShift 4.2, Red Hat e ka bërë më të lehtë punën me Kubernetes. Janë shfaqur mjete dhe shtojca të reja për krijimin e kontejnerëve, tubacioneve CI/CD dhe vendosjeve pa server. Inovacionet u japin zhvilluesve mundësinë të përqëndrohen në shkrimin e kodit, dhe jo në trajtimin e Kubernetes.
Në fakt, çfarë ka të re në versionet e OpenShift 4.2 dhe 4.3?
Lëvizja drejt reve hibride
Kur planifikojnë një infrastrukturë të re TI ose kur zhvillojnë një peizazh ekzistues të TI-së, kompanitë po konsiderojnë gjithnjë e më shumë një qasje cloud për ofrimin e burimeve të TI-së, për të cilat ata zbatojnë zgjidhje private cloud ose përdorin fuqinë e ofruesve publikë të cloud. Kështu, infrastrukturat moderne të TI-së po ndërtohen gjithnjë e më shumë sipas një modeli "hibrid" të resë kompjuterike, kur përdoren si burimet e brendshme ashtu edhe burimet publike të resë kompjuterike me një sistem të përbashkët menaxhimi. Red Hat OpenShift 4.2 është krijuar posaçërisht për të thjeshtuar kalimin në një model hibrid cloud dhe e bën të lehtë lidhjen e burimeve nga ofruesit si AWS, Azure dhe Google Cloud Platform me grupin, së bashku me përdorimin e reve private në VMware dhe OpenStack.
Qasje e re për instalimin
Në versionin 4, qasja për instalimin e OpenShift ka ndryshuar. Red Hat ofron një mjet të veçantë për vendosjen e një grupi OpenShift - openshift-install. Shërbimi është një skedar i vetëm binar i shkruar në Go. Openshit-installer përgatit një skedar yaml me konfigurimin e kërkuar për vendosje.
Në rast të instalimit duke përdorur burimet e resë kompjuterike, do t'ju duhet të specifikoni informacionin minimal për grupin e ardhshëm: zona DNS, numri i nyjeve të punëtorëve, cilësimet specifike për ofruesin e cloud, informacioni i llogarisë për të hyrë në ofruesin e cloud. Pas përgatitjes së skedarit të konfigurimit, grupi mund të vendoset me një komandë.
Në rast instalimi në burimet tuaja kompjuterike, për shembull, kur përdorni një re private (vSphere dhe OpenStack mbështeten) ose kur instaloni në serverë metalikë të zhveshur, do t'ju duhet të konfiguroni manualisht infrastrukturën - përgatitni numrin minimal të makinave virtuale ose serverët fizikë të nevojshëm për të krijuar një grupim të Planit të Kontrollit, për të konfiguruar shërbimet e rrjetit. Pas këtij konfigurimi, një grup OpenShift mund të krijohet në mënyrë të ngjashme me një komandë të programit openshift-installer.
Përditësimet e infrastrukturës
Integrimi i CoreOS
Përditësimi kryesor është integrimi me Red Hat CoreOS. Nyjet kryesore të Red Hat OpenShift tani mund të funksionojnë vetëm në sistemin operativ të ri. Ky është një sistem operativ falas nga Red Hat që është krijuar posaçërisht për zgjidhjet e kontejnerëve. Red Hat CoreOS është një Linux i lehtë i optimizuar për drejtimin e kontejnerëve.
Nëse në 3.11 sistemi operativ dhe OpenShift ekzistonin veçmas, atëherë në 4.2 është i lidhur pazgjidhshmërisht me OpenShift. Tani kjo është një pajisje e vetme - infrastrukturë e pandryshueshme.
Për grupimet që përdorin RHCOS për të gjitha nyjet, përmirësimi i OpenShift Container Platform është një proces i thjeshtë dhe shumë i automatizuar.
Më parë, për të përditësuar OpenShift, së pari duhej të përditësoje sistemin operativ themelor në të cilin po funksiononte produkti (në atë kohë, Red Hat Enterprise Linux). Vetëm atëherë OpenShift mund të përditësohej gradualisht, nyje pas nyje. Nuk u fol për ndonjë automatizim të procesit.
Tani, meqenëse OpenShift Container Platform kontrollon plotësisht sistemet dhe shërbimet në secilën nyje, duke përfshirë OS, kjo detyrë zgjidhet duke shtypur një buton nga ndërfaqja e internetit. Pas kësaj, një operator i veçantë lëshohet brenda grupit OpenShift, i cili kontrollon të gjithë procesin e përditësimit.
CSI e re
Së dyti, CSI i ri është një kontrollues i ndërfaqes së ruajtjes që ju lejon të lidhni sisteme të ndryshme të ruajtjes së jashtme me grupin OpenShift. Një numër i madh i ofruesve të drejtuesve të ruajtjes për OpenShift mbështeten bazuar në drejtuesit e ruajtjes që janë shkruar nga vetë prodhuesit e sistemit të ruajtjes. Një listë e plotë e drejtuesve CSI të mbështetur mund të gjendet në këtë dokument: . Në këtë listë mund të gjeni të gjitha modelet kryesore të grupeve të disqeve nga prodhuesit kryesorë (Dell/EMC, IBM, NetApp, Hitachi, HPE, PureStorage), zgjidhjet SDS (Ceph) dhe ruajtjen në cloud (AWS, Azure, Google). OpenShift 4.2 mbështet drejtuesit CSI të versionit 1.1 të specifikimit CSI.
Rrjetë e shërbimit RedHat OpenShift
Bazuar në projektet Istio, Kiali dhe Jaeger, Red Hat OpenShift Service Mesh, përveç detyrave të zakonshme të rrugëtimit të kërkesave ndërmjet shërbimeve, lejon gjurmimin dhe vizualizimin e tyre. Kjo i ndihmon zhvilluesit të komunikojnë, monitorojnë dhe menaxhojnë me lehtësi një aplikacion të vendosur brenda Red Hat OpenShift.
Vizualizimi i një aplikacioni që ka një arkitekturë mikroservice duke përdorur Kiali
Për të thjeshtuar instalimin, mirëmbajtjen dhe menaxhimin e ciklit jetësor të Service Mesh sa më shumë që të jetë e mundur, Red Hat OpenShift u ofron administratorëve një operator të veçantë, Operatorin Service Mesh. Ky është një operator Kubernetes që ju lejon të vendosni paketat e rikonfiguruara Istio, Kiali dhe Jaeger në një grup, duke maksimizuar barrën administrative të menaxhimit të aplikacioneve.
CRI-O në vend të Docker
Koha e paracaktuar e ekzekutimit të kontejnerit Docker është zëvendësuar nga CRI-O. Ishte e mundur të përdorej CRI-O tashmë në versionin 3.11, por në 4.2 u bë kryesori. Jo mirë apo keq, por diçka që duhet mbajtur parasysh kur përdorni produktin.
Operatorët dhe vendosja e aplikacioneve
Operatorët janë një ent i ri për RedHat OpenShift, i cili u shfaq në versionin e katërt. Është një metodë e paketimit, vendosjes dhe menaxhimit të një aplikacioni Kubernetes. Mund të mendohet si një shtojcë për aplikacionet e vendosura në kontejnerë, të drejtuar nga Kubernetes API dhe veglat kubectl.
Operatorët Kubernetes ndihmojnë në automatizimin e çdo detyre që lidhet me administrimin dhe menaxhimin e ciklit jetësor të aplikacionit që vendosni në grupin tuaj. Për shembull, operatori mund të automatizojë përditësimet, kopjet rezervë dhe shkallëzimin e aplikacionit, të ndryshojë konfigurimin, etj. Një listë e plotë e operatorëve mund të gjendet në .
OperatorHub është i aksesueshëm drejtpërdrejt nga ndërfaqja në internet e konsolës së menaxhimit. Është një direktori aplikacioni për OpenShift i mirëmbajtur nga Red Hat. Ato. të gjithë operatorët e miratuar nga Red Hat do të mbulohen nga mbështetja e shitësit.
Portali OperatorHub në tastierën e menaxhimit OpenShift
Imazhi bazë universale
Është një grup i standardizuar imazhesh RHEL OS që mund të përdoren për të ndërtuar aplikacionet tuaja të kontejnerizuara. Ka komplete minimale, standarde dhe të plota. Ata zënë shumë pak hapësirë dhe mbështesin të gjitha paketat e nevojshme të instaluara dhe gjuhët e programimit.
Mjetet CI/CD
Në RedHat OpenShif 4.2, u bë e mundur të zgjidhni midis Jenkins dhe OpenShift Pipelines bazuar në Tekton Pipelines.
OpenShift Pipelines bazohet në Tekton, i cili mbështetet më mirë nga Pipeline ndërsa afrohet Kodi dhe GitOps. Në tubacionet OpenShift, çdo hap shkon në kontejnerin e vet, kështu që burimet përdoren vetëm gjatë ekzekutimit të hapit. Kjo u jep zhvilluesve kontroll të plotë mbi tubacionet e shpërndarjes së moduleve, shtojcat dhe kontrollin e aksesit pa një server qendror CI/CD për të menaxhuar.
OpenShift Pipelines është aktualisht në Parashikimin e Zhvilluesit dhe disponohet si operator në një grup OpenShift 4. Sigurisht, përdoruesit e OpenShift mund të përdorin ende Jenkins në RedHat OpenShift 4.
Përditësimet e menaxhimit të zhvilluesve
Në 4.2 OpenShift, ndërfaqja e uebit është përditësuar plotësisht si për zhvilluesit ashtu edhe për administratorët.
Në versionet e mëparshme të OpenShift, të gjithë punonin në tre konzola: drejtoria e shërbimit, tastiera e administratorit dhe tastiera e punës. Tani grupi është i ndarë në vetëm dy pjesë - tastiera e administratorit dhe tastiera e zhvilluesit.
Konsola e Zhvilluesit ka marrë përmirësime të rëndësishme të ndërfaqes së përdoruesit. Tani ai shfaq në mënyrë më të përshtatshme topologjitë e aplikacioneve dhe asambletë e tyre. Kjo e bën më të lehtë për zhvilluesit të krijojnë, vendosin dhe vizualizojnë aplikacionet e kontejnerëve dhe burimet e grumbulluara. I lejon ata të përqendrohen në atë që është e rëndësishme për ta.
Portali i zhvilluesve në tastierën e menaxhimit OpenShift
Veshit
Odo është një mjet i linjës komanduese të orientuar nga zhvilluesi që thjeshton zhvillimin e aplikacionit në OpenShift. Duke përdorur komunikimin e stilit git push, kjo CLI ndihmon zhvilluesit e rinj në Kubernetes të ndërtojnë aplikacione në OpenShift.
Integrimi me mjediset e zhvillimit
Zhvilluesit tani mund të ndërtojnë, korrigjojnë dhe vendosin aplikacionet e tyre në OpenShift pa lënë mjedisin e tyre të preferuar të zhvillimit të kodit, si Microsoft Visual Studio, JetBrains (përfshirë IntelliJ), Eclipse Desktop, etj.
Shtesa e vendosjes së Red Hat OpenShift për Microsoft Azure DevOps
Zgjerimi Red Hat OpenShift Deployment për Microsoft Azure DevOps është lëshuar. Përdoruesit e këtij grupi mjetesh DevOps tani mund t'i vendosin aplikacionet e tyre në Azure Red Hat OpenShift ose çdo grup tjetër OpenShift direkt nga Microsoft Azure DevOps.
Kalimi nga versioni i tretë në të katërtin
Meqenëse po flasim për një version të ri, dhe jo për një përditësim, nuk mund të vendosni thjesht versionin e katërt në krye të të tretit. Përditësimi nga versioni XNUMX në versionin XNUMX nuk do të mbështetet..
Por ka një lajm të mirë: Red Hat ofron mjete për migrimin e projekteve nga 3.7 në 4.2. Ju mund të migroni ngarkesat e punës së aplikacionit duke përdorur mjetin Cluster Application Migration (CAM). CAM ju lejon të kontrolloni migrimin dhe të minimizoni kohën e ndërprerjes së aplikacionit.
OpenShift 4.3
Risitë kryesore të përshkruara në këtë artikull u shfaqën në versionin 4.2. Ndryshimet e lëshuara së fundmi në 4.3 nuk janë aq të mëdha, por ka ende disa gjëra të reja. Lista e ndryshimeve është mjaft e gjerë, këtu janë më të rëndësishmet për mendimin tonë:
Përditësoni versionin e Kubernetes në 1.16.
Versioni u përditësua me dy hapa menjëherë; në OpenShift 4.2 ishte 1.14.
Kriptimi i të dhënave në etj
Duke filluar me versionin 4.3, u bë i mundur enkriptimi i të dhënave në bazën e të dhënave etcd. Pasi të aktivizohet kriptimi, do të jetë e mundur të kriptoni burimet e mëposhtme të OpenShift API dhe Kubernetes API: Sekretet, ConfigMaps, Rrugët, shenjat e aksesit dhe autorizimi OAuth.
kaskë
Mbështetje e shtuar për Helm versionin 3, një menaxher popullor paketash për Kubernetes. Për momentin, mbështetja ka statusin PARAPRAKE TECHNOLOGY. Mbështetja e Helm do të zgjerohet në mbështetje të plotë në versionet e ardhshme të OpenShift. Programi kryesor i klimës vjen me OpenShift dhe mund të shkarkohet nga tastiera e uebit e menaxhimit të grupimeve.
Përditësimi i panelit të projektit
Në versionin e ri, Paneli i Projektit ofron informacion shtesë në faqen e projektit: statusin e projektit, përdorimin e burimeve dhe kuotat e projektit.
Shfaqja e dobësive për kalatë në tastierën e uebit
Një veçori është shtuar në tastierën e menaxhimit për të shfaqur dobësitë e njohura për imazhet në depot e Quay. Shfaqja e dobësive për depot lokale dhe të jashtme mbështetet.
Krijimi i thjeshtuar i operatorit offline
Për rastin e vendosjes së një grupi OpenShift në një rrjet të izoluar, nga i cili qasja në internet është e kufizuar ose mungon, krijimi i një "pasqyre" për regjistrin OperatorHub është thjeshtuar. Tani kjo mund të bëhet vetëm me tre ekipe.
Autorët:
Victor Puchkov, Yuri Semenyukov
Burimi: www.habr.com