Source to image el proceso de creación de aplicaciones

¡Hola a todo el mundo! Volvemos por aquí para seguir hablando de Red Hat OpenShift. Más concretamente, de la capacidad de esta tecnología de automatizar completamente el proceso de construcción de imágenes de contenedores, también conocido como Source to Image o S2I. Red Hat OpenShift no sólo permite automatizar el S2I, sino también lanzar el despliegue y ejecución de la aplicación, todo ello partiendo de su código fuente alojado en un repositorio Git.

Como ya sabes, en Essi Projects somos Red Hat Container Platform Specialists y por esta razón queremos acompañarte a descubrir todo lo que Red Hat OpenShift puede hacer en el desarrollo de aplicaciones.
¡Sigue leyendo!

¡Sigue leyendo!

¿Qué es el Source to Image o S2I?

Como te decíamos en la introducción, una de las características de OpenShift es su capacidad de automatizar el proceso de construcción de aplicaciones, además de su despliegue y ejecución partiendo del código alojado en repositorios Git.

Red Hat OpenShift es capaz de realizar un despliegue de contenedores a partir de imágenes de contenedores ya existentes, además de existir otros métodos de creación de imágenes de contenedor como el conocido “Dockerfiles”. Pero además, esta tecnología de Red Hat dispone de otro método adicional conocido como «Source-to-Image» o S2I.

S2I es un proceso de construcción de imágenes de contenedor en un clúster OpenShift

El proceso S2I requiere de una imagen de contenedor que contenga las librerías del sistema operativo base, compiladores y/o intérpretes, runtimes, frameworks y herramientas propias de S2I. Estas serán utilizadas en el proceso de construcción de la imagen de contenedor con nuestra aplicación.

La imagen de contenedor resultante que contenga nuestra aplicación será la generada a partir de la combinación del código fuente de nuestra aplicación y la imagen de contenedor de compilación mencionada anteriormente. Una vez generada la imagen de contenedor con nuestra aplicación, ésta podrá ser desplegada directamente en el clúster de OpenShift.

¿Cómo puede ayudarte el Source to image (s2I)?

Los desarrolladores se benefician del S2I ya que pueden invertir una mayor cantidad de tiempo en detalles concretos de su aplicación. Con el Source to Image el proceso de compilación y construcción de la imagen de contenedor se automatiza completamente. En determinados casos, el desarrollador tendrá que establecer una serie de scripts que indican cómo se construirá su código. Sin embargo, en la gran mayoría de los casos se podrá ahorrar esta tarea dado que esos scripts ya existen y vienen definidos para diversos tipos de lenguajes, como por ejemplo PHP, Perl, NodeJS, Ruby, Python, etc.

source to image
VISIón general del proceso de construcción de aplicaciones s2i

¿Qué ventajas nos aporta S2I?

El proceso S2I es la principal estrategia de construcción de aplicaciones en un clúster OpenShift. Las principales ventajas de S2I son:

– El desarrollador no necesita saber sobre cómo se construyen imágenes de contenedor con Dockerfiles, lo cual requeriría conocer algunos comandos del sistema operativo generalmente utilizados por administradores de sistemas (por ej.: «yum install»). De esta manera el desarrollador se centra en utilizar sus propias herramientas.

– Al cambiar una imagen base debido a algún parcheado de seguridad se actualizarán automáticamente todas las imágenes que dependan de la misma. Esto se consigue gracias a los «Image Streams», que son referencias a las imágenes base de construcción, sobre las cuales OpenShift detecta si ha habido algún cambio y toma una acción basada en ese cambio

– La construcción de imágenes de contenedor es más rápida ya que no se crean nuevas capas en cada etapa de la construcción, como en el caso de imágenes creadas con Dockerfiles

– Las imágenes base y los scripts de construcción pueden ser personalizados y reutilizados por diferentes tipos de aplicaciones

Conociendo las imágenes de construcción S2I

Existen diferentes tipos de imágenes de compilador S2I dependiendo de las necesidades de nuestra aplicación:

