Dieser Beitrag wurde geschrieben, weil unsere Mitarbeiter viele Gespräche mit Kunden über die Anwendungsentwicklung auf Kubernetes und die Besonderheiten einer solchen Entwicklung auf OpenShift geführt haben.
Wir beginnen normalerweise mit der These, dass Kubernetes einfach Kubernetes ist und OpenShift bereits eine Kubernetes-Plattform ist, wie Microsoft AKS oder Amazon EKS. Jede dieser Plattformen hat ihre eigenen Vorteile und richtet sich an eine bestimmte Zielgruppe. Anschließend geht es um den Vergleich der Stärken und Schwächen bestimmter Plattformen.
Im Allgemeinen dachten wir daran, diesen Beitrag mit einer Schlussfolgerung zu schreiben wie „Hören Sie, es spielt keine Rolle, wo der Code ausgeführt wird, auf OpenShift oder auf AKS, auf EKS, auf einigen benutzerdefinierten Kubernetes oder auf irgendeinem anderen Kubernetes.“ (der Kürze halber nennen wir es KUK) „Es ist wirklich einfach, sowohl dort als auch dort.“
Dann wollten wir das einfachste „Hello World“ nehmen und anhand seines Beispiels zeigen, was zwischen dem KUC und der Red Hat OpenShift Container Platform (im Folgenden OCP oder einfach OpenShift) gemeinsam ist und was der Unterschied ist.
Als wir diesen Beitrag schrieben, wurde uns jedoch klar, dass wir schon so lange an die Verwendung von OpenShift gewöhnt waren, dass wir einfach nicht realisierten, wie es sich zu einer erstaunlichen Plattform entwickelt hatte, die viel mehr als nur eine Kubernetes-Distribution war. Wir neigen dazu, die Reife und Einfachheit von OpenShift als selbstverständlich zu betrachten und seine Brillanz aus den Augen zu verlieren.
Im Allgemeinen ist die Zeit für aktive Reue gekommen, und jetzt werden wir Schritt für Schritt die Inbetriebnahme unserer „Hello World“ auf KUK und auf OpenShift vergleichen und dies so objektiv wie möglich tun (naja, außer manchmal, indem wir a zeigen). persönliche Einstellung zum Thema). Wenn Sie an einer rein subjektiven Meinung zu diesem Thema interessiert sind, können Sie diese lesen . Und in diesem Beitrag bleiben wir bei den Fakten und nur bei den Fakten.
Cluster
Unsere „Hallo Welt“ erfordert also Cluster. Wir sagen sofort „Nein“ zu öffentlichen Clouds, um nicht für Server, Registrys, Netzwerke, Datenübertragung usw. zu bezahlen. Dementsprechend wählen wir einen einfachen Single-Node-Cluster aus (für KUK) und (für OpenShift-Cluster). Beide Optionen sind wirklich einfach zu installieren, erfordern jedoch eine Menge Ressourcen auf Ihrem Laptop.
Versammlung auf KUK-e
Also lass uns gehen
Schritt 1 – Erstellen unseres Container-Images
Beginnen wir mit der Bereitstellung unserer „Hello World“ auf Minikube. Dazu benötigen Sie:
- 1. Docker installiert.
- 2. Git installiert.
- 3. Maven installiert (eigentlich verwendet dieses Projekt die mvnw-Binärdatei, Sie können also darauf verzichten).
- 4. Eigentlich ist die Quelle selbst, d.h. Repository-Klon
Der erste Schritt besteht darin, ein Quarkus-Projekt zu erstellen. Seien Sie nicht beunruhigt, wenn Sie noch nie mit Quarkus.io gearbeitet haben – es ist ganz einfach. Sie wählen einfach die Komponenten aus, die Sie im Projekt verwenden möchten (RestEasy, Hibernate, Amazon SQS, Camel usw.), und dann konfiguriert Quarkus selbst, ohne Ihr Zutun, den Maven-Archetyp und stellt alles auf Github. Das heißt, buchstäblich ein Mausklick und Sie sind fertig. Deshalb lieben wir Quarkus.
Der einfachste Weg, unsere „Hello World“ in ein Container-Image zu integrieren, ist die Verwendung der Quarkus-Maven-Erweiterungen für Docker, die alle notwendigen Arbeiten erledigen. Mit der Einführung von Quarkus ist dies wirklich einfach und unkompliziert geworden: Fügen Sie die Erweiterung „container-image-docker“ hinzu und Sie können Bilder mit Maven-Befehlen erstellen.
./mvnw quarkus:add-extension -Dextensions=”container-image-docker”
Schließlich erstellen wir unser Image mit Maven. Dadurch wird aus unserem Quellcode ein fertiges Container-Image, das bereits in der Container-Laufzeitumgebung ausgeführt werden kann.
./mvnw -X clean package -Dquarkus.container-image.build=true
Das ist alles, jetzt können Sie den Container mit dem Docker-Run-Befehl starten und unseren Dienst dem Port 8080 zuordnen, damit darauf zugegriffen werden kann.
docker run -i — rm -p 8080:8080 gcolman/quarkus-hello-world
Nachdem die Container-Instanz gestartet ist, müssen wir nur noch mit dem Curl-Befehl prüfen, ob unser Dienst ausgeführt wird:
Es funktioniert also alles und es war wirklich einfach und unkompliziert.
Schritt 2 – Senden Sie unseren Container an das Container-Image-Repository
Das von uns erstellte Image wird vorerst lokal in unserem lokalen Containerspeicher gespeichert. Wenn wir dieses Bild in unserer COOK-Umgebung verwenden möchten, muss es in einem anderen Repository abgelegt werden. Kubernetes verfügt nicht über solche Funktionen, daher verwenden wir Dockerhub. Denn erstens ist es kostenlos und zweitens macht es (fast) jeder.
Auch dies ist sehr einfach und Sie benötigen lediglich ein Dockerhub-Konto.
Also installieren wir Dockerhub und senden unser Image dorthin.
Schritt 3 – Kubernetes starten
Es gibt viele Möglichkeiten, die Kubernetes-Konfiguration zusammenzustellen, um unser „Hello World“ auszuführen, aber wir werden die einfachste davon verwenden, das ist unsere Art ...
Starten wir zunächst den Minikube-Cluster:
minikube start
Schritt 4 – Stellen Sie unser Container-Image bereit
Jetzt müssen wir unseren Code und unser Container-Image in Kubernetes-Konfigurationen konvertieren. Mit anderen Worten: Wir benötigen eine Pod- und Bereitstellungsdefinition, die auf unser Container-Image auf Dockerhub verweist. Eine der einfachsten Möglichkeiten, dies zu tun, besteht darin, den Befehl zum Erstellen der Bereitstellung auszuführen, der auf unser Image verweist:
kubectl create deployment hello-quarkus — image =gcolman/quarkus-hello-world:1.0.0-SNAPSHOT
Mit diesem Befehl haben wir unseren COO angewiesen, eine Bereitstellungskonfiguration zu erstellen, die die Pod-Spezifikation für unser Container-Image enthalten sollte. Dieser Befehl wendet diese Konfiguration auch auf unseren Minikube-Cluster an und erstellt eine Bereitstellung, die unser Container-Image herunterlädt und den Pod im Cluster startet.
Schritt 5 – Freier Zugang zu unserem Service
Nachdem wir nun ein bereitgestelltes Container-Image haben, ist es an der Zeit, darüber nachzudenken, wie wir den externen Zugriff auf diesen Restful-Dienst konfigurieren, der tatsächlich in unserem Code programmiert ist.
Hier gibt es viele Möglichkeiten. Sie können beispielsweise den Befehl „exposure“ verwenden, um automatisch die entsprechenden Kubernetes-Komponenten wie Dienste und Endpunkte zu erstellen. Genau das tun wir, indem wir den Expose-Befehl für unser Bereitstellungsobjekt ausführen:
kubectl expose deployment hello-quarkus — type=NodePort — port=8080
Nehmen wir uns einen Moment Zeit, um einen Blick auf die Option „-type“ des Befehls „expose“ zu werfen.
Wenn wir die für den Betrieb unseres Dienstes erforderlichen Komponenten bereitstellen und erstellen, müssen wir unter anderem in der Lage sein, von außen eine Verbindung zum Hello-Quarkus-Dienst herzustellen, der sich in unserem softwaredefinierten Netzwerk befindet. Und Parameter tippe ermöglicht es uns, Dinge wie Load Balancer zu erstellen und zu verbinden, um den Datenverkehr an dieses Netzwerk weiterzuleiten.
Zum Beispiel durch Schreiben type=LoadBalancerstellen wir automatisch einen Load Balancer in der öffentlichen Cloud bereit, um eine Verbindung zu unserem Kubernetes-Cluster herzustellen. Das ist natürlich großartig, aber Sie müssen verstehen, dass eine solche Konfiguration strikt an eine bestimmte öffentliche Cloud gebunden ist und schwieriger zwischen Kubernetes-Instanzen in verschiedenen Umgebungen zu übertragen ist.
In unserem Beispiel type=NodePortDas heißt, auf unseren Dienst wird über die IP-Adresse und Portnummer des Knotens zugegriffen. Diese Option ermöglicht es Ihnen, keine öffentlichen Clouds zu verwenden, erfordert jedoch eine Reihe zusätzlicher Schritte. Erstens benötigen Sie Ihren eigenen Load Balancer, daher werden wir den NGINX Load Balancer in unserem Cluster bereitstellen.
Schritt 6 – Installieren Sie einen Load Balancer
minikube verfügt über eine Reihe von Plattformfunktionen, die die Erstellung von extern zugänglichen Komponenten, wie z. B. Ingress-Controllern, erleichtern. Minikube wird mit dem Nginx-Ingress-Controller geliefert und wir müssen ihn nur noch aktivieren und konfigurieren.
minikube addons enable ingress
Jetzt erstellen wir mit nur einem Befehl einen Nginx-Ingress-Controller, der in unserem Minikube-Cluster funktioniert:
ingress-nginx-controller-69ccf5d9d8-j5gs9 1/1 Running 1 33m
Schritt 7 – Einrichten des Eingangs
Jetzt müssen wir den Nginx-Ingress-Controller so konfigurieren, dass er Hello-Quarkus-Anfragen akzeptiert.
Und schließlich müssen wir diese Konfiguration anwenden.
kubectl apply -f ingress.yml
Da wir dies alles auf unserem eigenen Computer tun, fügen wir einfach die IP-Adresse unseres Knotens zur Datei /etc/hosts hinzu, um HTTP-Anfragen an unseren Minikube an den NGINX-Load-Balancer weiterzuleiten.
192.168.99.100 hello-quarkus.info
Jetzt ist unser Minikube-Dienst von außen über den Nginx-Ingress-Controller zugänglich.
Nun ja, das war einfach, oder? Oder nicht so sehr?
Ausführung unter OpenShift (Code Ready Containers)
Sehen wir uns nun an, wie das alles auf der Red Hat OpenShift Container Platform (OCP) funktioniert.
Wie bei Minikube wählen wir ein Single-Node-OpenShift-Cluster-Design in Form von Code Ready Containers (CRC). Früher hieß es Minishift und basierte auf dem OpenShift Origin-Projekt, jetzt heißt es CRC und basiert auf der OpenShift Container Platform von Red Hat.
Hier können wir leider nicht umhin zu sagen: „OpenShift ist wunderbar!“
Ursprünglich dachten wir beim Schreiben, dass sich die Entwicklung auf OpenShift nicht von der Entwicklung auf Kubernetes unterscheidet. Und im Wesentlichen ist es so. Aber während wir diesen Beitrag schrieben, haben wir uns daran erinnert, wie viele zusätzliche Bewegungen man machen muss, wenn man nicht über OpenShift verfügt, und deshalb ist es wiederum wunderbar. Wir lieben es, wenn alles einfach geht, und wie einfach sich unser Beispiel im Vergleich zu Minikube unter OpenShift bereitstellen und ausführen lässt, hat uns dazu bewogen, diesen Beitrag zu schreiben.
Lassen Sie uns den Prozess durchgehen und sehen, was wir tun müssen.
Im Minikube-Beispiel haben wir also mit Docker begonnen ... Moment, Docker muss nicht mehr auf der Maschine installiert sein.
Und wir brauchen keinen lokalen Idioten.
Und Maven wird nicht benötigt.
Und Sie müssen ein Container-Image nicht manuell erstellen.
Und Sie müssen nicht nach einem Repository mit Container-Images suchen.
Und es ist nicht erforderlich, einen Ingress-Controller zu installieren.
Und Sie müssen den Eingang auch nicht konfigurieren.
Du verstehst, oder? Um unsere Anwendung auf OpenShift bereitzustellen und auszuführen, benötigen Sie keine der oben genannten Voraussetzungen. Und der Prozess selbst sieht so aus.
Schritt 1 – Starten Sie Ihren OpenShift-Cluster
Wir verwenden Code Ready Containers von Red Hat, bei denen es sich im Wesentlichen um Minikube handelt, jedoch nur mit einem vollwertigen Openshift-Cluster mit einem Knoten.
crc start
Schritt 2 – Erstellen Sie die Anwendung und stellen Sie sie im OpenShift-Cluster bereit
In diesem Schritt kommen die Einfachheit und der Komfort von OpenShift in ihrer ganzen Pracht zum Vorschein. Wie bei allen Kubernetes-Distributionen gibt es viele Möglichkeiten, eine Anwendung in einem Cluster auszuführen. Und wie im Fall von KUK wählen wir gezielt die einfachste Variante.
OpenShift wurde schon immer als Plattform zum Erstellen und Ausführen von Containeranwendungen entwickelt. Der Containeraufbau war schon immer ein integraler Bestandteil dieser Plattform, daher gibt es eine Menge zusätzlicher Kubernetes-Ressourcen für verwandte Aufgaben.
Wir verwenden den Source 2 Image (S2I)-Prozess von OpenShift, der verschiedene Möglichkeiten bietet, unsere Quelle (Code oder Binärdateien) in ein Container-Image umzuwandeln, das auf einem OpenShift-Cluster ausgeführt wird.
Dazu benötigen wir zwei Dinge:
- Unser Quellcode befindet sich im Git-Repository
- Builder-Image, auf dessen Grundlage der Build ausgeführt wird.
Es gibt viele solcher Images, die sowohl von Red Hat als auch auf Community-Ebene verwaltet werden, und wir werden das OpenJDK-Image verwenden, da ich eine Java-Anwendung erstelle.
Sie können den S2I-Build sowohl über die grafische OpenShift Developer-Konsole als auch über die Befehlszeile ausführen. Wir werden den Befehl new-app verwenden und ihm mitteilen, wo er das Builder-Image und unseren Quellcode erhalten soll.
oc new-app registry.access.redhat.com/ubi8/openjdk-11:latest~https://github.com/gcolman/quarkus-hello-world.git
Das war's, unsere Anwendung ist erstellt. Dabei hat der S2I-Prozess Folgendes getan:
- Erstellte einen Service-Build-Pod für alle möglichen Dinge im Zusammenhang mit der Erstellung der Anwendung.
- Erstellt die OpenShift Build-Konfiguration.
- Ich habe das Builder-Image in die interne OpenShift-Docker-Registrierung heruntergeladen.
- „Hello World“ in das lokale Repository geklont.
- Ich habe gesehen, dass dort ein Maven-Pom war, also habe ich die Anwendung mit Maven kompiliert.
- Erstellte ein neues Container-Image mit der kompilierten Java-Anwendung und fügte dieses Image in die interne Container-Registrierung ein.
- Erstellt eine Kubernetes-Bereitstellung mit Spezifikationen für Pod, Service usw.
- Ich habe mit der Bereitstellung des Container-Images begonnen.
- Der Dienst-Build-Pod wurde entfernt.
Auf dieser Liste steht viel, aber das Wichtigste ist, dass der gesamte Build ausschließlich innerhalb von OpenShift erfolgt, die interne Docker-Registrierung innerhalb von OpenShift liegt und der Build-Prozess alle Kubernetes-Komponenten erstellt und im Cluster ausführt.
Wenn Sie den Start von S2I in der Konsole visuell überwachen, können Sie sehen, wie der Build-Pod gestartet wird, wenn der Build abgeschlossen ist.
Werfen wir nun einen Blick auf die Builder-Pod-Protokolle: Zunächst wird gezeigt, wie Maven seine Arbeit erledigt und Abhängigkeiten herunterlädt, um unsere Java-Anwendung zu erstellen.
Nachdem der Maven-Build abgeschlossen ist, wird der Build des Container-Images gestartet und dann wird dieses erstellte Image an das interne Repository gesendet.
Damit ist der Build-Prozess abgeschlossen. Stellen wir nun sicher, dass die Pods und Dienste unserer Anwendung im Cluster ausgeführt werden.
oc get service
Das ist alles. Und nur ein Team. Wir müssen diesen Dienst lediglich für den Zugriff von außen freigeben.
Schritt 3 – Machen Sie den Dienst für den Zugriff von außen verfügbar
Wie im Fall von KUC benötigt auch unsere „Hello World“ auf der OpenShift-Plattform einen Router, um externen Datenverkehr an den Dienst innerhalb des Clusters weiterzuleiten. OpenShift macht dies sehr einfach. Erstens wird die HAProxy-Routing-Komponente standardmäßig im Cluster installiert (sie kann auf dasselbe NGINX geändert werden). Zweitens gibt es spezielle und hochgradig anpassbare Ressourcen namens Routes, die Ingress-Objekten im guten alten Kubernetes ähneln (tatsächlich haben die Routen von OpenShift das Design von Ingress-Objekten stark beeinflusst, die jetzt in OpenShift verwendet werden können), aber für unser „Hello World“ , und in fast allen anderen Fällen reicht uns die Standardroute ohne zusätzliche Konfiguration.
Um einen routbaren FQDN für „Hello World“ zu erstellen (ja, OpenShiift verfügt über einen eigenen DNS für das Routing nach Dienstnamen), legen wir einfach unseren Dienst offen:
oc expose service quarkus-hello-world
Wenn Sie sich die neu erstellte Route ansehen, finden Sie dort den FQDN und andere Routing-Informationen:
oc get route
Und schließlich greifen wir über den Browser auf unseren Dienst zu:
Aber jetzt war es wirklich einfach!
Wir lieben Kubernetes und alles, was uns diese Technologie ermöglicht, und wir lieben auch die Einfachheit und Leichtigkeit. Kubernetes wurde entwickelt, um den Betrieb verteilter, skalierbarer Container unglaublich zu vereinfachen, aber seine Einfachheit reicht heute nicht mehr aus, um Anwendungen in die Produktion zu bringen. Hier kommt OpenShift ins Spiel, das mit der Zeit geht und Kubernetes anbietet, das sich vor allem an den Entwickler richtet. Es wurde viel Aufwand investiert, um die OpenShift-Plattform speziell auf den Entwickler zuzuschneiden, einschließlich der Erstellung von Tools wie S2I, ODI, Entwicklerportal, OpenShift Operator Framework, IDE-Integration, Entwicklerkatalogen, Helm-Integration, Überwachung und vielen anderen.
Wir hoffen, dass dieser Artikel für Sie interessant und nützlich war. Auf dem Portal finden Sie zusätzliche Ressourcen, Materialien und andere nützliche Dinge für die Entwicklung auf der OpenShift-Plattform .
Source: habr.com