TÍTULO: TUBERÍAS DE

DESPLIEGUE CONTINUO CON

DOCKER Y GITLAB.

Autora: Lic. Laura Ben Artiles

septiembre, 2020
 INTRODUCCI
ÓN
Las metodologías tradicionales de desarrollo de software no son
suficientes para cumplir con los requisitos comerciales actuales, por lo que
en los últimos años DevOps y el paradigma de integración continua se han
convertido en un pilar fundamental dentro de cualquier empresa de
desarrollo. Al adoptar estas prácticas los equipos adquieren la capacidad de
responder mejor a las necesidades de los clientes y alcanzan los objetivos
en menos tiempo.
Para asegurar que la instauración de DevOps llegue a buen puerto en una
empresa es imprescindible diseñar y definir tuberías de despliegue
continuo que automaticen todo el proceso de desarrollo.
 INGENIERÍA CONTINUA COMO PARTE
FUNDAMENTAL DE LA CULTURA DEVOPS
En la actualidad en las empresas de desarrollo de software una de las cuestiones cruciales es
cómo desplegar un producto lo más rápido posible y llevarlo al alcance del usuario con la
mejor calidad. Muchas veces solamente hay un esfuerzo y enfoque en optimizar el diseño y
el desarrollo del código y no se presta toda la atención necesaria a otras etapas del ciclo de
vida del software que son las que en definitiva garantizarán una entrega rápida y con
pocos errores a los clientes.

Hoy, DevOps está siendo visto como el método más eficiente para el desarrollo de software.
Este tiene como objetivo integrar los equipos de desarrollo y operaciones para permitir la
entrega rápida de software. Al impulsar mejores comunicaciones y colaboración, ayuda a
acortar los ciclos de desarrollo, aumentar la frecuencia de implementación y satisfacer las
necesidades comerciales de la mejor manera posible. Con DevOps, las organizaciones de
software pueden reducir la complejidad del desarrollo, detectar y resolver problemas más
rápido y ofrecer continuamente software innovador y de alta calidad
DevOps es una colaboración entre los equipos de desarrollo y operaciones
que permite la entrega continua de aplicaciones y servicios a los usuarios
La ingeniería continua de software es un área emergente de investigación y
práctica. Se refiere a desarrollar, implementar y obtener comentarios del software y
del cliente en un ciclo muy rápido.

La Integración Continua (CI), Entrega Continua (CDE) y el Despliegue

Continuo (CD), llamadas prácticas continuas, son algunas de las prácticas
destinadas a ayudar a las organizaciones a acelerar su desarrollo y entrega de
funciones de software sin comprometer la calidad.

Mientras que CI aboga por la integración del trabajo en progreso varias veces al
día, CDE y CD tienen la capacidad de liberar valores de manera rápida y confiable
a los clientes al brindar el soporte de automatización tanto como sea posible.
 TUBERÍA DE INTEGRACIÓN Y
DESPLIEGUE CONTINUOS
La implementación de una tubería de CI/CD, o Integración Continua/Despliegue
Continuo, es la columna vertebral del entorno moderno de DevOps. Sirve de
puente entre los equipos de desarrollo y operaciones, automatizando la
construcción, las pruebas y el despliegue de las aplicaciones.

En la práctica, el CD se logra mediante el desarrollo y el mantenimiento de una

tubería de despliegue. Una tubería típica de CI/CD debe incluir las siguientes
fases: subir cambios en el código a un sistema de control de versión, compilación,
prueba, despliegue, pruebas automatizadas y despliegue a producción.
Los componentes y herramientas necesarios para construir una tubería
dependen de las necesidades particulares del equipo y del flujo de trabajo
existente. Un posible ejemplo de tubería de despliegue continuo se puede
apreciar en la Figura 2
 TECNOLOGÍA DE CONTENEDOR DE SOFTWARE

Los contenedores de software proporcionan un medio para encapsular la funcionalidad

