To pierwszy z serii postów na temat zmian, ulepszeń i dodatków w nadchodzącej aktualizacji platformy Red Hat OpenShift 4.0, które pomogą Ci przygotować się do przejścia na nową wersję.
Od chwili, gdy raczkująca społeczność Kubernetes po raz pierwszy zebrała się w biurze Google w Seattle jesienią 2014 roku, było jasne, że projekt Kubernetes ma zrewolucjonizować dzisiejszy sposób tworzenia i wdrażania oprogramowania. Jednocześnie dostawcy usług chmury publicznej w dalszym ciągu aktywnie inwestowali w rozwój infrastruktury i usług, dzięki czemu praca z IT i tworzenie oprogramowania stały się znacznie łatwiejsze i bardziej dostępne, a także niezwykle przystępne, o czym na początku historii mało kto mógł sobie wyobrazić dekada.
Oczywiście zapowiedzi każdej nowej usługi chmurowej towarzyszyły liczne dyskusje wśród ekspertów na Twitterze, a debaty toczyły się na różne tematy – m.in. koniec ery open source, upadek IT on-premise czy nieuchronność nowego monopolu na oprogramowanie w chmurze oraz o tym, jak nowy paradygmat X zastąpi wszystkie inne paradygmaty.
Nie trzeba dodawać, że wszystkie te spory były bardzo głupie
Rzeczywistość jest taka, że nic nie zniknie i dziś możemy zaobserwować wykładniczy wzrost produktów końcowych i sposobu ich opracowywania, ze względu na ciągłe pojawianie się nowego oprogramowania w naszym życiu. I pomimo tego, że wszystko wokół się zmieni, jednocześnie w istocie wszystko pozostanie niezmienione. Twórcy oprogramowania nadal będą pisać kod z błędami, inżynierowie operacyjni i specjaliści ds. niezawodności nadal będą chodzić z pagerami i otrzymywać automatyczne alerty w Slacku, menedżerowie nadal będą działać w koncepcjach OpEx i CapEx, a za każdym razem, gdy wystąpi awaria, starszy programista wzdycham smutno ze słowami: „A nie mówiłem”…
Oh naprawdę należy omówić, to jakie narzędzia możemy mieć do dyspozycji, aby tworzyć lepsze oprogramowanie i w jaki sposób mogą one poprawić bezpieczeństwo oraz sprawić, że programowanie będzie łatwiejsze i bardziej niezawodne. Wraz ze wzrostem złożoności projektów rosną także nowe zagrożenia, a życie ludzi jest dziś tak zależne od oprogramowania, że programiści muszą po prostu starać się wykonywać lepszą robotę.
Kubernetes jest jednym z takich narzędzi. Trwają prace nad połączeniem Red Hat OpenShift z innymi narzędziami i usługami w jedną platformę, która sprawi, że oprogramowanie będzie bardziej niezawodne, łatwiejsze w zarządzaniu i bezpieczniejsze dla użytkowników.
Mając to na uwadze, zespół OpenShift zadaje jedno proste pytanie:
Jak sprawić, by praca z Kubernetesem była łatwiejsza i wygodniejsza?
Odpowiedź jest zaskakująco oczywista:
- automatyzować złożone aspekty wdrażania w chmurze lub poza chmurą;
- skoncentruj się na niezawodności, ukrywając złożoność;
- kontynuuj nieustanne prace nad wydawaniem prostych i bezpiecznych aktualizacji;
- osiągnąć sterowalność i audytowalność;
- dążyć do zapewnienia początkowo wysokiego bezpieczeństwa, ale nie kosztem użyteczności.
Kolejne wydanie OpenShift powinno uwzględniać zarówno doświadczenie twórców, jak i doświadczenie innych programistów, którzy na masową skalę wdrażają oprogramowanie w największych firmach na świecie. Ponadto musi uwzględniać całe zgromadzone doświadczenie otwartych ekosystemów, które leżą u podstaw współczesnego świata. Jednocześnie konieczne jest porzucenie starej mentalności programisty-amatora i przejście na nową filozofię zautomatyzowanej przyszłości. Musi wypełnić lukę między starymi i nowymi sposobami wdrażania oprogramowania i w pełni wykorzystać całą dostępną infrastrukturę — niezależnie od tego, czy jest hostowana przez największego dostawcę usług w chmurze, czy działa na małych systemach brzegowych.
Jak osiągnąć taki wynik?
W Red Hat zwyczajem jest wykonywanie nudnej i niewdzięcznej pracy przez długi czas, aby zachować ustaloną społeczność i zapobiec zamknięciu projektów, w które firma jest zaangażowana. Społeczność open source obejmuje ogromną liczbę 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 będą podążać w tym samym kierunku lub dążyć do wspólnych celów . Wykorzystanie tej energii i przekierowanie jej we właściwym kierunku jest czasami konieczne, aby rozwijać obszary, które przyniosą korzyści naszym użytkownikom, ale jednocześnie musimy monitorować rozwój naszych społeczności i uczyć się od nich.
Na początku 2018 roku Red Hat nabył projekt CoreOS, który miał podobne poglądy na przyszłość – bezpieczniejszy i bardziej niezawodny, stworzony na zasadach open source. Firma pracowała nad dalszym rozwojem tych pomysłów i ich wdrażaniem, wdrażając naszą filozofię w praktyce - starając się zapewnić, że całe oprogramowanie działa bezpiecznie. Cała ta praca opiera się na Kubernetesie, Linuksie, chmurach publicznych, chmurach prywatnych i tysiącach innych projektów, które stanowią podstawę naszego nowoczesnego ekosystemu cyfrowego.
Nowa wersja OpenShift 4 będzie przejrzysta, zautomatyzowana i bardziej naturalna
Platforma OpenShift będzie współpracować z najlepszymi i najbardziej niezawodnymi systemami operacyjnymi Linux, ze wsparciem sprzętu typu bare-metal, wygodną wirtualizacją, automatycznym programowaniem infrastruktury i oczywiście kontenerami (które w zasadzie są tylko obrazami Linuksa).
Platforma musi być bezpieczna od samego początku, ale jednocześnie umożliwiać programistom łatwą iterację — to znaczy być wystarczająco elastyczna i bezpieczna, a jednocześnie umożliwiać administratorom łatwe jej kontrolowanie i zarządzanie.
Powinno umożliwiać uruchamianie oprogramowania „jako usługę” i nie prowadzić do niemożliwego do zarządzania wzrostu infrastruktury dla operatorów.
Pozwoli programistom skoncentrować się na tworzeniu prawdziwych produktów dla użytkowników i klientów. Nie będziesz musiał przedzierać się przez dżunglę ustawień sprzętu i oprogramowania, a wszelkie przypadkowe komplikacje staną się przeszłością.
OpenShift 4: platforma NoOps, która nie wymaga konserwacji
В opisał te zadania, które pomogły ukształtować wizję firmy na OpenShift 4. Celem zespołu jest maksymalne uproszczenie codziennych zadań związanych z obsługą i utrzymaniem oprogramowania, aby procesy te były łatwe i relaksujące – zarówno dla specjalistów zajmujących się wdrożeniami, jak i dla programistów. Jak jednak 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óbujesz abstrahować, to dla programistów pojęcia „serverless” lub „NoOps” oznaczają narzędzia i usługi, które pozwalają ukryć komponent „operacyjny” lub zminimalizować to obciążenie dla programisty.
- Pracuj nie z systemami, ale z interfejsami aplikacji (API).
- Nie zajmuj się wdrażaniem oprogramowania – pozwól dostawcy zrobić to za Ciebie.
- Nie powinieneś od razu zabierać się za tworzenie dużego frameworka - zacznij od napisania małych elementów, które będą działać jak „elementy składowe”, spróbuj sprawić, aby ten kod działał z danymi i zdarzeniami, a nie z dyskami i bazami danych.
Celem, tak jak poprzednio, jest przyspieszenie iteracji w procesie tworzenia oprogramowania, zapewnienie możliwości tworzenia lepszych produktów, a także sprawienie, aby programista nie musiał martwić się o systemy, na których działa jego oprogramowanie. Doświadczony programista doskonale zdaje sobie sprawę, że skupienie się na użytkownikach może szybko zmienić obraz, dlatego nie należy wkładać zbyt wiele wysiłku w pisanie oprogramowania, jeśli nie jest się całkowicie pewnym, że jest ono potrzebne.
Dla specjalistów ds. konserwacji i operacji słowo „NoOps” może brzmieć nieco przerażająco. Jednak komunikując się z inżynierami terenowymi, staje się oczywiste, że stosowane przez nich wzorce i techniki mające na celu zapewnienie niezawodności i niezawodności (Site Reliability Engineering, SRE) mają wiele podobieństw do wzorców opisanych powyżej:
- Nie zarządzaj systemami - automatyzuj ich procesy zarządzania.
- Nie wdrażaj oprogramowania — utwórz potok jego wdrożenia.
- Unikaj łączenia wszystkich usług w jedną całość i nie pozwalaj, aby awaria jednej z nich spowodowała awarię całego systemu — rozprosz je po całej infrastrukturze za pomocą narzędzi do automatyzacji i połącz je w sposób umożliwiający monitorowanie i monitorowanie.
Specjaliści SRE wiedzą, że coś może pójść nie tak i będą musieli wyśledzić i naprawić problem, dlatego automatyzują rutynową pracę i z wyprzedzeniem ustalają budżety błędów, aby byli gotowi ustalać priorytety i podejmować decyzje, gdy pojawi się problem.
Kubernetes w OpenShift to platforma zaprojektowana, aby rozwiązać dwa główne problemy: zamiast zmuszać Cię do zrozumienia maszyn wirtualnych lub API równoważenia obciążenia, działa z abstrakcjami wyższego rzędu – procesami i usługami wdrożeniowymi. Zamiast instalować agenty programowe, możesz uruchamiać kontenery, a zamiast pisać własny stos monitorujący, skorzystać z narzędzi już dostępnych na platformie. Tak więc tajemnica OpenShift 4 tak naprawdę nie jest tajemnicą — to tylko kwestia wzięcia zasad SRE i koncepcji bezserwerowych i doprowadzenia ich do logicznych wniosków, aby pomóc programistom i inżynierom operacyjnym:
- Automatyzuj i standaryzuj infrastrukturę, z której korzystają aplikacje
- Połącz procesy wdrażania i programowania, nie ograniczając samych programistów
- Zapewnienie, że uruchomienie, audyt i zabezpieczenie setnej usługi, funkcji, aplikacji lub całego stosu nie będzie trudniejsze niż w przypadku pierwszego.
Czym jednak różni się platforma OpenShift 4 od jej poprzedników i od „standardowego” podejścia do rozwiązywania takich problemów? Co napędza skalę w zespołach wdrożeniowych i operacyjnych? Z uwagi na to, że królem w tej sytuacji jest klaster. Więc,
- Dbamy o to, aby cel klastrów był jasny (Droga chmuro, wybrałem ten klaster, bo mogłem)
- Istnieją maszyny i systemy operacyjne, które służą klastrowi (Wasza Wysokość)
- Zarządzaj stanem hostów z klastra, minimalizuj ich odbudowę (dryft).
- Do każdego ważnego elementu systemu potrzebna jest niania (mechanizm), która będzie monitorować i eliminować problemy
- Awaria *każdego* aspektu lub elementu systemu i powiązanych mechanizmów odzyskiwania są normalną częścią życia
- Całą infrastrukturę należy skonfigurować poprzez API.
- Użyj Kubernetes do uruchomienia Kubernetes. (Tak, tak, to nie jest literówka)
- Instalowanie aktualizacji powinno być łatwe i bezproblemowe. Jeśli instalacja aktualizacji wymaga więcej niż jednego kliknięcia, oznacza to, że oczywiście robimy coś złego.
- Monitorowanie i debugowanie dowolnego komponentu nie powinno stanowić problemu, dlatego śledzenie i raportowanie w całej infrastrukturze również powinno być łatwe i wygodne.
Chcesz zobaczyć możliwości platformy w akcji?
Wersja poglądowa OpenShift 4 została udostępniona programistom. Dzięki łatwemu w użyciu instalatorowi możesz uruchomić klaster na platformie AWS na platformie Red Had CoreOS. Aby skorzystać z podglądu, potrzebujesz jedynie konta AWS w celu udostępnienia infrastruktury oraz zestawu kont, aby uzyskać dostęp do obrazów podglądu.
- Aby rozpocząć, przejdź do i kliknij „Rozpocznij”.
- Zaloguj się na swoje konto Red Hat (lub utwórz nowe) i postępuj zgodnie z instrukcjami, aby skonfigurować swój pierwszy klaster.
Po udanej instalacji zapoznaj się z naszymi tutorialami aby lepiej zrozumieć systemy i koncepcje, dzięki którym platforma OpenShift 4 jest tak łatwym i wygodnym sposobem na uruchamianie Kubernetes.
Wypróbuj nową wersję OpenShift i podziel się swoją opinią. Zależy nam na tym, aby współpraca z Kumbernetes była jak najbardziej dostępna i łatwa w obsłudze — przyszłość NoOps zaczyna się dzisiaj.
Teraz uwaga!
Na konferencji 20 kwietnia jeden z programistów OpenShift, Vadim Rutkovsky, poprowadzi klasę mistrzowską - rozbije dziesięć klastrów i zmusi ich do ich naprawienia. Konferencja jest płatna, ale z kodem promocyjnym #RedHat otrzymasz 37% zniżki
Zajęcia mistrzowskie w godzinach 17:15 - 18:15, a stoisko czynne przez cały dzień. T-shirty, czapki, naklejki - jak zwykle!
Sala nr 2
„Tutaj konieczna jest zmiana całego systemu: uszkodzone klastry K8 naprawiamy wspólnie z certyfikowanymi mechanikami.”
Źródło: www.habr.com