Czwarta wersja OpenShift została wydana stosunkowo niedawno. Aktualna wersja 4.3 jest dostępna od końca stycznia i wszystkie zmiany w niej zawarte są albo czymś zupełnie nowym, czego nie było w trzeciej wersji, albo poważną aktualizacją tego, co pojawiło się w wersji 4.1. Wszystko, co Ci teraz powiemy, musi poznać, zrozumieć i wziąć pod uwagę osoby pracujące z OpenShift i planujące przejście na nową wersję.
Wraz z wydaniem OpenShift 4.2 firma Red Hat ułatwiła pracę z Kubernetesem. Pojawiły się nowe narzędzia i wtyczki do tworzenia kontenerów, potoków CI/CD i wdrożeń bezserwerowych. Innowacje dają programistom możliwość skupienia się na pisaniu kodu, a nie na zajmowaniu się Kubernetesem.
Właściwie, co nowego w wersjach OpenShift 4.2 i 4.3?
W stronę chmur hybrydowych
Planując nową infrastrukturę IT lub rozwijając istniejący krajobraz IT, firmy coraz częściej rozważają chmurowe podejście do udostępniania zasobów IT, dla których wdrażają rozwiązania chmury prywatnej lub wykorzystują siłę dostawców chmur publicznych. Tym samym nowoczesne infrastruktury IT coraz częściej budowane są w oparciu o model chmury „hybrydowej”, gdy wykorzystywane są zarówno zasoby lokalne, jak i zasoby chmury publicznej ze wspólnym systemem zarządzania. Red Hat OpenShift 4.2 został specjalnie zaprojektowany, aby uprościć przejście do modelu chmury hybrydowej i ułatwić łączenie zasobów od dostawców takich jak AWS, Azure i Google Cloud Platform z klastrem, a także korzystanie z chmur prywatnych na VMware i OpenStack.
Nowe podejście do instalacji
W wersji 4 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 pojedynczy plik binarny napisany w Go. Instalator Openshit przygotowuje plik YAML z konfiguracją wymaganą do wdrożenia.
W przypadku instalacji przy użyciu zasobów chmury konieczne będzie podanie minimalnych informacji o przyszłym klastrze: strefa DNS, liczba węzłów roboczych, szczegółowe ustawienia dostawcy chmury, informacje o koncie umożliwiającym dostęp do dostawcy chmury. Po przygotowaniu pliku konfiguracyjnego klaster można wdrożyć za pomocą jednego polecenia.
W przypadku instalacji na własnych zasobach obliczeniowych, np. przy korzystaniu z chmury prywatnej (obsługiwane są vSphere i OpenStack) lub przy instalacji na serwerach typu bare metal, konieczna będzie ręczna konfiguracja infrastruktury – przygotowanie minimalnej liczby maszyn wirtualnych lub serwerów fizycznych wymaganych do utworzenia klastra płaszczyzny kontrolnej, skonfiguruj usługi sieciowe. Po tej konfiguracji klaster OpenShift można w podobny sposób utworzyć za pomocą jednego polecenia narzędzia openshift-installer.
Aktualizacje infrastruktury
Integracja z CoreOS
Kluczową aktualizacją jest integracja z Red Hat CoreOS. Węzły główne Red Hat OpenShift mogą teraz działać tylko na nowym systemie operacyjnym. Jest to darmowy system operacyjny firmy Red Hat, zaprojektowany specjalnie dla rozwiązań kontenerowych. Red Hat CoreOS to lekki Linux zoptymalizowany pod kątem uruchamiania kontenerów.
Jeśli w wersji 3.11 system operacyjny i OpenShift istniały osobno, to w wersji 4.2 są one nierozerwalnie powiązane z OpenShift. Teraz jest to jedno urządzenie – niezmienna infrastruktura.
W przypadku klastrów korzystających z RHCOS dla wszystkich węzłów aktualizacja OpenShift Container Platform jest prostym i wysoce zautomatyzowanym procesem.
Wcześniej, aby zaktualizować OpenShift, trzeba było najpierw zaktualizować podstawowy system operacyjny, na którym działał produkt (wówczas Red Hat Enterprise Linux). Tylko wtedy będzie można stopniowo aktualizować OpenShift, węzeł po węźle. Nie było mowy o jakiejkolwiek automatyzacji procesu.
Teraz, ponieważ platforma kontenerowa OpenShift w pełni kontroluje systemy i usługi w każdym węźle, w tym system operacyjny, zadanie to rozwiązuje się poprzez naciśnięcie przycisku w interfejsie internetowym. Następnie wewnątrz klastra OpenShift uruchamiany jest specjalny operator, który kontroluje cały proces aktualizacji.
Nowe CSI
Po drugie, nowy CSI to kontroler interfejsu pamięci masowej, który umożliwia podłączenie różnych zewnętrznych systemów pamięci masowej do klastra OpenShift. Wielu dostawców sterowników pamięci masowej dla OpenShift jest obsługiwanych w oparciu o sterowniki pamięci masowej napisane przez samych producentów systemów pamięci masowej. Pełną listę obsługiwanych sterowników CSI można znaleźć w tym dokumencie: . Na tej liście można znaleźć wszystkie główne modele macierzy dyskowych wiodących producentów (Dell/EMC, IBM, NetApp, Hitachi, HPE, PureStorage), rozwiązań SDS (Ceph) i przechowywania w chmurze (AWS, Azure, Google). OpenShift 4.2 obsługuje sterowniki CSI ze specyfikacją CSI w wersji 1.1.
Siatka usług RedHat OpenShift
Bazując na projektach Istio, Kiali i Jaeger, Red Hat OpenShift Service Mesh oprócz zwykłych zadań routingu żądań pomiędzy usługami, pozwala na ich śledzenie i wizualizację. Pomaga to programistom w łatwej komunikacji, monitorowaniu i zarządzaniu aplikacją wdrożoną w Red Hat OpenShift.
Wizualizacja aplikacji posiadającej architekturę mikroserwisową z wykorzystaniem Kiali
Aby maksymalnie uprościć instalację, konserwację i zarządzanie cyklem życia Service Mesh, Red Hat OpenShift udostępnia administratorom specjalnego operatora, Service Mesh Operator. Jest to operator Kubernetes, który umożliwia wdrażanie rekonfigurowanych pakietów Istio, Kiali i Jaeger w klastrze, maksymalizując obciążenie administracyjne związane z zarządzaniem aplikacjami.
CRI-O zamiast Dockera
Domyślny Docker środowiska uruchomieniowego kontenera został zastąpiony przez CRI-O. Można było zastosować CRI-O już w wersji 3.11, ale w 4.2 stało się to głównym. Nie jest to ani dobre, ani złe, ale warto o tym pamiętać podczas korzystania z produktu.
Operatorzy i wdrażanie aplikacji
Operatorzy to nowy podmiot w RedHat OpenShift, który pojawił się w czwartej wersji. Jest to metoda pakowania, wdrażania i zarządzania aplikacją Kubernetes. Można go traktować jako wtyczkę do aplikacji wdrażanych w kontenerach, sterowaną przez Kubernetes API i narzędzia kubectl.
Operatorzy Kubernetes pomagają zautomatyzować wszelkie zadania związane z administracją i zarządzaniem cyklem życia aplikacji wdrażanej w klastrze. Operator może na przykład zautomatyzować aktualizacje, kopie zapasowe i skalowanie aplikacji, zmienić konfigurację itp. Pełną listę operatorów można znaleźć na stronie .
Dostęp do OperatorHub można uzyskać bezpośrednio z interfejsu internetowego konsoli zarządzania. Jest to katalog aplikacji dla OpenShift prowadzony przez firmę Red Hat. Te. wszyscy operatorzy zatwierdzeni przez firmę Red Hat będą objęci wsparciem dostawcy.
Portal OperatorHub w konsoli zarządzania OpenShift
Uniwersalny obraz bazowy
Jest to ustandaryzowany zestaw obrazów systemu operacyjnego RHEL, których można używać do tworzenia aplikacji kontenerowych. Istnieją zestawy minimalne, standardowe i pełne. Zajmują bardzo mało miejsca i obsługują wszystkie niezbędne zainstalowane pakiety i języki programowania.
Narzędzia CI/CD
W RedHat OpenShif 4.2 stał się możliwy wybór pomiędzy Jenkinsem a OpenShift Pipelines opartym na Tekton Pipelines.
OpenShift Pipelines opiera się na Tektonie, który jest lepiej obsługiwany przez Pipeline w miarę zbliżania się do Code i GitOps. W potokach OpenShift każdy krok jest uruchamiany we własnym kontenerze, więc zasoby są używane tylko podczas wykonywania kroku. Daje to programistom pełną kontrolę nad potokami dostarczania modułów, wtyczkami i kontrolą dostępu bez konieczności zarządzania centralnym serwerem CI/CD.
OpenShift Pipelines jest obecnie w wersji Developer Preview i jest dostępny jako operator w klastrze OpenShift 4. Oczywiście użytkownicy OpenShift mogą nadal używać Jenkinsa w RedHat OpenShift 4.
Aktualizacje zarządzania programistami
W wersji 4.2 OpenShift interfejs sieciowy został całkowicie zaktualizowany zarówno dla programistów, jak i administratorów.
W poprzednich wersjach OpenShift wszyscy pracowali na trzech konsolach: katalogu usług, konsoli administratora i konsoli roboczej. Teraz klaster jest podzielony tylko na dwie części - konsolę administratora i konsolę programisty.
Konsola programisty otrzymała znaczące ulepszenia interfejsu użytkownika. Teraz wygodniej wyświetla topologie aplikacji i ich zespołów. Ułatwia to programistom tworzenie, wdrażanie i wizualizację aplikacji kontenerowych i zasobów klastrowych. Pozwala im skupić się na tym, co jest dla nich ważne.
Portal deweloperski w konsoli zarządzania OpenShift
Odo
Odo to narzędzie wiersza poleceń przeznaczone dla programistów, które upraszcza tworzenie aplikacji w OpenShift. Korzystając z komunikacji w stylu git push, ten interfejs wiersza polecenia pomaga programistom, którzy nie mają doświadczenia z Kubernetes, w tworzeniu aplikacji w OpenShift.
Integracja ze środowiskami deweloperskimi
Programiści mogą teraz tworzyć, debugować i wdrażać swoje aplikacje w OpenShift bez opuszczania ulubionego środowiska programistycznego, takiego jak Microsoft Visual Studio, JetBrains (w tym IntelliJ), Eclipse Desktop itp.
Rozszerzenie wdrożenia Red Hat OpenShift dla Microsoft Azure DevOps
Zostało wydane rozszerzenie Red Hat OpenShift Deployment dla Microsoft Azure DevOps. Użytkownicy tego zestawu narzędzi DevOps mogą teraz 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 do czwartej
Ponieważ mówimy o nowej wersji, a nie aktualizacji, nie można po prostu umieścić czwartej wersji na trzeciej. Aktualizacja z wersji XNUMX do wersji XNUMX nie będzie obsługiwana..
Ale jest dobra wiadomość: Red Hat udostępnia narzędzia do migracji projektów z wersji 3.7 do 4.2. Obciążenia aplikacji można migrować za pomocą narzędzia Cluster Application Migration (CAM). CAM pozwala kontrolować migrację i minimalizować przestoje aplikacji.
OpenShift 4.3
Główne innowacje opisane w tym artykule pojawiły się w wersji 4.2. Niedawno wydane zmiany w wersji 4.3 nie są tak duże, ale wciąż jest kilka nowych rzeczy. Lista zmian jest dość obszerna, oto najważniejsze naszym zdaniem:
Zaktualizuj wersję Kubernetes do 1.16.
Wersja została zaktualizowana o dwa etapy od razu; w OpenShift 4.2 było to 1.14.
Szyfrowanie danych w itp
Począwszy od wersji 4.3 możliwe stało się szyfrowanie danych w bazie danych etcd. Po włączeniu szyfrowania możliwe będzie szyfrowanie następujących zasobów OpenShift API i Kubernetes API: Secrets, ConfigMaps, Routes, tokens dostępu i autoryzacja OAuth.
Ster
Dodano obsługę Helm w wersji 3, popularnego menedżera pakietów dla Kubernetes. Na razie wsparcie ma status PRZEGLĄD TECHNOLOGII. Obsługa Helm zostanie rozszerzona do pełnej obsługi w przyszłych wersjach OpenShift. Narzędzie helm cli jest dostarczane z OpenShift i można je pobrać z konsoli internetowej zarządzania klastrem.
Aktualizacja panelu projektu
W nowej wersji Project Dashboard udostępnia na stronie projektu dodatkowe informacje: status projektu, wykorzystanie zasobów oraz limity projektu.
Wyświetlanie podatności dla Quay w konsoli internetowej
Do konsoli zarządzania dodano funkcję wyświetlającą znane luki w zabezpieczeniach obrazów w repozytoriach Quay. Obsługiwane jest wyświetlanie luk w zabezpieczeniach repozytoriów lokalnych i zewnętrznych.
Uproszczone tworzenie centrum operatorskiego offline
W przypadku wdrożenia klastra OpenShift w izolowanej sieci, z której dostęp do Internetu jest ograniczony lub nie ma go wcale, uproszczone jest utworzenie „lustrzanego” rejestru OperatorHub. Teraz można to zrobić za pomocą zaledwie trzech zespołów.
Autorzy:
Wiktor Puchkow, Jurij Semenyukow
Źródło: www.habr.com