dentro de un espacio de proceso aislado. La tecnología de contenedores resuelve dos
problemas claves, lo que permite la construcción de tuberías de despliegue rápido y
estrategias avanzadas de implementación de software.
En primer lugar, el problema de “funciona en mi máquina”, pues el contenedor
contiene tanto el código como el entorno de ejecución, o sea las dependencias de
bibliotecas, el sistema operativo subyacente y la configuración del entorno, etc. Esto
significa que un contenedor que se ejecuta con éxito en un entorno de prueba puede
promoverse a producción con un alto grado de confianza de que se ejecutará
correctamente, eliminando preocupaciones de diferencias en la versión del sistema
operativo y cadenas complejas de dependencia de código.
En segundo lugar, los contenedores proporcionan una abstracción homogénea que
permite que los scripts de implementación y las herramientas se ocupen de una sola
entidad, independientemente de lo que se ejecute dentro del contenedor
La arquitectura del contenedor es diferente a la de una máquina virtual. El contenedor
comparte el sistema operativo en el que cada proceso en ejecución está aislado dentro
del espacio del usuario por lo que los contenedores acaban consumiendo menos
espacio que la máquina virtual. Los contenedores superan a la máquina virtual en
diferentes comportamientos como un mejor tiempo de inicio, distribución de
recursos y menor redundancia.
 DOCKER

La tecnología de contenedores comenzó a ganar una amplia adopción en 2013 a través del
proyecto Docker. Para hacer que la aplicación sea independiente de la plataforma, se genera una
imagen de construcción de paquetes del código usando Docker, el cual permite empaquetar,
construir, probar y desplegar cada una de las aplicaciones en un entorno Linux aislado llamado
contenedor.

Un contenedor Docker contiene todo lo necesario para ejecutar el software de forma

independiente. Puede haber varios contenedores Docker en una sola máquina y estos están
completamente aislados unos de otros, así como de la máquina anfitriona. En otras palabras, un
contenedor Docker incluye un componente de software junto con todas sus dependencias
(binarios, librerías, archivos de configuración, scripts, jars, etc.)
 TERMINOLOGÍA BÁSICA DE DOCKER
Imágenes: Una imagen es una plantilla de solo lectura, un componente de construcción
de Docker desde el cual se lanzan los contenedores. Cada imagen comienza con una
imagen base. Con Docker, las imágenes pueden ser construidas localmente o descargadas
desde un repositorio de fuente remota.

Contenedores: El contenedor es una instancia de ejecución de una imagen de Docker

que consiste en una imagen Docker, un entorno de ejecución y un conjunto de
instrucciones estándar. Un contenedor Docker se crea a partir de una imagen Docker que
puede ser ejecutada, iniciada, detenida o eliminada a voluntad con muy poco esfuerzo.

Docker Daemon: El servicio de fondo que se ejecuta en el host que gestiona la

construcción, el funcionamiento y la distribución de los contenedores Docker. El
demonio es el proceso que se ejecuta en el sistema operativo con el que los clientes se
comunican.
Docker Client: La herramienta de línea de comandos que permite al usuario
interactuar con el demonio.

Docker Registry: Las imágenes de Docker se almacenan generalmente en depósitos

compartidos llamados registros Docker. Los registros permiten descargar o subir
imágenes a través de un conjunto de comandos del cliente Docker, que facilitan la
distribución de las imágenes y que, junto con otras partes de la tecnología Docker,
contribuyen a crear una nueva forma de distribuir las aplicaciones que pueden tener
los desarrolladores, al igual que trabajar con la gestión del código fuente.

Dockerfile: Es un documento de texto que contiene instrucciones para construir una

imagen Docker.
 ARQUITECTURA DE DOCKER
Docker utiliza una arquitectura cliente-servidor. Los usuarios de Docker utilizan un
conjunto de comandos Docker del componente client para interactuar con el Docker
host a través del Docker daemon que se ejecuta en el host.
Por su parte, el Docker daemon hace la construcción, ejecución y distribución de
contenedores Docker, así como la publicación de imágenes a un registro Docker
particular. El Docker client puede funcionar en el mismo sistema con Docker daemon,
o en uno diferente y luego interactuar remotamente con el daemon.
Componentes básicos de Docker y la relación entre estos
CICLO DE VIDA DE UNA APLICACIÓN
CONTENEDORIZADA CON DOCKER
 IMÁGENES DE DOCKER. DOCKERFILE

Para obtener una nueva imagen de Docker se puede descargar desde un registro de
Docker como Docker Hub el cual posee miles de imágenes disponibles. O se puede
crear una imagen propia. Además, el comando docker search permite buscar
imágenes disponibles desde la interfaz de línea de comandos.

Dockerfile es un script de construcción basado en texto que contiene instrucciones

