ATICA DevOps

ATICA
DevOps
v2.0
Construcción y despliegue de aplicaciones en el siglo XXI
Juan José Meroño Sánchez
Noviembre 2017

Contexto
● Cómo se desarrolla y se despliegan aplicaciones en Atica.
○ Control de versiones con SVN.
○ Marco de desarrollo homogéneo (FundeWeb)
○ Integración contínua con Jenkins.
○ Despliegue con Jenkins apoyado en pulling SVN y scripts de sistemas.
Subversion Subversion
Rama Codigo Fuente Rama Servidores
Jenkins Desa/Test/Prod
restart, update,...
Build, tests, deploy...

Contexto
● Jenkins pieza clave
○ Realiza tareas fundamentales durante el ciclo de vida.
○ Lamentablemente no lo tenemos protegido como se merece.
○ No hay control de cambios sobre lo que Jenkins hace (desplegar).
○ No hay control de cambios sobre la infraestructura necesaria en el proyecto.
○ El repositorio del proyecto debería guardar toda la información necesaria:
■ Código fuente. << OK
■ Información de la build. << OK
■ Información del despliegue. << Pipeline
■ Información de la Infraestructura. << Docker

Contexto
● Concepto de pipeline
○ Construir y desplegar un proyecto requiere varios pasos.
○ La idea es describir esos pasos en un fichero e incorporarlo al proyecto.
○ De ese modo en el repositorio del proyecto ya está todo lo necesario.
○ Permite ejecutar el pipeline para cualquier rama sin esfuerzo extra.

Contexto
● Aprovechando el cambio de concepto
○ Simplificar procesos de Jenkins (eliminar trabajo extra).
■ [1] Jenkins realiza merges de ramas de código.
■ [2] Se despliega haciendo commits sobre subversion.
● [1] Sería más sencillo con GitLab
○ Los merges se hacen en la plataforma de control de versiones.
○ El pipeline describe cómo crear una versión ejecutable partiendo de la rama.
● [2] Sería más sencillo con Docker
○ La integración contínua crea una imagen y la sube a un repositorio.
○ El despliegue simplemente descarga y lanza la imagen.

Objetivo
● Mi propuesta de desarrollo y despliegue para Atica.
○ Control de versiones con Git/Gitlab.
○ Marco de desarrollo homogéneo (FundeWeb).
○ Integración contínua con Gitlab Runner/Gitlab.
○ Despliegue con Docker/Gitlab.
Gitlab
Docker Swarm
Desa/Test/Prod
Pipeline
Build, tests, deploy...
Docker Registry
Container Container
Container Container
Container Container
Container Container

Primer paso
GitLab: Internal Open Source

GitLab
● Se presenta como la plataforma ideal
○ Gitlab CE permite instalación on-premise (gitlab.atica.um.es).
○ Incluye Git para el control de versiones.
○ Merge Request para reintegrar las ramas de desarrollo en las protegidas.
○ Integración continua con GitLab Runner que permite usar docker.
○ Registro interno de imágenes docker.
○ Para qué mantener SVN + Jenkins si lo tienes junto en gitlab.
● Ofrece herramientas extra y mucho más
○ Issues (no nos hacen falta).
○ Wiki.
○ Snippets.
○ Estadísticas de actividad.
○ Más orientado a la colaboración entre el equipo del proyecto.

Subversion/Git
● Subversion es opaco
○ El resto del equipo no ve nada hasta que no se integra.
○ Para colaborar necesitas permisos en el repositorio
remoto.
● Git es transparente
○ Permite el equipo consensuar antes de integrar.
○ Ofrece comparativa de código.
○ Permite comentar los cambios.
○ Establecer workflow a la hora de revisar modificaciones.
○ Posibilidad de colaborar en otros proyectos sólo con
permisos de lectura en el repositorio remoto (fork).

Git
Internal Open Source
alice, david, bob y clair son
miembros del proyecto y tienen
permisos en el repositorio
alice, david, bob y clair NO son
miembros del proyecto NI tienen
permisos en el repositorio, pero
pueden colaborar igualmente

