Ten post został napisany, ponieważ nasi pracownicy mieli wiele rozmów z klientami na temat tworzenia aplikacji w Kubernetes oraz 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, ukierunkowane na różne grupy docelowe. A później rozmowa płynnie przechodzi w porównanie mocnych i słabych stron konkretnych platform.
Ogólnie rzecz biorąc, myśleliśmy o napisaniu tego posta z wnioskiem w stylu: „Słuchajcie, gdzie uruchamiać kod, na OpenShift czy na AKS, EKS, jakimś dostosowanym Kubernetes, czy na jakimkolwiek Kubernetes, to naprawdę nie ma znaczenia”. (dla skrótu nazwijmy to KUK) – to naprawdę proste zarówno tam, jak i tam.
Następnie planowaliśmy wziąć najprostszą aplikację „Hello World” i na jej przykładzie pokazać, co jest wspólnego i jakie są różnice między KUK a Red Hat OpenShift Container Platform (dalej, OCP lub po prostu OpenShift).
Jednak w trakcie pisania tego posta zrozumieliśmy, że tak bardzo przywykliśmy do korzystania z OpenShift, że po prostu nie dostrzegamy, jak bardzo się rozwinął i stał niesamowitą platformą, która stała się czymś więcej niż tylko dystrybucją Kubernetes. Przyzwyczailiśmy się traktować dojrzałość i prostotę OpenShift jako coś naturalnego, pomijając jego wspaniałość.
Czas na aktywne zadośćuczynienie, a teraz krok po kroku porównamy wprowadzenie do działania naszego „Hello World” na KUK i na OpenShift, i zrobimy to jak najbardziej obiektywnie (choć czasami wyrażając osobiste zainteresowanie tematem). Jeśli interesuje Cię wyłącznie subiektywna opinia na ten temat, to można ją przeczytać. . A w tym poście będziemy trzymać się faktów i tylko faktów.
Klastery
Więc do naszego „Hello World” potrzebne są klastry. Od razu mówimy „nie” wszelkim publicznym chmurom, aby nie płacić za serwery, rejestry, sieci, transfer danych itp. W związku z tym wybieramy proste, jednouwzględnione klastry na (dla KUK) oraz (dla klastra OpenShift). Oba te warianty są naprawdę proste w instalacji, ale wymagają sporo zasobów na Twoim laptopie.
Budowanie na KUK
No to zaczynajmy.
Krok 1 – budujemy nasz obraz kontenera
Zacznijmy od tego, że uruchomimy nasze „Hello World” na minikube. W tym celu potrzebne będą:
- 1. Zainstalowany Docker.
- 2. Zainstalowany Git.
- 3. Zainstalowany Maven (tak naprawdę w tym projekcie używany jest binarka mvnw, więc można to pominąć).
- 4. Sam kod źródłowy, czyli klon repozytorium
Na początku musimy stworzyć projekt Quarkus. Nie martwcie się, jeśli nigdy nie pracowaliście z stroną Quarkus.io – to jest proste. Wystarczy wybrać komponenty, które chcecie użyć w projekcie (RestEasy, Hibernate, Amazon SQS, Camel itp.), a następnie Quarkus samodzielnie, bez waszego udziału, skonfiguruje archetyp maven i umieści wszystko na githubie. To znaczy, dosłownie jeden klik myszką – i gotowe. Za to właśnie kochamy Quarkus.
Najprostszym sposobem na zbudowanie naszego "Hello World" w obrazie kontenera – jest użycie rozszerzeń quarkus-maven dla Dockera, które wykonają całą niezbędną pracę. Z pojawieniem się Quarkus to naprawdę stało się łatwe i proste: dodajecie rozszerzenie container-image-docker i możecie tworzyć obrazy za pomocą poleceń maven.
./mvnw quarkus:add-extension -Dextensions="container-image-docker"
A teraz przeprowadzamy budowę naszego obrazu, używając Maven. W wyniku nasz kod źródłowy zostaje przekształcony w gotowy obraz kontenera, który można już uruchomić w środowisku wykonywania kontenerów.
./mvnw -X clean package -Dquarkus.container-image.build=true
Oto, i wszystko, teraz można uruchomić kontener poleceniem docker run, mapując naszą usługę na port 8080, aby można było się do niej odwołać.
docker run -i --rm -p 8080:8080 gcolman/quarkus-hello-world
Po uruchomieniu instancji kontenera wystarczy tylko sprawdzić poleceniem curl, czy nasza usługa działa:
Tak więc, wszystko działa i naprawdę było to łatwe i proste.
Krok 2 – wysyłamy nasz kontener do repozytorium obrazów kontenerów
Jak dotąd nasz stworzony obraz jest przechowywany lokalnie, w naszym lokalnym repozytorium kontenerów. Jeśli chcemy używać tego obrazu w naszym środowisku K8S, musimy go umieścić w jakimś innym repozytorium. W Kubernetes nie ma takich funkcji, więc będziemy używać dockerhub. Po pierwsze, jest darmowy, a po drugie, (prawie) wszyscy tak robią.
To również jest bardzo proste i potrzebne jest tutaj tylko konto na dockerhubie.
A więc logujemy się do dockerhub i wysyłamy tam nasz obraz.
Krok 3 – uruchamiamy Kubernetes
Istnieje wiele sposobów na złożenie konfiguracji kubernetes do uruchomienia naszego "Hello World", ale skorzystamy z najprostszej z nich, tacy już jesteśmy...
Na początek uruchamiamy klaster minikube:
minikube start
Krok 4 - wdrażamy nasz obraz kontenera
Teraz musimy przekształcić nasz kod i obraz kontenera na konfiguracje kubernetes. Innymi słowy, potrzebujemy definicji pod i deploymentu wskazującej na nasz obraz na dockerhub. Jednym z najprostszych sposobów, aby to zrobić, jest uruchomienie polecenia create deployment, wskazując na nasz obraz:
kubectl create deployment hello-quarkus --image=gcolman/quarkus-hello-world:1.0.0-SNAPSHOT
Tym poleceniem powiedzieliśmy naszemu KUBECIE stworzyć konfigurację deploymentu, która powinna zawierać specyfikację pod'a dla naszego obrazu kontenera. To polecenie również zastosuje tę konfigurację do naszego klastra minikube i stworzy deployment, który pobierze nasz obraz kontenera i uruchomi pod w klastrze.
Krok 5 - otwieramy dostęp do naszego serwisu
Teraz, gdy mamy wdrożony obraz kontenera, czas pomyśleć, jak skonfigurować zewnętrzny dostęp do tego serwisu Restful, który rzeczywiście jest zaprogramowany w naszym kodzie.
Jest wiele sposobów na to. Na przykład, można użyć polecenia expose, aby automatycznie stworzyć odpowiednie komponenty Kubernetes, takie jak usługi i punkty końcowe. Właśnie tak zamierzamy zrobić, wykonując polecenie expose dla naszego obiektu deployment:
kubectl expose deployment hello-quarkus --type=NodePort --port=8080
Zatrzymajmy się na chwilę przy opcji "--type" polecenia expose.
Kiedy wykonujemy expose i tworzymy komponenty niezbędne do uruchomienia naszego serwisu, musimy, między innymi, zapewnić, że na zewnątrz możliwe będzie połączenie z usługą hello-quarkus, która znajduje się w naszej definiowanej programowo sieci. I parametr type pozwala nam stworzyć i połączyć takie rzeczy, jak load balancery, aby kierować ruch do tej sieci.
Na przykład, wpisując type=LoadBalancer, automatycznie inicjujemy load balancer w publicznej chmurze, aby połączyć się z naszym klastrem Kubernetes. To, oczywiście, wspaniale, ale trzeba rozumieć, że taka konfiguracja będzie ściśle związana z konkretną publiczną chmurą i będzie trudniejsza do przenoszenia między instancjami Kubernetes w różnych środowiskach.
W naszym przykładzie type=NodePort, czyli dostęp do naszej usługi odbywa się za pośrednictwem adresu IP i numeru portu węzła. Ta opcja pozwala na niekorzystanie z żadnych publicznych chmur, ale wymaga kilku dodatkowych kroków. Po pierwsze, potrzebny jest własny load balancer, dlatego wdrożymy w naszym klastrze load balancer NGINX.
Krok 6 – instalacja load balancera
Minikube ma szereg funkcji platformowych, ułatwiających tworzenie wymaganych komponentów do zewnętrznego dostępu, takich jak kontrolery ingress. Minikube dostarczany jest z kontrolerem ingress Nginx, więc wystarczy go tylko włączyć i skonfigurować.
minikube addons enable ingress
Teraz za pomocą jednego polecenia utworzymy kontroler ingress Nginx, który będzie działał wewnątrz naszego klastra minikube:
ingress-nginx-controller-69ccf5d9d8-j5gs9 1/1 Running 1 33m
Krok 7 – konfiguracja ingress
Teraz musimy skonfigurować kontroler ingress Nginx, aby obsługiwał żądania hello-quarkus.
I w końcu musimy zastosować tę konfigurację.
kubectl apply -f ingress.yml
Ponieważ robimy to wszystko na swoim komputerze, po prostu dodajemy adres IP swojego węzła do pliku /etc/hosts, aby kierować żądania http do naszego minikube na load balancer NGINX.
192.168.99.100 hello-quarkus.info
Gotowe, teraz nasza usługa minikube jest dostępna z zewnątrz przez kontroler ingress Nginx.
No cóż, to było łatwe, prawda? A może nie za bardzo?
Uruchomienie na OpenShift (Code Ready Containers)
A teraz zobaczmy, jak to wszystko działa na platformie Red Hat OpenShift Container Platform (OCP).
Podobnie jak w przypadku minikube, wybieramy schemat z jedno węzłowym klastrem OpenShift w formie Code Ready Containers (CRC). Wcześniej nazywało się to minishift i było oparte na projekcie OpenShift Origin, teraz to CRC i jest zbudowane na platformie Red Hat OpenShift Container.
Tutaj, przepraszamy, nie możemy powstrzymać się od powiedzenia: „OpenShift jest wspaniały!”
Początkowo myśleliśmy, że napisanie, iż rozwój na OpenShift niczym się nie różni od rozwoju na Kubernetes, będzie zasadne. I w zasadzie tak jest. Jednak podczas pisania tego posta przypomnieliśmy sobie, ile zbędnych ruchów trzeba wykonać, gdy nie masz OpenShift, dlatego powtarzamy: jest wspaniały. Lubimy, gdy wszystko dzieje się łatwo, a to, jak prosto w porównaniu do minikube wdraża się i uruchamia nasz przykład na OpenShift, skłoniło nas do napisania tego posta.
Przejdźmy do procesu i sprawdźmy, co będziemy musieli zrobić.
Zatem w przykładzie z minikube zaczynaliśmy od Dockera… Chwileczkę, nie potrzebujemy już, aby Docker był zainstalowany na maszynie.
I lokalny git nie jest nam potrzebny.
I Maven nie jest potrzebny.
Nie musimy też ręcznie tworzyć obrazu kontenera.
Nie musimy szukać jakiegoś repozytorium obrazów kontenerowych.
Nie musimy też instalować kontrolera ingress.
Konfiguracja ingress również nie jest konieczna.
Rozumiesz, tak? Aby wdrożyć i uruchomić naszą aplikację na OpenShift, nie potrzebujemy nic z wymienionych wcześniej rzeczy. A sam proces wygląda następująco.
Krok 1 – Uruchamiamy swój klaster OpenShift
Używamy Code Ready Containers od Red Hat, który w zasadzie jest tym samym co Minikube, ale oferuje pełnoprawny jednolity klaster Openshift.
crc start
Krok 2 – Wykonujemy budowę i wdrożenie aplikacji w klastrze OpenShift
To właśnie na tym etapie prostota i wygoda OpenShift ukazują się w całej okazałości. Jak w każdym dystrybucji Kubernetes, mamy wiele sposobów uruchomienia aplikacji w klastrze. I, jak w przypadku K8s, celowo wybieramy najprostsze rozwiązanie.
OpenShift zawsze był budowany jako platforma do tworzenia i uruchamiania aplikacji kontenerowych. Budowanie kontenerów od początku było nieodłączną częścią tej platformy, dlatego istnieje tutaj mnóstwo dodatkowych zasobów Kubernetes do odpowiednich zadań.
Będziemy korzystać z procesów OpenShift Source 2 Image (S2I), które mają kilka różnych sposobów na przekształcenie naszego kodu źródłowego (kod lub pliki binarne) w obraz kontenera uruchamiany w klastrze OpenShift.
Do tego będą nam potrzebne dwie rzeczy:
- Nasz kod źródłowy w repozytorium git
- Obraz Builder, na podstawie którego będzie wykonywane budowanie.
Istnieje wiele takich obrazów, wspieranych zarówno przez Red Hat, jak i na poziomie społeczności, a my skorzystamy z obrazu OpenJDK, ponieważ buduję aplikację w Javie.
Uruchomienie budowy S2I można przeprowadzić zarówno z graficznego interfejsu konsoli OpenShift Developer, jak i z linii poleceń. Skorzystamy z polecenia new-app, wskazując, skąd brać obraz builder 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
Gotowe, nasza aplikacja została stworzona. Proces S2I wykonał następujące czynności:
- Utworzono specjalny build-pod do różnych zadań związanych z budowaniem aplikacji.
- Utworzono konfigurację OpenShift Build.
- Pobrano obraz buildera do wewnętrznego rejestru docker OpenShift.
- Skopiowano 'Hello World' do lokalnego repozytorium.
- Zauważyłem, że jest tam plik maven pom, więc skompilowałem aplikację za pomocą maven.
- Utworzyłem nowy obraz kontenery, zawierający skompilowaną aplikację Java, i umieściłem ten obraz w wewnętrznym rejestrze kontenerów.
- Utworzyłem Kubernetes Deployment z specyfikacjami pod’a, usługi itp.
- Uruchomiłem wdrożenie obrazu kontenera.
- Usunąłem służbowy build-pod.
W tej liście jest wiele rzeczy, ale najważniejsze jest to, że cały proces budowy odbywa się wyłącznie wewnątrz OpenShift, wewnętrzny rejestr Docker znajduje się w OpenShift, a proces budowy tworzy wszystkie komponenty Kubernetes i uruchamia je w klastrze.
Jeśli wizualnie śledzić uruchomienie S2I w konsoli, można zobaczyć, jak podczas budowy uruchamia się build pod.
A teraz przyjrzyjmy się logom builder pod’a: po pierwsze, widać, jak maven wykonuje swoją pracę i pobiera zależności do budowy naszej aplikacji java.
Po zakończeniu budowy maven uruchamiana jest budowa obrazu kontenera, a następnie ten zbudowany obraz jest wysyłany do wewnętrznego repozytorium.
Wszystko, proces budowy zakończony. Teraz upewnijmy się, że w klastrze uruchomiły się pod’y i usługi naszej aplikacji.
oc get service
To wszystko. I tylko jedna komenda. Musimy teraz tylko expose tej usługi, aby uzyskać dostęp z zewnątrz.
Krok 3 – expose usługi dla dostępu z zewnątrz
Tak jak w przypadku CUK, na platformie OpenShift nasz «Hello World» również potrzebuje routera, aby kierować ruch zewnętrzny do usługi wewnątrz klastra. W OpenShift jest to bardzo proste. Po pierwsze, w klastrze domyślnie zainstalowany jest komponent routingu HAProxy (można go zmienić na NGINX). Po drugie, istnieją specjalne i elastyczne zasoby, które nazywają się Routes i przypominają obiekty Ingress w starym dobrym Kubernetes (w rzeczywistości Routes w OpenShift znacząco wpłynęły na projekt obiektów Ingress, które można teraz również używać w OpenShift), ale dla naszego «Hello World» oraz niemal we wszystkich innych przypadkach wystarczy standardowy Route bez dodatkowego konfigurowania.
Aby stworzyć routowalny FQDN dla «Hello World» (tak, w OpenShift istnieje swój DNS do kierowania na podstawie nazw usług), po prostu wykonamy expose dla naszej usługi:
oc expose service quarkus-hello-world
Jeśli przyjrzymy się właśnie utworzonemu Route, to można znaleźć FQDN i inne informacje dotyczące routingu:
oc get route
I na końcu, zwracamy się do naszej usługi z przeglądarki:
A teraz to było naprawdę łatwe!
Kochamy Kubernetes i wszystko, co ta technologia umożliwia, ale również uwielbiamy prostotę i łatwość. Kubernetes został stworzony, aby niesamowicie uprościć eksploatację rozproszonych, skalowalnych kontenerów, jednak do uruchamiania aplikacji ta prostota nie wystarcza już dzisiaj. I tutaj wkracza OpenShift, który podąża za czasami i oferuje Kubernetes, przede wszystkim skupiony na deweloperze. Włożono mnóstwo pracy, aby dostosować platformę OpenShift specjalnie dla dewelopera, w tym stworzenie takich narzędzi jak S2I, ODI, Developer Portal, OpenShift Operator Framework, integracja z IDE, Katalogi Deweloperów, integracja z Helm, monitorowanie i wiele innych.
Mamy nadzieję, że ten artykuł był dla Ciebie interesujący i przydatny. Dodatkowe zasoby, materiały oraz inne przydatne elementy do rozwoju na platformie OpenShift można znaleźć na portalu .
Źródło: habr.com
