{"id":97254,"date":"2020-10-17T02:42:32","date_gmt":"2020-10-17T00:42:32","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/prosti-openshift-my-nedostatochno-czenili-tebya-i-prinimali-kak-dolzhnoe"},"modified":"2020-10-17T02:42:32","modified_gmt":"2020-10-17T00:42:32","slug":"prosti-openshift-my-nedostatochno-czenili-tebya-i-prinimali-kak-dolzhnoe","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/prosti-openshift-my-nedostatochno-czenili-tebya-i-prinimali-kak-dolzhnoe","title":{"rendered":"Es tut mir leid, OpenShift, wir haben dich nicht genug gesch\u00e4tzt und als selbstverst\u00e4ndlich angesehen","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Dieser Beitrag wurde verfasst, weil wir viele Gespr\u00e4che mit unseren Kunden \u00fcber die Entwicklung von Anwendungen auf Kubernetes und \u00fcber die Besonderheiten dieser Entwicklung auf OpenShift gef\u00fchrt haben.<\/p>\n

\"Es
\n
\nWir beginnen normalerweise mit der These, dass Kubernetes einfach Kubernetes ist, w\u00e4hrend OpenShift bereits eine Kubernetes-Plattform ist, \u00e4hnlich wie Microsoft AKS oder Amazon EKS. Jede dieser Plattformen hat ihre eigenen Vorteile, die auf eine bestimmte Zielgruppe ausgerichtet sind. Danach flie\u00dft das Gespr\u00e4ch bereits in einen Vergleich der St\u00e4rken und Schw\u00e4chen der jeweiligen Plattformen \u00fcber.
\n<\/a><\/noindex>
\nIm Grunde dachten wir dar\u00fcber nach, diesen Beitrag mit der Schlussfolgerung zu schreiben: \u201eH\u00f6rt zu, es spielt keine Rolle, wo der Code ausgef\u00fchrt wird, auf OpenShift oder auf AKS, auf EKS, auf einem beliebigen benutzerdefinierten Kubernetes oder auf irgendeinem Kubernetes (um es kurz zu machen, nennen wir es KUK)<\/i> \u2013 es ist tats\u00e4chlich einfach, sowohl dort als auch dort.\u201c<\/p>\n

Dann hatten wir geplant, ein einfaches \"Hello World\" zu nehmen und anhand dieses Beispiels zu zeigen, was gemeinsam ist und was die Unterschiede zwischen KUK und der Red Hat OpenShift Container Platform (nachfolgend OCP oder einfach OpenShift) sind.<\/p>\n

Doch w\u00e4hrend des Schreibens dieses Beitrags wurde uns klar, dass wir so sehr an OpenShift gew\u00f6hnt sind, dass wir einfach nicht bemerken, wie es gewachsen ist und sich in eine gro\u00dfartige Plattform verwandelt hat, die viel mehr ist als nur eine Kubernetes-Distribution. Wir haben uns daran gew\u00f6hnt, die Reife und Einfachheit von OpenShift als selbstverst\u00e4ndlich zu betrachten und dabei seine hervorragenden Eigenschaften au\u00dfer Acht zu lassen.<\/p>\n

Im Grunde ist es an der Zeit f\u00fcr aktives Bedauern, und jetzt werden wir Schritt f\u00fcr Schritt den Einsatz unseres \"Hello World\" auf KUK und OpenShift vergleichen, und wir werden dies so objektiv wie m\u00f6glich tun (au\u00dfer vielleicht, dass wir gelegentlich pers\u00f6nliche Meinungen zu dem Thema \u00e4u\u00dfern). Wenn Sie an einer rein subjektiven Meinung zu diesem Thema interessiert sind, k\u00f6nnen Sie sie lesen . Heute zeigen wir, wie man AMQ Online und Quarkus kombiniert, um ein modernes Nachrichtenaustauschsystem auf Basis von OpenShift zu erstellen, das zwei neue Technologien zur Nachrichtenverarbeitung nutzt.<\/a><\/noindex>. In diesem Beitrag werden wir uns jedoch an die Fakten und nur an die Fakten halten.<\/p>\n

Cluster<\/h3>\n

\nAlso, f\u00fcr unser \"Hello World\" ben\u00f6tigen wir Cluster. Zun\u00e4chst einmal sagen wir \"nein\" zu allen \u00f6ffentlichen Clouds, um keine Kosten f\u00fcr Server, Registries, Netzwerke, Datentransfers usw. zu haben. Daher w\u00e4hlen wir einen einfachen Ein-Knoten-Cluster auf Minikube<\/a><\/noindex> (f\u00fcr KUK) und Code Ready Containers<\/a><\/noindex> (f\u00fcr den OpenShift-Cluster). Beide Varianten sind in der Installation wirklich einfach, ben\u00f6tigen jedoch ziemlich viele Ressourcen auf Ihrem Laptop.<\/p>\n

\"Es<\/p>\n

Build auf KUK<\/h3>\n

\nAlso, lass uns anfangen.<\/p>\n

Schritt 1 \u2013 wir erstellen unser Container-Image<\/h4>\n

\nIch beginne damit, unser \"Hello World\" auf minikube zu deployen. Daf\u00fcr ben\u00f6tigen wir:<\/p>\n

    \n
  1. 1. Installiertes Docker.<\/li>\n
  2. 2. Installiertes Git.<\/li>\n
  3. 3. Installiertes Maven (in diesem Projekt wird eigentlich die mvnw-Bin\u00e4rdatei verwendet, also ist es nicht erforderlich).<\/li>\n
  4. 4. Tats\u00e4chlich der Quellcode, d.h. ein Klon des Repositories github.com\/gcolman\/quarkus-hello-world.git<\/a><\/noindex><\/li>\n<\/ol>\n

    \nZuerst muss ein Quarkus-Projekt erstellt werden. Keine Sorge, wenn Sie noch nie mit der Webseite Quarkus.io gearbeitet haben \u2013 das ist einfach. W\u00e4hlen Sie einfach die Komponenten aus, die Sie in Ihrem Projekt verwenden m\u00f6chten (RestEasy, Hibernate, Amazon SQS, Camel usw.), und dann konfiguriert Quarkus alles f\u00fcr Sie, ohne dass Sie irgendetwas tun m\u00fcssen; es richtet das Maven-Archetyp ein und stellt alles auf GitHub bereit. Das hei\u00dft, mit nur einem Mausclick ist alles bereit. Daf\u00fcr lieben wir Quarkus.<\/p>\n

    \"Es<\/p>\n

    Der einfachste Weg, um unser \"Hello World\" in ein Container-Image zu packen, ist die Verwendung von Quarkus-Maven-Erweiterungen f\u00fcr Docker, die die gesamte erforderliche Arbeit erledigen. Mit dem Erscheinen von Quarkus ist das wirklich einfach und unkompliziert geworden: Sie f\u00fcgen die Erweiterung container-image-docker hinzu und k\u00f6nnen Images mit Maven-Befehlen erstellen.<\/p>\n

    .\/mvnw quarkus:add-extension -Dextensions=\"container-image-docker\"\n<\/code><\/pre>\n
    \nUnd schlie\u00dflich bauen wir unser Image mit Maven. Dabei verwandelt sich unser Quellcode in ein fertiges Container-Image, das bereits in einer Container-Ausf\u00fchrungsumgebung gestartet werden kann.<\/p>\n
    \"Es<\/p>\n
    .\/mvnw -X clean package -Dquarkus.container-image.build=true\n<\/code><\/pre>\n
    \nUnd das war's, jetzt k\u00f6nnen Sie den Container mit dem Befehl docker run starten und unseren Dienst auf Port 8080 bereitstellen, sodass er erreichbar ist.<\/p>\n
    docker run -i --rm -p 8080:8080 gcolman\/quarkus-hello-world\n<\/code><\/pre>\n
    \"Es<\/p>\n
    Nachdem der Container-Instanz gestartet wurde, m\u00fcssen wir nur noch mit dem Befehl curl \u00fcberpr\u00fcfen, dass unser Dienst funktioniert:<\/p>\n
    \"Es<\/p>\n
    Also, alles funktioniert und es war wirklich einfach und unkompliziert.<\/p>\n
    Schritt 2 \u2013 \u00dcbertragen unseres Containers in ein Container-Image-Repository<\/h4>\n
    \nMomentan wird das von uns erstellte Image lokal in unserem lokalen Container-Repository gespeichert. Wenn wir dieses Image in unserer Kubernetes-Umgebung verwenden m\u00f6chten, m\u00fcssen wir es in ein anderes Repository hochladen. Kubernetes hat diese Funktionen nicht eingebaut, deshalb werden wir Docker Hub verwenden. Es ist erstens kostenlos und zweitens machen es (fast) alle so.<\/p>\n
    Das ist auch ganz einfach, man braucht nur ein Konto bei Docker Hub.<\/p>\n
    Also, melden wir uns bei Docker Hub an und laden unser Image dort hoch.<\/p>\n
    \"Es<\/p>\n
    Schritt 3 \u2013 Kubernetes starten<\/h4>\n
    \nEs gibt viele M\u00f6glichkeiten, die Kubernetes-Konfiguration f\u00fcr unser \"Hello World\" zusammenzustellen, aber wir werden die einfachste davon verwenden, weil wir so sind...<\/p>\n
    Zuerst starten wir den Minikube-Cluster:<\/p>\n
    minikube start\n<\/code><\/pre>\n
    <\/p>\n
    Schritt 4 \u2013 Wir deployen unser Container-Image<\/h4>\n
    \nJetzt m\u00fcssen wir unseren Code und das Container-Image in Kubernetes-Konfigurationen umwandeln. Mit anderen Worten, wir ben\u00f6tigen eine Pod- und Deployment-Definition, die auf unser Container-Image auf Dockerhub verweist. Einer der einfachsten Wege, dies zu tun, ist der Befehl zum Erstellen eines Deployments, indem wir auf unser Image verweisen:<\/p>\n
    \"Es<\/p>\n
    kubectl create deployment hello-quarkus --image=gcolman\/quarkus-hello-world:1.0.0-SNAPSHOT\n<\/code><\/pre>\n
    \nMit diesem Befehl haben wir Kubernetes gesagt, dass es eine Deployment-Konfiguration erstellen soll, die eine Pod-Spezifikation f\u00fcr unser Container-Image enthalten muss. Dieser Befehl wendet auch diese Konfiguration auf unseren Minikube-Cluster an und erstellt ein Deployment, das unser Container-Image herunterl\u00e4dt und einen Pod im Cluster startet.<\/p>\n
    Schritt 5 \u2013 Wir \u00f6ffnen den Zugriff auf unseren Dienst<\/h4>\n
    \nJetzt, wo wir unser Container-Image bereitgestellt haben, ist es an der Zeit zu \u00fcberlegen, wie wir den externen Zugriff auf diesen RESTful-Service konfigurieren, der in unserem Code programmiert ist.<\/p>\n
    Hier gibt es viele M\u00f6glichkeiten. Zum Beispiel k\u00f6nnen wir den Befehl expose verwenden, um automatisch die entsprechenden Kubernetes-Komponenten wie Services und Endpoints zu erstellen. Genau das werden wir tun, indem wir den Befehl expose f\u00fcr unser Deployment-Objekt ausf\u00fchren:<\/p>\n
    kubectl expose deployment hello-quarkus --type=NodePort --port=8080\n<\/code><\/pre>\n
    \nLass uns einen Moment auf die Option \"--type\" des Expose-Befehls eingehen.<\/p>\n
    Wenn wir expose machen und die f\u00fcr den Betrieb unseres Dienstes erforderlichen Komponenten erstellen, m\u00fcssen wir unter anderem gew\u00e4hrleisten, dass von au\u00dfen auf den Dienst hello-quarkus zugegriffen werden kann, der in unserem softwaredefinierten Netzwerk sitzt. Und der Parameter type<\/b> erm\u00f6glicht es uns, solche Dinge wie Lastenausgleichsserver zu erstellen und zu verbinden, um den Verkehr in dieses Netzwerk zu leiten.<\/p>\n
    Wenn wir also type=LoadBalancer<\/b>, geben wir automatisch einen Lastenausgleichsserver in der \u00f6ffentlichen Cloud in Betrieb, um eine Verbindung zu unserem Kubernetes-Cluster herzustellen. Das ist nat\u00fcrlich gro\u00dfartig, man muss jedoch verstehen, dass eine solche Konfiguration stark an eine bestimmte \u00f6ffentliche Cloud gebunden sein wird und es schwieriger ist, sie zwischen Kubernetes-Instanzen in verschiedenen Umgebungen zu \u00fcbertragen.<\/p>\n
    In unserem Beispiel type=NodePort<\/b>, das hei\u00dft, der Zugriff auf unseren Dienst erfolgt \u00fcber die IP-Adresse des Knotens und die Portnummer. Diese M\u00f6glichkeit erfordert keine \u00f6ffentlichen Clouds, bringt jedoch eine Reihe zus\u00e4tzlicher Schritte mit sich. Erstens ben\u00f6tigen wir einen eigenen Load-Balancer, daher werden wir einen NGINX-Load-Balancer in unserem Cluster bereitstellen.<\/p>\n
    Schritt 6 \u2013 Load-Balancer einrichten<\/h4>\n
    \nMinikube verf\u00fcgt \u00fcber eine Reihe plattforminterner Funktionen, die die Erstellung der erforderlichen Komponenten f\u00fcr den externen Zugriff, wie Ingress-Controller, erleichtern. Minikube wird mit dem Nginx-Ingress-Controller geliefert, und wir m\u00fcssen ihn nur aktivieren und konfigurieren.<\/p>\n
    minikube addons enable ingress\n<\/code><\/pre>\n
    \nJetzt erstellen wir mit einem einzigen Befehl den Nginx-Ingress-Controller, der innerhalb unseres Minikube-Clusters funktioniert:<\/p>\n
    ingress-nginx-controller-69ccf5d9d8-j5gs9 1\/1 Running 1 33m\n<\/code><\/pre>\n
    <\/p>\n
    Schritt 7 \u2013 Ingress konfigurieren<\/h4>\n
    \nJetzt m\u00fcssen wir den Nginx-Ingress-Controller so konfigurieren, dass er die Anfragen an hello-quarkus akzeptiert.<\/p>\n
    \"Es<\/p>\n
    \"Es<\/p>\n
    Und schlie\u00dflich m\u00fcssen wir diese Konfiguration anwenden.<\/p>\n
    \"Es<\/p>\n
    kubectl apply -f ingress.yml\n<\/code><\/pre>\n
    \"Es<\/p>\n
    Da wir das alles auf unserem Computer machen, f\u00fcgen wir einfach die IP-Adresse unseres Knotens in die Datei \/etc\/hosts ein, um HTTP-Anfragen an unser Minikube an den NGINX-Load-Balancer zu leiten.<\/p>\n
    192.168.99.100 hello-quarkus.info\n<\/code><\/pre>\n
    \nAlles klar, jetzt ist unser Minikube-Dienst von au\u00dfen \u00fcber den Nginx-Ingress-Controller zug\u00e4nglich.<\/p>\n
    \"Es<\/p>\n
    Na, das war doch einfach, oder? Oder nicht so sehr?<\/h3>\n
    \"Es<\/p>\n
    Starten in OpenShift (Code Ready Containers)<\/h3>\n
    \nUnd jetzt schauen wir uns an, wie das alles auf der Red Hat OpenShift Container Platform (OCP) funktioniert.<\/p>\n
    Wie im Fall von Minikube w\u00e4hlen wir das Schema mit einem einzelnen Knoten in Form von Code Ready Containers (CRC). Fr\u00fcher hie\u00df es Minishift und basierte auf dem OpenShift-Origin-Projekt, jetzt ist es CRC und basiert auf der OpenShift Container Platform von Red Hat.<\/p>\n
    Hier k\u00f6nnen wir einfach nicht widerstehen zu sagen: 'OpenShift ist gro\u00dfartig!'<\/p>\n
    Urspr\u00fcnglich dachten wir, wir w\u00fcrden schreiben, dass die Entwicklung auf OpenShift sich nicht von der Entwicklung auf Kubernetes unterscheidet. Und im Grunde genommen stimmt das auch. Aber w\u00e4hrend wir diesen Beitrag schrieben, erinnerten wir uns, wie viele unn\u00f6tige Schritte man unternehmen muss, wenn man kein OpenShift hat, und deshalb ist es, um es noch einmal zu sagen, gro\u00dfartig. Wir lieben es, wenn alles einfach ist, und wie einfach unser Beispiel im Vergleich zu Minikube auf OpenShift bereitgestellt und gestartet wird, hat uns tats\u00e4chlich dazu bewegt, diesen Beitrag zu schreiben.<\/p>\n
    Lassen Sie uns den Prozess durchgehen und sehen, was wir tun m\u00fcssen.<\/p>\n
    Also, im Beispiel mit Minikube haben wir mit Docker begonnen... Halt, wir brauchen Docker nicht mehr auf dem Rechner installiert zu haben.<\/p>\n
    Und lokales Git ben\u00f6tigen wir nicht.
    \nUnd Maven ist auch nicht n\u00f6tig.
    \nUnd es ist nicht n\u00f6tig, ein Container-Image manuell zu erstellen.
    \nUnd es ist nicht n\u00f6tig, ein Container-Image-Repository zu suchen.
    \nUnd es ist nicht n\u00f6tig, einen Ingress-Controller zu installieren.
    \nUnd auch Ingress zu konfigurieren, ist nicht n\u00f6tig.<\/b><\/p>\n
    Ihr habt es verstanden, ja? Um unsere Anwendung in OpenShift zu starten und bereitzustellen, braucht man nichts davon. Der Prozess sieht folgenderma\u00dfen aus.<\/p>\n
    Schritt 1 \u2013 Starten Sie Ihr OpenShift-Cluster<\/h4>\n
    \nWir verwenden Code Ready Containers von Red Hat, was im Grunde dasselbe wie Minikube ist, jedoch mit einem voll funktionsf\u00e4higen Ein-Knoten-Cluster von Openshift.<\/p>\n
    crc start\n<\/code><\/pre>\n
    <\/p>\n
    Schritt 2 \u2013 F\u00fchren Sie den Build und die Bereitstellung der Anwendung im OpenShift-Cluster durch<\/h4>\n
    \nGenau in diesem Schritt zeigt sich die Einfachheit und Benutzerfreundlichkeit von OpenShift in vollem Umfang. Wie in allen Kubernetes-Distributionen gibt es viele M\u00f6glichkeiten, eine Anwendung im Cluster zu starten. Und wie im Fall von KUK w\u00e4hlen wir absichtlich die einfachste.<\/p>\n
    OpenShift wurde immer als Plattform zur Erstellung und Ausf\u00fchrung von containerisierten Anwendungen entwickelt. Das Erstellen von Containern war immer ein wesentlicher Bestandteil dieser Plattform, daher gibt es hier eine Menge zus\u00e4tzlicher Kubernetes-Ressourcen f\u00fcr entsprechende Aufgaben.<\/p>\n
    Wir werden den Source-to-Image (S2I) Prozess von OpenShift verwenden, der mehrere verschiedene Methoden bietet, um unseren Quellcode (Code oder Bin\u00e4rdateien) in ein containerbasiertes Image zu verwandeln, das im OpenShift-Cluster ausgef\u00fchrt wird.<\/p>\n
    Daf\u00fcr ben\u00f6tigen wir zwei Dinge:<\/p>\n