aprenderDevOps

Para profesionales TI interesados en DevOps

  • Inicio
  • Acerca de
  • Categorías
    • Aseguramiento de la calidad
    • Cloud
    • Contenedores
    • Infraestructura como código
    • Integración y entrega continua
    • Otros
  • Recursos
    • GitHub
    • Docker Hub
  • Contacto

14 de febrero de 2018 por Arturo

Configuración de builds automatizados en Docker Hub utilizando tags de Git

Configuración de builds automatizados en Docker Hub utilizando tags de Git

En esta entrada vamos a ver cómo configurar builds automatizados en Docker Hub para que estos se desencadenen a partir del etiquetado de un commit en GitHub.

En la entrada Configuración de builds automatizados en Docker Hub vimos cómo configurar un repositorio Docker Hub (aprenderdevops/jenkins) para enlazarlo con un repositorio de código GitHub (aprenderdevops/docker-jenkins), de forma que cualquier actualización del código fuente en el repositorio GitHub desencadene automáticamente en Docker Hub la construcción de una nueva versión de la imagen Docker.

Con esta configuración, cualquier actualización de código en la rama master del repositorio GitHub desencadenará la construcción de una nueva imagen Docker etiquetada con el tag latest.

Además, cualquier actualización en otra rama del repositorio GitHub distinta de la rama master desencadenará la construcción de una nueva imagen Docker etiquetada con el nombre de la rama de GitHub.

Esta última configuración es útil si tenemos una o más líneas de desarrollo paralelas a la línea principal (rama master) y queremos que se construyan imágenes Docker etiquetadas con el nombre de cada rama, de forma que sea muy sencillo identificar a que código fuente corresponde cada imagen en función de su etiqueta asignada. Las modificaciones en GitHub en cualquiera de las ramas desencadenarán la construcción de la imagen correspondiente, de forma que se puede ir evolucionando la funcionalidad de cualquiera de las ramas en paralelo al resto de ramas y de la rama principal.

Utilidad de los tags de Git

El problema de las ramas de Git es que no sirven para identificar una versión concreta y estática del código. Para conseguir esto, lo mejor es utilizar tags (o etiquetas) de Git.

Un tag es una cadena arbitraria que apunta a un commit específico de un repositorio Git. Se trata, por lo tanto, de algo estático, ya que el código puede seguir evolucionando, pero el tag siempre apuntará a un determinado punto de la historia del código. La principal utilidad de los tags es identificar las distintas versiones o releases del código.

Podéis encontrar información sobre el uso de tags en Git en el siguiente enlace: https://git-scm.com/book/es/v1/Fundamentos-de-Git-Creando-etiquetas

Cuando tenemos builds automatizados en Docker Hub, la utilización de tags Git resulta de gran utilidad para identificar las distintas versiones de las imágenes Docker que se van construyendo.

Vamos a ver cómo configurar en Docker Hub esta característica.

Configuración de builds automatizados en Docker Hub utilizando tags de Git

Lo primero que tenemos que hacer es logarnos en Docker Hub y acceder a la configuración de los builds (opción Build Settings) del repositorio en el que queremos configurar builds automatizados utilizando tags de Git.

Una vez en la pantalla Build Settings nos aparecerá una configuración similar a la de la siguiente pantalla.

Configuración de builds automatizados en Docker Hub utilizando tags de Git

En esta configuración, si previamente ya habíamos configurado los builds automatizados, tendremos una línea para la rama master y otra línea para cualquier rama distinta de la rama master. Lo que tenemos que hacer ahora es pulsar en el símbolo más de color verde y añadir una línea de tipo Tag. Para esta nueva línea podemos dejar los valores por defecto. De esta forma, cualquier tag creado en el repositorio GitHub desencadenará un build cuya imagen Docker resultante será etiquetada con el mismo tag que se ha creado en GitHub.

Configuración de builds automatizados en Docker Hub utilizando tags de Git

Actualización del código en GitHub y etiquetado con un tag

Para probar que esta nueva configuración de builds automatizados funciona correctamente, vamos a hacer una modificación en la rama master del código de nuestro proyecto de instalación de Jenkins con Docker. También vamos a etiquetar ese código con el comando git tag. Por último, lo vamos a subir al repositorio GitHub (aprenderdevops/docker-jenkins) mediante el comando git push.

Todo esto, debería desencadenar la construcción de dos imágenes Docker, una correspondiente a la rama master y que se etiquetará con el tag latest, y otra correspondiente al tag de Git que hayamos subido a GitHub y que se etiquetará con ese mismo tag. Ambas imágenes serán totalmente idénticas, cambiando únicamente la etiqueta que tienen asignada.

Vamos a ver en detalle los pasos de esta modificación en el código del proyecto de instalación de Jenkins con Docker.

Instalación de un plugin adicional en Jenkins

La modificación que vamos a hacer es muy sencilla. Consistirá en añadir un nuevo plugin Jenkins a nuestra imagen Docker. El plugin que he elegido es Blue Ocean (identificado como blueocean). Este plugin realiza un completo rediseño del interfaz de usuario de Jenkins.

