Четвъртата версия на OpenShift беше пусната сравнително наскоро. Текущата версия 4.3 е налична от края на януари и всички промени в нея са или нещо напълно ново, което не беше в третата версия, или основна актуализация на това, което се появи във версия 4.1. Всичко, което ще ви кажем сега, трябва да бъде известно, разбрано и взето предвид от тези, които работят с OpenShift и планират да преминат към нова версия.
С пускането на OpenShift 4.2 Red Hat улесни работата с Kubernetes. Появиха се нови инструменти и добавки за създаване на контейнери, CI/CD тръбопроводи и внедрявания без сървър. Иновациите дават възможност на разработчиците да се съсредоточат върху писането на код, а не върху работа с Kubernetes.
Всъщност какво е новото във версиите на OpenShift 4.2 и 4.3?
Придвижване към хибридни облаци
Когато планират нова ИТ инфраструктура или когато развиват съществуваща ИТ среда, компаниите все повече обмислят облачен подход при предоставянето на ИТ ресурси, за който внедряват частни облачни решения или използват силата на публичните облачни доставчици. По този начин съвременните ИТ инфраструктури все повече се изграждат според „хибриден“ облачен модел, когато се използват както локални ресурси, така и публични облачни ресурси с обща система за управление. Red Hat OpenShift 4.2 е специално проектиран да опрости прехода към хибриден облачен модел и улеснява свързването на ресурси от доставчици като AWS, Azure и Google Cloud Platform към клъстера, заедно с използването на частни облаци на VMware и OpenStack.
Нов подход към монтажа
Във версия 4 подходът за инсталиране на OpenShift е променен. Red Hat предоставя специална помощна програма за разполагане на OpenShift клъстер - openshift-install. Помощната програма е единичен двоичен файл, написан на Go. Openshit-installer подготвя yaml файл с конфигурацията, необходима за внедряване.
В случай на инсталиране с използване на облачни ресурси, ще трябва да посочите минимална информация за бъдещия клъстер: DNS зона, брой работни възли, специфични настройки за облачния доставчик, информация за акаунта за достъп до облачния доставчик. След подготовка на конфигурационния файл, клъстерът може да бъде разгърнат с една команда.
В случай на инсталиране на вашите собствени изчислителни ресурси, например, когато използвате частен облак (vSphere и OpenStack се поддържат) или когато инсталирате на голи сървъри, ще трябва ръчно да конфигурирате инфраструктурата - да подготвите минималния брой виртуални машини или физически сървъри, необходими за създаване на клъстер на Control Plane, конфигуриране на мрежови услуги. След тази конфигурация клъстер OpenShift може да бъде създаден по подобен начин с една команда на помощната програма за инсталиране на openshift.
Актуализации на инфраструктурата
Интеграция с CoreOS
Ключовата актуализация е интеграцията с Red Hat CoreOS. Главните възли на Red Hat OpenShift вече могат да работят само на новата ОС. Това е безплатна операционна система от Red Hat, която е проектирана специално за контейнерни решения. Red Hat CoreOS е лек Linux, оптимизиран за работа с контейнери.
Ако в 3.11 операционната система и OpenShift съществуват отделно, то в 4.2 тя е неразривно свързана с OpenShift. Сега това е едно устройство - неизменна инфраструктура.
За клъстери, които използват RHCOS за всички възли, надграждането на OpenShift Container Platform е прост и силно автоматизиран процес.
Преди, за да актуализирате OpenShift, първо трябваше да актуализирате основната операционна система, на която продуктът работи (по това време Red Hat Enterprise Linux). Само тогава OpenShift може да се актуализира постепенно, възел по възел. За никаква автоматизация на процеса не се говори.
Сега, тъй като OpenShift Container Platform напълно контролира системите и услугите на всеки възел, включително операционната система, тази задача се решава чрез натискане на бутон от уеб интерфейса. След това в клъстера OpenShift се стартира специален оператор, който контролира целия процес на актуализиране.
Нов CSI
Второ, новият CSI е контролер за интерфейс за съхранение, който ви позволява да свържете различни външни системи за съхранение към клъстера OpenShift. Голям брой доставчици на драйвери за съхранение за OpenShift се поддържат въз основа на драйвери за съхранение, които са написани от самите производители на системи за съхранение. Пълен списък на поддържаните 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
Докерът за изпълнение на контейнера по подразбиране е заменен от CRI-O. Беше възможно да се използва CRI-O вече във версия 3.11, но в 4.2 той стана основен. Не е добро или лошо, но нещо, което трябва да имате предвид, когато използвате продукта.
Оператори и внедряване на приложения
Операторите са нов обект за RedHat OpenShift, който се появи в четвъртата версия. Това е метод за опаковане, разполагане и управление на приложение на Kubernetes. Може да се разглежда като плъгин за приложения, разположени в контейнери, управлявани от Kubernetes API и инструменти kubectl.
Операторите на Kubernetes помагат за автоматизирането на всякакви задачи, свързани с администрирането и управлението на жизнения цикъл на приложението, което внедрявате във вашия клъстер. Например, операторът може да автоматизира актуализациите, архивирането и мащабирането на приложението, да променя конфигурацията и т.н. Пълен списък на операторите можете да намерите на .
OperatorHub е достъпен директно от уеб интерфейса на конзолата за управление. Това е директория на приложения за OpenShift, поддържана от Red Hat. Тези. всички оператори, одобрени от Red Hat, ще бъдат обхванати от поддръжката на доставчика.
Порталът OperatorHub в конзолата за управление на OpenShift
Универсално основно изображение
Това е стандартизиран набор от изображения на RHEL OS, които могат да се използват за изграждане на вашите контейнерни приложения. Има минимални, стандартни и пълни комплекти. Те заемат много малко място и поддържат всички необходими инсталирани пакети и езици за програмиране.
CI/CD инструменти
В RedHat OpenShif 4.2 стана възможно да избирате между Jenkins и OpenShift Pipelines, базирани на Tekton Pipelines.
OpenShift Pipelines е базиран на Tekton, който се поддържа по-добре от Pipeline като Code и GitOps подходи. В конвейерите на OpenShift всяка стъпка се изпълнява в свой собствен контейнер, така че ресурсите се използват само докато стъпката се изпълнява. Това дава на разработчиците пълен контрол върху тръбопроводите за доставка на модули, добавките и контрола на достъпа без централен CI/CD сървър за управление.
OpenShift Pipelines в момента е в Developer Preview и е достъпен като оператор в клъстер OpenShift 4. Разбира се, потребителите на OpenShift все още могат да използват Jenkins на RedHat OpenShift 4.
Актуализации за управление на разработчиците
В 4.2 OpenShift уеб интерфейсът е напълно актуализиран както за разработчици, така и за администратори.
В предишните версии на OpenShift всеки работеше в три конзоли: сервизна директория, администраторска конзола и работна конзола. Сега клъстерът е разделен само на две части - администраторска конзола и конзола за разработчици.
Конзолата за разработчици получи значителни подобрения в потребителския интерфейс. Сега той по-удобно показва топологиите на приложенията и техните сборки. Това улеснява разработчиците да създават, внедряват и визуализират контейнеризирани приложения и клъстерирани ресурси. Позволява им да се съсредоточат върху това, което е важно за тях.
Портал за разработчици в конзолата за управление на OpenShift
Одо
Odo е ориентирана към разработчиците помощна програма за команден ред, която опростява разработката на приложения в OpenShift. Използвайки комуникация в стил git push, този CLI помага на разработчиците, които са нови за Kubernetes, да създават приложения в OpenShift.
Интеграция със среди за разработка
Разработчиците вече могат да създават, отстраняват грешки и внедряват своите приложения в OpenShift, без да напускат любимата си среда за разработка на код, като Microsoft Visual Studio, JetBrains (включително IntelliJ), Eclipse Desktop и др.
Red Hat OpenShift Deployment разширение за Microsoft Azure DevOps
Разширението Red Hat OpenShift Deployment за Microsoft Azure DevOps беше пуснато. Потребителите на този набор от инструменти DevOps вече могат да разгръщат своите приложения в Azure Red Hat OpenShift или всеки друг OpenShift клъстер директно от Microsoft Azure DevOps.
Преход от трета версия към четвърта
Тъй като говорим за нова версия, а не за актуализация, не можете просто да поставите четвъртата версия върху третата. Актуализиране от версия XNUMX на версия XNUMX няма да се поддържа..
Но има добри новини: Red Hat предоставя инструменти за мигриране на проекти от 3.7 към 4.2. Можете да мигрирате работни натоварвания на приложения с помощта на инструмента за миграция на клъстерни приложения (CAM). CAM ви позволява да контролирате миграцията и да минимизирате времето за престой на приложението.
OpenShift 4.3
Основните иновации, описани в тази статия, се появиха във версия 4.2. Наскоро пуснатите промени 4.3 не са толкова големи, но все пак има някои нови неща. Списъкът с промени е доста обширен, ето най-значимите според нас:
Актуализирайте версията на Kubernetes до 1.16.
Версията беше надстроена с две стъпки наведнъж; в OpenShift 4.2 беше 1.14.
Криптиране на данни в etcd
Започвайки с версия 4.3, стана възможно да се криптират данни в базата данни etcd. След като шифроването бъде активирано, ще бъде възможно да се шифроват следните OpenShift API и API ресурси на Kubernetes: Secrets, ConfigMaps, Routes, токени за достъп и OAuth оторизация.
Шлем
Добавена е поддръжка за Helm версия 3, популярен мениджър на пакети за Kubernetes. Засега поддръжката е със статус TECHNOLOGY PREVIEW. Поддръжката на Helm ще бъде разширена до пълна поддръжка в бъдещите версии на OpenShift. Помощната програма helm cli идва с OpenShift и може да бъде изтеглена от уеб конзолата за управление на клъстери.
Актуализация на таблото за управление на проекта
В новата версия Project Dashboard предоставя допълнителна информация на страницата на проекта: състояние на проекта, използване на ресурси и квоти за проекта.
Показване на уязвимости за quay в уеб конзолата
Към конзолата за управление е добавена функция за показване на известни уязвимости за изображения в хранилищата на Quay. Поддържа се показване на уязвимости за локални и външни хранилища.
Опростено създаване на офлайн операторски център
В случай на разполагане на клъстер OpenShift в изолирана мрежа, от която достъпът до интернет е ограничен или липсва, създаването на „огледало“ за регистъра на OperatorHub е опростено. Сега това може да стане само с три отбора.
Автори:
Виктор Пучков, Юрий Семенюков
Източник: www.habr.com