Mi experiencia de pasantía en Open Mainframe Project

El programa de pasantías Open Mainframe Project es un trabajo remoto para que los estudiantes contribuyan al Open Mainframe Project.

El Open Mainframe Project está destinado a servir como punto focal para la implementación y el uso de Linux y Open Source en un entorno informático de mainframe. El Proyecto tiene la intención de aumentar la colaboración en la comunidad de mainframe y desarrollar conjuntos de herramientas y recursos compartidos. Además, el Proyecto busca involucrar la participación de instituciones académicas para ayudar a enseñar y educar a los ingenieros y desarrolladores de mainframe del mañana.

El objetivo de mi proyecto era crear imágenes acoplables para distribuciones de Linux basadas en s390x de la pila de desarrollo como MEAN y dockerizar varios marcos y lenguajes modernos. La segunda parte del proyecto fue automatizar la compilación de todas las imágenes de Docker, toda la biblioteca de clefOS, una de las imágenes oficiales de DockerHub, utilizando Jenkins CI.

Comencé a intentar postularme para este programa desde el comienzo del año y estaba muy emocionado cuando finalmente me seleccionaron.

Estas últimas semanas estuvieron llenas de emoción y aprendizaje para mí. El objetivo de mi proyecto era crear imágenes acoplables para la arquitectura s390x en SUSE Linux Enterprise Server 15 y automatizar el proceso de compilación programado para las imágenes clefOS. La primera mitad del proyecto fue hacer las imágenes. Inicialmente planeamos construir las imágenes para openSUSE. Pero openSUSE no se había mantenido actualizado con s390x. Eso nos obligó a cambiar a SLES15 en su lugar.

Mi primer desafío fue construir una imagen base de SLES15. La imagen base será utilizada por todas las demás imágenes. Esto fue un desafío para mí, ya que nunca antes había creado una imagen base. Para lograr esto, Neale, mi mentor, me proporcionó una instancia de SLES15 linux guest. Accedí a la máquina virtual y escribí un script bash que creará un entorno chroot, le agregará repositorios, instalará paquetes esenciales y finalmente creará un tarball. Este tarball luego será utilizado por nuestro Dockerfile que construye la imagen base usando FROM scratch.

Después de lograr este objetivo, pasé a crear más imágenes para SLES 15. Luego vino MEAN stack. La pila tecnológica de Mongodb, Express, Angular y Nodejs es muy popular y queríamos que fuera una imagen acoplable para s390x base SLES15. Pero no pudimos encontrar ningún paquete mongodb oficial para SLES15. Intenté usar mongodb para SLES12, pero no funcionó porque no pude encontrar un paquete. libcrypto aunque esté instalado. Finalmente decidimos que esperaremos el lanzamiento oficial de mongodb para SLES15 antes de construir una imagen para mongodb y mean stack.

La siguiente fase del proyecto fue construir un sistema para automatizar el proceso de construcción de las imágenes para que las imágenes puedan permanecer actualizadas. Lo logré construyendo una canalización en Jenkins. La canalización está programada para ejecutarse una vez al mes automáticamente cada vez que se realiza una confirmación en el código base o. La canalización ejecuta los comandos apropiados para compilar todas las imágenes de Docker. Esta característica nos permite evaluar si un cambio está rompiendo la imagen y la canalización está fallando, lo que agrega soporte de CI/CD al repositorio. También estoy construyendo una canalización similar para todas las imágenes del repositorio de clefOS que mantendrá las imágenes de clefOS actualizadas.

Construir la tubería fue una parte desafiante en sí misma. Jenkinsfile se puede usar para ejecutar comandos bash y si el servidor Jenkins tiene acceso a las imágenes de construcción del daemon de la ventana acoplable es bastante sencillo. Pero el problema es que no puedes enviar esas imágenes. Para eso, deberá iniciar sesión en la ventana acoplable y proporcionar credenciales, lo cual es bastante inseguro. Aquí es donde el complemento de compilación docker viene al rescate. En un Jenkinsfile con secuencias de comandos, esto le permite crear una imagen acoplable simplemente escribiendo:

