Чацвёртая версія OpenShift выйшла параўнальна нядаўна. Актуальная на бягучы момант версія 4.3 даступная з канца студзеня і ўсе змены ў ёй - гэта ці нешта зусім новае, чаго ў трэцяй версіі не было, або буйное абнаўленне таго, што з'явілася ў версіі 4.1. Усё, што мы зараз раскажам, трэба ведаць, разумець і ўлічваць тым, хто працуе з OpenShift і плануе пераходзіць на новую версію.
З выпускам версіі OpenShift 4.2 Red Hat спрасціла працу з Kubernetes. З'явіліся новыя прылады і плагіны для стварэння кантэйнераў, CI/CD-канвеераў і serverless-разгортванняў. Новаўвядзенні даюць распрацоўшчыкам магчымасць засяродзіцца на напісанні кода, а не на разборах з Kubernetes.
Уласна, што новага ў версіях OpenShift 4.2 і 4.3/XNUMX?
Рух у бок гібрыдных аблокаў
Пры планаванні новай ІТ-інфраструктуры або пры развіцці існуючага ІТ-ландшафту кампаніі ўсё часцей разглядаюць хмарны падыход у прадастаўленні ІТ-рэсурсаў, для чаго рэалізуюць прыватныя хмарныя рашэнні, або выкарыстоўваюць магутнасці публічных хмарных правайдэраў. Такім чынам, сучасныя ІТ-інфраструктуры ўсё часцей будуюцца па "гібрыднай" хмарнай мадэлі, калі прымяняюцца як on-premises рэсурсы, так і публічныя хмарныя рэсурсы з агульнай сістэмай кіравання. Red Hat OpenShift 4.2 спецыяльна распрацаваны для спрашчэння пераходу да мадэлі гібрыднага аблокі і дазваляе лёгка падключаць да кластара рэсурсы такіх правайдэраў, як AWS, Azure і Google Cloud Platform нароўні з выкарыстаннем прыватных аблокаў на VMware і OpenStack.
Новы падыход да ўсталёўкі
У 4-й версіі змяніўся падыход да ўсталёўкі OpenShift. Red Hat дае адмысловую ўтыліту для разгортвання кластара OpenShift - openshift-install. Утыліта ўяўляе сабой адзіны бінарны файл, напісаны на Go. Openshit-installer падрыхтоўвае yaml-файл з канфігурацыяй, неабходнай для разгортвання.
У выпадку ўсталёўкі з выкарыстаннем хмарных рэсурсаў запатрабуецца паказаць мінімальную інфармацыю аб будучыні кластары: DNS-зону, колькасць worker-вузлоў, спецыфічныя налады для хмарнага правайдэра, дадзеныя ўліковага запісу для доступу да хмарнага правайдэру. Пасля падрыхтоўкі файла канфігурацыі кластар можа быць разгорнуты адной камандай.
У выпадку ўсталёўкі на ўласных вылічальных рэсурсах, напрыклад, пры выкарыстанні прыватнага аблокі (падтрымліваюцца vSphere і OpenStack) або пры ўсталёўцы на bare metal серверы, запатрабуецца ручная налада інфраструктуры - падрыхтаваць мінімальную колькасць віртуальных машын або фізічных сервераў, неабходнае для стварэння Control Plane кластара, наладзіць сеткавыя службы. Пасля такой налады кластар OpenShift можна будзе аналагічна стварыць адной камандай утыліты openshift-installer.
Абнаўленні ў інфраструктуры
Інтэграцыя з CoreOS
Ключавое абнаўленне - гэта інтэграцыя з Red Hat CoreOS. Цяпер master-ноды Red Hat OpenShift могуць працаваць толькі на новай АС. Гэта бясплатная аперацыйная сістэма ад Red Hat, якая прызначаная спецыяльна для кантэйнерных рашэнняў. Red Hat CoreOS уяўляе сабой палегчаны Linux, аптымізаваны для запуску кантэйнераў.
Калі ў 3.11 аперацыйная сістэма і OpenShift існавалі асобна, то ў 4.2 яна непарыўна злучана з OpenShift. Цяпер гэта адзіны appliance - immutable infrastructure.
Для кластараў, якія выкарыстоўваюць RHCOS для ўсіх вузлоў, абнаўленне OpenShift Container Platform з'яўляецца простым і добра аўтаматызаваным працэсам.
Раней, каб абнавіць OpenShift, неабходна было спачатку абнавіць базавую аперацыйную сістэму, на якой прадукт быў запушчаны (у той час гэта была Red Hat Enterprise Linux). Толькі пасля гэтага можна было абнаўляць OpenShift паступова, вузел за вузлом. Ні пра якую аўтаматызацыі працэсу гаворкі не ішло.
Цяпер жа, паколькі OpenShift Container Platform цалкам кантралюе сістэмы і службы на кожным вузле, у тым ліку АС, гэтая задача вырашаецца націскам кнопкі з вэб-інтэрфейсу. Пасля гэтага запускаецца спецыяльны аператар усярэдзіне кластара OpenShift, які кіруе ўсім працэсам абнаўлення.
Новы CSI
Другое – новы CSI – кантролер storage-інтэрфейсу, які дазваляе падлучаць розныя вонкавыя СХД да кластара OpenShift. Падтрымліваецца вялікая колькасць правайдэраў storage-драйвераў для OpenShift на базе storage-драйвераў, якія пішуць самі вытворцы СГД. Поўны спіс падтрымліваемых CSI-драйвераў можна знайсці ў гэтым дакуменце: . У гэтым спісе можна знайсці ўсе асноўныя мадэлі дыскавых масіваў вядучых вытворцаў (Dell / EMC, IBM, NetApp, Hitachi, HPE, PureStorage), SDS-рашэнняў (Ceph) і хмарных сховішчаў (AWS, Azure, Google). OpenShift 4.2 падтрымлівае працу з CSI-драйверамі спецыфікацыі CSI версіі 1.1.
RedHat OpenShift Service Mesh
Заснаваная на праектах Istio, Kiali і Jaeger – Red Hat OpenShift Service Mesh, апроч звычайных задач маршрутызацыі запытаў паміж службамі дазваляе выконваць іх трасіроўку і візуалізацыю. Гэта дапамагае распрацоўшчыкамі спрасціць узаемадзеянне, назіранне і кіраванне дадаткам, разгорнутым ўнутры Red Hat OpenShift.
Візуалізацыя прыкладання, які мае мікрасэрвісную архітэктуру з выкарыстаннем Kiali
Каб максімальна спрасціць працэсы ўстаноўкі, сэрвісу і кіравання жыццёвым цыклам Service Mesh, Red Hat OpenShift дае адміністратарам спецыяльны аператар - Service Mesh Operator. Гэта аператар Kubernetes, які дазваляе разгарнуць на кластары пераканфігураваныя пакеты Istio, Kiali і Jaeger, максімальна здымаючы адміністрацыйную нагрузку на кіраванне праграмамі.
CRI-O замест Docker
Дэфолтны кантэйнерны runtime Docker быў заменены на CRI-O. Скарыстацца CRI-O можна было ўжо ў версіі 3.11/4.2, але ў XNUMX/XNUMX ён стаў асноўным. Не добра і не дрэнна, але варта мець на ўвазе пры выкарыстанні прадукта.
Аператары і дэплой прыкладанняў
Аператары – новая сутнасць для RedHat OpenShift, якая з'явілася ў чацвёртай версіі. Гэта метад упакоўкі, разгортвання і кіравання дадаткам Kubernetes. Яго можна ўявіць, як кіраваны з дапамогай API Kubernetes і інструментаў kubectl убудова для прыкладанняў, разгорнутых у кантэйнерах.
Аператары Kubernetes дапамагаюць аўтаматызаваць любыя задачы, звязаныя з адміністраваннем і кіраваннем жыццёвым цыклам прыкладання, якое вы разгортваеце ў сваім кластары. Напрыклад, аператар можа аўтаматызаваць абнаўленні, рэзервовае капіраванне і маштабаванне прыкладання, змяняць канфігурацыю і г.д. Поўны спіс аператараў можна паглядзець на .
OperatorHub даступны прама з вэб-інтэрфейсу кансолі кіравання. Ён уяўляе сабой каталог прыкладанняў для OpenShift, які падтрымліваецца Red Hat. Г.зн. усе аператары, ухваленыя Red Hat, будуць пакрывацца вендорскай падтрымкай.
Партал OperatorHub у кансолі кіраванне OpenShift
Universal base image
Гэта стандартызаваны набор вобразаў АС RHEL, якія можна выкарыстоўваць для стварэння вашых прыкладанняў у кантэйнерах. Ёсць мінімальны, стандартны і поўны наборы. Яны займаюць зусім няшмат месца, падтрымліваюць усе неабходныя ўсталяваныя пакеты і мовы праграмавання.
Інструменты CI/CD
У RedHat OpenShif 4.2 з'явілася магчымасць абраць паміж Jenkins і OpenShift Pipelines на базе Tekton Pipelines.
OpenShift Pipelines заснаваны на Tekton, які лепш падтрымліваюць падыходы Pipeline as Code і GitOps. У канвеерах OpenShift кожны крок выконваецца ва ўласным кантэйнеры, таму рэсурсы выкарыстоўваюцца толькі падчас выканання кроку. Гэта дае распрацоўнікам поўны кантроль над канвеерамі дастаўкі модуляў, убудовамі і кантролем доступу без цэнтральнага сервера CI/CD для кіравання.
OpenShift Pipelines у цяперашні час знаходзіцца ў стадыі Preview для распрацоўнікаў і даступны ў якасці аператара на кластары OpenShift 4. Зразумела, карыстачы OpenShift па-ранейшаму могуць выкарыстоўваць Jenkins у RedHat OpenShift 4.
Абнаўленні ва ўпраўленні для распрацоўшчыкаў
У 4.2 OpenShift цалкам абнавіўся вэб-інтэрфейс як для распрацоўшчыкаў, так і для адміністратараў.
У папярэдніх версіях OpenShift усё працавалі ў трох кансолях: сэрвіс-каталог, адміністратар-кансоль і work-кансоль. Цяпер кластар падзелены толькі на дзве часткі - administrator console і developer console.
Developer console атрымала значныя паляпшэнні карыстацкага інтэрфейсу. Цяпер на ёй зручней адлюстроўваюцца тапалогіі прыкладанняў і іх зборак. Гэта палягчае распрацоўшчыкам стварэнне, разгортванне і візуалізацыю кантэйнерных прыкладанняў і кластарных рэсурсаў. Дазваляе засяродзіцца на тым, што для іх важна.
Партал распрацоўніка ў кансолі кіравання OpenShift
одо
Odo – арыентаваная на распрацоўнікаў утыліта каманднага радка, якая спрашчае распрацоўку прыкладанняў у OpenShift. Выкарыстоўваючы ўзаемадзеянне ў стылі git push, гэты CLI дапамагае распрацоўнікам, не знаёмым з Kubernetes, ствараць прыкладанні ў OpenShift.
Інтэграцыя з асяроддзямі распрацоўкі
Распрацоўнікі зараз могуць ствараць, адладжваць і разгортваць свае прыкладанні ў OpenShift, не пакідаючы сваё каханае асяроддзе распрацоўкі кода, напрыклад, Microsoft Visual Studio, JetBrains (уключаючы IntelliJ), Eclipse Desktop і т.д.
Red Hat OpenShift Deployment Extension for Microsoft Azure DevOps
З'явілася пашырэнне Red Hat OpenShift Deployment для Microsoft Azure DevOps. Зараз карыстачы гэтага набору DevOps-інструментаў могуць разгортваць свае прыкладанні ў Azure Red Hat OpenShift або любым іншым кластары OpenShift непасрэдна з Microsoft Azure DevOps.
Пераход з трэцяй версіі на чацвёртую
Паколькі гаворка ідзе аб новым рэлізе, а не аб абнаўленні, то нельга так проста ўзяць і паставіць чацвёртую версію па-над трэцяй. Абнаўленне з трэцяй на чацвёртую версію падтрымлівацца не будзе.
Але ёсць і добрая навіна: Red Hat дае прылады для пераносу праектаў з 3.7 у 4.2. Вы можаце перанесці працоўныя нагрузкі прыкладанняў з дапамогай прылады Cluster Application Migration (CAM). CAM дазваляе кантраляваць міграцыю і мінімізаваць час прастою прыкладання.
OpenShift 4.3
Асноўныя навіны, апісаныя ў дадзеным артыкуле, з'явіліся ў версіі 4.2. У нядаўна выпушчанай 4.3/XNUMX змены не такія значныя, але ўсё ж ёсць сёе-тое новае. Пералік змен досыць шырокі, прывядзем найболей значныя на наш погляд:
Апдэйт версіі Kubernetes да 1.16.
Версія праапгрэйдзілася адразу на два крокі, у OpenShift 4.2 была 1.14.
Шыфраванне дадзеных у etcd
Пачынальна з версіі 4.3, з'явілася магчымасць шыфраваць дадзеныя ў базе etcd. Пасля ўключэння шыфравання будзе магчыма шыфраванне наступных рэсурсаў OpenShift API і Kubernetes API: Secrets, ConfigMaps, Routes, токенаў доступу і аўтарызацыі OAuth.
шлем
Дададзена падтрымка Helm 3-й версіі - папулярнага пакетнага мэнэджара для Kubernetes. Пакуль падтрымка мае статут TECHNOLOGY PREVIEW. У будучых версіях OpenShift падтрымка Helm будзе пашырана да поўнай. Утыліта helm cli пастаўляецца разам з OpenShift і можа быць загружана з Web-кансолі кіравання кластарам.
Абнаўленне Project Dashboard
У новай версіі Project Dashboard дае дадатковую інфармацыю на старонцы праекта: статус праекта, утылізацыю рэсурсаў і квоты для праекта.
Адлюстраванне ўразлівасцяў для quay у Web-кансолі
У кансоль кіравання дададзена функцыя адлюстравання вядомых уразлівасцяў для выяў у рэпазітарах Quay. Падтрымліваецца адлюстраванне ўразлівасцяў для лакальных і вонкавых рэпазітараў.
Спрошчана стварэнне афлайн operatorhub
Для выпадку разгортвання кластара OpenShift у ізаляванай сетцы, доступ з якой у інтэрнэт абмежаваны або адсутнічае, спрошчана стварэнне "люстэрка" для рэестра OperatorHub. Цяпер гэта можна будзе зрабіць усяго трыма камандамі.
аўтары:
Віктар Пучкоў, Юры Семянюкоў
Крыніца: habr.com