{"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\/nl\/blog\/administrirovanie\/prosti-openshift-my-nedostatochno-czenili-tebya-i-prinimali-kak-dolzhnoe","title":{"rendered":"Sorry, OpenShift, we hebben je niet genoeg gewaardeerd en hebben je als vanzelfsprekend beschouwd","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Deze post is geschreven omdat we veel gesprekken met klanten hadden over het ontwikkelen van applicaties op Kubernetes en de specifieke aspecten van deze ontwikkeling op OpenShift.<\/p>\n

\"Sorry,
\n
\nWe beginnen meestal met de stelling dat Kubernetes gewoon Kubernetes is, terwijl OpenShift een Kubernetes-platform is, net als Microsoft AKS of Amazon EKS. Elke van deze platforms heeft zijn eigen voordelen, gericht op een specifieke doelgroep. En na dit gesprek vloeit het al snel over in een vergelijking van de sterke en zwakke punten van specifieke platforms.
\n<\/a><\/noindex>
\nIn feite dachten we deze post te schrijven met de conclusie: 'Luister, het maakt niet uit waar je de code draait, op OpenShift of op AKS, op EKS, op een aangepaste Kubernetes, zelfs op elk soort Kubernetes.' (Om het kort te houden noemen we het KUK)<\/i> \u2013 het is immers echt eenvoudig, zowel daar als daar.<\/p>\n

Daarna was het plan om een eenvoudige 'Hello World' te nemen en aan de hand daarvan te laten zien wat gemeenschappelijk is en wat de verschillen zijn tussen KUK en Red Hat OpenShift Container Platform (hierna OCP of gewoon OpenShift).<\/p>\n

Maar tijdens het schrijven van deze post beseften we dat we zo lang en zo sterk gewend zijn geraakt aan het gebruik van OpenShift, dat we gewoon niet doorhadden hoe het is gegroeid en veranderd in een geweldige platform dat veel meer is geworden dan alleen een Kubernetes-distributie. We beschouwen de volwassenheid en eenvoud van OpenShift als vanzelfsprekend, waardoor we zijn pracht uit het oog verliezen.<\/p>\n

Over het algemeen is het tijd voor constructieve berusting, en nu zullen we stap voor stap de implementatie van onze 'Hello World' op KUK en OpenShift vergelijken, en we zullen dit maximaal objectief doen (zij het af en toe met een persoonlijke voorkeur voor het onderwerp). Als je een puur subjectieve mening over dit onderwerp wilt, kun je die lezen hier (EN)<\/a><\/noindex>. Maar in deze post zullen we ons uitsluitend aan de feiten houden.<\/p>\n

Clusters<\/h3>\n

\nDus, voor onze 'Hello World' hebben we clusters nodig. Laten we meteen 'nee' zeggen tegen publieke clouds, om geen kosten te maken voor servers, registries, netwerken, datatransmissie, enz. Daarom kiezen we voor een eenvoudige single-node cluster op Minikube<\/a><\/noindex> (voor KUK) en Code Ready Containers<\/a><\/noindex> (voor de OpenShift-cluster). Beide opties zijn echt eenvoudig te installeren, maar vereisen behoorlijk wat middelen op je laptop.<\/p>\n

\"Sorry,<\/p>\n

Bouwen op KUK<\/h3>\n

\nLaten we beginnen.<\/p>\n

Stap 1 \u2013 we bouwen ons containerbeeld<\/h4>\n

\nIk begin met het uitrollen van onze 'Hello World' op minikube. Hiervoor heb je nodig:<\/p>\n

    \n
  1. 1. Ge\u00efnstalleerde Docker.<\/li>\n
  2. 2. Ge\u00efnstalleerde Git.<\/li>\n
  3. 3. Ge\u00efnstalleerde Maven (in dit project wordt eigenlijk de mvnw-binaire gebruikt, dus dit is niet noodzakelijk).<\/li>\n
  4. 4. Eigenlijk de broncode, dat wil zeggen, een kloon van de repository github.com\/gcolman\/quarkus-hello-world.git<\/a><\/noindex><\/li>\n<\/ol>\n

    \nAls eerste moeten we een Quarkus-project cre\u00ebren. Maak je geen zorgen als je nog nooit met de site Quarkus.io gewerkt hebt \u2013 het is eenvoudig. Je kiest gewoon de componenten die je in je project wilt gebruiken (RestEasy, Hibernate, Amazon SQS, Camel, enzovoort), en verder configureert Quarkus zelf, zonder jouw tussenkomst, het Maven-archetype en plaatst alles op GitHub. E\u00e9n muisklik \u2013 en klaar. Dat is waarom we van Quarkus houden.<\/p>\n

    \"Sorry,<\/p>\n

    De eenvoudigste manier om onze \"Hello World\" in een containerafbeelding te bouwen, is door gebruik te maken van de quarkus-maven extensies voor Docker, die al het nodige werk doen. Met de komst van Quarkus is dit echt gemakkelijk geworden: je voegt de extensie container-image-docker toe en je kunt afbeeldingen maken met Maven-commando's.<\/p>\n

    .\/mvnw quarkus:add-extension -Dextensions=\"container-image-docker\"\n<\/code><\/pre>\n
    \nEn tenslotte bouwen we onze afbeelding met Maven. Het resultaat is dat onze broncode verandert in een kant-en-klare containerafbeelding die al kan worden uitgevoerd in een container-omgeving.<\/p>\n
    \"Sorry,<\/p>\n
    .\/mvnw -X clean package -Dquarkus.container-image.build=true\n<\/code><\/pre>\n
    \nDat is het eigenlijk, nu kun je de container starten met het commando docker run, door onze service op poort 8080 te mappen zodat deze benaderbaar is.<\/p>\n
    docker run -i --rm -p 8080:8080 gcolman\/quarkus-hello-world\n<\/code><\/pre>\n
    \"Sorry,<\/p>\n
    Nadat de containerinstantie is gestart, hoef je alleen nog maar met het commando curl te controleren of onze service werkt:<\/p>\n
    \"Sorry,<\/p>\n
    Dus, alles werkt, en het was echt gemakkelijk en simpel.<\/p>\n
    Stap 2 \u2013 we sturen onze container naar de containerafbeeldingsrepository<\/h4>\n
    \nTot nu toe wordt de afbeelding die we hebben aangemaakt lokaal opgeslagen in onze lokale containeropslag. Als we deze afbeelding willen gebruiken in onze K8s-omgeving, moet deze in een andere repository worden geplaatst. Kubernetes heeft geen dergelijke functies, dus we zullen dockerhub gebruiken. Omdat het ten eerste gratis is, en ten tweede, (bijna) iedereen dat doet.<\/p>\n
    Dit is ook heel eenvoudig, je hebt hier alleen een account op dockerhub nodig.<\/p>\n
    Dus, we loggen in op dockerhub en sturen onze afbeelding daarheen.<\/p>\n
    \"Sorry,<\/p>\n
    Stap 3 \u2013 we starten Kubernetes<\/h4>\n
    \nEr zijn veel manieren om de Kubernetes-configuratie voor het draaien van onze \"Hello World\" samen te stellen, maar we zullen de eenvoudigste gebruiken, want zo zijn we...<\/p>\n
    We starten met het opzetten van de minikube-cluster:<\/p>\n
    minikube start\n<\/code><\/pre>\n
    <\/p>\n
    Stap 4 \u2013 we zetten ons containerbeeld uit<\/h4>\n
    \nNu moeten we onze code en het containerbeeld omzetten naar Kubernetes-configuraties. Met andere woorden, we hebben een pod en deployment-definitie nodig die verwijst naar ons containerbeeld op Docker Hub. Een van de eenvoudigste manieren om dit te doen, is door het commando create deployment uit te voeren en ons beeld op te geven:<\/p>\n
    \"Sorry,<\/p>\n
    kubectl create deployment hello-quarkus --image=gcolman\/quarkus-hello-world:1.0.0-SNAPSHOT\n<\/code><\/pre>\n
    \nMet dit commando hebben we onze K8s gezegd dat het een deployment-configuratie moet maken, die een pod-specificatie voor ons containerbeeld moet bevatten. Dit commando past ook deze configuratie toe op onze minikube-cluster en cre\u00ebert een deployment die ons containerbeeld downloadt en een pod in de cluster opstart.<\/p>\n
    Stap 5 \u2013 we openen toegang tot onze service<\/h4>\n
    \nNu we een uitgerold containerbeeld hebben, is het tijd om te denken aan hoe we externe toegang kunnen configureren tot deze RESTful-service, die in feite in onze code is geprogrammeerd.<\/p>\n
    Er zijn veel manieren om dit te doen. We kunnen bijvoorbeeld het commando expose gebruiken om automatisch de benodigde Kubernetes-componenten zoals services en endpoints te cre\u00ebren. Dat is precies wat we gaan doen door het expose-commando voor ons deployment object uit te voeren:<\/p>\n
    kubectl expose deployment hello-quarkus --type=NodePort --port=8080\n<\/code><\/pre>\n
    \nLaten we even stilstaan bij de optie \"--type\" van het expose-commando.<\/p>\n
    Wanneer we expose maken en de noodzakelijke componenten cre\u00ebren om onze service uit te voeren, moeten we, onder andere, ervoor zorgen dat we van buitenaf verbinding kunnen maken met de hello-quarkus service, die zich binnen ons softwaregedefinieerde netwerk bevindt. En de parameter type<\/b> maakt het mogelijk om dingen zoals load balancers aan te maken en verbinding te maken met dat netwerk.<\/p>\n
    Bijvoorbeeld, door te specificeren type=LoadBalancer<\/b>, initialiseren we automatisch een load balancer in de openbare cloud om verbinding te maken met onze Kubernetes-cluster. Dit is natuurlijk geweldig, maar we moeten begrijpen dat deze configuratie stevig is verbonden aan een specifieke openbare cloud en moeilijker te migreren zal zijn tussen Kubernetes-instanties in verschillende omgevingen.<\/p>\n
    In ons voorbeeld type=NodePort<\/b>, dat wil zeggen dat de toegang tot onze service verloopt via het IP-adres van de node en het poortnummer. Deze optie maakt het mogelijk om geen gebruik te maken van publieke clouds, maar vereist een aantal extra stappen. Ten eerste is er een eigen load balancer nodig, dus we zullen een load balancer NGINX in onze cluster opzetten.<\/p>\n
    Stap 6 - Laten we de load balancer opzetten<\/h4>\n
    \nMinikube heeft verschillende platformfuncties die het cre\u00ebren van de benodigde componenten voor externe toegang vergemakkelijken, zoals ingress-controllers. Minikube wordt geleverd met de Nginx ingress-controller, en we hoeven deze alleen maar in te schakelen en te configureren.<\/p>\n
    minikube addons enable ingress\n<\/code><\/pre>\n
    \nNu cre\u00ebren we met \u00e9\u00e9n commando de Nginx ingress-controller, die binnen onze minikube-cluster zal draaien:<\/p>\n
    ingress-nginx-controller-69ccf5d9d8-j5gs9 1\/1 Running 1 33m\n<\/code><\/pre>\n
    <\/p>\n
    Stap 7 - We configureren de ingress<\/h4>\n
    \nNu moeten we de Nginx ingress-controller configureren, zodat deze de verzoeken naar hello-quarkus kan verwerken.<\/p>\n
    \"Sorry,<\/p>\n
    \"Sorry,<\/p>\n
    En tot slot moeten we deze configuratie toepassen.<\/p>\n
    \"Sorry,<\/p>\n
    kubectl apply -f ingress.yml\n<\/code><\/pre>\n
    \"Sorry,<\/p>\n
    Omdat we dit allemaal op onze computer doen, voegen we eenvoudigweg het IP-adres van onze node toe aan het bestand \/etc\/hosts, zodat http-verzoeken naar onze minikube naar de load balancer NGINX worden geleid.<\/p>\n
    192.168.99.100 hello-quarkus.info\n<\/code><\/pre>\n
    \nDat is het, nu is onze minikube-service extern toegankelijk via de Nginx ingress-controller.<\/p>\n
    \"Sorry,<\/p>\n
    Nou, dat was toch eenvoudig, nietwaar? Of niet echt?<\/h3>\n
    \"Sorry,<\/p>\n
    Laten we het uitrollen op OpenShift (Code Ready Containers)<\/h3>\n
    \nLaten we eens bekijken hoe dit allemaal werkt op het Red Hat OpenShift Container Platform (OCP).<\/p>\n
    Net als bij minikube kiezen we voor de enkel-node clusterconfiguratie van OpenShift in de vorm van Code Ready Containers (CRC). Dit heette eerder minishift en was gebaseerd op het OpenShift Origin-project, en nu is het CRC, gebouwd op het Red Hat OpenShift Container Platform.<\/p>\n
    Hier kunnen we het niet laten om te zeggen: \"OpenShift is prachtig!\"<\/p>\n
    Oorspronkelijk dachten we te schrijven dat de ontwikkeling op OpenShift niet verschilt van de ontwikkeling op Kubernetes. En in wezen is dat ook zo. Maar tijdens het schrijven van deze post herinnerden we ons hoeveel extra stappen er nodig zijn als je geen OpenShift hebt, en daarom is het, herhaal ik, prachtig. We houden ervan als alles eenvoudig is, en de manier waarop ons voorbeeld op OpenShift veel eenvoudiger wordt uitgerold en gestart in vergelijking met minikube, motiveerde ons om deze post te schrijven.<\/p>\n
    Laten we het proces doorlopen en kijken wat we nodig hebben.<\/p>\n
    Dus, in het minikube-voorbeeld zijn we begonnen met Docker... Stop, we hebben niet meer nodig dat Docker op de machine is ge\u00efnstalleerd.<\/p>\n
    En lokale git hebben we niet nodig.
    \nMaven is ook niet nodig.
    \nEn we hoeven geen containerimage handmatig te maken.
    \nEn we hoeven geen enkele containerimage repository te zoeken.
    \nEn we hoeven geen ingress-controller te installeren.
    \nEn we hoeven ook geen ingress te configureren.<\/b><\/p>\n
    Begrijp je het? Om onze applicatie op OpenShift te implementeren en uit te voeren, is niets van het bovenstaande nodig. En het proces ziet er als volgt uit.<\/p>\n
    Stap 1 \u2013 Start je OpenShift-cluster<\/h4>\n
    \nWe gebruiken Code Ready Containers van Red Hat, dat in wezen dezelfde is als Minikube, maar met een volledige enkele-node OpenShift-cluster.<\/p>\n
    crc start\n<\/code><\/pre>\n
    <\/p>\n
    Stap 2 \u2013 Bouw en implementeer de applicatie in het OpenShift-cluster<\/h4>\n
    \nOp deze stap komen de eenvoud en het gemak van OpenShift helemaal tot uiting. Zoals in alle Kubernetes-distributies hebben we veel manieren om een applicatie in het cluster te starten. En, net als in het geval van K8s, kiezen we opzettelijk de aller eenvoudigste.<\/p>\n
    OpenShift is altijd gebouwd als een platform voor het cre\u00ebren en uitvoeren van containerapplicaties. Het bouwen van containers is altijd een integraal onderdeel van dit platform geweest, dus er zijn hier tal van extra Kubernetes-resources voor de relevante taken.<\/p>\n
    We zullen het OpenShift-proces Source 2 Image (S2I) gebruiken, dat verschillende manieren heeft om onze bron (code of binaire bestanden) om te zetten in een containerafbeelding die in de OpenShift-cluster draait.<\/p>\n
    Hiervoor hebben we twee dingen nodig:<\/p>\n