especiales en una secuencia para construir las imágenes correctas y relevantes a
partir de las imágenes base. Las instrucciones secuenciales dentro del Dockerfile
pueden incluir la selección de la imagen base, la instalación de la aplicación
requerida, la adición de la configuración y los archivos de datos, y la ejecución
automática de los servicios.

El Dockerfile soporta diferentes instrucciones, que le dicen a

este cómo construir la imagen y cómo ejecutarla dentro de un contenedor.
EL DOCKERFILE SOPORTA DIFERENTES INSTRUCCIONES, QUE LE DICEN A
ESTE CÓMO CONSTRUIR LA IMAGEN Y CÓMO EJECUTARLA DENTRO DE UN
CONTENEDOR.

Además de esto se ha creado un archivo app1.sh que permite ejecutar la aplicación anterior.
 FROM crea una capa que se tomará como
imagen base, en este caso ubuntu18.04.
ENV NAME especifica las variables de
ambiente que pudieran pasarse como argumentos
por línea de comandos a la aplicación. En este
caso se aceptan tres como máximo.
COPY copia los archivos especificados desde
nuestro directorio hasta la imagen.
WORKDIR cambia el directorio de trabajo en la
imagen a /Ejemplo.
RUN compila el archivo aplicacion1.cpp y crea
un ejecutable con el mismo nombre.
CMD corre el ejecutable creado en el paso
anterior utilizando el archivo shell script.

docker build -t cppImage1

docker run -it -e ARG1='7' cppImage1

PUBLICACIÓN DE IMÁGENES EN REGISTROS DOCKER

Para simplificar su distribución, las imágenes se guardan en un registro en línea. El

registro actúa como un sistema de almacenamiento y entrega de contenido, que
contiene imágenes Docker nombradas. Algunos registros populares de Docker son
Docker Hub, Quay.io, Artifactory, Google Container Registry y el registro de
contenedores IBM Cloud.

Docker Hub proporciona un depósito público y privado. El repositorio público es

gratuito para los usuarios y el privado es un servicio de pago.

Normalmente, a las empresas no les favorece mantener sus imágenes Docker en un

repositorio Docker público o privado. Prefieren mantener, conservar y dar soporte a su
propio repositorio. Por lo tanto, Docker también ofrece la opción de que las empresas
creen e instalen su propio repositorio mediante Docker Registry que es una aplicación
de servidor altamente escalable que almacena y permite distribuir imágenes de Docker.
El registro es de código abierto, bajo la licencia permisiva de Apache.
INTERACCIÓN ENTRE EL DOCKER
CLIENT Y LOS REGISTROS DE IMÁGENES

Desoft cuenta con un registro para

descargar las imágenes de Docker en
la dirección:
docker.cloud.desoft.cu
 AMBIENTES MULTICONTENEDORES

Al igual que es una buena estrategia desacoplar los niveles de aplicación, es prudente
mantener los contenedores para cada uno de los servicios por separado. Es probable que
cada nivel tenga necesidades de recursos diferentes y que esas necesidades crezcan a
ritmos diferentes.

Docker Compose es una herramienta de orquestación para Docker que permite definir
un conjunto de contenedores y sus interdependencias en forma de un archivo YAML.
Proporciona un archivo de configuración llamado docker-compose.yml que se puede
utilizar para echar a andar una aplicación y el conjunto de servicios de los que depende
con un solo comando.

Para las aplicaciones que requieren servicios externos como MySQL, Postgres, Redis,
Nginx, HAProxy, etc., Docker ofrece una forma sencilla de abstraerlos en contenedores
que son fáciles de gestionar y desplegar para el desarrollo o la producción.
El uso de Compose es básicamente un proceso de tres pasos:
1. Definir el entorno de aplicación con un Dockerfile para que pueda ser reproducido en
cualquier lugar.
2. Definir los servicios que componen la aplicación en un archivo docker-compose.yml para
que se puedan ejecutar juntos en un entorno aislado.
3. Introducir el comando docker-compose up para que Compose se inicie y ejecute toda la
aplicación.

El siguiente ejemplo demuestra cómo construir una aplicación web simple en Python, la cual
usa el framework Flask y mantiene un contador de entradas en Redis. Se deberá tener
instalado Docker y Docker Compose, las instalaciones de Python o Redis no son necesarias
pues se obtendrán directamente de imágenes Docker.
Será necesario tener otro archivo
requirements.txt con los
requerimientos de la aplicación:

