Esta publicación foi escrita porque o noso persoal mantivo bastantes conversas con clientes sobre o desenvolvemento de aplicacións en Kubernetes e as particularidades deste desenvolvemento en OpenShift.
Normalmente comezamos coa tese de que Kubernetes é só Kubernetes, e OpenShift xa é unha plataforma Kubernetes, como Microsoft AKS ou Amazon EKS. Cada unha destas plataformas ten as súas propias vantaxes, dirixidas a un público obxectivo concreto. E despois disto, a conversa pasa a comparar os puntos fortes e débiles de plataformas específicas.
En xeral, pensamos en escribir esta publicación cunha saída como "Escoita, non importa onde executes o código, en OpenShift ou en AKS, en EKS, nalgúns Kubernetes personalizados, si en calquera Kubernetes. (para brevidade chamémoslle KUK) "É moi sinxelo, tanto alí como alí".
Entón planeamos tomar o "Hello World" máis sinxelo e utilizalo para mostrar o que é común e cales son as diferenzas entre a CMC e a plataforma de contedores Red Hat OpenShift (en diante, OCP ou simplemente OpenShift).
Non obstante, ao escribir esta publicación, decatámonos de que estamos tan afeitos a usar OpenShift que simplemente non nos damos conta de como creceu e se converteu nunha plataforma incrible que se converteu en moito máis que unha distribución de Kubernetes. Tendemos a dar por descontada a madurez e a sinxeleza de OpenShift, mentres pasamos por alto a súa magnificencia.
En xeral, chegou o momento do arrepentimento activo, e agora compararemos paso a paso a posta en servizo do noso "Hello World" en KUK e en OpenShift, e farémolo o máis obxectivamente posible (ben, quizais ás veces mostrando un actitude ante o tema). Se che interesa unha opinión puramente subxectiva sobre este tema, podes lela . E neste post aterémonos aos feitos e só aos feitos.
Clústeres
Polo tanto, o noso "Ola mundo" require clusters. Inmediatamente diremos "non" a ningunha nube pública, para non pagar por servidores, rexistros, redes, transferencia de datos, etc. En consecuencia, escollemos un clúster simple dun só nodo (para KUK) e (para clúster OpenShift). Estas dúas opcións son moi fáciles de instalar, pero requirirán moitos recursos no teu portátil.
Montaxe en KUK-e
Entón, imos.
Paso 1: construír a nosa imaxe de contedores
Comecemos por implementar o noso "Hello World" en minikube. Para iso necesitarás:
- 1. Docker instalado.
- 2. Git instalado.
- 3. Instalouse Maven (en realidade, este proxecto usa o binario mvnw, polo que podes prescindir del).
- 4. En realidade, a propia fonte, é dicir. clon do repositorio
O primeiro paso é crear un proxecto Quarkus. Non teñas medo se nunca usaches Quarkus.io: é doado. Só tes que seleccionar os compoñentes que queres usar no proxecto (RestEasy, Hibernate, Amazon SQS, Camel, etc.), e despois o propio Quarkus, sen a túa participación, configura o arquetipo maven e pon todo en github. É dicir, literalmente un clic do rato - e xa está. É por iso que amamos Quarkus.
A forma máis sinxela de construír o noso "Ola mundo" nunha imaxe en contenedores é usar as extensións quarkus-maven para Docker, que farán todo o traballo necesario. Coa chegada de Quarkus, isto fíxose moi sinxelo e sinxelo: engade a extensión container-image-docker e poderás crear imaxes con comandos maven.
./mvnw quarkus:add-extension -Dextensions=”container-image-docker”
Finalmente, construímos a nosa imaxe usando Maven. Como resultado, o noso código fonte convértese nunha imaxe de contedor preparada que xa se pode executar no ambiente de execución do contedor.
./mvnw -X clean package -Dquarkus.container-image.build=true
Isto, de feito, é todo, agora podes executar o contedor co comando docker run, tendo mapeado o noso servizo ao porto 8080 para que se poida acceder a el.
docker run -i — rm -p 8080:8080 gcolman/quarkus-hello-world
Despois de que se inicie a instancia do contedor, só queda comprobar co comando curl que o noso servizo está a executar:
Así que todo funciona e foi moi sinxelo e sinxelo.
Paso 2: envía o noso contedor ao repositorio de imaxes do contedor
Polo momento, a imaxe que creamos almacénase localmente, no noso almacenamento de contedores local. Se queremos empregar esta imaxe no noso entorno COOK, entón hai que colocala nalgún outro repositorio. Kubernetes non ten tales funcións, polo que usaremos dockerhub. Porque, en primeiro lugar, é gratuíto e, en segundo lugar, faino (case) todo o mundo.
Isto tamén é moi sinxelo e só se necesita unha conta dockerhub aquí.
Entón, instalamos dockerhub e enviamos alí a nosa imaxe.
Paso 3: inicia Kubernetes
Hai moitas formas de montar a configuración de kubernetes para executar o noso "Hello World", pero usaremos a máis sinxela delas, así somos...
En primeiro lugar, iniciamos o clúster minikube:
minikube start
Paso 4: implantación da nosa imaxe de contedores
Agora necesitamos converter o noso código e a imaxe do contedor en configuracións de kubernetes. Noutras palabras, necesitamos unha definición de pod e despregamento que apunte á nosa imaxe de contedor en dockerhub. Unha das formas máis sinxelas de facelo é executar o comando create deployment apuntando á nosa imaxe:
kubectl create deployment hello-quarkus — image =gcolman/quarkus-hello-world:1.0.0-SNAPSHOT
Con este comando dixémoslle ao noso COO que crease unha configuración de implantación, que debería conter a especificación do pod para a imaxe do noso contedor. Este comando tamén aplicará esta configuración ao noso clúster de minikube e creará un despregamento que descargará a nosa imaxe de contedor e lanzará o pod no clúster.
Paso 5: abre o acceso ao noso servizo
Agora que temos unha imaxe de contedor despregada, é hora de pensar como configurar o acceso externo a este servizo Restful, que, de feito, está programado no noso código.
Aquí hai moitas maneiras. Por exemplo, pode usar o comando expose para crear automaticamente os compoñentes de Kubernetes axeitados, como servizos e puntos finais. En realidade, isto é o que faremos executando o comando expose para o noso obxecto de implementación:
kubectl expose deployment hello-quarkus — type=NodePort — port=8080
Detémonos un momento na opción "-type" do comando expose.
Cando expomos e creamos os compoñentes necesarios para executar o noso servizo, entre outras cousas, debemos poder conectarnos desde o exterior ao servizo hello-quarkus, que se atopa dentro da nosa rede definida por software. E parámetro tipo permítenos crear e conectar cousas como equilibradores de carga para dirixir o tráfico a esa rede.
Por exemplo, escribindo type=LoadBalancer, proporcionamos automaticamente un equilibrador de carga na nube pública para conectarse ao noso clúster de Kubernetes. Isto, por suposto, é xenial, pero cómpre entender que tal configuración estará estrictamente ligada a unha nube pública específica e será máis difícil de transferir entre instancias de Kubernetes en diferentes ambientes.
No noso exemplo tipo=NodePort, é dicir, a chamada ao noso servizo vai polo enderezo IP do nodo e o número de porto. Esta opción permítelle non usar ningunha nube pública, pero require unha serie de pasos adicionais. En primeiro lugar, necesitas o teu propio equilibrador de carga, polo que implementaremos o equilibrador de carga NGINX no noso clúster.
Paso 6: instala un equilibrador de carga
minikube ten unha serie de funcións da plataforma que facilitan a creación de compoñentes accesibles externamente, como controladores de entrada. Minikube vén incluído co controlador de entrada Nginx e todo o que temos que facer é activalo e configuralo.
minikube addons enable ingress
Agora imos crear un controlador de entrada Nginx cun só comando, que funcionará dentro do noso clúster minikube:
ingress-nginx-controller-69ccf5d9d8-j5gs9 1/1 Running 1 33m
Paso 7: configure a entrada
Agora necesitamos configurar o controlador de entrada Nginx para aceptar solicitudes de hello-quarkus.
E, finalmente, necesitamos aplicar esta configuración.
kubectl apply -f ingress.yml
Xa que estamos a facer todo isto na nosa propia máquina, simplemente engadimos o enderezo IP do noso nodo ao ficheiro /etc/hosts para dirixir as solicitudes http ao noso minikube ao equilibrador de carga NGINX.
192.168.99.100 hello-quarkus.info
Isto é todo, agora o noso servizo minikube está dispoñible desde fóra a través do controlador de entrada Nginx.
Ben, iso foi doado, non? Ou non tanto?
Executar en OpenShift (contenedores preparados para código)
E agora vexamos como se fai todo na plataforma Red Hat OpenShift Container Platform (OCP).
Do mesmo xeito que con minikube, escollemos un deseño de clúster OpenShift dun só nodo en forma de Code Ready Containers (CRC). Anteriormente chamábase minishift e estaba baseado no proxecto OpenShift Origin, pero agora é CRC e construído na plataforma OpenShift Container de Red Hat.
Aquí, perdón, non podemos evitar dicir: "OpenShift é xenial!"
Inicialmente, pensamos escribir que o desenvolvemento en OpenShift non é diferente do desenvolvemento en Kubernetes. E, en esencia, é así. Pero no proceso de escribir esta publicación, lembramos cantos movementos adicionais tes que facer cando non tes OpenShift, e por iso, de novo, é marabilloso. Encántanos cando todo se fai con facilidade, e o sinxelo que é o noso exemplo de implementar e executar en OpenShift en comparación con minikube é o que nos levou a escribir esta publicación.
Repasemos o proceso e vexamos o que temos que facer.
Entón, no exemplo de minikube, comezamos con Docker... Agarde, xa non necesitamos instalar Docker na máquina.
E non necesitamos un git local.
E Maven non é necesario.
E non tes que crear unha imaxe de contedor a man.
E non tes que buscar ningún repositorio de imaxes de contedores.
E non precisa instalar un controlador de entrada.
E tampouco é necesario configurar a entrada.
Entendes? Para implementar e executar a nosa aplicación en OpenShift, non é necesario ningún dos anteriores. E o proceso en si é o seguinte.
Paso 1: inicia o teu clúster OpenShift
Usamos Code Ready Containers de Red Hat, que é esencialmente o mesmo Minikube, pero só cun clúster Openshift completo dun só nodo.
crc start
Paso 2: crea e implementa a aplicación no clúster OpenShift
É neste paso cando a sinxeleza e comodidade de OpenShift se manifesta en todo o seu esplendor. Como con todas as distribucións de Kubernetes, temos moitas formas de executar unha aplicación nun clúster. E, como no caso de KUK, eliximos especificamente o máis sinxelo.
OpenShift sempre foi construído como unha plataforma para crear e executar aplicacións en contenedores. A construción de contedores sempre foi parte integrante desta plataforma, polo que hai moitos recursos adicionais de Kubernetes para tarefas relacionadas.
Usaremos o proceso Source 2 Image (S2I) de OpenShift, que ten varias formas diferentes de tomar a nosa fonte (código ou binarios) e convertela nunha imaxe en contedores que se executa nun clúster OpenShift.
Para iso necesitamos dúas cousas:
- O noso código fonte está no repositorio git
- Imaxe do constructor sobre a base da cal se realizará a construción.
Hai moitas imaxes deste tipo, mantidas tanto por Red Hat como pola comunidade, e usaremos a imaxe OpenJDK, ben, xa que estou construíndo unha aplicación Java.
Pode executar unha compilación S2I tanto desde a consola gráfica de OpenShift Developer como desde a liña de comandos. Usaremos o comando da nova aplicación, dicíndolle onde obter a imaxe do constructor e o noso código fonte.
oc new-app registry.access.redhat.com/ubi8/openjdk-11:latest~https://github.com/gcolman/quarkus-hello-world.git
Isto é todo, a nosa aplicación está creada. Ao facelo, o proceso S2I fixo as seguintes cousas:
- Creouse un servizo de compilación para todo tipo de cousas relacionadas coa creación da aplicación.
- Creouse unha configuración de compilación de OpenShift.
- Descarguei a imaxe do constructor no rexistro interno do docker OpenShift.
- Clonouse "Hello World" no repositorio local.
- Vin que había un maven pom alí, así que compilei a aplicación usando Maven.
- Creouse unha nova imaxe de contedor que contén a aplicación Java compilada e colocou esta imaxe no rexistro de contedores interno.
- Creouse a implementación de Kubernetes con especificacións para pod, servizo, etc.
- Imaxe do contedor de implementación lanzada.
- Eliminouse o servizo build-pod.
Hai moito nesta lista, pero o principal é que toda a compilación ocorre exclusivamente dentro de OpenShift, o rexistro interno de Docker está dentro de OpenShift e o proceso de compilación crea todos os compoñentes de Kubernetes e execútaos no clúster.
Se supervisas visualmente o lanzamento de S2I na consola, podes ver como se inicia o pod de compilación cando se completa.
Agora imos botar unha ollada aos rexistros de pod do constructor: en primeiro lugar, mostra como Maven fai o seu traballo e descarga as dependencias para construír a nosa aplicación java.
Despois de completar a compilación de Maven, iníciase a compilación da imaxe do contedor e, a continuación, esta imaxe creada envíase ao repositorio interno.
Iso é todo, o proceso de construción está completo. Agora asegurémonos de que os pods e servizos da nosa aplicación estean executando no clúster.
oc get service
Iso é todo. E só un equipo. O único que temos que facer é expor este servizo para o acceso desde fóra.
Paso 3: expón o servizo para acceder desde fóra
Como no caso de KUC, na plataforma OpenShift o noso "Hello World" tamén necesita un enrutador para dirixir o tráfico externo ao servizo dentro do clúster. OpenShift fai isto moi sinxelo. En primeiro lugar, o compoñente de enrutamento HAProxy está instalado no clúster por defecto (pódese cambiar ao mesmo NGINX). En segundo lugar, hai recursos especiais e altamente personalizables chamados Routes e semellan obxectos Ingress nos bos Kubernetes antigos (de feito, as Routes de OpenShift influíron moito no deseño dos obxectos Ingress, que agora se poden usar en OpenShift), pero para o noso "Hello World" , e en case todos os demais casos, a Ruta estándar é suficiente para nós sen configuración adicional.
Para crear un FQDN enrutable para "Hello World" (si, OpenShiift ten o seu propio DNS para o enrutamento por nomes de servizo), simplemente exporemos o noso servizo:
oc expose service quarkus-hello-world
Se miras a Ruta recentemente creada, podes atopar alí o FQDN e outra información de rutas:
oc get route
E por último, accedemos ao noso servizo desde o navegador:
Pero agora era moi doado!
Encántanos Kubernetes e todo o que che permite facer esta tecnoloxía, e tamén nos encanta a sinxeleza e a lixeireza. Kubernetes foi deseñado para facer que os contedores distribuídos e escalables sexan incriblemente fáciles de operar, pero a súa sinxeleza xa non é suficiente para levar aplicacións á produción actual. Aquí é onde entra en xogo OpenShift, seguindo os tempos e ofrecendo Kubernetes centrados nos desenvolvedores. Investiuse moito esforzo para adaptar a plataforma OpenShift específicamente para o programador, incluíndo a creación de ferramentas como S2I, ODI, Portal de desenvolvedores, OpenShift Operator Framework, integración IDE, catálogos de programadores, integración Helm, monitorización e moitas outras.
Agardamos que este artigo fose interesante e útil para vostede. E podes atopar recursos adicionais, materiais e outras cousas útiles para desenvolver na plataforma OpenShift do portal .
Fonte: www.habr.com