Por lo general, comenzamos con la tesis de que Kubernetes es solo Kubernetes, y OpenShift ya es una plataforma de Kubernetes, como Microsoft AKS o Amazon EKS. Cada una de estas plataformas tiene sus propias ventajas, dirigidas a uno u otro público objetivo. Y después de eso, la conversación ya se extiende a comparar las fortalezas y debilidades de plataformas específicas.
En general, pensamos en escribir esta publicación con una conclusión como "Escuche, no importa dónde ejecutar el código, en OpenShift o en AKS, en EKS, en algunos Kubernetes personalizados o en cualquier Kubernetes (para abreviar, llamémoslo KUK) es realmente simple, tanto allí como allí ".
Luego planeamos tomar el "Hello World" más simple y, usando su ejemplo, mostrar qué es común y cuáles son las diferencias entre KUK y Red Hat OpenShift Container Platform (en adelante, OCP o simplemente OpenShift).
Sin embargo, mientras escribíamos esta publicación, nos dimos cuenta de que nos acostumbramos a usar OpenShift durante tanto tiempo y tanto que simplemente no nos damos cuenta de cómo ha crecido y se ha convertido en una plataforma increíble que se ha convertido en mucho más que una simple distribución de Kubernetes. Estamos acostumbrados a dar por sentada la madurez y la simplicidad de OpenShift mientras perdemos de vista su brillantez.
En general, ha llegado el momento del arrepentimiento activo, y ahora compararemos paso a paso la puesta en marcha de nuestro "Hello World" en KUK y en OpenShift, y lo haremos de la manera más objetiva posible (bueno, quizás mostrando a veces una actitud personal hacia el tema). Si está interesado en una opinión puramente subjetiva sobre este tema, puede leerla aquí (EN) . En esta publicación, nos ceñiremos únicamente a hechos y hechos.
Clusters
Entonces, nuestro "Hola mundo" necesita clústeres. Digamos "no" a cualquier nube pública de inmediato para no pagar por servidores, registros, redes, transferencia de datos, etc. En consecuencia, elegimos un clúster de un solo nodo simple en Minikube (para KUK) y contenedores listos para el código (para el clúster OpenShift). Ambas opciones son realmente fáciles de instalar, pero requerirán una gran cantidad de recursos en su computadora portátil.
Montaje en KUK-e
Entonces vamos.
Paso 1: construir nuestra imagen de contenedor
Empezaré implementando nuestro "Hola mundo" en minikube. Esto requerirá:
- 1. Docker instalado.
- 2. Git instalado.
- 3. Maven instalado (en realidad, este proyecto utiliza el binario mvnw, por lo que puede prescindir de él).
- 4. En realidad, la fuente en sí, es decir clon del repositorio github.com/gcolman/quarkus-hello-world.git
El primer paso es crear un proyecto de Quarkus. No se alarme si nunca ha trabajado con Quarkus.io, es fácil. Simplemente seleccione los componentes que desea usar en el proyecto (RestEasy, Hibernate, Amazon SQS, Camel, etc.), y luego Quarkus, sin su participación, configura el arquetipo de maven y carga todo en github. Es decir, literalmente con un clic del mouse, y listo. Por eso amamos a Quarkus.
La forma más fácil de construir nuestro "Hola mundo" en una imagen de contenedor es usar las extensiones de Docker quarkus-maven, que harán todo el trabajo. Con la llegada de Quarkus, esto se ha vuelto realmente fácil y simple: agregue la extensión container-image-docker y podrá crear imágenes con comandos maven.
./mvnw quarkus:add-extension -Dextensions=”container-image-docker”
Finalmente, construimos nuestra imagen usando Maven. Como resultado, nuestro código fuente se convierte en una imagen de contenedor lista para usar que ya se puede lanzar en el tiempo de ejecución del contenedor.
./mvnw -X clean package -Dquarkus.container-image.build=true
Eso, de hecho, es todo, ahora puedes iniciar el contenedor con el comando docker run, habiendo mapeado nuestro servicio al puerto 8080 para que puedas acceder a él.
docker run -i — rm -p 8080:8080 gcolman/quarkus-hello-world
Una vez iniciada la instancia del contenedor, solo queda comprobar con el comando curl que nuestro servicio se está ejecutando:
Entonces todo funciona y fue realmente fácil y simple.
Paso 2: empujar nuestro contenedor al repositorio de imágenes del contenedor
Hasta ahora, la imagen que hemos creado se almacena localmente, en nuestro almacenamiento de contenedores local. Si queremos usar esta imagen en nuestro entorno KUK, entonces debemos colocarla en algún otro repositorio. Kubernetes no tiene tales características, por lo que usaremos dockerhub. Porque, en primer lugar, es gratis y en segundo lugar, (casi) todo el mundo lo hace.
Esto también es muy simple y solo necesita una cuenta de dockerhub.
Entonces, instalamos dockerhub y enviamos nuestra imagen allí.
Paso 3: lanzamiento de Kubernetes
Hay muchas formas de armar la configuración de kubernetes para ejecutar nuestro Hello World, pero usaremos la más simple de ellas, somos el tipo de personas que somos ...
Primero, inicie el clúster de minikube:
minikube start
Paso 4: implementar nuestra imagen de contenedor
Ahora necesitamos transformar nuestro código y la imagen del contenedor en la configuración de Kubernetes. En otras palabras, necesitamos un pod y una definición de implementación con una indicación de nuestra imagen de contenedor en dockerhub. Una de las formas más fáciles de hacer esto es ejecutar el comando create deployment apuntando a nuestra imagen:
kubectl create deployment hello-quarkus — image =gcolman/quarkus-hello-world:1.0.0-SNAPSHOT
Con este comando, le dijimos a nuestro KUK que creara una configuración de implementación que debería contener la especificación del pod para nuestra imagen de contenedor. Este comando también aplicará esta configuración a nuestro clúster de minikube y creará una implementación que descarga nuestra imagen de contenedor e inicia el pod en el clúster.
Paso 5: acceso abierto a nuestro servicio
Ahora que tenemos una imagen de contenedor desplegada, es hora de pensar en cómo configurar el acceso externo a este servicio Restful, que, de hecho, está programado en nuestro código.
Hay muchas maneras. Por ejemplo, puede utilizar el comando expose para crear automáticamente los componentes de Kubernetes adecuados, como servicios y puntos finales. En realidad, esto es exactamente lo que haremos al ejecutar el comando expose para nuestro objeto de implementación:
kubectl expose deployment hello-quarkus — type=NodePort — port=8080
Detengámonos en la opción "- tipo" del comando exponer por un momento.
Cuando exponemos y creamos los componentes necesarios para ejecutar nuestro servicio, queremos, entre otras cosas, poder conectarnos desde el exterior al servicio hello-quarkus que se encuentra dentro de nuestra SDN. Y el parámetro de tipo nos permite crear y conectar cosas como balanceadores de carga para enrutar el tráfico a esa red.
Por ejemplo, escribiendo type = LoadBalancer, inicializaremos automáticamente el equilibrador de carga en la nube pública para conectarnos a nuestro clúster de Kubernetes. Esto, por supuesto, es genial, pero debe comprender que dicha configuración estará rígidamente vinculada a una nube pública específica y será más difícil transferirla entre instancias de Kubernetes en diferentes entornos.
En nuestro ejemplo, escriba = NodePort , es decir, la llamada a nuestro servicio pasa por la dirección IP del nodo y el número de puerto. Esta opción le permite no utilizar ninguna nube pública, pero requiere una serie de pasos adicionales. Primero, necesita su propio equilibrador de carga, por lo que implementaremos un equilibrador de carga NGINX en nuestro clúster.
Paso 6: instale el equilibrador de carga
Minikube tiene una serie de funciones de plataforma que facilitan la creación de los componentes necesarios para el acceso externo, como los controladores de entrada. Minikube viene con el controlador de entrada Nginx, y solo necesitamos habilitarlo y configurarlo.
minikube addons enable ingress
Ahora, con solo un comando, crearemos un controlador de ingreso Nginx que funcionará dentro de nuestro clúster de minikube:
ingress-nginx-controller-69ccf5d9d8-j5gs9 1/1 Running 1 33m
Paso 7: configuración de Ingress
Ahora necesitamos configurar el controlador de ingreso de Nginx para aceptar solicitudes de hello-quarkus.
Finalmente, necesitamos aplicar esta configuración.
kubectl apply -f ingress.yml
Como hacemos todo esto en nuestra computadora, simplemente agregamos la dirección IP de nuestro nodo al archivo / etc / hosts para enrutar las solicitudes http a nuestro minikube al balanceador de carga NGINX.
192.168.99.100 hello-quarkus.info
Eso es todo, ahora se puede acceder a nuestro servicio minikube desde el exterior a través del controlador de ingreso de Nginx.
Bueno, eso fue fácil, ¿verdad? ¿O no realmente?
Lanzar en OpenShift (contenedores listos para código)
Ahora veamos cómo se hace todo en Red Hat OpenShift Container Platform (OCP).
Al igual que con minikube, elegimos un esquema con un clúster OpenShift de un solo nodo en forma de Code Ready Containers (CRC). Antes se llamaba minishift y se basaba en el proyecto OpenShift Origin, pero ahora es un CRC y se basa en OpenShift Container Platform de Red Hat.
Aquí, lo sentimos, no podemos evitar decir: "¡OpenShift es genial!"
Inicialmente, pensamos en escribir que el desarrollo en OpenShift no es diferente del desarrollo en Kubernetes. Y de hecho es así. Pero en el proceso de redacción de este post, recordamos cuántos movimientos innecesarios tienes que hacer cuando no tienes OpenShift, y por eso, repetimos, es maravilloso. Nos encanta cuando todo se hace fácilmente y lo fácil que es en comparación con minikube, nuestro ejemplo se implementa y ejecuta en OpenShift, de hecho, y nos impulsó a escribir esta publicación.
Repasemos el proceso y veamos qué tenemos que hacer.
Entonces, en el ejemplo de minikube, comenzamos con Docker ... Deténgase, ya no necesitamos Docker instalado en la máquina.
Y no necesitamos git local.
Y Maven no es necesario.
Y no tienes que crear una imagen de contenedor con tus manos.
Y no es necesario buscar ningún repositorio de imágenes de contenedores.
Y no es necesario instalar un controlador de entrada.
Y tampoco necesitas configurar la entrada.
Lo entiendes, ¿verdad? No necesita nada de lo anterior para implementar y ejecutar nuestra aplicación en OpenShift. Y el proceso en sí se ve así.
Paso 1: lanzamiento de su clúster de OpenShift
Usamos Code Ready Containers de Red Hat, que es esencialmente el mismo Minikube, pero solo con un clúster Openshift de un solo nodo completo.
crc start
Paso 2: compile e implemente la aplicación en el clúster de OpenShift
Es en este paso donde la simplicidad y la comodidad de OpenShift se destacan. Como ocurre con todas las distribuciones de Kubernetes, tenemos muchas formas de ejecutar una aplicación en un clúster. Y, como en el caso de KUK, elegimos deliberadamente el más simple.
OpenShift siempre se ha creado como una plataforma para crear y ejecutar aplicaciones en contenedores. La creación de contenedores siempre ha sido una parte integral de esta plataforma, por lo que hay muchos recursos adicionales de Kubernetes para tareas relacionadas.
Usaremos el proceso OpenShift Source 2 Image (S2I), que tiene varias formas diferentes de tomar nuestra fuente (código o binarios) y convertirla en una imagen de contenedor que se ejecuta en un clúster de OpenShift.
Para esto necesitamos dos cosas:
- Nuestro código fuente en el repositorio de git
- Imagen del constructor sobre la base de la cual se realizará la construcción.
Hay muchas imágenes de este tipo, mantenidas tanto por Red Hat como a nivel de la comunidad, y usaremos la imagen OpenJDK, ya que estoy construyendo una aplicación Java.
Puede iniciar la compilación de S2I tanto desde la consola gráfica de OpenShift Developer como desde la línea de comandos. Usaremos el comando new-app para decirle dónde obtener la imagen del constructor y nuestro código fuente.
oc new-app registry.access.redhat.com/ubi8/openjdk-11:latest~https://github.com/gcolman/quarkus-hello-world.git
Eso es todo, nuestra aplicación ha sido creada. Al hacerlo, el proceso S2I hizo lo siguiente:
- Creó un módulo de creación de servicios para todo tipo de cosas relacionadas con la creación de la aplicación.
- Creó la configuración de OpenShift Build.
- Descargó la imagen del constructor en el registro interno de la ventana acoplable de OpenShift.
- Se clonó "Hello World" en el repositorio local.
- Vi que había un maven pom allí y compilé la aplicación con maven.
- Creó una nueva imagen de contenedor que contiene la aplicación Java compilada y colocó esa imagen en el registro de contenedor interno.
- Implementación de Kubernetes creada con especificaciones de pod, servicio, etc.
- Implementación lanzada de la imagen del contenedor.
- Se eliminó el servicio build-pod.
Hay muchas cosas en esta lista, pero lo principal es que toda la compilación se lleva a cabo exclusivamente dentro de OpenShift, el registro interno de Docker está dentro de OpenShift y el proceso de compilación crea todos los componentes de Kubernetes y los ejecuta en el clúster.
Si realiza un seguimiento visual del lanzamiento de S2I en la consola, puede ver cómo se inicia el pod de compilación durante la compilación.
Ahora echemos un vistazo a los registros del pod de construcción: en primer lugar, muestra cómo maven hace su trabajo y descarga las dependencias para construir nuestra aplicación Java.
Una vez finalizada la compilación de Maven, se inicia la compilación de la imagen del contenedor y, a continuación, esta imagen compilada se envía al repositorio interno.
Eso es todo, el proceso de montaje está completo. Ahora asegurémonos de que los pods y los servicios de nuestra aplicación se estén ejecutando en el clúster.
oc get service
Eso es todo. Y solo un equipo. Solo tenemos que exponer este servicio para acceso externo.
Paso 3: exponer el servicio para acceso externo
Como en el caso de KUK, en la plataforma OpenShift, nuestro "Hello World" también necesita un enrutador para dirigir el tráfico externo a un servicio dentro del clúster. OpenShift lo hace muy fácil. En primer lugar, el componente de enrutamiento HAProxy se instala en el clúster de forma predeterminada (puede cambiarlo al mismo NGINX). En segundo lugar, existen recursos especiales y altamente personalizables llamados Rutas, que se asemejan a los objetos de Ingress en los viejos Kubernetes (de hecho, las Rutas de OpenShift influyeron fuertemente en el diseño de los objetos de Ingress, que ahora se pueden usar en OpenShift) , pero para nuestro "Hola Mundo", y en casi todos los demás casos, la Ruta estándar sin configuración adicional es suficiente para nosotros.
Para crear un FQDN enrutable para "Hello World" (sí, OpenShiift tiene su propio DNS para el enrutamiento por nombre de servicio), simplemente exponemos nuestro servicio:
oc expose service quarkus-hello-world
Si observa la ruta recién creada, puede encontrar el FQDN y otra información de enrutamiento allí:
oc get route
Finalmente, accedemos a nuestro servicio desde el navegador:
¡Ahora era realmente fácil!
Amamos Kubernetes y todo lo que la tecnología nos permite hacer, y también amamos la sencillez y la ligereza. Kubernetes se creó para que sea increíblemente fácil operar contenedores distribuidos y escalables, pero su simplicidad ya no es suficiente para implementar aplicaciones. Y aquí es donde entra en juego OpenShift, que sigue el ritmo de los tiempos y ofrece Kubernetes, centrado principalmente en el desarrollador. Se ha realizado un gran esfuerzo para hacer que la plataforma OpenShift sea exactamente para el desarrollador, incluida la creación de herramientas como S2I, ODI, Developer Portal, OpenShift Operator Framework, integración IDE, Developer Catalogs, integración Helm, monitoreo y muchas otras.
Esperamos que este artículo te haya resultado interesante y útil. Y para encontrar recursos adicionales, materiales y otras cosas útiles para el desarrollo en la plataforma OpenShift, visite el portal de desarrolladores de Red Hat .