Ten post powstał, ponieważ nasi pracownicy odbyli sporo rozmów z klientami na temat tworzenia aplikacji na Kubernetesie i specyfiki takiego rozwoju na OpenShift.
Zwykle zaczynamy od tezy, że Kubernetes to po prostu Kubernetes, a OpenShift to już platforma Kubernetes, jak Microsoft AKS czy Amazon EKS. Każda z tych platform ma swoje zalety, skierowana do określonej grupy docelowej. A potem rozmowa schodzi na porównywanie mocnych i słabych stron konkretnych platform.
Ogólnie rzecz biorąc, myśleliśmy o napisaniu tego posta z konkluzją w stylu: „Słuchaj, nie ma znaczenia, gdzie uruchomić kod, na OpenShift czy na AKS, na EKS, na jakimś niestandardowym Kubernetesie czy jakimkolwiek Kubernetesie (dla ścisłości nazwijmy to KUK) „To naprawdę proste, zarówno tam, jak i tam”.
Następnie planowaliśmy wziąć najprostsze „Hello World” i na jego przykładzie pokazać, co jest wspólne i jaka jest różnica pomiędzy KUC a platformą kontenerową Red Hat OpenShift (zwaną dalej OCP lub po prostu OpenShift).
Jednak pisząc ten post, zdaliśmy sobie sprawę, że tak długo byliśmy przyzwyczajeni do korzystania z OpenShift, że po prostu nie zdawaliśmy sobie sprawy, jak bardzo się rozwinął i zamienił w niesamowitą platformę, która stała się czymś więcej niż tylko dystrybucją Kubernetesa. Zwykle traktujemy dojrzałość i prostotę OpenShift jako coś oczywistego i tracimy z oczu jego świetność.
W ogóle przyszedł czas na aktywną pokutę, a teraz będziemy krok po kroku porównywać uruchomienie naszego „Hello World” na KUK i na OpenShift i zrobimy to możliwie obiektywnie (no, z wyjątkiem czasami pokazania osobiste podejście do tematu). Jeśli interesują Cię czysto subiektywne zdanie na ten temat, możesz je przeczytać . I w tym poście będziemy trzymać się faktów i tylko faktów.
Klastry
Zatem nasze „Hello World” wymaga klastrów. Od razu powiemy „nie” jakimkolwiek chmurom publicznym, aby nie płacić za serwery, rejestry, sieci, transfer danych itp. W związku z tym wybieramy prosty klaster jednowęzłowy (dla KUK) i (dla klastra OpenShift). Obie te opcje są naprawdę łatwe w instalacji, ale będą wymagały sporo zasobów na twoim laptopie.
Montaż na KUK-e
Więc chodźmy.
Krok 1 – zbudowanie wizerunku naszego kontenera
Zacznijmy od wdrożenia naszego „Hello World” w minikube. Aby to zrobić, będziesz potrzebować:
- 1. Zainstalowano Dockera.
- 2. Zainstalowano Gita.
- 3. Zainstalowano Mavena (właściwie ten projekt używa pliku binarnego mvnw, więc możesz się bez niego obejść).
- 4. Właściwie samo źródło, tj. klon repozytorium
Pierwszym krokiem jest utworzenie projektu Quarkus. Nie przejmuj się, jeśli nigdy nie pracowałeś z Quarkus.io – to proste. Po prostu wybierasz komponenty, których chcesz użyć w projekcie (RestEasy, Hibernate, Amazon SQS, Camel itp.), a następnie sam Quarkus, bez Twojego udziału, konfiguruje archetyp mavena i umieszcza wszystko na githubie. Oznacza to, że dosłownie jedno kliknięcie myszką i gotowe. Dlatego kochamy Quarkus.
Najłatwiejszym sposobem wbudowania naszego „Hello World” w obraz kontenera jest użycie rozszerzeń quarkus-maven dla Dockera, które wykonają całą niezbędną pracę. Wraz z pojawieniem się Quarkus stało się to naprawdę łatwe i proste: dodaj rozszerzenie docker-obraz-kontener i możesz tworzyć obrazy za pomocą poleceń maven.
./mvnw quarkus:add-extension -Dextensions=”container-image-docker”
Na koniec budujemy nasz obraz za pomocą Mavena. W rezultacie nasz kod źródłowy zamienia się w gotowy obraz kontenera, który można już uruchomić w środowisku wykonawczym kontenera.
./mvnw -X clean package -Dquarkus.container-image.build=true
To wszystko, teraz możesz uruchomić kontener za pomocą polecenia docker run, mapując naszą usługę na port 8080, aby był dostępny.
docker run -i — rm -p 8080:8080 gcolman/quarkus-hello-world
Po uruchomieniu instancji kontenera pozostaje jedynie sprawdzić za pomocą polecenia curl, czy nasza usługa jest uruchomiona:
Wszystko więc działa i było naprawdę łatwe i proste.
Krok 2 – wyślij nasz kontener do repozytorium obrazów kontenerów
Na razie utworzony przez nas obraz jest przechowywany lokalnie, w naszym lokalnym magazynie kontenerowym. Jeżeli chcemy wykorzystać ten obraz w naszym środowisku COOK to należy go umieścić w jakimś innym repozytorium. Kubernetes nie ma takich funkcji, dlatego skorzystamy z dockerhuba. Bo po pierwsze jest darmowy, a po drugie (prawie) każdy to robi.
Jest to również bardzo proste, a wszystko, czego potrzebujesz, to konto dockerhub.
Instalujemy więc dockerhub i wysyłamy tam nasz obraz.
Krok 3 – uruchom Kubernetes
Istnieje wiele sposobów na zbudowanie konfiguracji Kubernetes w celu uruchomienia naszego „Hello World”, ale my użyjemy najprostszego z nich, tak właśnie robimy…
Najpierw uruchommy klaster minikube:
minikube start
Krok 4 – wdróż nasz obraz kontenera
Teraz musimy przekonwertować nasz kod i obraz kontenera na konfiguracje kubernetes. Innymi słowy, potrzebujemy poda i definicji wdrożenia wskazującej na nasz obraz kontenera w dockerhubie. Jednym z najprostszych sposobów, aby to zrobić, jest uruchomienie polecenia create Deployment wskazującego na nasz obraz:
kubectl create deployment hello-quarkus — image =gcolman/quarkus-hello-world:1.0.0-SNAPSHOT
Za pomocą tego polecenia powiedzieliśmy naszemu dyrektorowi operacyjnemu, aby utworzył konfigurację wdrożenia, która powinna zawierać specyfikację pod dla naszego obrazu kontenera. To polecenie zastosuje również tę konfigurację do naszego klastra minikube i utworzy wdrożenie, które pobierze nasz obraz kontenera i uruchomi zasobnik w klastrze.
Krok 5 – otwórz dostęp do naszego serwisu
Teraz, gdy mamy już wdrożony obraz kontenera, czas pomyśleć o tym, jak skonfigurować zewnętrzny dostęp do tej usługi Restful, która tak naprawdę jest zaprogramowana w naszym kodzie.
Jest tu wiele sposobów. Na przykład możesz użyć polecenia Expose, aby automatycznie utworzyć odpowiednie komponenty Kubernetes, takie jak usługi i punkty końcowe. Właściwie to właśnie zrobimy, wykonując polecenie odsłonięcia dla naszego obiektu wdrożenia:
kubectl expose deployment hello-quarkus — type=NodePort — port=8080
Poświęćmy chwilę na przyjrzenie się opcji „-type” polecenia Expo.
Kiedy udostępniamy i tworzymy komponenty niezbędne do uruchomienia naszej usługi, musimy między innymi mieć możliwość połączenia się z zewnątrz z usługą hello-quarkus, która znajduje się w naszej sieci zdefiniowanej programowo. I parametr rodzaj pozwala nam tworzyć i łączyć elementy takie jak moduły równoważenia obciążenia w celu kierowania ruchu do tej sieci.
Na przykład pisząc typ=LoadBalancer, automatycznie udostępniamy moduł równoważenia obciążenia w chmurze publicznej, aby połączyć się z naszym klastrem Kubernetes. To oczywiście jest super, jednak trzeba mieć świadomość, że taka konfiguracja będzie ściśle powiązana z konkretną chmurą publiczną i trudniej będzie ją przenieść pomiędzy instancjami Kubernetesa w różnych środowiskach.
W naszym przykładzie typ=Port węzłaoznacza to, że dostęp do naszej usługi odbywa się poprzez adres IP węzła i numer portu. Ta opcja pozwala nie używać żadnych chmur publicznych, ale wymaga szeregu dodatkowych kroków. Po pierwsze potrzebujesz własnego modułu równoważenia obciążenia, dlatego wdrożymy moduł równoważenia obciążenia NGINX w naszym klastrze.
Krok 6 – zainstaluj moduł równoważenia obciążenia
minikube posiada szereg funkcji platformy, które ułatwiają tworzenie komponentów dostępnych z zewnątrz, takich jak kontrolery wejścia. Minikube jest dostarczany w zestawie z kontrolerem wejściowym Nginx i jedyne, co musimy zrobić, to go włączyć i skonfigurować.
minikube addons enable ingress
Teraz utworzymy kontroler wejściowy Nginx za pomocą tylko jednego polecenia, które będzie działać w naszym klastrze minikube:
ingress-nginx-controller-69ccf5d9d8-j5gs9 1/1 Running 1 33m
Krok 7 – Konfiguracja ingresu
Teraz musimy skonfigurować kontroler wejściowy Nginx tak, aby akceptował żądania hello-quarkus.
I na koniec musimy zastosować tę konfigurację.
kubectl apply -f ingress.yml
Ponieważ robimy to wszystko na własnym komputerze, po prostu dodajemy adres IP naszego węzła do pliku /etc/hosts, aby kierować żądania HTTP do naszego minikube do modułu równoważenia obciążenia NGINX.
192.168.99.100 hello-quarkus.info
To wszystko, teraz nasza usługa minikube jest dostępna zewnętrznie poprzez kontroler wejściowy Nginx.
Cóż, to było łatwe, prawda? Albo nie tak bardzo?
Działa na OpenShift (kontenery gotowe do kodu)
Zobaczmy teraz, jak to wszystko odbywa się na platformie kontenerowej Red Hat OpenShift (OCP).
Podobnie jak w przypadku minikube, wybieramy jednowęzłowy projekt klastra OpenShift w postaci kontenerów Code Ready (CRC). Wcześniej nazywał się minishift i był oparty na projekcie OpenShift Origin, ale teraz jest to CRC i jest zbudowany na platformie OpenShift Container Platform firmy Red Hat.
W tym miejscu, niestety, nie możemy powstrzymać się od powiedzenia: „OpenShift jest cudowny!”
Początkowo pomyśleliśmy, żeby napisać, że rozwój na OpenShift nie różni się od rozwoju na Kubernetesie. I w zasadzie tak właśnie jest. Ale w trakcie pisania tego posta przypomnieliśmy sobie, ile dodatkowych ruchów musisz wykonać, gdy nie masz OpenShift, i dlatego znowu jest to cudowne. Uwielbiamy, gdy wszystko można łatwo zrobić, a to, jak łatwo jest wdrożyć i uruchomić nasz przykład na OpenShift w porównaniu z minikube, skłoniło nas do napisania tego posta.
Przejdźmy przez proces i zobaczmy, co musimy zrobić.
Tak więc w przykładzie minikube zaczęliśmy od Dockera... Czekaj, nie potrzebujemy już instalować Dockera na komputerze.
I nie potrzebujemy lokalnego gita.
A Maven nie jest potrzebny.
I nie musisz tworzyć obrazu kontenera własnymi rękami.
I nie musisz szukać żadnego repozytorium obrazów kontenerów.
Nie ma też potrzeby instalowania kontrolera wejścia.
Nie musisz też konfigurować wejścia.
Rozumiesz, prawda? Aby wdrożyć i uruchomić naszą aplikację na OpenShift, nie potrzebujesz żadnego z powyższych. A sam proces wygląda tak.
Krok 1 – Uruchom klaster OpenShift
Korzystamy z kontenerów Code Ready firmy Red Hat, które w zasadzie są tym samym Minikube, ale tylko z pełnoprawnym jednowęzłowym klastrem Openshift.
crc start
Krok 2 – Zbuduj i wdróż aplikację w klastrze OpenShift
Na tym etapie prostota i wygoda OpenShift ujawniają się w całej okazałości. Podobnie jak w przypadku wszystkich dystrybucji Kubernetes, mamy wiele sposobów na uruchomienie aplikacji w klastrze. I podobnie jak w przypadku KUK-a, specjalnie wybieramy ten najprostszy.
OpenShift zawsze był budowany jako platforma do tworzenia i uruchamiania aplikacji kontenerowych. Tworzenie kontenerów zawsze było integralną częścią tej platformy, dlatego dostępnych jest mnóstwo dodatkowych zasobów Kubernetes do wykonywania powiązanych zadań.
Będziemy używać procesu Source 2 Image (S2I) OpenShift, który ma kilka różnych sposobów na pobranie naszego źródła (kodu lub plików binarnych) i przekształcenie go w konteneryzowany obraz działający w klastrze OpenShift.
Aby to zrobić, potrzebujemy dwóch rzeczy:
- Nasz kod źródłowy znajduje się w repozytorium git
- Obraz konstruktora, na podstawie którego zostanie wykonana kompilacja.
Istnieje wiele takich obrazów utrzymywanych zarówno przez firmę Red Hat, jak i na poziomie społeczności, a my użyjemy obrazu OpenJDK, cóż, ponieważ buduję aplikację w Javie.
Kompilację S2I można uruchomić zarówno z konsoli graficznej OpenShift Developer, jak i z wiersza poleceń. Użyjemy polecenia new-app, informując, skąd pobrać obraz kreatora i nasz kod źródłowy.
oc new-app registry.access.redhat.com/ubi8/openjdk-11:latest~https://github.com/gcolman/quarkus-hello-world.git
To wszystko, nasza aplikacja została utworzona. W ten sposób proces S2I wykonał następujące czynności:
- Utworzono moduł kompilacji usługi do wszelkiego rodzaju rzeczy związanych z budowaniem aplikacji.
- Utworzono konfigurację OpenShift Build.
- Pobrałem obraz kreatora do wewnętrznego rejestru doków OpenShift.
- Sklonowano „Hello World” do lokalnego repozytorium.
- Widziałem, że był tam pom maven, więc skompilowałem aplikację za pomocą mavena.
- Utworzono nowy obraz kontenera zawierający skompilowaną aplikację Java i umieścił ten obraz w wewnętrznym rejestrze kontenerów.
- Utworzono wdrożenie Kubernetes ze specyfikacjami dotyczącymi podów, usług itp.
- Zacząłem wdrażać obraz kontenera.
- Usunięto moduł kompilacji usługi.
Na tej liście jest wiele, ale najważniejsze jest to, że cała kompilacja odbywa się wyłącznie w OpenShift, wewnętrzny rejestr Dockera znajduje się w OpenShift, a proces kompilacji tworzy wszystkie komponenty Kubernetes i uruchamia je w klastrze.
Jeśli wizualnie monitorujesz uruchomienie S2I w konsoli, możesz zobaczyć, jak uruchamiany jest moduł kompilacji po zakończeniu kompilacji.
Przyjrzyjmy się teraz dziennikom modułu budującego: po pierwsze pokazuje, jak maven wykonuje swoją pracę i pobiera zależności w celu zbudowania naszej aplikacji Java.
Po zakończeniu kompilacji maven rozpoczyna się kompilacja obrazu kontenera, a następnie ten zbudowany obraz jest wysyłany do wewnętrznego repozytorium.
To wszystko, proces kompilacji został zakończony. Teraz upewnijmy się, że w klastrze działają pody i usługi naszej aplikacji.
oc get service
To wszystko. I tylko jeden zespół. Wszystko, co musimy zrobić, to udostępnić tę usługę dostępowi z zewnątrz.
Krok 3 – udostępnij usługę na dostęp z zewnątrz
Podobnie jak w przypadku KUC, tak i na platformie OpenShift nasz „Hello World” również potrzebuje routera, który będzie kierował ruch zewnętrzny do usługi w ramach klastra. Dzięki OpenShift jest to bardzo łatwe. Po pierwsze, w klastrze domyślnie instalowany jest komponent routingu HAProxy (można go zmienić na ten sam NGINX). Po drugie, istnieją specjalne i wysoce konfigurowalne zasoby zwane Routes i przypominające obiekty Ingress w starym, dobrym Kubernetesie (w rzeczywistości trasy OpenShift miały ogromny wpływ na projektowanie obiektów Ingress, których można teraz używać w OpenShift), ale dla naszego „Hello World” , a w prawie wszystkich pozostałych przypadkach wystarczy nam standardowa trasa bez dodatkowej konfiguracji.
Aby utworzyć routowalną nazwę FQDN dla „Hello World” (tak, OpenShiift ma własny DNS do routingu według nazw usług), po prostu ujawnimy naszą usługę:
oc expose service quarkus-hello-world
Jeśli spojrzysz na nowo utworzoną trasę, znajdziesz tam nazwę FQDN i inne informacje o trasie:
oc get route
I wreszcie uzyskujemy dostęp do naszej usługi z przeglądarki:
Ale teraz było to naprawdę łatwe!
Kochamy Kubernetes i wszystko, na co pozwala nam ta technologia, uwielbiamy też prostotę i łatwość. Kubernetes został stworzony, aby niesamowicie uprościć obsługę rozproszonych, skalowalnych kontenerów, jednak jego prostota nie jest już wystarczająca, aby dziś wprowadzać aplikacje do produkcji. I tu z pomocą przychodzi OpenShift, który idzie z duchem czasu i oferuje Kubernetes, skierowany przede wszystkim do programisty. Włożono wiele wysiłku w dostosowanie platformy OpenShift specjalnie dla programisty, w tym w stworzenie narzędzi takich jak S2I, ODI, Portal dla programistów, OpenShift Operator Framework, integracja IDE, Katalogi programistów, integracja Helm, monitorowanie i wiele innych.
Mamy nadzieję, że ten artykuł był dla Ciebie interesujący i przydatny. Dodatkowe zasoby, materiały i inne rzeczy przydatne do rozwoju platformy OpenShift znajdziesz na portalu .
Źródło: www.habr.com