Integración Continua con Gitlab CI/Runner y Docker

Cómo montar un entorno de entrega continua con Gitlab CI, Gitlab Runner y Docker

Transcript

1. INTEGRACIÓN CONTINUA CON GITLAB CI/RUNNER Y DOCKER NACHO ÁLVAREZ @NEONIGMACDB
2. ÍNDICE • ¿Docker? • CI / CD • Plataformas disponibles • The Chosen One: Gitlab CI • Configurando jobs con gitlab-ci.yml • Demo
3. 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.
4. UN POCO DE CONTEXTO ¿DOCKER? DOCKER VMs
5. 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.
6. 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
7. 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
8. 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
9. 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
10. TRASTEAMOS UNA IMAGEN Y LEVANTAMOS VARIOS CONTENEDORES DEMO
11. Y SUS DIFERENCIAS CI/CD • Integración Continua (Continuous Integration) • Entrega Continua (Continuous Delivery) • Despliegue Continuo (Continuous Deployment)
12. 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
13. 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
14. 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
15. CI/CD
16. CI/CD
17. PLATAFORMAS DISPONIBLES
18. GITLAB CI THE CHOSEN ONE
19. GITLAB CI THE CHOSEN ONE
20. 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.
21. 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.
22. 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
23. SHOW ME THE MONEY! https://www.openshine.com/oferta-devops.html http://www.expansion.com/expansion-empleo/ empleo/2018/05/10/5af434a6e5fdea603f8b45b7.html
24. DEL LADO DEL DESARROLLADOR Y DEL LADO DEL DEVOPS DEMO
25. INTEGRACIÓN CONTINUA CON GITLAB CI/RUNNER Y DOCKER NACHO ÁLVAREZ @NEONIGMACDB