Czwarta wersja OpenShift została wydana stosunkowo niedawno. Aktualna wersja 4.3 jest dostępna od końca stycznia, a wszystkie zmiany w niej to albo coś zupełnie nowego, czego nie było w trzeciej wersji, albo znacząca aktualizacja tego, co pojawiło się w wersji 4.1. Wszystko, o czym teraz opowiemy, powinno być znane, rozumiane i uwzględnione przez osoby pracujące z OpenShift i planujące przejście na nową wersję.
Z wydaniem wersji OpenShift 4.2 Red Hat uprościł pracę z Kubernetes. Pojawiły się nowe narzędzia i wtyczki do tworzenia kontenerów, CI/CD oraz rozwiązań serverless. Nowości te dają programistom możliwość skupienia się na pisaniu kodu, a nie na problemach związanych z Kubernetes.
Cóż, co nowego w wersjach OpenShift 4.2 i 4.3?
Kierunek w stronę chmurowych rozwiązań hybrydowych
Przy planowaniu nowej infrastruktury IT lub rozwoju istniejącego krajobrazu IT firmy coraz częściej rozważają chmurowe podejście do dostarczania zasobów IT, implementując rozwiązania chmurowe prywatne lub korzystając z mocy dostawców chmury publicznej. W ten sposób nowoczesne infrastruktury IT coraz częściej budowane są według 'hybrydowego' modelu chmurowego, w którym stosowane są zarówno zasoby lokalne, jak i publiczne zasoby chmurowe z wspólnym systemem zarządzania. Red Hat OpenShift 4.2 został specjalnie zaprojektowany, aby ułatwić przejście do modelu hybrydowej chmury i umożliwia łatwe łączenie zasobów takich dostawców jak AWS, Azure i Google Cloud Platform wraz z wykorzystaniem prywatnych chmur na VMware i OpenStack.
Nowe podejście do instalacji
W czwartej wersji zmieniło się podejście do instalacji OpenShift. Red Hat udostępnia specjalne narzędzie do wdrażania klastra OpenShift – openshift-install. Narzędzie to stanowi pojedynczy plik binarny napisany w języku Go. Openshift-installer przygotowuje plik yaml z konfiguracją niezbędną do wdrożenia.
W przypadku instalacji z wykorzystaniem zasobów chmurowych konieczne będzie podanie minimalnych informacji o przyszłym klastrze: strefa DNS, liczba węzłów roboczych, specyficzne ustawienia dla dostawcy chmury, dane konta do uzyskania dostępu do dostawcy chmury. Po przygotowaniu pliku konfiguracyjnego klaster może być wdrożony jedną komendą.
W przypadku instalacji na własnych zasobach obliczeniowych, na przykład przy użyciu prywatnej chmury (wsparcie dla vSphere i OpenStack) lub instalacji na serwerach bare metal, wymagana będzie ręczna konfiguracja infrastruktury — przygotowanie minimalnej liczby maszyn wirtualnych lub serwerów fizycznych potrzebnych do utworzenia klastra Control Plane oraz skonfigurowanie usług sieciowych. Po tej konfiguracji klaster OpenShift można utworzyć jedną komendą narzędzia openshift-installer.
Aktualizacje w infrastrukturze
Integracja z CoreOS
Kluczową aktualizacją jest integracja z Red Hat CoreOS. Teraz węzły master Red Hat OpenShift mogą działać tylko na nowym systemie operacyjnym. To darmowy system operacyjny od Red Hat, zaprojektowany specjalnie dla rozwiązań kontenerowych. Red Hat CoreOS to lekki Linux, zoptymalizowany do uruchamiania kontenerów.
Jeśli w wersji 3.11 system operacyjny i OpenShift istniały oddzielnie, to w wersji 4.2 zostały nierozerwalnie połączone z OpenShift. Teraz to jedyny appliance — immutable infrastructure.
Dla klastrów, które wykorzystują RHCOS dla wszystkich węzłów, aktualizacja OpenShift Container Platform jest prostym i dobrze zautomatyzowanym procesem.
Wcześniej, aby zaktualizować OpenShift, najpierw należało zaktualizować podstawowy system operacyjny, na którym uruchomiono produkt (w tym czasie był to Red Hat Enterprise Linux). Dopiero potem można było systematycznie aktualizować OpenShift, węzeł po węźle. Nie było mowy o automatyzacji tego procesu.
Obecnie, ponieważ OpenShift Container Platform w pełni kontroluje systemy i usługi na każdym węźle, w tym system operacyjny, zadanie to realizowane jest jednym kliknięciem w interfejsie webowym. Następnie uruchamiany jest specjalny operator w klastrze OpenShift, który zarządza całym procesem aktualizacji.
Nowy CSI
Drugim aspektem jest nowy CSI — kontroler interfejsu storage, który umożliwia podłączanie różnych zewnętrznych macierzy dyskowych do klastra OpenShift. Wsparcie dla wielu dostawców sterowników storage dla OpenShift opartych na sterownikach storage, które sami piszą producenci macierzy dyskowych. Pełna lista wspieranych sterowników CSI znajduje się w tym dokumencie: W tej liście można znaleźć wszystkie główne modele macierzy dyskowych czołowych producentów (Dell/EMC, IBM, NetApp, Hitachi, HPE, PureStorage), rozwiązań SDS (Ceph) oraz chmur obliczeniowych (AWS, Azure, Google). OpenShift 4.2 obsługuje pracę z driverami CSI specyfikacji CSI w wersji 1.1.
RedHat OpenShift Service Mesh
Oparty na projektach Istio, Kiali i Jaeger — Red Hat OpenShift Service Mesh, oprócz standardowych zadań routingu zapytań między usługami, umożliwia ich śledzenie i wizualizację. To pomaga programistom uprościć interakcję, monitorowanie i zarządzanie aplikacją wdrożoną w Red Hat OpenShift.
Wizualizacja aplikacji o architekturze mikrousługowej z wykorzystaniem Kiali
Aby maksymalnie uprościć procesy instalacji, usług oraz zarządzania cyklem życia Service Mesh, Red Hat OpenShift oferuje administratorom specjalnego operatora – Service Mesh Operator. To operator Kubernetes, który pozwala na wdrożenie w klastrze przeconfigurowanych pakietów Istio, Kiali i Jaeger, maksymalnie redukując administracyjną obciążenie związane z zarządzaniem aplikacjami.
CRI-O zamiast Docker
Domyślny runtime kontenerowy Docker został zastąpiony CRI-O. Z CRI-O można było korzystać już w wersji 3.11, ale w 4.2 stał się głównym. Nie jest to ani dobrze, ani źle, ale warto to mieć na uwadze podczas korzystania z produktu.
Operatory i wdrażanie aplikacji
Operatory to nowa jednostka w RedHat OpenShift, która pojawiła się w czwartej wersji. To metoda pakowania, wdrażania i zarządzania aplikacją Kubernetes. Można to sobie wyobrazić jako plugin do aplikacji, zarządzany za pomocą API Kubernetes i narzędzi kubectl, dla aplikacji wdrożonych w kontenerach.
Operatory Kubernetes pomagają automatyzować wszelkie zadania związane z administracją i zarządzaniem cyklem życia aplikacji, którą wdrażasz w swoim klastrze. Na przykład, operator może automatyzować aktualizacje, tworzenie kopii zapasowych i skalowanie aplikacji, zmieniać konfigurację itd. Pełną listę operatorów można zobaczyć na .
OperatorHub jest dostępny bezpośrednio z interfejsu webowego konsoli zarządzania. Stanowi on katalog aplikacji dla OpenShift, wspierany przez Red Hat. To znaczy, że wszystkie operatory zatwierdzone przez Red Hat będą objęte wsparciem dostawcy.
Portal OperatorHub w konsoli zarządzania OpenShift
Uniwersalny obraz bazowy
To jest zunifikowany zestaw obrazów systemu operacyjnego RHEL, które można wykorzystać do tworzenia aplikacji w kontenerach. Są dostępne minimalne, standardowe i pełne zestawy. Zajmują bardzo mało miejsca, wspierają wszystkie niezbędne zainstalowane pakiety oraz języki programowania.
Narzędzia CI/CD
W RedHat OpenShift 4.2 wprowadzono możliwość wyboru między Jenkins a OpenShift Pipelines opartych na Tekton Pipelines.
OpenShift Pipelines oparty jest na Tekton, który lepiej wspiera podejścia Pipeline as Code oraz GitOps. W pipeline'ach OpenShift każdy krok wykonuje się w osobnym kontenerze, dzięki czemu zasoby są wykorzystywane tylko w czasie wykonywania kroku. To daje programistom pełną kontrolę nad pipeline'ami dostarczania modułów, wtyczkami oraz kontrolą dostępu bez centralnego serwera CI/CD do zarządzania.
OpenShift Pipelines jest obecnie w fazie Preview dla programistów i dostępny jako operator na klastrze OpenShift 4. Oczywiście, użytkownicy OpenShift mogą wciąż korzystać z Jenkins w RedHat OpenShift 4.
Aktualizacje w zarządzaniu dla programistów
W 4.2 OpenShift całkowicie zaktualizował interfejs webowy zarówno dla programistów, jak i administratorów.
W poprzednich wersjach OpenShift wszyscy pracowali w trzech konsolach: katalogu usług, konsoli administratora oraz konsoli roboczej. Teraz klaster dzieli się tylko na dwie części — konsolę administratora i konsolę programisty.
Konsola programisty zyskała znaczące usprawnienia interfejsu użytkownika. Teraz wyświetlanie topologii aplikacji i ich kompilacji jest wygodniejsze. Ułatwia to programistom tworzenie, wdrażanie i wizualizowanie aplikacji kontenerowych oraz zasobów klastra, pozwalając im skupić się na tym, co dla nich ważne.
Portal programisty w konsoli zarządzania OpenShift
Odo
Odo to narzędzie wiersza poleceń, skoncentrowane na programistach, które upraszcza rozwój aplikacji w OpenShift. Korzystając z interakcji w stylu git push, to CLI pomaga programistom, którzy nie znają Kubernetes, w tworzeniu aplikacji w OpenShift.
Integracja ze środowiskami programistycznymi
Programiści mogą teraz tworzyć, debugować i wdrażać swoje aplikacje w OpenShift, nie opuszczając swojego ulubionego środowiska do kodowania, takiego jak Microsoft Visual Studio, JetBrains (w tym IntelliJ), Eclipse Desktop itp.
Red Hat OpenShift Deployment extension for Microsoft Azure DevOps
Zostało wprowadzone rozszerzenie Red Hat OpenShift Deployment dla Microsoft Azure DevOps. Teraz użytkownicy tego zestawu narzędzi DevOps mogą wdrażać swoje aplikacje w Azure Red Hat OpenShift lub dowolnym innym klastrze OpenShift bezpośrednio z Microsoft Azure DevOps.
Przejście z wersji trzeciej na czwartą
Ponieważ mamy do czynienia z nowym wydaniem, a nie aktualizacją, nie można po prostu zainstalować czwartej wersji na trzeciej. Aktualizacja z trzeciej na czwartą wersję nie będzie wspierana.
Ale jest też dobra wiadomość: Red Hat oferuje narzędzia do przenoszenia projektów z wersji 3.7 do 4.2. Możesz przenieść obciążenia aplikacji za pomocą narzędzia Cluster Application Migration (CAM). CAM pozwala kontrolować migrację i minimalizować czas przestoju aplikacji.
OpenShift 4.3
Główne nowości opisane w tym artykule pojawiły się w wersji 4.2. W niedawno wydanej wersji 4.3 zmiany nie są aż tak znaczące, ale mimo to jest kilka nowości. Lista zmian jest dość rozbudowana, wymienimy te, które naszym zdaniem są najbardziej znaczące:
Aktualizacja wersji Kubernetes do 1.16.
Wersja została uaktualniona od razu o dwa kroki; w OpenShift 4.2 była 1.14.
Szyfrowanie danych w etcd
Począwszy od wersji 4.3, wprowadzono możliwość szyfrowania danych w bazie etcd. Po włączeniu szyfrowania możliwe będzie szyfrowanie następujących zasobów OpenShift API i Kubernetes API: Secrets, ConfigMaps, Routes, tokeny dostępu i autoryzacji OAuth.
Helm
Dodano wsparcie dla wersji Helm 3 – popularnego menedżera pakietów dla Kubernetes. Na razie wsparcie ma status TECHNOLOGY PREVIEW. W przyszłych wersjach OpenShift wsparcie dla Helm zostanie rozszerzone do pełnego. Narzędzie helm cli jest dostarczane razem z OpenShift i można je pobrać z webowej konsoli zarządzania klastrami.
Aktualizacja Dashboardu Projektu
W nowej wersji Dashboardu Projektu dostarczane są dodatkowe informacje na stronie projektu: status projektu, wykorzystanie zasobów oraz limity dla projektu.
Wyświetlanie podatności dla quay w konsoli webowej
Do konsoli zarządzania dodano funkcję wyświetlania znanych podatności dla obrazów w repozytoriach Quay. Obsługiwane jest wyświetlanie podatności dla repozytoriów lokalnych i zewnętrznych.
Uproszczono tworzenie offline operatorhub
W przypadku wdrażania klastra OpenShift w izolowanej sieci, której dostęp do internetu jest ograniczony lub nie istnieje, uproszczono tworzenie „lustrzanego odbicia” rejestru OperatorHub. Teraz można to zrobić w zaledwie trzech poleceniach.
Autorzy:
Wiktor Puczkow, Jurij Sienieniukow
Źródło: habr.com
