¡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.
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.
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.shSAVE-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 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-aplicacionCon 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-aplicacionO 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
Gastón Zunino
DevOps Engineer & Red Hat Instructor
Essi Projects
Comparte la noticia