El siguiente paso es crear un

archivo Dockerfile que construya
la imagen Docker. Esta contendrá
todas las dependencias que la
aplicación Python necesita,
incluyendo el mismo Python
Brevemente este pequeño archivo de configuración le
está diciendo a Docker que:
Construya una imagen tomando como base la imagen
python:3.7-alpine
Establezca como directorio de trabajo /code
Establezca las variables de ambientes usadas por el
comando flask
Instale gcc para que algunos paquetes de Python como
MarkupSafe y SQLAlchemy puedan compilar
aceleraciones
Copie requirements.txt e instale las dependencias de
Python
Copie el directorio actual del proyecto . para el
directorio de trabajo . de la imagen
Establezca como comando por defecto del contendor
flask run
 CREAR UN ARCHIVO DOCKER-COMPOSE.YML CON LAS
SIGUIENTES CONFIGURACIONES PARA DEFINIR LOS SERVICIOS

El archivo anterior define dos servicios: web y redis.

El servicio web usa una imagen que es construida desde el
Dockerfile que se encuentra en el directorio actual. Luego vincula
el contenedor y la máquina anfitriona al puerto expuesto, 5000.
La llave volumes monta el directorio del proyecto (directorio
actual) en el host en /code dentro del contenedor
El servicio redis utiliza una imagen pública de Redis

En el directorio del proyecto se puede iniciar la aplicación usando

el comando docker-compose up.
Se puede usar docker-compose ps para obtener los contendores
que se están ejecutando en el momento
El comando docker-compose down eliminará completamente los
contenedores
INTEGRACIÓN Y DESPLIEGUE
CONTINUOS
Las herramientas que deben usarse en la construcción de una tubería de despliegue
continuo para la empresa Desoft deben ser por razones obvias open source o
proyectos de software libre.
El sistema de control de versiones que se propone por su gran aceptación mundial es
Git.
Las tuberías que se diseñen requieren que el proyecto sea primeramente
contenedorizado y para esto se usará la herramienta Docker.
Se propone el uso de la herramienta GitLab CI/CD para las etapas de integración y
despliegue continuos, ya que ofrece un ciclo de vida completo de desarrollo-
construcción-implementación con configuraciones de flujo de trabajo sofisticadas.
GITLAB
CI/CD
GitLab es algo más que la gestión de código fuente o CI/CD. Es una herramienta
completa de desarrollo de software y de DevOps en una sola aplicación. GitLab
CI/CD es una potente herramienta integrada en GitLab que permite aplicar todos los
métodos continuos (Integración, Entrega y Despliegue continuos) a un software, sin
necesidad de otras aplicaciones o integración de terceros.
CARACTERÍSTICAS Y
VENTAJAS DE GITLAB CI/CD
 Multiplataforma: se pueden ejecutar construcciones en Unix, Windows, macOS y
cualquier otra plataforma que soporte el lenguaje Go.
 Multilenguaje: Los scripts de construcción están dirigidos por la línea de
comandos y funcionan con Java, PHP, Ruby, C, y cualquier otro lenguaje.
 Tuberías flexibles: se pueden definir múltiples trabajos paralelos por etapas y se
pueden desencadenar otras construcciones.
 Soporte de Docker: permite usar imágenes Docker personalizadas, activar
servicios como parte de las pruebas y construir nuevas imágenes.
 Registro de Contenedores: se encuentra incorporado para almacenar, compartir y
utilizar las imágenes de los contenedores.
Los pipelines de GitLab CI/CD construyen, prueban, despliegan y monitorean el código como
parte de un único e integrado flujo de trabajo.

Permite construir aplicaciones usando GitLab Runners, ejecutar pruebas unitarias y de

integración, despliegue a múltiples ambientes como los de preparación y producción, y
monitorear el rendimiento y el estado de las aplicaciones.

Para usar GitLab CI/CD, todo lo que se necesita es una base de código de aplicación alojada en
un repositorio Git, y que los scripts de construcción, prueba y despliegue se especifiquen en un
archivo llamado .gitlab-ci.yml, situado en la ruta raíz del repositorio.

Una vez añadido el archivo de configuración .gitlab-ci.yml al repositorio, GitLab lo