Git
Always work in your branch
http://nvie.com/posts/a-successful-git-branching-model/
● Mantener protegidas las ramas
que se despliegan en los entornos
de pruebas y producción. Impide
el push.
● Colabora en los proyectos de los
que eres miembro igual que
harías en uno en el que no tienes
permisos.
Always Merge Request

Segundo paso
Docker: Open Source Infrastructure

Docker
● La magia de los contenedores
○ Permite generar imágenes (una especie de VM).
○ Ejecutarlas como procesos aislados denominados contenedores.
○ La diferencia entre entornos desaparece.
○ Disponemos de versiones de las máquinas ejecutables.
● Despliegue de stacks
○ Se pueden desplegar servicios (contenedores) agrupados en stacks.
○ Indicando condiciones de servicio (réplicas de cada contenedor,...)
○ Especificando redes, volúmenes compartidos, etc…
○ Escalado de aplicaciones inmediato.
● Es necesario gestionar todo eso
○ Shipyard, Rancher, Portainer,...
○ Kubernetes, Swarm, Mesos,...

Hasta ahora
● Para Sistemas
○ En desarrollo no tienen ni idea.
○ Se preocupan de que funcione en su entorno local y punto.
○ Nunca optimizan nada porque cuando falla piden más recursos.
● Para Desarrollo
○ En sistemas no tienen ni idea.
○ Si va lento es culpa de ellos que no ponen más recursos.
○ Si no funciona en sus servidores es porque lo configuran mal.
● Soluciones
○ Disponer de un entorno común (Docker).
○ Comunicarnos más y mejor (GitLab).

Propuesta Global
Mi humilde opinión de cómo mejorar

Propuesta global
● Desarrollo (cualquiera que quiera desplegar algo on-premise)
○ Utilizar GitLab para control de versiones y su pipeline para CI/CD.
○ Genera imágenes docker para desplegar en los diferentes entornos.
● Sistemas
○ Junto a desarrollo, define la imagen base para cada tecnología de forma que
se consensua cómo desplegar correctamente los servicios.
○ Utilizar GitLab y su pipeline para generar esas imágenes base.
○ Desarrollo puede proponer cambios en las imágenes base “Merge Request”.
○ Sistemas puede actualizar imágenes base para aplicar parches.
● La comunicación
○ Dockerfile y docker-compose.yml, obligan al consenso desarrollo/sistemas.
○ Sistemas usando GitLab, con un proyecto para contener los despliegues de
los diferentes entornos.
○ Cualquiera puede proponer un cambio en la infraestructura “Merge
Request”.

Posibilidades
● Creación de entornos express
○ Basta con añadir un compose en el proyecto de gitlab.
○ Y tener recursos para desplegar el nuevo stack en el orquestador elegido.
● Adopción rápida de tecnologías
○ Desarrollo y sistemas pueden compartir las tareas que supone.
○ No quiero programar en mil lenguajes diferentes, pero tampoco que no usar
el marco tecnológico oficial sea excusa para ir cada uno a su bola.
● Un sistema de trabajo para todos
○ Nada impide cualquiera que quiera desplegar un servicio en Atica lo haga así.
○ En muchos casos son desarrollos y deben seguir buenas prácticas.
○ Todos los desarrolladores pueden colaborar sin importar su filiación.
● CD/Downtime ZERO (No estamos preparados, ni queremos)
○ Se puede llegar a actualizar aplicaciones sin pérdida de servicio.
○ Filosofía every commit to production.

Achtung baby !
● El uso de Docker
○ Desarrollo creando las máquinas de producción.
○ Hay que seguir buenas prácticas.
● La gestión de logs
○ Se crean contenedores efímeros de difícil acceso.
○ Se necesita ELK/Lagar para poder gestionar los logs.
● El uso de Git
○ Requiere algo de pericia y liarla un par de veces para llegar a controlarlo.
● Copias de seguridad
○ Sólo necesitas hacer copias de los datos y del registro de imágenes (gitlab).
○ Siempre que tengas activo el registro de imágenes puedes recrear el servicio
en segundos en cualquier máquina.