Imágenes de construcción proporcionadas por Red Hat. Son imágenes soportadas por diferentes tipos de aplicaciones, y son las recomendadas por Red Hat. Aseguran la máxima compatibilidad y que están actualizadas y libres de posibles vulnerabilidades

Imágenes de construcción creadas a partir de Dockerfiles. Consiste en crear imágenes secundarias a partir de imágenes de construcción padre proporcionadas por Red Hat. Con esto reutilizaríamos los scripts y herramientas de construcción de la imagen padre y nos permitiría agregar otros adicionales

Imágenes de construcción personalizadas. Es decir, para un lenguaje cuyos scripts y herramientas de construcción no estén definidos por defecto, podremos crear una imagen totalmente personalizada

Proceso de construcción de aplicación contenerizada con S2I

Una vez tenemos todos estos componentes… ¿Cómo se produce el proceso de construcción de nuestra aplicación y la imagen de contenedor?

El primer paso es la obtención del código fuente de la aplicación desde el repositorio Git donde se encuentra alojado.

A continuación, hay que depositar el código fuente junto con los scripts de construcción dentro de la imagen de construcción. La transferencia de todos los ficheros se realiza en un fichero .tar y, posteriormente, el proceso S2I lo desempaqueta dentro de la imagen del contenedor de construcción.

Como es de suponer, la utilidad ‘tar’ debe estar disponible en el contenedor de construcción. Además, la ubicación ‘/tmp’ es la utilizada por defecto a menos que se haya especificado otra ruta diferente.

Componentes que intervienen en proceso s2i

SCRIPTS DE CONSTRUCCIÓN Y SUS ETAPAS

Hasta ahora habíamos mencionado los scripts de construcción que indican cómo se construirá el código. Estos scripts pueden estar implementados en cualquier lenguaje. Vamos a entrar un poco más en detalle en cada uno de ellos y las etapas de la construcción donde intervienen. Tendremos los siguientes:

ASSEMBLE

La función de Assemble es la de construir los artefactos a partir del código fuente de nuestra aplicación. Un ejemplo de script ‘assemble’ sería el siguiente:

#!/bin/bash

