Aquesta publicació es va escriure perquè el nostre personal va tenir moltes converses amb clients sobre el desenvolupament d'aplicacions a Kubernetes i els detalls d'aquest desenvolupament a OpenShift.
Normalment comencem amb la tesi que Kubernetes és només Kubernetes, i OpenShift ja és una plataforma Kubernetes, com Microsoft AKS o Amazon EKS. Cadascuna d'aquestes plataformes té els seus propis avantatges, enfocades a un públic objectiu concret. I després d'això, la conversa ja desemboca en una comparació dels punts forts i febles de plataformes específiques.
En general, hem pensat escriure aquesta publicació amb una sortida com "Escolta, no importa on executes el codi, a OpenShift o a AKS, a EKS, a alguns Kubernetes personalitzats, sí a qualsevol Kubernetes. (anomenarem-lo KUK per abreujar-lo) "És molt senzill, tant allà com allà".
A continuació, vam planejar agafar el "Hello World" més senzill i utilitzar-lo per mostrar què és comú i quines són les diferències entre el CMC i la plataforma de contenidors Red Hat OpenShift (d'ara endavant, OCP o simplement OpenShift).
Tanmateix, en el curs d'escriure aquesta publicació, ens hem adonat que ens hem acostumat tant a utilitzar OpenShift que simplement no ens adonem de com ha crescut i s'ha convertit en una plataforma sorprenent que s'ha convertit en molt més que una distribució de Kubernetes. Tenim tendència a donar per feta la maduresa i la senzillesa d'OpenShift, tot passant per alt la seva magnificència.
En general, ha arribat el moment del penediment actiu, i ara compararem pas a pas la posada en marxa del nostre "Hello World" a KUK i a OpenShift, i ho farem de la manera més objectiva possible (bé, potser de vegades mostrant un actitud davant el tema). Si us interessa una opinió purament subjectiva sobre aquest tema, podeu llegir-la . I en aquest post ens atenem als fets i només als fets.
Clústers
Per tant, el nostre "Hello World" necessita grups. Diguem "no" a qualsevol núvol públic, per no pagar servidors, registres, xarxes, transferència de dades, etc. En conseqüència, escollim un clúster simple d'un node (per a KUK) i (per a un clúster OpenShift). Ambdues opcions són molt fàcils d'instal·lar, però requereixen molts recursos al vostre ordinador portàtil.
Muntatge a KUK-e
Així que anem.
Pas 1 - Creació de la nostra imatge de contenidor
Comencem desplegant el nostre "Hello World" a minikube. Això requerirà:
- 1. Docker instal·lat.
- 2. Git instal·lat.
- 3. S'ha instal·lat Maven (en realitat, aquest projecte utilitza mvnw binary, de manera que podeu prescindir-ne).
- 4. En realitat, la pròpia font, és a dir. clon del repositori
El primer pas és crear un projecte Quarkus. No us espanteu si mai no heu utilitzat Quarkus.io: és fàcil. Només heu de seleccionar els components que voleu utilitzar al projecte (RestEasy, Hibernate, Amazon SQS, Camel, etc.), i després el mateix Quarkus, sense la vostra participació, configura l'arquetip maven i ho posa tot a github. És a dir, literalment un clic del ratolí, i ja està. Per això ens encanta Quarkus.
La manera més senzilla de crear el nostre "Hello World" en una imatge en contenidors és utilitzar les extensions quarkus-maven per a Docker, que farà tot el treball necessari. Amb l'arribada de Quarkus, això s'ha tornat molt fàcil i senzill: afegiu l'extensió container-image-docker i podreu crear imatges amb ordres maven.
./mvnw quarkus:add-extension -Dextensions=”container-image-docker”
I finalment, construïm la nostra imatge amb Maven. Com a resultat, el nostre codi font es converteix en una imatge de contenidor preparada, que ja es pot executar en el temps d'execució del contenidor.
./mvnw -X clean package -Dquarkus.container-image.build=true
Això, de fet, és tot, ara podeu executar el contenidor amb l'ordre docker run, havent mapejat el nostre servei al port 8080 perquè s'hi pugui accedir.
docker run -i — rm -p 8080:8080 gcolman/quarkus-hello-world
Un cop iniciat la instància del contenidor, només queda comprovar amb l'ordre curl que el nostre servei s'està executant:
Per tant, tot funciona, i va ser molt fàcil i senzill.
Pas 2: envieu el nostre contenidor al dipòsit d'imatges del contenidor
De moment, la imatge que hem creat s'emmagatzema localment al nostre emmagatzematge de contenidors local. Si volem utilitzar aquesta imatge al nostre entorn KUK, hem de posar-la en un altre dipòsit. Kubernetes no té aquestes característiques, per la qual cosa farem servir dockerhub. Perquè, en primer lloc, és gratuït i, en segon lloc, ho fa (quasi) tothom.
Això també és molt senzill i aquí només cal un compte dockerhub.
Per tant, instal·lem dockerhub i hi enviem la nostra imatge.
Pas 3: inicieu Kubernetes
Hi ha moltes maneres de muntar una configuració de kubernetes per executar el nostre "Hello World", però utilitzarem la més senzilla d'elles, perquè som aquestes persones...
Primer, iniciem el clúster minikube:
minikube start
Pas 4: desplegament de la nostra imatge de contenidor
Ara hem de convertir el nostre codi i la imatge del contenidor a la configuració de kubernetes. En altres paraules, necessitem un pod i una definició de desplegament que apunti a la nostra imatge de contenidor a dockerhub. Una de les maneres més fàcils de fer-ho és executar l'ordre create deployment que apunta a la nostra imatge:
kubectl create deployment hello-quarkus — image =gcolman/quarkus-hello-world:1.0.0-SNAPSHOT
Amb aquesta ordre, vam dir al nostre COOK que creés una configuració de desplegament, que hauria de contenir l'especificació del pod per a la nostra imatge de contenidor. Aquesta ordre també aplicarà aquesta configuració al nostre clúster minikube i crearà un desplegament que baixarà la nostra imatge de contenidor i executarà un pod al clúster.
Pas 5: obre l'accés al nostre servei
Ara que tenim una imatge de contenidor desplegada, és hora de pensar com configurar l'accés extern a aquest servei Restful, que, de fet, està programat al nostre codi.
Aquí hi ha moltes maneres. Per exemple, podeu utilitzar l'ordre expose per crear automàticament components de Kubernetes adequats, com ara serveis i punts finals. De fet, això és el que farem executant l'ordre expose per al nostre objecte de desplegament:
kubectl expose deployment hello-quarkus — type=NodePort — port=8080
Anem a detenir-nos un moment en l'opció "-type" de l'ordre expose.
Quan exposem i creem els components necessaris per executar el nostre servei, necessitem, entre altres coses, poder connectar-nos des de l'exterior al servei hello-quarkus que es troba dins de la nostra xarxa definida per programari. I paràmetre type ens permet crear i connectar coses com ara equilibradors de càrrega per encaminar el trànsit a aquesta xarxa.
Per exemple, escriure tipus=LoadBalancer, inicialitzem automàticament l'equilibrador de càrrega del núvol públic per connectar-se al nostre clúster de Kubernetes. Això, per descomptat, és fantàstic, però cal entendre que aquesta configuració estarà estretament lligada a un núvol públic específic i serà més difícil transferir-la entre instàncies de Kubernetes en diferents entorns.
En el nostre exemple tipus=NodePort, és a dir, la trucada al nostre servei passa per l'adreça IP del node i el número de port. Aquesta opció us permet no utilitzar cap núvol públic, però requereix una sèrie de passos addicionals. Primer, necessiteu el vostre propi equilibrador de càrrega, de manera que implementarem l'equilibrador de càrrega NGINX al nostre clúster.
Pas 6: configureu un equilibrador de càrrega
minikube té una sèrie de funcions de plataforma que faciliten la creació dels components que necessiteu per a l'accés extern, com ara controladors d'entrada. Minikube ve inclòs amb el controlador d'entrada Nginx i tot el que hem de fer és habilitar-lo i configurar-lo.
minikube addons enable ingress
Ara, amb només una ordre, crearem un controlador d'entrada Nginx que funcionarà dins del nostre clúster minikube:
ingress-nginx-controller-69ccf5d9d8-j5gs9 1/1 Running 1 33m
Pas 7: configureu l'entrada
Ara hem de configurar el controlador d'entrada Nginx per acceptar sol·licituds de hello-quarkus.
I finalment, hem d'aplicar aquesta configuració.
kubectl apply -f ingress.yml
Com que estem fent tot això a la nostra pròpia màquina, simplement afegim l'adreça IP del nostre node al fitxer /etc/hosts per tal de dirigir les sol·licituds http al nostre minikube a l'equilibrador de càrrega NGINX.
192.168.99.100 hello-quarkus.info
Això és tot, ara el nostre servei minikube està disponible des de l'exterior mitjançant el controlador d'entrada Nginx.
Bé, va ser fàcil, oi? O no tant?
Executar a OpenShift (contenidors preparats per a codi)
I ara vegem com es fa tot a la plataforma de contenidors OpenShift de Red Hat (OCP).
Com en el cas de minikube, escollim un esquema amb un clúster OpenShift d'un sol node en forma de contenidors preparats per a codi (CRC). Abans es deia minishift i es basava en el projecte OpenShift Origin, però ara és CRC i es basa en la plataforma de contenidors OpenShift de Red Hat.
Aquí, ho sento, no podem evitar dir: "OpenShift és fantàstic!"
Inicialment, vam pensar que el desenvolupament a OpenShift no és diferent del desenvolupament a Kubernetes. I, de fet, és així. Però en el procés d'escriure aquesta entrada, hem recordat quants moviments innecessaris has de fer quan no tens OpenShift, i per tant, de nou, és bonic. Ens encanta que les coses siguin fàcils, i el fàcil que és desplegar i executar el nostre exemple a OpenShift en comparació amb minikube és el que ens va inspirar a escriure aquesta publicació.
Repassem el procés i veurem què hem de fer.
Així, a l'exemple de minikube, vam començar amb Docker... Espereu, ja no necessitem instal·lar Docker a la màquina.
I no necessitem un git local.
I Maven no és necessari.
I no cal que creeu una imatge de contenidor a mà.
I no cal que busqueu cap repositori d'imatges de contenidors.
I no cal que instal·leu un controlador d'entrada.
I tampoc cal que configureu l'entrada.
Entens? Per implementar i executar la nostra aplicació a OpenShift, no cal cap de les anteriors. I el procés en si és el següent.
Pas 1: inicieu el vostre clúster OpenShift
Utilitzem Code Ready Containers de Red Hat, que és essencialment el mateix Minikube, però només amb un clúster Openshift complet d'un sol node.
crc start
Pas 2: creeu i implementeu l'aplicació al clúster OpenShift
És en aquest pas on la senzillesa i la comoditat d'OpenShift es manifesta amb tota la seva glòria. Com passa amb totes les distribucions de Kubernetes, tenim moltes maneres d'executar una aplicació en un clúster. I, com en el cas de KUK, escollim específicament el més senzill.
OpenShift sempre s'ha creat com una plataforma per crear i executar aplicacions en contenidors. Construir contenidors sempre ha estat una part integral d'aquesta plataforma, de manera que hi ha un munt de recursos addicionals de Kubernetes per a les tasques corresponents.
Utilitzarem el procés Source 2 Image (S2I) d'OpenShift, que té diverses maneres diferents d'agafar el nostre codi font (codi o binaris) i convertir-lo en una imatge en contenidors que s'executa en un clúster OpenShift.
Per a això necessitem dues coses:
- El nostre codi font al repositori git
- Imatge del constructor, a partir de la qual es realitzarà el muntatge.
Hi ha moltes imatges d'aquest tipus, mantingudes tant per Red Hat com per la comunitat, i utilitzarem la imatge OpenJDK, bé, ja que estic construint una aplicació Java.
Podeu executar una compilació S2I tant des de la consola gràfica de l'OpenShift Developer com des de la línia d'ordres. Utilitzarem l'ordre new-app, indicant-li on aconseguir la imatge del constructor i el nostre codi font.
oc new-app registry.access.redhat.com/ubi8/openjdk-11:latest~https://github.com/gcolman/quarkus-hello-world.git
Això és tot, la nostra aplicació està creada. En fer-ho, el procés S2I va fer les coses següents:
- S'ha creat un servei build-pod per a tot tipus de coses relacionades amb la creació de l'aplicació.
- S'ha creat una configuració de compilació d'OpenShift.
- Vaig baixar la imatge del constructor al registre intern d'OpenShift Docker.
- S'ha clonat "Hello World" al repositori local.
- Vaig veure que hi havia un maven pom allà dins i així que vaig compilar l'aplicació amb Maven.
- S'ha creat una imatge de contenidor nova que conté l'aplicació Java compilada i s'ha posat aquesta imatge al registre de contenidors intern.
- S'ha creat un desplegament de Kubernetes amb especificacions per a un pod, servei, etc.
- S'ha llançat la imatge del contenidor de desplegament.
- S'ha eliminat el servei build-pod.
Hi ha moltes coses en aquesta llista, però el més important és que tota la construcció es realitza exclusivament dins d'OpenShift, el registre intern de Docker es troba dins d'OpenShift i el procés de creació crea tots els components de Kubernetes i els executa al clúster.
Si controleu visualment el llançament de S2I a la consola, podeu veure com s'inicia el pod de compilació durant la compilació.
I ara fem una ullada als registres del pod del constructor: en primer lloc, podeu veure com Maven fa la seva feina i descarrega dependències per construir la nostra aplicació java.
Un cop finalitzada la compilació de maven, s'inicia la creació de la imatge del contenidor i, a continuació, aquesta imatge creada s'envia al dipòsit intern.
Tot, el procés de muntatge està acabat. Ara ens assegurem que els pods i els serveis de la nostra aplicació s'han iniciat al clúster.
oc get service
Això és tot. I només hi ha un equip. L'únic que hem de fer és exposar aquest servei per a l'accés exterior.
Pas 3: feu que el servei estigui exposat per accedir des de l'exterior
Com en el cas de KUK, a la plataforma OpenShift, el nostre "Hello World" també necessita un encaminador per dirigir el trànsit extern a un servei dins del clúster. A OpenShift això ho fa molt fàcil. En primer lloc, el component d'encaminament HAProxy s'instal·la al clúster de manera predeterminada (es pot canviar al mateix NGINX). En segon lloc, hi ha recursos especials i altament configurables anomenats Rutes, que recorden els objectes Ingress a Kubernetes antics (de fet, les Rutes d'OpenShift van influir molt en el disseny dels objectes Ingress, que ara es poden utilitzar a OpenShift), però per al nostre "Hola". World", i en gairebé tots els altres casos, la Ruta estàndard és suficient per a nosaltres sense configuració addicional.
Per crear un FQDN encaminable per a "Hello World" (sí, OpenShiift té el seu propi DNS per a l'encaminament per noms de servei), simplement exposem el nostre servei:
oc expose service quarkus-hello-world
Si mireu la Ruta acabada de crear, hi podreu trobar el FQDN i altra informació d'encaminament:
oc get route
I finalment, accedim al nostre servei des del navegador:
Però ara era molt fàcil!
Ens encanta Kubernetes i tot el que aquesta tecnologia et permet fer, i també ens agrada la senzillesa i la lleugeresa. Kubernetes va ser dissenyat per fer que els contenidors distribuïts i escalables siguin increïblement fàcils d'operar, però la seva senzillesa ja no és suficient per portar aplicacions a la producció actual. Aquí és on entra en joc OpenShift, seguint-se amb els temps i oferint Kubernetes centrat en els desenvolupadors. S'ha invertit molt d'esforç per adaptar la plataforma OpenShift específicament per al desenvolupador, inclosa la creació d'eines com S2I, ODI, Developer Portal, OpenShift Operator Framework, integració IDE, catàlegs de desenvolupadors, integració Helm, monitorització i moltes altres.
Esperem que aquest article us hagi estat interessant i útil. I podeu trobar recursos addicionals, materials i altres coses útils per desenvolupar a la plataforma OpenShift del portal .
Font: www.habr.com