Proof of Concept
La demo que siempre falla

Prueba de Concepto
Build/Test Image Trigger
Registry
Docker
Swarm
Listener
Push Push
Pull
Service Update
GitLab Atica
Cloud Atica
gitlab.com labs.play-with-docker.com
docker-compose.ymlDockerfile
.gitlab-ci.yml

Prueba de Concepto
● El entorno de gitlab.com
○ El proyecto testing (Java + MySQL).
○ El proyecto noding (Nodejs).
● Definición del pipeline (formato YAML)
○ .gitlab-ci.yml
● Definición de la imagen (formato Docker)
○ Dockerfile
● Definición del stack (formato YAML)
○ docker-compose.yml

Prueba de Concepto
● Despliegue en play with docker
○ Crear los workers.
○ Arrancar el stack del listener.
○ Añadir en gitlab la URL del WEBHOOK.
○ Desplegar los stacks de testing y noding.
● Desplegados varios stacks
○ nodingdesa stack (1+2).
○ testingdesa stack (1+6+1).
○ visualizer stack (1+1)
● Visualizer/Listener
○ Muestra lo que hay desplegado en el swarm.
○ Escucha eventos del pipeline para actualizar.

Prueba de Concepto
● Escalar/desescalar servicios.
● Recuperación automática de réplicas.
● Desplegar un cambio usando una rama.
● Volver al estado anterior sin compilar (rollback).
● Mostrar los resultados de los test (gitlab.io).
● Incorporar los cambios al tronco, moverlos a otro entorno.
● Acceder a los logs y a los contenedores (Portainer.io)
● Ver servicios/contenedores/stacks… (Portainer.io).

Prueba de Concepto
https://www.youtube.com/watch?v=OAOi2Fh3HTs

Prueba de Concepto
https://www.youtube.com/watch?v=KV4quPXvXxk

Prueba de Concepto
https://www.youtube.com/watch?v=PGc05xRV1P

Roadmap
Mucho camino aún por recorrer

Roadmap
● Montar un piloto real.... con Aula Virtual.
○ Gestionando el Open Source de Sakai nuestro equipo:
■ Maneja git/github desde hace tiempo (muy similar a gitlab).
■ Utiliza docker a nivel básico en local para montar mysql.
● Objetivo a medio plazo
○ Montar migración de Aula Virtual a Sakai 12 con gitlab.
○ El pipeline desplegará de forma “tradicional” y en forma de imagen.
○ Montar mini-cloud para desplegar un entorno de test con tecnología docker.
● Qué usaremos
○ Un Gitlab CE 10.1 completo con registro de imágenes e integración contínua
para docker, instalado en nuestra infraestructura interna.
○ Un Mini-Swarm con portainer para desplegar uno o varios entornos de test.
¡Hasta llegar a producción aún nos falta mucho!

Futuro Contexto
● Cómo se desarrollarán y se desplegarán aplicaciones en Atica.
○ Marco de desarrollo homogéneo (FundeWeb).
○ Integración contínua con Gitlab-CI/CD.
○ Despliegue continuo con Gitlab-CI/CD, apoyado en contenedores docker.
○ Trabajaremos a nivel interno con filosofía Open Source, más transparente.
○ Tendremos versiones de código fuente, definición de infraestructura e
imágenes docker.
○ Reduciremos la barrera tecnológica:
■ Seremos capaces de adoptar productos Open Source de forma ágil.
■ Podremos adoptar la tecnología adecuada para el servicio a crear.
■ Todos serán bienvenidos a Gitlab sin importar su marco tecnológico, buenas
prácticas para todos.

That’s all “forks”
We’ll see you on gitlab

ATICA DevOps

Más contenido relacionado

La actualidad más candente

Similar a ATICA DevOps

Más de Sección de Metodologías, Normalización y Calidad del Software

Último

ATICA DevOps