Az OpenShift negyedik verziója viszonylag nemrég jelent meg. Az aktuális, 4.3-as verzió január vége óta elérhető, és minden benne történt változás vagy valami olyan, ami teljesen új, és amit a harmadik verzió nem tartalmazott, vagy jelentős frissítés annak, ami a 4.1-es verzióban megjelent. Mindezeket tudni, érteni és figyelembe venni kell annak, aki az OpenShift-tel dolgozik, és tervezi az új verzióra való áttérést.
A 4.2-es OpenShift verzió kiadásával a Red Hat egyszerűsítette a Kubernetes alkalmazását. Új eszközök és pluginek kerültek bevezetésre a konténer létrehozásához, CI/CD munkafolyamatokhoz és serverless telepítésekhez. Az újítások lehetővé teszik a fejlesztők számára, hogy a kód írására összpontosítsanak, ne pedig a Kubernetes kezelésével foglalkozzanak.
Tulajdonképpen mi újdonság van az OpenShift 4.2 és 4.3 verziókban?
Irány a hibrid felhők felé
Új IT-infrastruktúra tervezésekor vagy a meglévő IT-ökológia fejlesztésekor egyre többen fontolgatják a felhő alapú megoldásokat az IT-erőforrások biztosítására, ezért privát felhőalapú megoldásokat alkalmaznak, vagy a nyilvános felhőszolgáltatók teljesítményét használják. Ennek eredményeként a modern IT-infrastruktúrák egyre inkább a hibrid felhőmodellt követik, ahol mind a saját helyszínen lévő erőforrásokat, mind a nyilvános felhőforrásokat használják közös irányítási rendszerrel. A Red Hat OpenShift 4.2 kifejezetten a hibrid felhőmodellre való átállás megkönnyítésére lett kifejlesztve, és lehetővé teszi, hogy könnyen csatlakoztassák a klaszterhez olyan szolgáltatók, mint az AWS, Azure és Google Cloud Platform, a VMware és OpenStack privát felhőinek használata mellett.
Új telepítési megközelítés
A 4. verzióban megváltozott az OpenShift telepítési megközelítése. A Red Hat külön eszközt biztosít az OpenShift klaszter telepítéséhez – az openshift-install-t. Ez az eszköz egyetlen bináris fájl, amely Go nyelven készült. Az openshift-installer előkészíti a telepítéshez szükséges konfigurációs YAML fájlt.
Felhőalapú erőforrások használata esetén meg kell adni a jövőbeli klaszterrel kapcsolatos minimális információkat: DNS-zóna, munkás csomópontok száma, speciális beállítások a felhőszolgáltató számára, és a felhőszolgáltatóhoz való hozzáféréshez szükséges fiókadatai. A konfigurációs fájl előkészítése után a klaszter egyetlen parancs segítségével telepíthető.
Ha a saját számítástechnikai erőforrásain történik az telepítés, például magán felhő használatával (a vSphere és az OpenStack támogatott), vagy bare metal szerverekre történő telepítéskor, kézi infrastruktúra-beállításra lesz szükség - minimalizálni kell a szükséges virtuális gépek vagy fizikai szerverek számát a Control Plane klaszter létrehozásához, valamint beállítani a hálózati szolgáltatásokat. Ezt követően az OpenShift klaszter egy parancs segítségével hozható létre az openshift-installer eszközzel.
Frissítések az infrastruktúrában
Integráció a CoreOS-szal
A kulcsfontosságú frissítés a Red Hat CoreOS-szal való integráció. Most a Red Hat OpenShift master csomópontjai az új operációs rendszeren tudnak működni. a fő DB példányhoz Ez egy ingyenes operációs rendszer a Red Hat-től, amely kifejezetten konténeres megoldásokhoz készült. A Red Hat CoreOS egy könnyű, optimalizált Linux a konténerek futtatásához.
Ha a 3.11-es verzióban az operációs rendszer és az OpenShift különállóan működtek, a 4.2-es verzióban ez szorosan összekapcsolódik az OpenShifttel. Most ez egy egységes appliance - immutable infrastruktúra.
Azoknál a klasztereknél, amelyek az RHCOS-t használják az összes csomóponton, az OpenShift Container Platform frissítése egy egyszerű és jól automatizált folyamat.
Korábban az OpenShift frissítéséhez először az alap operációs rendszert kellett frissíteni, amelyen a termék futott (akkoriban a Red Hat Enterprise Linux volt). Csak ezt követően lehetett fokozatosan frissíteni az OpenShift-et, csomópontonként. Az automatizálás pedig szóba sem jöhetett.
Jelenleg viszont, mivel az OpenShift Container Platform teljes mértékben ellenőrzi a rendszereket és szolgáltatásokat minden csomóponton, beleértve az operációs rendszert is, ez a feladat egy gombnyomással megoldható a webes felületen. Ezt követően egy speciális operátor indul el az OpenShift klaszterben, amely az egész frissítési folyamatot kezeli.
Új CSI
A második - új CSI - a storage interfész vezérlője, amely lehetővé teszi különböző külső tárolórendszerek csatlakoztatását az OpenShift klaszterhez. Nagy számú tárolómeghajtót támogató szolgáltató van, amelyeket maguk a tárolórendszerek gyártói írtak. A támogatott CSI meghajtók teljes listája megtalálható ebben a dokumentumban: Ebben a listában megtalálhatók a vezető gyártók (Dell/EMC, IBM, NetApp, Hitachi, HPE, PureStorage) legfontosabb tárolómodelljei, SDS megoldásai (Ceph) és felhőtárolói (AWS, Azure, Google). Az OpenShift 4.2 támogatja a CSI 1.1 szabványú CSI meghajtókkal való munkavégzést.
RedHat OpenShift Service Mesh
Az Istio, Kiali és Jaeger projektek alapján készült Red Hat OpenShift Service Mesh a szolgáltatások közötti kérések útvonalának irányítása mellett lehetővé teszi azok nyomon követését és vizualizálását is. Ez segít a fejlesztőknek egyszerűsíteni az alkalmazás interakcióját, megfigyelését és kezelését, amelyet a Red Hat OpenShift-en belül telepítettek.
Mikroszolgáltatás architektúrájú alkalmazás vizualizálása Kiali használatával
A Service Mesh telepítési, szolgáltatási és életciklus-kezelési folyamatainak leegyszerűsítése érdekében a Red Hat OpenShift speciális operátort - Service Mesh Operator-t biztosít az adminisztrátorok számára. Ez egy Kubernetes operátor, amely lehetővé teszi a módosított Istio, Kiali és Jaeger csomagok telepítését a klaszterre, minimalizálva az alkalmazások kezelésével járó adminisztratív terheket.
CRI-O Docker helyett
A Docker alapértelmezett tároló runtime-ot CRI-O-ra cserélték. A CRI-O már a 3.11-es verzióban is elérhető volt, de a 4.2-ben lett a fő. Nem jó, nem is rossz, de érdemes figyelembe venni a termék használata során.
Operátorok és alkalmazás telepítések
Az operátorok új entitást jelentenek a RedHat OpenShift számára, amely a negyedik verzióban jelent meg. Ez a Kubernetes alkalmazások csomagolásának, telepítésének és kezelésének módszere. Olyan, mint egy API-k útján vezérelt Kubernetes plug-in az konténerekben telepített alkalmazásokhoz.
A Kubernetes operátorok automatizálják a klaszteredben futó alkalmazás adminisztrálásával és életciklus-kezelésével kapcsolatos bármely feladatot. Például egy operátor automatizálhatja az alkalmazás frissítéseit, biztonsági mentéseit és skálázását, megváltoztathatja a konfigurációt stb. Az operátorok teljes listáját itt láthatod: .
Az OperatorHub közvetlenül a vezérlőpult webes interfészéből elérhető. Ez egy Red Hat által támogatott OpenShift alkalmazásokat tartalmazó katalógus. Azaz az összes Red Hat által jóváhagyott operátor biztosítással lesz ellátva.
Az OperatorHub portál az OpenShift kezelőpultban
Univerzális alapképfájl
Ez egy standardizált RHEL operációs rendszerképkészlet, amelyet alkalmazások konténerbe helyezésére használhat. Minimális, standard és teljes verziók érhetők el. Ezek nagyon kis helyet foglalnak, támogatják az összes szükséges csomagot és programozási nyelvet.
CI/CD Eszközök
A RedHat OpenShift 4.2-ben lehetőség van választani a Jenkins és a Tekton Pipelines alapú OpenShift Pipelines között.
Az OpenShift Pipelines a Tektonra épül, amely jobban támogatja a Pipeline as Code és GitOps megközelítéseket. Az OpenShift folyamatok minden lépése saját konténerben fut, így az erőforrások csak a lépés végrehajtása során használódnak. Ez teljes kontrollt biztosít a fejlesztők számára a modulok szállítási folyamatában, a bővítmények kezelésében és a hozzáférés-ellenőrzésben központi CI/CD szerver nélkül.
Az OpenShift Pipelines jelenleg Preview állapotban van fejlesztők számára és elérhető operátorként az OpenShift 4 klaszterben. Természetesen az OpenShift felhasználók továbbra is használhatják a Jenkins-t a RedHat OpenShift 4-ben.
Frissítések a fejlesztők menedzsmentjében
A 4.2 verzióban az OpenShift teljesen megújította a webes felületét mind a fejlesztők, mind az adminisztrátorok számára.
A korábbi OpenShift verziókban mindenki három konzolon dolgozott: szolgáltatáskönyvtár, adminisztrátor konzol és work konzol. Most a klaszter csak két részre oszlik - adminisztrátor konzolra és fejlesztő konzolra.
A fejlesztő konzol jelentős felhasználói felületjavításokat kapott. Most már kényelmesebben jeleníti meg az alkalmazások és azok összesítéseinek topológiáit. Ez megkönnyíti a fejlesztők számára a konténeres alkalmazások és klaszteres erőforrások létrehozását, telepítését és vizualizálását. Lehetővé teszi számukra, hogy a számukra fontos dolgokra összpontosítsanak.
Fejlesztői portál az OpenShift vezérlőpultban
Odo
Az Odo egy fejlesztőorientált parancssori eszköz, amely megkönnyíti az alkalmazásfejlesztést az OpenShiftben. A git push stílusú interakciót használva ez a CLI segít a Kubernetes-hez nem túl jártas fejlesztőknek alkalmazásokat létrehozni az OpenShiftben.
Integráció a fejlesztési környezetekkel
A fejlesztők most már létrehozhatják, hibakereshetik és telepíthetik alkalmazásaikat az OpenShiftbe, anélkül, hogy elhagynák kedvenc kódfejlesztő környezetüket, mint például a Microsoft Visual Studio, a JetBrains (beleértve az IntelliJ-t), az Eclipse Desktop stb.
Red Hat OpenShift Deployment kiegészítő a Microsoft Azure DevOpshoz
Megjelent a Red Hat OpenShift Deployment kiterjesztés a Microsoft Azure DevOps számára. Mostantól a DevOps eszközkészlet felhasználói közvetlenül a Microsoft Azure DevOps-ból telepíthetik alkalmazásaikat az Azure Red Hat OpenShift vagy bármely más OpenShift klaszterbe.
Átállás a harmadik verzióról a negyedik verzióra
Mivel új kiadásról van szó, nem lehet csak úgy a harmadik verzióra telepíteni a negyediket. A harmadik verzióra való frissítést nem támogatják.
De van jó hír is: a Red Hat eszközöket biztosít a projektek átkonvertálásához a 3.7 verzióból a 4.2 verzióba. Az alkalmazás terhelések átkonvertálása a Cluster Application Migration (CAM) eszközzel történhet. A CAM lehetővé teszi a migráció ellenőrzését és a leállások minimalizálását.
OpenShift 4.3
A cikkben leírt fő újítások a 4.2 verzióban jelentek meg. A nemrégiben kiadott 4.3 verzióban a változások nem annyira jelentősek, de mégis van néhány új dolog. A változások listája meglehetősen kiterjedt, és kiemeljük a legfontosabbakat véleményünk szerint:
Kubernetes verzió frissítése 1.16-ra.
A verzió két lépést ugrott, az OpenShift 4.2-ben 1.14 volt.
Adatok titkosítása az etcd-ben
A 4.3 verziótól kezdve lehetőség nyílik az etcd adatbázisban található adatok titkosítására. A titkosítás engedélyezése után titkosíthatóak a következő OpenShift API és Kubernetes API erőforrások: Secrets, ConfigMaps, Routes, hozzáférési tokenek és OAuth engedélyezési tokenek.
Helm
Harmadik verziójú Helm támogatás hozzáadása – a Kubernetes népszerű csomagkezelője. Jelenleg a támogatás TECHNOLOGY PREVIEW státuszú. A jövőbeni OpenShift verziókban a Helm támogatása teljes kiterjesztésre kerül. A helm cli eszköz az OpenShift mellett érkezik, és letölthető a klaszter kezelő webes konzoljából.
Project Dashboard frissítése
Az új Project Dashboard verzió további információkat nyújt a projektoldalon: projekt státusz, erőforrások kihasználtsága és kvóták a projekthez.
Az ismert sebezhetőségek megjelenítése a quay-ban a webes konzolban
A kezelő konzolhoz hozzáadva az ismert sebezhetőségek megjelenítése a Quay tárolókban lévő képekhez. Támogatott a sebezhetőségek megjelenítése helyi és külső tárolók esetén.
Az offline operatorhub létrehozása egyszerűsítve
Az OpenShift klaszter izolált hálózatban történő telepítésekor, ahol a hálózati hozzáférés az internetre korlátozott vagy hiányzik, egyszerűsödött az OperatorHub registry „tükörének” létrehozása. Mostantól mindezt csupán három parancs segítségével meg lehet valósítani.
Szerzők:
Viktor Puchkov, Jurij Szemenyukov
Forrás: habr.com