Para añadir un nuevo plugin Jenkins a la imagen Docker únicamente tenemos que incluir el identificador del plugin, en este caso blueocean, en el fichero plugins.txt. Os recuerdo que este fichero contiene todos los plugins de Jenkins que queremos incluir en nuestra imagen Docker. Se trata de un fichero en formato texto que incluye un identificador de plugin por línea. Añadiendo el identificador blueocean en el fichero plugins.txt se instalará el plugin Blue Ocean y todos los plugins de los que éste dependa para su correcto funcionamiento.

Asignación de un tag para versionar la imagen Docker

Una vez realizada la modificación en el código de nuestro proyecto, hacemos un commit de los cambios de nuestro código y le asignamos un tag. Esto lo hacemos ejecutando los comandos que detallo a continuación:

1
2
3
4
5
$ git add plugins.txt
$ git commit -m "Se añade el plugin blueocean en plugins.txt"
[master c38387a] Se añade el plugin blueocean en plugins.txt
1 file changed, 2 insertions(+), 1 deletion(-)
$ git tag 1.5 -m "Versión 1.5. Se añade el plugin Blue Ocean."

En mi caso he etiquetado esta versión como la 1.5.

Podemos obtener información sobre un determinado tag ejecutando un comando git show como el siguiente:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
$ git show 1.5
tag 1.5
Tagger: aprenderdevops <jarfernandez@aprenderdevops.com>
Date:   Sun Feb 11 14:44:19 2018 +0100
 
Versión 1.5. Se añade el plugin Blue Ocean.
 
commit 14287aafa95734a3e6fc4d8f5bceb1f73c33340d (HEAD -> master, tag: 1.5, origin/master, origin/HEAD)
Author: aprenderdevops <jarfernandez@aprenderdevops.com>
Date:   Sun Feb 11 14:43:51 2018 +0100
 
    Se añade el plugin blueocean en plugins.txt
 
diff --git a/plugins.txt b/plugins.txt
index 30ac56c..1b3b57c 100644
--- a/plugins.txt
+++ b/plugins.txt
@@ -5,6 +5,7 @@ antisamy-markup-formatter
apache-httpcomponents-client-4-api
authentication-tokens
branch-api
+blueocean
build-monitor-plugin
build-pipeline-plugin
checkstyle
@@ -69,4 +70,4 @@ workflow-job
workflow-multibranch
workflow-scm-step
workflow-step-api
-workflow-support
\ No newline at end of file
+workflow-support

Por último, para actualizar estos cambios en GitHub ejecutamos el siguiente comando:

1
2
3
4
5
6
7
8
9
10
$ git push origin master --tag
Counting objects: 4, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 489 bytes | 489.00 KiB/s, done.
Total 4 (delta 2), reused 0 (delta 0)
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
To https://github.com/aprenderdevops/docker-jenkins.git
   c6c882b..14287aa  master -> master
* [new tag]         1.5 -> 1.5

En el repositorio de GitHub tendremos una nueva release etiquetada con el tag 1.5.

Configuración de builds automatizados en Docker Hub utilizando tags de Git

Estos cambios en GitHub desencadenarán dos builds en Docker Hub, uno etiquetado como latest y otro como 1.5.

Configuración de builds automatizados en Docker Hub utilizando tags de Git

Pasados unos minutos ambas imágenes estarán disponibles en Docker Hub y podremos usarlas para ejecutar Jenkins con el plugin Blue Ocean.

Configuración de builds automatizados en Docker Hub utilizando tags de Git

Arranque del contenedor con la nueva imagen Docker

Para comprobar que todo ha ido bien, descargamos a local la nueva imagen Docker construida. Para ello, ejecutamos el siguiente comando:

1
$ docker pull aprenderdevops/jenkins

Una vez descargada la nueva imagen Docker, arrancamos el contenedor ejecutando el siguiente comando:

1
2
3
$ docker-compose up -d
Creating volume "dockerjenkins_jenkins_home" with default driver
Creating dockerjenkins_master_1 ... done

Una vez arrancado el contenedor, abrimos un navegador y accedemos a http://localhost:8080 para entrar en la consola de administración de Jenkins.

Para obtener la contraseña del usuario admin de Jenkins ejecutamos el siguiente comando:

1
$ docker exec -it dockerjenkins_master_1 cat /var/jenkins_home/secrets/initialAdminPassword

Si todo ha ido bien, en la parte izquierda de la consola de Jenkins se mostrará el icono de acceso a la interfaz Blue Ocean.

Configuración de builds automatizados en Docker Hub utilizando tags de Git

Código fuente del laboratorio

Podéis descargar o clonar de GitHub el código fuente completo de este laboratorio de https://github.com/aprenderdevops/docker-jenkins.

Archivado en: Contenedores, Integración y entrega continua Etiquetado con: builds automatizados, docker, docker hub, git tag, github

Deja una respuesta Cancelar la respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Lista de correo

Únete y recibe gratis en tu correo contenido actualizado.

Sígueme en la red

  • Correo electrónico
  • Facebook
  • GitHub
  • LinkedIn
  • RSS
  • Twitter
  • YouTube

Categorías

  • Aseguramiento de la calidad
  • Contenedores
  • Infraestructura como código
  • Integración y entrega continua
  • Otros
  • Correo electrónico
  • Facebook
  • GitHub
  • LinkedIn
  • RSS
  • Twitter
  • YouTube
  • Inicio
  • Acerca de
  • Categorías
  • Recursos
  • Contacto

Copyright © 2023 aprenderDevOps