Slide 1

Slide 1 text

INTEGRACIÓN CONTINUA CON GITLAB CI/RUNNER Y DOCKER NACHO ÁLVAREZ @NEONIGMACDB

Slide 2

Slide 2 text

ÍNDICE • ¿Docker? • CI / CD • Plataformas disponibles • The Chosen One: Gitlab CI • Configurando jobs con gitlab-ci.yml • Demo

Slide 3

Slide 3 text

UN POCO DE CONTEXTO ¿DOCKER? • La idea detrás de Docker es crear contenedores ligeros y portables para las aplicaciones software que puedan ejecutarse en cualquier máquina con Docker instalado • Los dos elementos más básicos de Docker son las imágenes y los contenedores: • Una imagen es una especie de plantilla, una captura del estado de un contenedor. Podríamos decir que una imagen de un contenedor es como un snapshot de una máquina virtual, pero mucho mucho más ligero. • Los contenedores son instancias en ejecución de una imagen. Son los que ejecutan nuestra aplicación con todos los recursos necesarios integrados. El concepto de contenedor es como si restauráramos una máquina virtual a partir de un snapshot.

Slide 4

Slide 4 text

UN POCO DE CONTEXTO ¿DOCKER? DOCKER VMs

Slide 5

Slide 5 text

UN POCO DE CONTEXTO ¿DOCKER? • La principal diferencia entre ambas tecnologías es que, por un lado, cuando virtualizamos un sistema operativo con VirtualBox instalamos y ejecutamos el 100% del sistema operativo, con su kernel, su entorno, sus librerías, sus dependencias, etc. Igual que instalamos Windows o Linux en un ordenador real se instala al completo en VirtualBox. • Cuando utilizamos los contenedores de Docker, por ejemplo, la cosa cambia. En lugar de virtualizar un sistema operativo completo, solo creamos un pequeño kernel con las librerías y dependencias necesarias para realizar nuestra tarea, obviando todo lo demás. De esta manera, los contenedores no son un sistema operativo virtual como tal, sino más bien se entienden como “paquetes” que se ejecutan aislados sobre el sistema operativo principal, pero sin depender de un sistema virtual.

Slide 6

Slide 6 text

COMPOSICIÓN DE IMÁGENES DOCKER • Se puede utilizar un fichero Dockerfile que contiene los comandos para construir una imagen propia FROM ubuntu:latest MAINTAINER john doe RUN apt-get update RUN apt-get install -y python python-pip wget RUN pip install Flask ADD hello.py /home/hello.py WORKDIR /home

Slide 7

Slide 7 text

COMPOSICIÓN DE IMÁGENES DOCKER • También se puede utilizar docker-compose • Es una herramienta para definir y ejecutar aplicaciones Docker multi-contenedores. • Se definen los servicios que constituyen tu app en un fichero docker-compose.yml de forma que se puedan ejecutar en entorno aislado • Con un simple comando docker-compose up levantas el contenedor con tu app

Slide 8

Slide 8 text

COMPOSICIÓN DE IMÁGENES DOCKER version: '3' services: db: image: postgres web: build: . command: python manage.py runserver 0.0.0.0:8000 volumes: - .:/code ports: - "8000:8000" depends_on: - db FROM python:3 ENV PYTHONUNBUFFERED 1 RUN mkdir /code WORKDIR /code COPY requirements.txt /code/ RUN pip install -r requirements.txt COPY . /code/ Dockerfile docker-compose.yml

Slide 9

Slide 9 text

BÚSQUEDA DE IMÁGENES DOCKER • Existe un repositorio público de imágenes, el Docker Hub, además de las miles que puedes encontrar en Github • Puedes utilizar directamente el comando ‘docker search’ para buscar una imagen

Slide 10

Slide 10 text

TRASTEAMOS UNA IMAGEN Y LEVANTAMOS VARIOS CONTENEDORES DEMO

Slide 11

Slide 11 text

Y SUS DIFERENCIAS CI/CD • Integración Continua (Continuous Integration) • Entrega Continua (Continuous Delivery) • Despliegue Continuo (Continuous Deployment)

Slide 12

Slide 12 text

CONTINUOUS INTEGRATION CI/CD • Los desarrolladores suben su código al menos una vez al día • El código se construye (compila) en cada subida • Se lanzan tests unitarios de forma automática en cada subida • Cualquier desarrollador permitido tiene acceso a los informes de construcción y testing • Los entregables se almacenan en un repositorio controlado de artefactos • Los entregables se despliegan automáticamente en un entorno de test tras una construcción exitosa

