To publikacja wprowadzająca do serii materiałów poświęconych zmianom, ulepszeniom i dodatkom w nadchodzącej aktualizacji platformy Red Hat OpenShift do wersji 4.0, które pomogą w przejściu na nową wersję.
Od momentu, gdy przedstawiciele dopiero kształtującej się społeczności Kubernetes po raz pierwszy spotkali się jesienią 2014 roku w biurze Google w Seattle, było jasne, że projekt Kubernetes zmieni współczesne podejścia do tworzenia i wdrażania oprogramowania. Równocześnie publiczni dostawcy usług chmurowych kontynuowali intensywne inwestycje w rozwój infrastruktury i usług, co znacząco ułatwiło i uprościło pracę w IT oraz tworzenie oprogramowania i uczyniło je niesamowicie dostępnymi, co w początkach tej dekady wydawało się trudne do wyobrażenia.
Oczywiście, ogłoszenie każdej nowej usługi chmurowej wiązało się z licznymi dyskusjami ekspertów na Twitterze, a debaty dotyczyły najróżniejszych tematów — w tym końca ery otwartego kodu źródłowego, upadku IT po stronie klienta (on-premises IT), nieuchronności nowej monopolii oprogramowania w chmurze oraz tego, jak nowa paradygma X zastąpi wszystkie pozostałe paradygmy.
Nie ma wątpliwości, że wszystkie te spory były dość absurdalne.
Rzeczywistość jest taka, że nic nigdzie nie znika, a dziś obserwujemy wykładniczy wzrost końcowych produktów i sposobów ich tworzenia, co związane jest z ciągłym pojawianiem się nowego oprogramowania w naszym życiu. I pomimo, że wszystko wokół będzie się zmieniać, w swej istocie pozostanie niezmienne. Programiści nadal będą pisać kod z błędami, inżynierowie operacyjni i specjaliści ds. niezawodności będą nadal nosić pager i otrzymywać powiadomienia automatyczne w Slacku, menedżerowie będą wciąż operować pojęciami OpEx i CapEx, a za każdym razem, gdy wystąpi awaria, główny programista westchnie mówiąc: „Mówiłem...”
Co naprawdę powinno być przedmiotem dyskusji, to co możemy uzyskać, aby tworzyć lepsze produkty programistyczne, i jak pozwala to zwiększyć bezpieczeństwo oraz uprościć i usprawnić procesy deweloperskie. Wraz ze wzrostem złożoności projektów pojawiają się nowe ryzyka, a dziś życie ludzi w dużym stopniu zależy od oprogramowania, przez co deweloperzy są zobowiązani do lepszego wykonywania swojej pracy.
Kubernetes jest jednym z takich narzędzi. Trwają prace nad zintegrowaniem go z innymi narzędziami i usługami w ramach Red Hat OpenShift, aby stworzyć jedną platformę, która uczyni oprogramowanie bardziej niezawodnym, łatwiejszym w zarządzaniu i bezpiecznym dla użytkowników.
Mając to na uwadze, zespół OpenShift zadaje sobie jedno proste pytanie:
Jak można uprościć i ułatwić pracę z Kubernetesem?
Odpowiedź jest zaskakująco oczywista:
- automatyzować złożone aspekty wdrażania w chmurze lub poza nią;
- skupiać się na niezawodności, ukrywając przy tym złożoność;
- nieprzerwanie dążyć do wypuszczania prostych i bezpiecznych aktualizacji;
- osiągać kontrolę i możliwość audytu;
- dążyć do zapewnienia wysokiego poziomu bezpieczeństwa od samego początku, ale bez uszczerbku dla użyteczności.
Następna wersja OpenShift powinna uwzględniać zarówno doświadczenie twórców, jak i doświadczenia innych deweloperów, którzy na dużą skalę wprowadzają oprogramowanie w największych firmach na świecie. Dodatkowo, należy uwzględnić wszelkie zdobyte doświadczenie otwartych ekosystemów, które są podstawą współczesnego świata. Ważne jest również, aby porzucić mentalność dewelopera amatora na rzecz nowej filozofii zautomatyzowanej przyszłości. Musi to być „most” między dawnymi a nowymi metodami wdrażania oprogramowania, w pełni wykorzystując wszystkie dostępne zasoby — niezależnie od tego, czy są zarządzane przez największego dostawcę chmurowego, czy uruchamiane na małych systemach na obrzeżach.
Jak osiągnąć taki wynik?
W Red Hat zwykle długo wykonuje się nudną i niewdzięczną pracę, aby zachować istniejącą społeczność i nie dopuścić do zamknięcia projektów, w które firma jest zaangażowana. W społeczności open-source znajduje się ogromna liczba utalentowanych programistów, którzy tworzą najbardziej niezwykłe rzeczy – zabawne, edukacyjne, otwierające nowe możliwości i po prostu piękne, ale oczywiście nikt nie oczekuje, że wszyscy uczestnicy będą działać w jednym kierunku lub będą dążyć do wspólnych celów. Wykorzystanie tej energii, przekierowanie jej w odpowiednie tory, czasami jest konieczne dla rozwoju obszarów, które byłyby korzystne dla naszych użytkowników, ale jednocześnie musimy śledzić rozwój naszych społeczności i uczyć się od nich.
Na początku 2018 roku Red Hat nabyła projekt CoreOS, który miał podobne wizje na przyszłość – bardziej bezpieczną i niezawodną, opracowywaną na zasadach open-source. Firma pracowała nad dalszym rozwojem tych idei i ich realizacją, wprowadzając w życie naszą filozofię – starając się zapewnić bezpieczne działanie całego oprogramowania. Cała ta praca opiera się na Kubernetes, Linuxie, publicznych chmurach, prywatnych chmurach i tysiącach innych projektów, które stanowią fundament naszej nowoczesnej cyfrowej ekosystemu.
Nowa wersja OpenShift 4 będzie zrozumiała, zautomatyzowana i bardziej naturalna.
Platforma OpenShift będzie współpracować z najlepszymi i najbardziej niezawodnymi systemami operacyjnymi Linux, z wsparciem bare-metal, wygodną wirtualizacją, automatycznym programowaniem infrastruktury i oczywiście kontenerami (które w zasadzie są po prostu obrazami Linux).
Platforma musi być bezpieczna od samego początku, ale jednocześnie zapewniać możliwość wygodnych iteracji dla programistów – czyli dysponować wystarczającą elastycznością i niezawodnością, a jednocześnie umożliwiać administratorom audyt i zapewniać łatwość zarządzania.
Musi pozwalać na uruchamianie oprogramowania „jako usługi” oraz nie prowadzić do niekontrolowanego wzrostu infrastruktury dla operatorów.
Pozwoli to programistom skupić się na tworzeniu prawdziwych produktów dla użytkowników i klientów. Nie będą musieli przeszukiwać gąszczu ustawień sprzętu i oprogramowania, a wszelkie przypadkowe komplikacje zostaną w przeszłości.
OpenShift 4: platforma NoOps, która nie wymaga wsparcia
W Opisano zadania, które pomogły ukształtować wizję firmy dotyczącej OpenShift 4. Zespół ma za zadanie maksymalnie uprościć codzienne zadania związane z eksploatacją i wsparciem oprogramowania, uczynić te procesy łatwymi i swobodnymi – zarówno dla specjalistów zajmujących się wdrożeniem, jak i dla programistów. Ale jak można zbliżyć się do tego celu? Jak stworzyć platformę do uruchamiania oprogramowania, która wymaga minimalnej interwencji? Co w ogóle oznacza NoOps w tym kontekście?
Jeśli spróbować się abstrahować, to dla programistów pojęcia „serverless” lub „NoOps” oznaczają narzędzia i usługi, które pozwalają ukryć składnik „eksploatacyjny” lub zminimalizować ten ciężar dla programisty.
- Pracuj nie z systemami, a z interfejsami aplikacyjnymi (API).
- Nie zajmuj się wdrażaniem oprogramowania – niech zajmie się tym dostawca.
- Nie należy od razu brać się za tworzenie dużego frameworka – zacznij od pisania małych fragmentów, które będą pełniły rolę „klocków konstrukcyjnych”, staraj się, aby ten kod działał z danymi i zdarzeniami, a nie z dyskami i bazami danych.
Zadanie, jak zawsze, polega na przyspieszeniu iteracji w procesie tworzenia oprogramowania, zapewnieniu możliwości tworzenia lepszej jakości produktów oraz na tym, aby programista nie musiał martwić się o systemy, na których uruchamiane jest jego oprogramowanie. Doświadczony programista doskonale rozumie, że jeśli skupi się na użytkownikach, sytuacja może szybko się zmienić, dlatego nie należy wkładać zbyt wiele wysiłku w pisanie oprogramowania, jeśli nie jesteś absolutnie pewny jego potrzeby.
Dla specjalistów zajmujących się wsparciem i eksploatacją słowo „NoOps” może brzmieć nieco przerażająco. Jednak podczas rozmowy z inżynierami ds. eksploatacji staje się oczywiste, że stosowane przez nich wzorce i metodyki mające na celu zapewnienie niezawodności (Site Reliability Engineering, SRE) w dużej mierze pokrywają się z opisanymi wcześniej wzorcami:
- Nie zarządzaj systemami – automatyzuj procesy ich zarządzania.
- Nie wdrażaj oprogramowania – stwórz pipeline do jego wdrożenia.
- Staraj się nie łączyć wszystkich swoich usług w jedną całość i nie pozwalaj, aby awaria jednej z nich prowadziła do awarii całego systemu – rozprosz je w całej infrastrukturze, wykorzystując narzędzia automatyzacji, i połącz je, przewidując możliwość kontroli i monitorowania.
Specjaliści ds. SRE wiedzą, że coś może pójść nie tak, i będą musieli śledzić i rozwiązywać problem – dlatego automatyzują rutynową pracę i określają z góry dopuszczalne odchylenia (error budgets), aby być gotowym na ustalanie priorytetów i podejmowanie decyzji w sytuacji kryzysowej.
Kubernetes w OpenShift to platforma, która ma na celu rozwiązanie dwóch głównych zadań: zamiast zmuszać Cię do zajmowania się maszynami wirtualnymi lub interfejsami API load balancerów, pracuje się z abstrakcjami wyższego poziomu – z procesami wdrażania i usługami. Zamiast instalować agentów oprogramowania można uruchomić kontenery, a zamiast pisać własny stos monitorowania użyć narzędzi dostępnych na platformie. Tak więc tajny składnik OpenShift 4 nie stanowi żadnej tajemnicy – wystarczy przyjąć zasady SRE oraz koncepcje serverless i doprowadzić je do logicznego zakończenia, wspierając deweloperów i inżynierów ds. eksploatacji:
- Automatyzować i standaryzować infrastrukturę, która jest wykorzystywana przez aplikacje
- Połączyć procesy wdrażania i rozwoju, nie ograniczając przy tym samych deweloperów
- Sprawić, aby uruchomienie, audyt i zapewnienie bezpieczeństwa setnej usługi, funkcji, aplikacji lub całego stosu były równie proste jak pierwszej.
Jakie są różnice między platformą OpenShift 4 a jej poprzedniczkami oraz standardowym podejściem do rozwiązywania podobnych problemów? Jak osiągane jest skalowanie dla zespołów zajmujących się wdrażaniem i eksploatacją? To dlatego, że królem w tej sytuacji jest klaster. Zatem,
- Zróbmy tak, aby przeznaczenie klastrów było jasne (Drogie chmurze, ten klaster stworzyłem, bo mogłem)
- Maszyny i systemy operacyjne istnieją, aby obsługiwać klaster (Wasza Wysokość)
- Zarządzaj stanem hostów w klastrze, minimalizując ich przemieszczenia (drift).
- Dla każdego ważnego elementu systemu potrzebny jest opiekun (mechanizm), który będzie monitorować i usuwać problemy.
- Awaria *każdego* aspektu lub elementu systemu to, że odpowiednie mechanizmy odzyskiwania— to normalna część życia.
- Cała infrastruktura powinna być konfigurowana za pomocą API.
- Używaj Kubernetes do uruchamiania Kubernetes. (Tak, to nie jest literówka)
- Aktualizacje powinny być instalowane łatwo i bezproblemowo. Jeśli zainstalowanie aktualizacji wymaga więcej niż jednego kliknięcia myszą, to oczywiście coś robimy źle.
- Monitorowanie i debugowanie dowolnego komponentu nie powinno stanowić problemu, dlatego śledzenie i raportowanie całej infrastruktury również powinno być proste i wygodne.
Chcesz zobaczyć możliwości platformy w akcji?
Wersja beta OpenShift 4 jest dostępna dla programistów. Dzięki prostemu w użyciu installerowi można uruchomić klaster na AWS na Red Hat CoreOS. Aby skorzystać z wersji beta, wystarczy konto AWS do dostarczenia infrastruktury oraz zestaw kont do uzyskania dostępu do obrazów beta.
- Aby zacząć, przejdź do i kliknij „Rozpocznij”.
- Zaloguj się do swojego konta Red Hat (lub załóż nowe) i postępuj zgodnie z instrukcjami, aby skonfigurować swój pierwszy klaster.
Po pomyślnej instalacji zapoznaj się z naszymi materiałami szkoleniowymi , aby uzyskać bardziej szczegółowy wgląd w systemy i koncepcje, które sprawiają, że platforma OpenShift 4 jest tak prostym i wygodnym narzędziem do uruchamiania Kubernetes.
Wypróbuj nową wersję OpenShift i podziel się swoją opinią. Dążymy do tego, aby praca z Kumbernetes była maksymalnie dostępna i nie wymagała wysiłku – przyszłość NoOps zaczyna się już dziś.
A teraz uwaga!
Na konferencji 20 kwietnia jeden z deweloperów OpenShift, Wadim Rutkowski, poprowadzi warsztaty — zburzy dziesięć klastrów i nakłoni do naprawy. Konferencja jest płatna, ale z kodem promocyjnym #RedHat zniżka 37%.
Warsztaty od 17:15 do 18:15, a stoisko działa przez cały dzień. Koszulki, czapki, naklejki — jak zwykle!
Sala #2
„Tutaj trzeba zmienić cały system: naprawiamy uszkodzone klastry k8s razem z certyfikowanymi fachowcami.”
Źródło: habr.com
