{"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\/da\/blog\/administrirovanie\/prosti-openshift-my-nedostatochno-czenili-tebya-i-prinimali-kak-dolzhnoe","title":{"rendered":"Undskyld, OpenShift, vi har ikke v\u00e6rdsat dig nok og har taget dig for givet","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Dette indl\u00e6g er skrevet, fordi vores medarbejdere har haft en del samtaler med kunder om app-udvikling p\u00e5 Kubernetes og de specifikke aspekter ved denne udvikling p\u00e5 OpenShift.<\/p>\n

\"Undskyld,
\n
\nVi starter ofte med tesen, at Kubernetes er bare Kubernetes, mens OpenShift er en Kubernetes-platform, ligesom Microsoft AKS eller Amazon EKS. Hver af disse platforme har sine fordele, rettet mod forskellige m\u00e5lgrupper. Og derefter flyder samtalen over i en sammenligning af styrker og svagheder ved de konkrete platforme.
\n<\/a><\/noindex>
\nGenerelt t\u00e6nkte vi at skrive dette indl\u00e6g med konklusionen, \"H\u00f8r her, det er ligegyldigt, hvor du k\u00f8rer koden, p\u00e5 OpenShift, AKS, EKS eller p\u00e5 en hvilken som helst specialbygget Kubernetes, ja, p\u00e5 hvilken som helst Kubernetes. (for kortheds skyld kalder vi det KUK)<\/i> \u2013 det er faktisk ret simpelt, begge steder.\"<\/p>\n

Derefter planlagde vi at tage en simpel \"Hello World\" og vise, hvad der er f\u00e6lles og hvor der er forskelle mellem KUK og Red Hat OpenShift Container Platform (herefter OCP eller blot OpenShift).<\/p>\n

Men mens vi skrev dette indl\u00e6g, inds\u00e5 vi, at vi p\u00e5 s\u00e5 mange m\u00e5der er blevet s\u00e5 vant til at bruge OpenShift, at vi simpelthen ikke er klar over, hvordan det er vokset og blevet en fantastisk platform, der er blevet meget mere end bare en Kubernetes-distribution. Vi har taget OpenShifts modenhed og enkelhed for givet og overset dets storhed.<\/p>\n

Generelt er det tid til forsoning, og nu vil vi trin-for-trin sammenligne implementeringen af vores \"Hello World\" p\u00e5 KUK og OpenShift og g\u00f8re det s\u00e5 objektivt som muligt (mediens vi nogle gange viser personlig holdning til emnet). Hvis du er interesseret i en rent subjektiv mening om dette emne, kan den l\u00e6ses her (EN)<\/a><\/noindex>. I dette indl\u00e6g holder vi os til fakta og kun fakta.<\/p>\n

Klynger<\/h3>\n

\nS\u00e5 til vores \"Hello World\" har vi brug for klynger. Lad os straks sige \"nej\" til offentlige skyer for ikke at betale for servere, registre, netv\u00e6rk, dataoverf\u00f8rsel osv. Derfor v\u00e6lger vi en simpel enkelt-nodeklynge p\u00e5 Minikube<\/a><\/noindex> (til KUK) og Code Ready Containers<\/a><\/noindex> (til OpenShift-klyngen). Begge disse muligheder er ret nemme at installere, men kr\u00e6ver en del ressourcer p\u00e5 din b\u00e6rbare computer.<\/p>\n

\"Undskyld,<\/p>\n

Bygning p\u00e5 KUK<\/h3>\n

\nS\u00e5 lad os komme i gang.<\/p>\n

Trin 1 \u2013 vi opbygger vores containerbillede<\/h4>\n

\nJeg starter med at deployere vores \"Hello World\" p\u00e5 minikube. Til dette vil vi f\u00e5 brug for:<\/p>\n

    \n
  1. 1. Installeret Docker.<\/li>\n
  2. 2. Installeret Git.<\/li>\n
  3. 3. Installeret Maven (faktisk bruger dette projekt mvnw-bin\u00e6ren, s\u00e5 dette kan undlades).<\/li>\n
  4. 4. Selve kilden, alts\u00e5 klon af repository'et. github.com\/gcolman\/quarkus-hello-world.git<\/a><\/noindex><\/li>\n<\/ol>\n

    \nF\u00f8rst skal vi oprette et Quarkus-projekt. Bliv ikke skr\u00e6mt, hvis du aldrig har arbejdet med Quarkus.io \u2013 det er let. Du v\u00e6lger bare de komponenter, du \u00f8nsker at bruge i projektet (RestEasy, Hibernate, Amazon SQS, Camel osv.), og s\u00e5 konfigurerer Quarkus selv archetypen mvn og uploader alt til GitHub. S\u00e5 det er bogstaveligt talt et enkelt klik med musen \u2013 og det er klar. Det er netop derfor, vi elsker Quarkus.<\/p>\n

    \"Undskyld,<\/p>\n

    Den nemmeste m\u00e5de at bygge vores \"Hello World\" i en containerbillede er at bruge quarkus-maven-udvidelserne til Docker, som klarer alt det n\u00f8dvendige arbejde. Med Quarkus er det virkelig blevet let og enkelt: tilf\u00f8j udvidelsen container-image-docker, og du kan oprette billeder med mvn-kommandoer.<\/p>\n

    .\/mvnw quarkus:add-extension -Dextensions=\"container-image-docker\"\n<\/code><\/pre>\n
    \nOg endelig bygger vi vores billede ved hj\u00e6lp af Maven. Resultatet er, at vores kildekode bliver til et klart containerbillede, som allerede kan k\u00f8res i containerudf\u00f8relsesmilj\u00f8et.<\/p>\n
    \"Undskyld,<\/p>\n
    .\/mvnw -X clean package -Dquarkus.container-image.build=true\n<\/code><\/pre>\n
    \nOg der har vi det, nu kan vi k\u00f8re containeren med kommandoen docker run, ved at kortl\u00e6gge vores service til port 8080, s\u00e5 den kan tilg\u00e5s.<\/p>\n
    docker run -i --rm -p 8080:8080 gcolman\/quarkus-hello-world\n<\/code><\/pre>\n
    \"Undskyld,<\/p>\n
    N\u00e5r container-instansen er startet, er det kun at kontrollere med kommandoen curl, om vores service k\u00f8rer:<\/p>\n
    \"Undskyld,<\/p>\n
    S\u00e5, det fungerer, og det var virkelig let og enkelt.<\/p>\n
    Trin 2 \u2013 sender vores container til containerbillede-repositoriet.<\/h4>\n
    \nIndtil videre opbevares det billede, vi har oprettet, lokalt i vores lokale containerlager. Hvis vi vil bruge dette billede i vores K8s-milj\u00f8, skal det placeres i et andet repository. Kubernetes har ikke denne funktion, s\u00e5 vi vil bruge Docker Hub. Fordi for det f\u00f8rste er det gratis, og for det andet (n\u00e6sten) alle g\u00f8r det.<\/p>\n
    Det er ogs\u00e5 meget enkelt, og her er der kun brug for en konto p\u00e5 Docker Hub.<\/p>\n
    S\u00e5, lad os tilf\u00f8je Docker Hub og sende vores billede derop.<\/p>\n
    \"Undskyld,<\/p>\n
    Trin 3 \u2013 starter Kubernetes.<\/h4>\n
    \nDer er mange m\u00e5der at samle Kubernetes-konfigurationen til at k\u00f8re vores \"Hello World\", men vi vil bruge den letteste af dem, vi er s\u00e5dan nogle mennesker...<\/p>\n
    Lad os starte med at k\u00f8re minikube-klister:<\/p>\n
    minikube start\n<\/code><\/pre>\n
    <\/p>\n
    Trin 4 \u2013 udl\u00e6gger vores containerbillede<\/h4>\n
    \nNu skal vi konvertere vores kode og containerbillede til Kubernetes-konfigurationer. Med andre ord, vi har brug for en pod- og deployment-definition, der henviser til vores containerbillede p\u00e5 Docker Hub. En af de nemmeste m\u00e5der at g\u00f8re dette p\u00e5 er at k\u00f8re kommandoen create deployment og angive vores billede:<\/p>\n
    \"Undskyld,<\/p>\n
    kubectl create deployment hello-quarkus --image=gcolman\/quarkus-hello-world:1.0.0-SNAPSHOT\n<\/code><\/pre>\n
    \nMed denne kommando har vi sagt til vores KUBE at skabe en deployment-konfiguration, der skal indeholde specifikationen af pod'en for vores containerbillede. Denne kommando anvender ogs\u00e5 denne konfiguration p\u00e5 vores Minikube-klynge og opretter en deployment, der downloader vores containerbillede og starter en pod i klyngen.<\/p>\n
    Trin 5 \u2013 \u00e5bner adgang til vores service<\/h4>\n
    \nNu hvor vi har et udrullet containerbillede, er det tid til at overveje, hvordan vi konfigurerer ekstern adgang til denne RESTful-service, som faktisk er programmeret i vores kode.<\/p>\n
    Der er mange m\u00e5der at g\u00f8re dette p\u00e5. For eksempel kan vi bruge kommandoen expose til automatisk at skabe de relevante Kubernetes-komponenter, s\u00e5som services og endpoints. Faktisk vil vi g\u00f8re netop dette ved at k\u00f8re expose-kommandoen for vores deployment-objekt:<\/p>\n
    kubectl expose deployment hello-quarkus --type=NodePort --port=8080\n<\/code><\/pre>\n
    \nLad os tage et \u00f8jeblik til at stoppe op ved optionen \"--type\" i expose-kommandoen.<\/p>\n
    N\u00e5r vi laver expose og skaber de komponenter, der er n\u00f8dvendige for at k\u00f8re vores service, skal vi blandt andet s\u00f8rge for, at vi kan tilslutte til service hello-quarkus, som er inde i vores softwaredefinerede netv\u00e6rk. Og parameteren type<\/b> giver os mulighed for at oprette og forbinde ting som belastningsafbalancere, s\u00e5 trafikken kan rutes til dette netv\u00e6rk.<\/p>\n
    For eksempel, ved at angive type=LoadBalancer<\/b>, initierer vi automatisk en belastningsafbalancer i det offentlige cloud for at tilslutte til vores Kubernetes-klynge. Dette er selvf\u00f8lgelig fantastisk, men det er vigtigt at forst\u00e5, at en s\u00e5dan konfiguration vil v\u00e6re stift knyttet til en bestemt offentlig cloud og vil v\u00e6re sv\u00e6rere at flytte mellem Kubernetes-instanser i forskellige milj\u00f8er.<\/p>\n
    I vores eksempel type=NodePort<\/b>, hvilket betyder, at anmodningen til vores service g\u00e5r via IP-adressen p\u00e5 noden og portnummeret. Denne l\u00f8sning kr\u00e6ver ikke brug af offentlige skyer, men kr\u00e6ver en r\u00e6kke ekstra skridt. For det f\u00f8rste har vi brug for en egen load balancer, s\u00e5 vi vil implementere en NGINX load balancer i vores klynge.<\/p>\n
    Trin 6 - Installerer load balancer<\/h4>\n
    \nMinikube har en r\u00e6kke platformfunktioner, der g\u00f8r det lettere at oprette de n\u00f8dvendige komponenter til ekstern adgang, som f.eks. ingress- controllere. Minikube leveres med en Nginx ingress-controller, og vi skal bare aktivere og konfigurere den.<\/p>\n
    minikube addons enable ingress\n<\/code><\/pre>\n
    \nNu genererer vi med et enkelt kommando en Nginx ingress-controller, som vil k\u00f8re inden i vores minikube klynge:<\/p>\n
    ingress-nginx-controller-69ccf5d9d8-j5gs9 1\/1 K\u00f8rer 1 33m\n<\/code><\/pre>\n
    <\/p>\n
    Trin 7 - Konfigurerer ingress<\/h4>\n
    \nNu skal vi konfigurere Nginx ingress-controlleren, s\u00e5 den kan h\u00e5ndtere anmodninger til hello-quarkus.<\/p>\n
    \"Undskyld,<\/p>\n
    \"Undskyld,<\/p>\n
    Og til sidst skal vi anvende denne konfiguration.<\/p>\n
    \"Undskyld,<\/p>\n
    kubectl apply -f ingress.yml\n<\/code><\/pre>\n
    \"Undskyld,<\/p>\n
    Da vi g\u00f8r alt dette p\u00e5 vores egen computer, tilf\u00f8jer vi blot IP-adressen til vores node i filen \/etc\/hosts for at dirigere http-anmodninger til vores minikube via NGINX load balancer.<\/p>\n
    192.168.99.100 hello-quarkus.info\n<\/code><\/pre>\n
    \nNu er vores minikube service tilg\u00e6ngelig udefra gennem Nginx ingress-controlleren.<\/p>\n
    \"Undskyld,<\/p>\n
    N\u00e5, det var da nemt, ikke? Eller m\u00e5ske ikke s\u00e5 meget?<\/h3>\n
    \"Undskyld,<\/p>\n
    K\u00f8rsel p\u00e5 OpenShift (Code Ready Containers)<\/h3>\n
    \nOg nu lad os se, hvordan det hele g\u00f8res p\u00e5 Red Hat OpenShift Container Platform (OCP).<\/p>\n
    Som med minikube v\u00e6lger vi en en-nodesklynge OpenShift ops\u00e6tning i form af Code Ready Containers (CRC). Tidligere kaldte man det minishift, og det var baseret p\u00e5 OpenShift Origin-projektet, men nu er det CRC, bygget p\u00e5 Red Hats OpenShift Container Platform.<\/p>\n
    Her kan vi, undskyld, ikke lade v\u00e6re med at sige: \"OpenShift er fantastisk!\"<\/p>\n
    I starten t\u00e6nkte vi at skrive, at udvikling p\u00e5 OpenShift ikke adskiller sig fra udvikling p\u00e5 Kubernetes. Og det er i princippet korrekt. Men mens vi skrev dette indl\u00e6g kom vi i tanker om, hvor mange un\u00f8dvendige skridt man skal tage, n\u00e5r man ikke har OpenShift, og derfor er det, som vi gentager, fantastisk. Vi elsker, n\u00e5r tingene er enkle, og hvor let vores eksempel kan implementeres og startes p\u00e5 OpenShift i forhold til minikube, er faktisk det, der inspirerede os til at skrive dette indl\u00e6g.<\/p>\n
    Lad os kaste et blik p\u00e5 processen og se, hvad vi skal g\u00f8re.<\/p>\n
    S\u00e5 i eksemplet med minikube startede vi med Docker... Stop, vi har ikke brug for, at Docker er installeret p\u00e5 maskinen l\u00e6ngere.<\/p>\n
    Og lokal git er ikke n\u00f8dvendigt.
    \nOg Maven er heller ikke n\u00f8dvendigt.
    \nOg det er ikke n\u00f8dvendigt at oprette containerbilleder manuelt.
    \nOg det er ikke n\u00f8dvendigt at finde et containerbillede-repositorium.
    \nOg det er ikke n\u00f8dvendigt at installere en ingress-controller.
    \nOg konfiguration af ingress er heller ikke n\u00f8dvendigt.<\/b><\/p>\n
    Forstod du det, ikke? For at implementere og k\u00f8re vores applikation p\u00e5 OpenShift, er intet af ovenst\u00e5ende n\u00f8dvendigt. Selve processen ser s\u00e5dan her ud.<\/p>\n
    Trin 1 \u2013 Start dit OpenShift-kluster<\/h4>\n
    \nVi bruger Code Ready Containers fra Red Hat, som i bund og grund er det samme som Minikube, men med et fuldt funktionelt enkelt-node OpenShift-kluster.<\/p>\n
    crc start\n<\/code><\/pre>\n
    <\/p>\n
    Trin 2 \u2013 Byg og implementer applikationen i OpenShift-klusteret<\/h4>\n
    \nNetop p\u00e5 dette trin kommer enkelheden og bekvemmeligheden ved OpenShift virkelig til sin ret. Som med alle Kubernetes-distributioner har vi mange m\u00e5der at k\u00f8re applikationen i klusteret p\u00e5. Og som med KUK v\u00e6lger vi bevidst den absolut enkleste metode.<\/p>\n
    OpenShift har altid v\u00e6ret bygget som en platform til at skabe og k\u00f8re containerapplikationer. Bygningen af containere har altid v\u00e6ret en uadskillelig del af denne platform, s\u00e5 der er en masse yderligere Kubernetes-ressourcer til relevante opgaver.<\/p>\n
    Vi vil bruge OpenShift's Source 2 Image (S2I) proces, som har flere forskellige m\u00e5der at tage vores kilde (kode eller bin\u00e6re filer) og omdanne det til et containerbillede, der kan k\u00f8re i OpenShift-klusteret.<\/p>\n
    For dette har vi brug for to ting:<\/p>\n