app = docker.build("repo/name”, "./relative/path/to/Dockerfile")

Esto nos permite usar la aplicación y enviar las imágenes a dockerhub utilizando el complemento de credenciales de jenkins. Pero este complemento tenía un problema importante. Construir más de 100 imágenes usando esto requerirá mucho código en Jenkinsfile. Esta es la única solución funcional que he encontrado que crea las imágenes de la ventana acoplable y nos permite enviarlas también desde el propio Jenkins.

Debo decir que este ha sido un proyecto muy desafiante y gratificante. Cada día, aprendo algo nuevo y lo domino una vez que lo implemento varias veces. Al trabajar en máquinas virtuales basadas en la arquitectura s390x, aprendí cómo funciona un sistema s390x. Tengo muchas ganas de trabajar y terminar este proyecto con éxito.

docker-jenkins.png

En la segunda fase de mi pasantía en Open Mainframe Project, automaticé la compilación de la biblioteca de imágenes de ClefOS y también mis imágenes acoplables de SLES15 para s390x. Para lograr esto, usé Jenkins CI y un poco de secuencias de comandos bash.

Configurar la tubería fue el mayor desafío de mi pasantía. Usé Jenkins CI y lo vinculé al repositorio de github que contiene todos los archivos docker del código fuente usando un webhook. Este webhook envía una solicitud POST al servidor Jenkins especificado cada vez que se envía una nueva confirmación. El servidor Jenkins está alojado en una máquina virtual ClefOS s390x en LinuxONE Community. Podría… El servidor Jenkins siempre está listo para recibir esta solicitud POST. La carga útil de esta solicitud contiene detalles como qué repositorio y qué confirmación activaron el webhook. Después de analizar la solicitud, Jenkins activa mis canalizaciones. Una canalización es para ClefOS y la segunda es para mis imágenes s390x SLES15. La canalización de ClefOS se ejecuta en el nodo maestro y la canalización de SLES15 se ejecuta en un nodo esclavo. Las canalizaciones se activan cada vez que se inserta una nueva confirmación (o confirmaciones) en la rama principal del repositorio. Un único repositorio contiene el código fuente de las imágenes ClefOS y SLES15 https://github.com/openmainframeproject-internship/DockerHub-Development-Stacks

Las canalizaciones extraen el archivo Jenkins desde el propio código fuente. Había demasiadas imágenes de ClefOS, por lo que instruir a Jenkins para que construyera cada imagen en Jenkinsfile se estaba volviendo engorroso. En cambio, a cada imagen se le asignó un Makefile. Este Makefile contenía comandos para construir todas las imágenes desde la carpeta del código fuente, empujarlas y limpiar el sistema. Entonces, el problema inicial era que si queríamos enviar la imagen, teníamos que construirla usando docker.build() y asignarla a una variable para la cual podemos usar para llamar al método push(). El complemento de Docker también admite un método de imagen que podemos usar para rastrear las imágenes de Docker que se han creado anteriormente. Así que utilicé estos dos factores a mi favor y escribí un script bash que itera sobre todas las carpetas y se ejecuta make all en todos ellos. Este script construye todas las imágenes presentes en la carpeta ClefOS. Después de eso, simplemente usamos docker.image() para asignar las imágenes a una variable en la que podemos aplicar todo el método push. Para eliminar las imágenes, estoy usando un script bash similar que se ejecuta make clean comando de Makefiles.

Esta solución tiene algunas ventajas y también algunos defectos. La principal ventaja es que todas las imágenes se compilan con un solo comando en Jenkinsfile. Pero elimina la flexibilidad de construir imágenes individuales. Para resolver este problema, también codifiqué la parte para crear imágenes individuales usando docker.build(). Este código está presente en Jenkinsfile como comentarios. Si alguien quiere verificar la compilación de una sola imagen en el CI, puede comentar la ejecución del script bash compilar todas las imágenes y descomentar el código para compilar una imagen.

También había algunas imágenes que usaban versiones codificadas en su código fuente. Cambié eso para usar la última versión disponible raspando un archivo .yml usando un script bash.

Los gasoductos están programados para ejecutarse el día 22 de cada mes. Esto garantiza que las imágenes estén en la última versión y que los desarrolladores puedan usarlas de inmediato y no tengan que lidiar con imágenes obsoletas.

Similar Posts

Leave a Reply

Your email address will not be published.