detectará y ejecutará los scripts con la herramienta llamada GitLab Runner, que funciona de
forma similar a una terminal. Los scripts se agrupan en trabajos (jobs), y juntos componen una
tubería o pipeline.
FLUJO DE
TRABAJO
GITLAB RUNNER
GitLab Runner es el proyecto de código abierto que se utiliza para ejecutar trabajos y enviar
los resultados a GitLab.
En GitLab, los Runners ejecutan los trabajos que se definen en el archivo .gitlab-
ci.yml. Un Runner puede ser una máquina virtual, un servidor virtual privado, un
contenedor Docker o incluso un cluster de contenedores.
GitLab y los Runners se comunican a través de una API, por lo que el único requisito es que la
máquina del Runner tenga acceso de red al servidor de GitLab.
Un Runner puede ser específico para un determinado proyecto o servir a múltiples proyectos
en GitLab (compartido).
GitLab Runner implementa varios ejecutores que pueden ser usados para correr las
construcciones en diferentes escenarios, estos son: SSH, Shell, Parallels, VirtualBox, Docker,
Docker Machine y Kubernetes.
GITLAB CONTAINER
REGISTRY
GitLab Container Registry es un registro seguro y privado de imágenes de Docker.
Construido sobre software de código abierto, no es solo un registro independiente, sino
que está completamente integrado con GitLab desde la versión 8.8 lanzada en 2016.
Ventajas:
•La autenticación de los usuarios se realiza desde el propio GitLab, por lo que se
respetan todas las definiciones de usuario y de grupo.
•No es necesario crear repositorios en el registro; el proyecto ya está definido en
GitLab.
•Los desarrolladores pueden subir y descargar fácilmente imágenes del GitLab CI.
•No hay necesidad de descargar o instalar software adicional
MODELO DE FLUJO
DE LA TUBERÍA
•La tubería final debe ser en gran medida
reusable y garantizar un alto nivel de
automatización.
El despliegue puede llevarse a cabo de dos
formas diferentes:
•la primera radica en instalar y copiar
todos los componentes y artefactos
necesarios directamente en el servidor de
producción.
•la segunda en entregar la aplicación como
un contenedor de Docker que pueda ser
ejecutado en cualquier momento en el
servidor de producción (no requiere que el
servidor de producción proporcione
componentes adicionales aparte de
Docker)
PROYECTOS EN GITLAB
Cada proyecto de GitLab pertenece a un grupo o subgrupo y tiene su propia URL. Estos
pueden ser privados, internos o públicos. Los proyectos pueden ser creados desde cero o
mediante plantillas ya definidas, además pueden ser importados desde otros servicios como
Google Code, GitHub u otro repositorio cualquiera con una URL.
Un proyecto típico que utilice Docker y al que se le vayan a realizar los procesos de CI/CD
en un pipeline de GitLab deberá contar mínimo con los siguientes archivos:
•El directorio site contendrá todo el código de la aplicación.

•En el Dockerfile se encuentran las instrucciones para

construir la imagen Docker de la aplicación.

•El archivo .gitlab-ci.yml contiene las operaciones y

los comandos que deberán ser ejecutados por los Runners cada
vez que se produzca un push en el repositorio.
ARCHIVO DE
CONFIGURACIÓN .GITLA-
CI.YML
A continuación se expone un archivo de configuración de GitLab CI que puede servir
como plantilla para varios proyectos, pues se corresponde con el diseño de flujo de
trabajo presentado anteriormente y lleva a cabo todas las etapas principales de una
tubería de despliegue continuo integrada con Docker, como son: construcción de
imágenes, ejecución de pruebas, almacenamiento de estas en registros privados, y
despliegue a un ambiente de producción.
 CONCLUSIONES
El flujo de trabajo de CI/CD propuesto en la tubería es completamente automatizado y
colaborativo y el diseño propuesto garantiza la obtención de resultados relativamente
rápidos en la implementación al apostar por GitLab como servidor de CI, ya que este
ofrece un ecosistema completo de herramientas, integradas y listas para usar, todo en un
mismo paquete.

La tubería propuesta se integra perfectamente con la herramienta de contenedorización

Docker, lo que garantiza que luego de construir una imagen para una aplicación, cada
miembro del equipo pueda tener acceso al mismo ambiente, lo que facilita el proceso de
desarrollo y evita conflictos de versiones y dependencias. Esta integración además dota a
la tubería de estandarización y flexibilidad, así como de gran eficiencia en el empaquetado
y despliegue de aplicaciones.