# Restaurar los artefactos de construcción
if [ "$(ls /tmp/s2i/artifacts/ 2>/dev/null)" ]; then
   mv /tmp/s2i/artifacts/* $HOME/.
fi

# Mover el código fuente de la aplicación
mv /tmp/s2i/src $HOME/src

# Construir los artefactos de la aplicación
pushd ${HOME}
make all

# Instalar los artefactos
make install
popd 

RUN

Se encarga de ejecutar la aplicación. Un ejemplo:

#!/bin/bash

# Ejecuta la aplicación
/opt/application/run.sh

SAVE-ARTIFACTS (OPCIONAL)

Se reutilizan los artefactos generados en la construcción anterior, por lo que el proceso S2I ahorra tiempo y recursos dedicados a la compilación. Esto es lo que se conoce como construcción incremental. En el siguiente ejemplo, los artefactos resultantes de una construcción anterior son empaquetados con ‘tar’ y enviados a la salida estándar. A continuación son inyectados en un nuevo contenedor de construcción:
#!/bin/bash

pushd ${HOME}

if [ -d deps ]; then

   tar cf - deps

fi

popd 

USAGE (OPCIONAL)

Podemos definir en este script una nota informativa para que se imprima por la salida estándar. Esta nota informativa daría instrucciones sobre cómo utilizar la imagen correctamente. Ejemplo:
#!/bin/bash

# Informa al usuario sobre cómo utilizar la imagen

cat <https://github.com/openshift/source-to-image

EOF

TEST/RUN (OPCIONAL)

Se utiliza para verificar el correcto funcionamiento de la imagen.

flujo de construcción de aplicación source to image
flujo de construcción de aplicación y su imagen de contenedor

pasando a la acción

Vamos directos a la práctica con unos ejemplos. Lo que queremos es construir nuestra aplicación, cuyo código se encuentra alojado en un repositorio Git y desplegarla en el clúster OpenShift. Esto lo podremos hacer fácilmente desde la línea de comandos gracias al CLI de OpenShift.

PHP

Por ejemplo, si nuestra aplicación está escrita en PHP, haremos algo así:

oc new-app php~http://mi.servidor.git.com/mi-aplicacion

Con esto estaremos lanzando el proceso S2I que construirá nuestra aplicación. Como nuestra aplicación es PHP, hemos especificado el Image Stream como ‘php~URL’ donde URL apunta al repositorio Git donde está nuestra aplicación.

REPOSITORIO GIT

También podemos construir una aplicación especificando el repositorio Git y un subdirectorio de contexto. Lo haríamos así:

oc new-app https://github.com/mi-github/mi-proyecto.git --context-dir=mi-aplicacion

O si lo que queremos es crear una aplicación especificando el repositorio Git con una referencia a una rama en particular, lo haremos de la siguiente manera:

oc new-app https://github.com/mi-github/python-hello-world.git#beta2 

LENGUAJES DE PROGRAMACIÓN

Con los anteriores ejemplos vemos que podemos especificar explícitamente el Image Stream o no. OpenShift es capaz de reconocer qué imagen de construcción utilizar si no la especificamos como Image Stream.

La detección del lenguaje de programación que utiliza nuestra aplicación y por lo tanto, qué imagen de construcción utilizar, se hace basándose en la existencia de ciertos ficheros en la raíz del repositorio:

Archivos Compilador o Intérprete Lenguaje
Dockerfile
-
Creación de imagen con Dockerfile (no S2I)
pom.xml
jee
Java EE (JBoss EAP)
app.json, package.json
nodejs
Node.js (JavaScript)
Contenidocomposer.json, index.php
php
PHP
Rakefile, Gemfile, config.ru
Contenid ruby
Ruby
requirements.txt, config.py
python
Python
index.pl, cpanfile
perl
Perl

CONCLUSIONES

El proceso de construcción de aplicaciones S2I es una de las más poderosas herramientas de OpenShift. Permite al desarrollador centrarse en detalles propios del desarrollo y dejando en manos de OpenShift todo el proceso de construcción.

Además de las imágenes que ya se incluyen, como por ejemplo para los lenguajes más habituales, PHP, Python, Java, Ruby o Perl, las herramientas S2I de OpenShift permiten la personalización de éstas imágenes, simplificando enormemente las tareas de despliegue y puesta en marcha de la aplicación.

BONUS TRACK

¿Quieres aprender más sobre contenerización y Red Hat OpenShift? ¡Esto es para ti!

Aprovecha esta oportunidad y haz el DO080 Containers, Kubernetes y Red Hat OpenShift Technical Overview de forma totalmente gratuita. Podrás aprender a organizar aplicaciones y servicios en contenedores, a realizar pruebas con Docker y a implementarlos en un clúster de Kubernetes utilizando Red Hat OpenShift.

¿Quieres saber más sobre esta tecnología?

Essi Projects, Red Hat Premier Partner en España, está certificado como Red Hat Container Platform Specialist, lo que nos acredita como expertos en Red Hat OpenShift Container Platform y partner de referencia en España.


Si quieres saber un poco más sobre esta tecnología, ¡no lo dudes!

¡Cuéntanos cómo podemos ayudarte!

Además, si tienes alguna otra duda, será un placer ayudarte. Puedes ponerte en contacto con nosotros a través del Formulario de Contacto o enviando un correo a info@essiprojects.com

gaston-zunino-blog

Gastón Zunino
DevOps Engineer & Red Hat Instructor
Essi Projects

¿QUIEN SOMOS?

Somos especialistas en DevOps Ecosystem y ayudamos a las empresas a revolucionar su infrastructura de servicios y aplicaciones para soportar su éxito.

A través de proyectos de consultoría, integración y formación técnica certificada, ofrecemos soluciones basadas en Open Hybrid Cloud Pass, Management & Automation, Monitoring & Performance, Middleware Solutions y Email & Collaboration.

¡Únete a nuestra newsletter!
Mantente al día de las últimas novedades del sector IT

POSTS RECIENTES

CATEGORÍAS

Etiquetas