{"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":"Entschuldige, OpenShift, wir haben dich nicht genug gesch\u00e4tzt und f\u00fcr selbstverst\u00e4ndlich gehalten","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Dieser Beitrag ist entstanden, da unser Team viele Gespr\u00e4che mit Kunden \u00fcber die Entwicklung von Anwendungen auf Kubernetes und die spezifischen Anforderungen dieser Entwicklung auf OpenShift hatte.<\/p>\n

\"Entschuldige,
\n
\nWir beginnen normalerweise mit der These, dass Kubernetes einfach Kubernetes ist, w\u00e4hrend OpenShift eine Kubernetes-Plattform ist, \u00e4hnlich wie Microsoft AKS oder Amazon EKS. Jede dieser Plattformen hat ihre eigenen Vorteile, die auf bestimmte Zielgruppen ausgerichtet sind. Im Anschluss flie\u00dft das Gespr\u00e4ch dann oft in einen Vergleich der St\u00e4rken und Schw\u00e4chen der jeweiligen Plattformen.
\n<\/a><\/noindex>
\nIm Gro\u00dfen und Ganzen dachten wir dar\u00fcber nach, diesen Beitrag mit einem Fazit zu schreiben wie: \u201eEgal, wo man den Code ausf\u00fchrt \u2013 auf OpenShift, AKS, EKS oder auf einem beliebigen benutzerdefinierten Kubernetes (wir nennen es mal KUK) \u2013 es ist wirklich einfach, egal wo.\u201c (Um es kurz zu machen, nennen wir es KUK)<\/i> \u2013 das gilt sowohl dort als auch da.<\/p>\n

Anschlie\u00dfend wollten wir ein einfaches \u201eHello World\u201c-Beispiel nehmen, um zu zeigen, was die Gemeinsamkeiten und Unterschiede zwischen KUK und der Red Hat OpenShift Container Platform (im Folgenden OCP oder einfach OpenShift) sind.<\/p>\n

W\u00e4hrend des Schreibens dieses Beitrags ist uns aufgefallen, dass wir uns so sehr an OpenShift gew\u00f6hnt haben, dass wir gar nicht bemerken, wie es sich zu einer beeindruckenden Plattform entwickelt hat, die weit mehr ist als nur eine Kubernetes-Distribution. Wir nehmen die Reife und Benutzerfreundlichkeit von OpenShift als selbstverst\u00e4ndlich hin und \u00fcbersehen dabei seine Brillanz.<\/p>\n

Es ist Zeit f\u00fcr eine aktive Auseinandersetzung, und jetzt werden wir schrittweise den Einsatz unseres \"Hello World\" sowohl in KUK als auch in OpenShift vergleichen, und das m\u00f6glichst objektiv (mit vielleicht gelegentlichen pers\u00f6nlichen Einsch\u00e4tzungen zum Thema). Wenn Sie an einer rein subjektiven Meinung zu diesem Thema interessiert sind, k\u00f6nnen Sie sie hier lesen (EN)<\/a><\/noindex>. In diesem Beitrag werden wir uns auf Fakten und nur auf Fakten konzentrieren.<\/p>\n

Cluster<\/h3>\n

\nF\u00fcr unser \"Hello World\" ben\u00f6tigen wir also Cluster. Um keine Kosten f\u00fcr Server, Register, Netzwerke, Daten\u00fcbertragungen usw. zu verursachen, sagen wir sofort \"nein\" zu \u00f6ffentlich zug\u00e4nglichen Clouds. Somit w\u00e4hlen wir einen einfachen Single-Node-Cluster auf Minikube<\/a><\/noindex> (f\u00fcr KUK) und Code Ready Containers<\/a><\/noindex> (f\u00fcr den OpenShift-Cluster). Beide Optionen sind tats\u00e4chlich einfach zu installieren, ben\u00f6tigen jedoch eine erhebliche Menge an Ressourcen auf Ihrem Laptop.<\/p>\n

\"Entschuldige,<\/p>\n

Build auf KUK<\/h3>\n

\nAlso, legen wir los.<\/p>\n

Schritt 1 \u2013 Erstellen unseres Container-Images<\/h4>\n

\nBeginnen wir damit, unser 'Hello World' auf minikube bereitzustellen. Dazu ben\u00f6tigen Sie:<\/p>\n

    \n
  1. 1. Installiertes Docker.<\/li>\n
  2. 2. Installiertes Git.<\/li>\n
  3. 3. Installiertes Maven (in diesem Projekt wird tats\u00e4chlich der mvnw-Binary verwendet, daher ist dies nicht unbedingt erforderlich).<\/li>\n
  4. 4. Den Quellcode selbst, d.h. ein Klon des Repositories github.com\/gcolman\/quarkus-hello-world.git<\/a><\/noindex><\/li>\n<\/ol>\n

    \nAls N\u00e4chstes m\u00fcssen wir ein Quarkus-Projekt erstellen. Keine Sorge, wenn Sie noch nie mit der Website Quarkus.io gearbeitet haben \u2013 es ist ganz einfach. W\u00e4hlen Sie einfach die Komponenten aus, die Sie im Projekt verwenden m\u00f6chten (RestEasy, Hibernate, Amazon SQS, Camel usw.), und Quarkus konfiguriert automatisch das Maven-Archetyp und stellt alles auf GitHub bereit. Das bedeutet, dass es nur ein Mausklick ben\u00f6tigt \u2013 und schon ist es fertig. Daf\u00fcr lieben wir Quarkus.<\/p>\n

    \"Entschuldige,<\/p>\n

    Der einfachste Weg, unser 'Hello World' in ein Container-Image zu packen, besteht darin, die quarkus-maven-Erweiterungen f\u00fcr Docker zu verwenden, die die gesamte notwendigen Schritte erledigen. Mit der Einf\u00fchrung von Quarkus wurde es wirklich einfach: F\u00fcgen Sie die Erweiterung container-image-docker hinzu und Sie k\u00f6nnen Images mit Maven-Befehlen erstellen.<\/p>\n

    .\/mvnw quarkus:add-extension -Dextensions=\"container-image-docker\"\n<\/code><\/pre>\n
    \nUnd schlie\u00dflich erstellen wir unser Image mit Maven. Unser Quellcode wird somit zu einem einsatzbereiten Container-Image, das bereits in einer Container-Laufzeitumgebung gestartet werden kann.<\/p>\n
    \"Entschuldige,<\/p>\n
    .\/mvnw -X clean package -Dquarkus.container-image.build=true\n<\/code><\/pre>\n
    \nDas ist alles, jetzt k\u00f6nnen wir den Container mit dem Befehl docker run starten und unseren Service auf Port 8080 mappen, um darauf zugreifen zu k\u00f6nnen.<\/p>\n
    docker run -i --rm -p 8080:8080 gcolman\/quarkus-hello-world\n<\/code><\/pre>\n
    \"Entschuldige,<\/p>\n
    Nachdem die Container-Instanz gestartet ist, m\u00fcssen wir nur noch mit dem Befehl curl \u00fcberpr\u00fcfen, dass unser Service funktioniert:<\/p>\n
    \"Entschuldige,<\/p>\n
    Alles funktioniert also, und es war tats\u00e4chlich ganz einfach.<\/p>\n
    Schritt 2 \u2013 Wir schicken unseren Container in das Container-Image-Repository<\/h4>\n
    \nBis jetzt 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. In Kubernetes gibt es daf\u00fcr keine eigenen Funktionen, deshalb werden wir Docker Hub verwenden. Erstens, weil es kostenlos ist, und zweitens, weil das fast jeder so macht.<\/p>\n
    Das ist auch sehr einfach, und man ben\u00f6tigt dazu nur ein Konto bei Docker Hub.<\/p>\n
    Also, lassen Sie uns Docker Hub einrichten und unser Image dorthin hochladen.<\/p>\n
    \"Entschuldige,<\/p>\n
    Schritt 3 \u2013 Kubernetes starten<\/h4>\n
    \nEs gibt viele M\u00f6glichkeiten, eine Kubernetes-Konfiguration f\u00fcr den Start unseres 'Hello World' zu erstellen, aber wir verwenden die einfachste, denn wir sind so...<\/p>\n
    Zun\u00e4chst starten wir den Minikube-Cluster:<\/p>\n
    minikube start\n<\/code><\/pre>\n
    <\/p>\n
    Schritt 4 \u2013 Unsere Container-Image bereitstellen<\/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 bei Docker Hub verweist. Eine der einfachsten M\u00f6glichkeiten, dies zu tun, besteht darin, den Befehl 'create deployment' auszuf\u00fchren und auf unser Image zu verweisen:<\/p>\n
    \"Entschuldige,<\/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 angewiesen, eine Deployment-Konfiguration zu erstellen, die die Pod-Spezifikation f\u00fcr unser Container-Image enthalten sollte. Dieser Befehl wendet auch diese Konfiguration auf unseren Minikube-Cluster an und erstellt ein Deployment, das unser Container-Image herunterl\u00e4dt und das Pod im Cluster startet.<\/p>\n
    Schritt 5 \u2013 Zugriffsberechtigungen f\u00fcr unseren Service einrichten<\/h4>\n
    \nJetzt, da wir unser Container-Image bereitgestellt haben, ist es an der Zeit zu \u00fcberlegen, wie wir den externen Zugriff auf diesen RESTful-Service konfigurieren, der letztendlich 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 \u2014 type=NodePort \u2014 port=8080\n<\/code><\/pre>\n
    \nLassen Sie uns einen Moment bei der Option \u201e\u2014 type\u201c des Befehls expose innehalten.<\/p>\n
    Wenn wir expose ausf\u00fchren und die notwendigen Komponenten erstellen, um unseren Service zu starten, m\u00fcssen wir unter anderem sicherstellen, dass wir von au\u00dfen auf den Service hello-quarkus zugreifen k\u00f6nnen, der sich innerhalb unseres softwaredefinierten Netzwerks befindet. Der Parameter type<\/b> erm\u00f6glicht es uns, Dinge wie Load-Balancer zu erstellen und zu verbinden, um den Verkehr in dieses Netzwerk zu leiten.<\/p>\n
    Indem wir beispielsweise type=LoadBalancer<\/b>, initialisieren wir automatisch einen Load-Balancer in der \u00f6ffentlichen Cloud, der eine Verbindung zu unserem Kubernetes-Cluster herstellt. Das ist nat\u00fcrlich gro\u00dfartig, aber man muss verstehen, dass eine solche Konfiguration stark an eine bestimmte \u00f6ffentliche Cloud gebunden ist und es schwieriger sein wird, sie zwischen Kubernetes-Instanzen in verschiedenen Umgebungen zu migrieren.<\/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 Option erm\u00f6glicht es, keine \u00f6ffentlichen Clouds zu nutzen, erfordert jedoch einige zus\u00e4tzliche Schritte. Zuerst ben\u00f6tigen wir einen eigenen Lastenausgleichsmechanismus, weshalb wir einen NGINX-Load-Balancer in unserem Cluster bereitstellen werden.<\/p>\n
    Schritt 6 \u2013 Lastenausgleichsmechanismus einrichten<\/h4>\n
    \nMinikube bietet eine Reihe von Plattformfunktionen, die das Erstellen der ben\u00f6tigten Komponenten f\u00fcr den externen Zugriff erleichtern, wie z.B. Ingress-Controller. 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 nur einem Befehl einen Nginx-Ingress-Controller, der innerhalb unseres Minikube-Clusters l\u00e4uft:<\/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 einstellen, dass er Anfragen an hello-quarkus verarbeitet.<\/p>\n
    \"Entschuldige,<\/p>\n
    \"Entschuldige,<\/p>\n
    Und schlie\u00dflich m\u00fcssen wir diese Konfiguration anwenden.<\/p>\n
    \"Entschuldige,<\/p>\n
    kubectl apply -f ingress.yml\n<\/code><\/pre>\n
    \"Entschuldige,<\/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, unser minikube-Service ist jetzt \u00fcber den Nginx Ingress-Controller extern erreichbar.<\/p>\n
    \"Entschuldige,<\/p>\n
    Na, das war doch einfach, oder? Oder nicht ganz?<\/h3>\n
    \"Entschuldige,<\/p>\n
    Starten auf OpenShift (Code Ready Containers)<\/h3>\n
    \nJetzt schauen wir uns an, wie das Ganze auf der Red Hat OpenShift Container Platform (OCP) funktioniert.<\/p>\n
    Wie bei minikube w\u00e4hlen wir das Szenario mit einem einzelnen OpenShift-Cluster in Form von Code Ready Containers (CRC). Fr\u00fcher bekannt als minishift basierend auf dem OpenShift Origin-Projekt, ist dies jetzt CRC und baut auf der Red Hat OpenShift Container Platform auf.<\/p>\n
    Hier k\u00f6nnen wir uns nicht zur\u00fcckhalten und m\u00fcssen sagen: \u201eOpenShift ist gro\u00dfartig!\u201c<\/p>\n
    Urspr\u00fcnglich dachten wir, dass die Entwicklung auf OpenShift sich nicht von der Entwicklung auf Kubernetes unterscheidet. Im Grunde genommen ist das auch richtig. Doch w\u00e4hrend wir diesen Beitrag schrieben, erinnerten wir uns daran, wie viele unn\u00f6tige Schritte n\u00f6tig sind, wenn man kein OpenShift hat, und deshalb ist es, um es nochmal zu sagen, gro\u00dfartig. Wir lieben es, wenn alles einfach ist, und wie viel einfacher unser Beispiel im Vergleich zu minikube auf OpenShift bereitgestellt und gestartet wird, hat uns motiviert, diesen Beitrag zu schreiben.<\/p>\n
    Lassen Sie uns den Prozess durchgehen und sehen, was wir tun m\u00fcssen.<\/p>\n
    In unserem Beispiel mit minikube haben wir mit Docker begonnen... Stopp, wir ben\u00f6tigen Docker nicht mehr auf der Maschine.<\/p>\n
    Und lokale git ben\u00f6tigen wir nicht.
    \nUnd Maven ist nicht erforderlich.
    \nUnd es ist nicht n\u00f6tig, das Container-Image manuell zu erstellen.
    \nUnd wir m\u00fcssen kein Container-Image-Repository suchen.
    \nUnd es ist nicht erforderlich, einen Ingress-Controller zu installieren.
    \nUnd wir m\u00fcssen auch den Ingress nicht konfigurieren.<\/b><\/p>\n
    Haben Sie es verstanden? Um unsere Anwendung in OpenShift bereitzustellen und zu starten, brauchen wir nichts davon. Der gesamte Prozess sieht wie folgt aus.<\/p>\n
    Schritt 1 \u2013 Starten Sie Ihren OpenShift-Cluster<\/h4>\n
    \nWir verwenden Code Ready Containers von Red Hat, das im Grunde das gleiche wie Minikube ist, jedoch mit einem vollwertigen ein-Knoten-Openshift-Cluster.<\/p>\n
    crc start\n<\/code><\/pre>\n
    <\/p>\n
    Schritt 2 \u2013 Bauen und Bereitstellen der Anwendung im OpenShift-Cluster<\/h4>\n
    \nGerade in diesem Schritt zeigt sich die Einfachheit und Benutzerfreundlichkeit von OpenShift in vollem Umfang. Wie in allen Kubernetes-Distributionen haben wir viele M\u00f6glichkeiten, eine Anwendung im Cluster auszuf\u00fchren. Und wie im Fall von KUK w\u00e4hlen wir absichtlich die einfachste.<\/p>\n
    OpenShift wurde immer als Plattform zum Erstellen und Ausf\u00fchren von Containeranwendungen konzipiert. Der Aufbau von Containern war schon immer ein wesentlicher Bestandteil dieser Plattform, weshalb es hier viele zus\u00e4tzliche Kubernetes-Ressourcen f\u00fcr die entsprechenden Aufgaben gibt.<\/p>\n
    \u041c\u044b \u0431\u0443\u0434\u0435\u043c \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c OpenShift’\u043e\u0432\u0441\u043a\u0438\u0439 \u043f\u0440\u043e\u0446\u0435\u0441\u0441 Source 2 Image (S2I), \u0443 \u043a\u043e\u0442\u043e\u0440\u043e\u0433\u043e \u0435\u0441\u0442\u044c \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0440\u0430\u0437\u043b\u0438\u0447\u043d\u044b\u0445 \u0441\u043f\u043e\u0441\u043e\u0431\u043e\u0432 \u0434\u043b\u044f \u0442\u043e\u0433\u043e, \u0447\u0442\u043e\u0431\u044b \u0432\u0437\u044f\u0442\u044c \u043d\u0430\u0448 \u0438\u0441\u0445\u043e\u0434\u043d\u0438\u043a (\u043a\u043e\u0434 \u0438\u043b\u0438 \u0434\u0432\u043e\u0438\u0447\u043d\u044b\u0435 \u0444\u0430\u0439\u043b\u044b) \u0438 \u043f\u0440\u0435\u0432\u0440\u0430\u0442\u0438\u0442\u044c \u0435\u0433\u043e \u0432 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u043d\u044b\u0439 \u043e\u0431\u0440\u0430\u0437, \u0437\u0430\u043f\u0443\u0441\u043a\u0430\u0435\u043c\u044b\u0439 \u0432 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0435 OpenShift.<\/p>\n
    Dazu ben\u00f6tigen wir zwei Dinge:<\/p>\n