Slide 13

Slide 13 text

CONTINUOUS DELIVERY CI/CD • El software es desplegable a través de su ciclo de vida • El equipo prioriza mantener el software desplegable por encima de trabajar en nuevas características • Todo el mundo obtiene feedback rápido y automatizado sobre la preparación de producción de sus sistemas cada vez que alguien les hace un cambio • Puedes realizar (pulsando un botón) despliegues de cualquier versión del software a cualquier entorno a demanda • Hay una cercana y colaborativa relación de trabajo entre las personas involucradas en la entrega (a menudo referida como "cultura DevOps") • Se consigue una automatización extensiva de todas las posibles partes del proceso de entrega, habitualmente a través de un Deployment Pipeline

Slide 14

Slide 14 text

CONTINUOUS DEPLOYMENT CI/CD • Todos los cambios van a producción directamente • Se obtiene feedback incluso más rápido • Las partes que no se han terminado aún también se despliegan a producción, de esta forma se obtiene feedback sobre el despliegue de esa nueva parte • Es posible también dejar a un pequeño grupo de usuarios testear la nueva funcionalidad para recibir feedback rápido

Slide 15

Slide 15 text

CI/CD

Slide 16

Slide 16 text

CI/CD

Slide 17

Slide 17 text

PLATAFORMAS DISPONIBLES

Slide 18

Slide 18 text

GITLAB CI THE CHOSEN ONE

Slide 19

Slide 19 text

GITLAB CI THE CHOSEN ONE

Slide 20

Slide 20 text

FUNCIONALIDADES GITLAB CI • Pipeline: define múltiples jobs por etapa e incluso disparan otros pipelines. • Build artifacts: sube binarios y otros build artifacts a GitLab, navega por ellos y descárgalos. • Testing local: reproducir tests localmente utilizando 'gitlab-runner exec'. • Soporte Docker: utiliza imágenes Docker personalizadas, levanta servicios como parte del testing, construye nuevas imágenes Docker, ejecútalas en Kubernetes... • Container Registry: registro de contenedores integrado para almacenar, compartir y utilizar imágenes de contenedor. • Entrega Continua (CD): entrega y despliegue continuo fácil con múltiples tipos de jobs, y variables de entorno seguro. • Entornos: define múltiples entornos incluyendo Revisión Aplicaciones, visualiza histórico de despliegue para cada entorno.

Slide 21

Slide 21 text

CONFIGURANDO JOBS CON .GITLAB-CI.YML GITLAB CI •Si se añade un fichero .gitlab-ci.yml al directorio raiz del repositorio, y se configura el proyecto para usar un Runner, cada commit o push dispara nuestro pipeline CI.
 •El fichero .gitlab-ci.yml le dice a GitLab Runner qué hacer. Por defecto, ejecuta un pipeline con tres etapas: build, test y deploy. No necesitamos usar las tres concretamente; las etapas sin jobs se ignoran.
 •Si todo ejecuta OK (no se devuelven valores diferentes de 0), obtendremos una marca verde asociada al commit. Esto hace más sencillo ver si un commit causa que cualquiera de los tests fallen antes incluso de mirar el código.
 •La mayoría de los proyectos de hecho usan GitLab CI para ejecutar la suite de tests de forma que los desarrolladores obtengan feedback inmediato acerca de si han roto algo.

Slide 22

Slide 22 text

CONFIGURANDO JOBS CON .GITLAB-CI.YML GITLAB CI •El fichero YAML define un conjunto de jobs con restricciones especificando cuándo deberían ejecutarse. Puedes especificar un número ilimitado de jobs que se definen como elementos de alto nivel con un nombre arbitrario y siempre tienen que contener al menos la cláusula script. •Los jobs son recolectados por Runners y ejecutados dentro del entorno del Runner. Lo más importante, es que cada job es ejecutado independientemente de cualquier otro. •Un job se define por una lista de parámetros que definen el comportamiento del job. •https://docs.gitlab.com/ee/ci/yaml/README.html

Slide 23

Slide 23 text

SHOW ME THE MONEY! https://www.openshine.com/oferta-devops.html http://www.expansion.com/expansion-empleo/ empleo/2018/05/10/5af434a6e5fdea603f8b45b7.html

Slide 24

Slide 24 text

DEL LADO DEL DESARROLLADOR Y DEL LADO DEL DEVOPS DEMO

Slide 25

Slide 25 text

INTEGRACIÓN CONTINUA CON GITLAB CI/RUNNER Y DOCKER NACHO ÁLVAREZ @NEONIGMACDB