DevOps: Ejemplo de cómo efectuar un Despliegue Continuo

Miércoles 21 Abril 2021

Autores: 

El despliegue continuo es una de las herramientas que nos facilita DevOps donde nosotros como desarrolladores queremos controlar el proceso de desarrollo de la APP que estamos desplegando. Por tanto, en este ejemplo partimos de la base de que ya tenemos una aplicación (o sino está en desarrollo) y queremos que esta pueda ser desplegada por nosotros mismos y de forma automática.

Cuando hablamos de CD en entorno de DevOps tiene dos posibles significados:

  • Entrega Continua (Continuous Delivery): se construye el paquete y se deja a punto de ser desplegado, pero el desarrollo se hace manual.
  • DespliegueContinuo (Continuous Deployment): el despliegue también se hace de manera automatizada.

Antes de empezar con la configuración hace falta que nos situemos en el entorno que nosotros tenemos para poder hacer el despliegue. En este caso el entorno del que disponemos es gitlbab + kubernetes. Este entorno consta de un entorno de PRE y un entorno de PRO. En este artículo queremos explicar como desplegar de forma automática en el entorno de PRE.

Lo primero que hace falta es pedir el alta del servicio y, una vez realizados los trámites pertinentes, recibimos como respuesta una serie de parámetros de configuración que debemos añadir al gitlab. Para esto entraremos a gitlab y, en la barra de la izquierda, iremos a SETTINGS -> CI/CD.

Ahora hacemos “expand” a las variables y hacemos “add value” y añadimos los valores que nos han llegado.

Estos valores configuran donde se encuentra nuestro “artifactory” (lugar dónde dejaremos las imágenes de nuestra aplicación) y con qué usuario y contraseña accederemos.

También configuramos API y el TOKEN del RUNDECK (consola para la automatización de tareas que se acceden vía API).

Llegados a este punto, ya tenemos entorno preparado para poder empezar con el CD. En el caso de gitlab, todo el referente a CI/CD pasa por el fichero de configuración llamado .gitlab-ci.yml.

Una primera versión de este fichero será la siguiente:

Fijémonos que definimos 3 etapas (test, build_pre i deploy_pre).

En este artículo no haremos referencia a la etapa de test, ya que se trata de ejecutar todo aquello que hace falta para verificar que nuestra app funciona.

El build_pre lo que hace es construir las imágenes docker de nuestra app (necesitamos tener un fichero DOCKERFILE en nuestro repositorio donde explicitamos como se deben construir cada una de las imágenes del proyecto).

En este caso del ejemplo en cuestión, nuestra APP estaba formada por BD+ API+UI. La base de datos, como era imagen docker por defecto, no hacía falta que la construyésemos, por tanto lo que haremos es:

  • Construimos las imágenes que sí necesitamos (API y UI).
  • Nos autenticamos contra el artifactory.
  • Hacemos push de las imágenes que hemos creado.

 

Antes de seguir dejadme hacer una breve explicación del funcionamiento del .gitlab-ci.yml

Nosotros, como desarrolladores, hacemos de repente: git push origin master para subir el código al repositorio, si tenemos el fichero .gitlab-ci.yml bien configurado en cada push se ejecutará la etapa de test, pero no se ejecutarán las otras etapas (para no hacer un CD cada vez que hacemos un push).

Cuando nosotros decidimos que queremos hacer una imagen nueva de nuestra app, tendremos que ejecutar las siguientes comandas:

  • git push origin master (comprobamos que no hemos roto nada)
  • git tag <num_versió>
  • git push –tags

Este comportamiento que la etapa de build_pre y deploy_pre, que solo se hacen cuando hacemos un tag, lo configuramos con las líneas siguientes dentro de las etapas de build_pre y deploy_pre:

Si acabásemos aquí el artículo, lo que habríamos hecho es Continuous Delivery, tenemos las imágenes a punto de ser desplegadas, pero el despliegue se haría manualmente.

Pero nosotros queremos ir más allá, queremos desplegar, por eso añadimos en nuestro .gitlab-ci.yml  en el apartado variable, todas las variables siguientes:

Y debajo de la etapa de build_pre añadimos la etapa de deploy_pre:

Lo que hacemos con estas líneas es coger las imágenes del artefactory  y las copiamos en el RUNDECK mediante  API, el TOKEN y el JOB_ID que hemos definido (unas cosas están en el Settings del gitlab y el job está en las variables del fichero .gitlab-ci.yml)

Si todo ha ido bien, llegados a este punto podemos acceder a nuestra APP (en la URL y Puerto donde la hemos definido) y podremos ver los logs de la APP mediante el kibana.

Segueix-nos a

Els nostres articles del bloc d'inLab FIB

         
         

inLab FIB incorpora esCert

Icona ESCERT

First LogoCSIRT Logo

inLab es miembro de

inLab és centre TECNIO

ACCIO