Introducción a Docker: Docker
VS Máquinas virtuales
● ¿containers Docker o Máquinas virtuales?
– Depende…
– Existen escenarios idóneos para cada
aproximación.
– Puede que la combinación de ambos sea la
opción más propicia.
Introducción a Docker: Docker
VS Máquinas virtuales
● Docker es idóneo para…
– Cloud. Promueve la portabilidad entre
diferentes entornos (cloud providers)
– Es una plataforma abierta para desarrolladores.
Permite aislar dependencias de las aplicaciones
aislándolas en contenedores.
– Los contenedores son más escalables y
seguros que otras estrategias.
Introducción a Docker: Docker
VS Máquinas virtuales
● ¿En qué difieren los containers Docker de las
máquinas virtuales?
– VM tienen un SO completo con su propia gestión de
memoria y la sobrecarga de los virtual device drivers.
Tienes más “capas” de complejidad que los containers
Docker.
– Docker usa UAFS para ahorrar espacio. Los containers
son “procesos” limitados o enjaulados. Menos
complejidad.
– Los servicios son PROCESOS dentro del docker host
Introducción a Docker: Docker
VS Máquinas virtuales
● Diferencias de almacenamiento:
Introducción a Docker: Docker
VS Máquinas virtuales
● IMPORTANTE:
– Los contenedores Docker son ejecutados por el
Docker engine (NOTA: instalar docker-engine, no
“[Link]”) en lugar de por un hypervisor.
– Los containers son más pequeños,
– se inician antes,
– rinden mejor y
– comparten kernel
Introducción a Docker:
Docker VS Máquinas virtuales
● Docker containers (DC) versus VM
– DC comparten kernel y librerías=> cargan
menos memoria.
● DC 1, MV 0
– Las MV tienen mejor aislamiento (Intel
Vtd/Vtx). DC no tiene aislamiento hardware
● DC 1, MV 1
– En media, una aplicación puede llegar a
ejecutarse dos veces más rápido que en MV
● DC 2, MV 1 => DC WINS!
Máquinas Virtuales y Containers:
mejor juntos
● Existen escenarios de distribución de cargas de trabajo en los
que es más apropiado utilizar máquinas físicas.
– Caso 1: BD Oracle.
● Oracle no ofrece soporte de su BD en contenedores.
● Oracle sólo ofrece soporte de su BD en instalación bare metal o con su propio
hypervisor.
– Caso 2: appliances de terceros, con los que nuestros containers deben
poder comunicarse.
– Caso 3: clusters de BD preexistentes o remotos.
– Caso 4: Software PARA WINDOWS o PARA SPARC
● Puede utilizarse un escenario mixto con máquinas físicas y
contenedores
Máquinas Virtuales y Containers:
mejor juntos
● Esquemas híbridos:
– Los entornos productivos no se sostienen
únicamente con MV y contenedores.
– La gestión de la capacidad, seguridad y
rendimiento pueden requerir herramientas aún
no disponibles para entornos de
contenedores, aunque están apareciendo.
Máquinas Virtuales y Containers:
mejor juntos
● En esquemas híbridos, tendremos que
habilitar modos de red “más compleja”, en
“OVERLAY”:
Máquinas Virtuales y Containers:
mejor juntos
Máquinas Virtuales y Containers:
mejor juntos
Máquinas Virtuales y Containers:
mejor juntos
● Conclusión:
– VM proporcionan alta flexibilidad
– DC pone el foco en aplicaciones y sus
dependencias.
– DC promete sencillez al traspasar pilas de
aplicación entre proveedores de cloud.
– Disponemos de herramientas y documentción
suficientes para montar nuestro cluster Docker y
comenzar a trabajar en este modelo.
Orquestadores que trabajan con
Docker.
● OpenStack: incorpora un “driver” de
hypervisor para OpenStack Nova
Compute:
Orquestadores que trabajan con
Docker.
● OpenNebula:
– Docker machine te permite crear Docker
Hosts en nuestra computadora, en
proveedores de cloud y en nuestro propio
DataCenter.
– La integración de OpenNebula y docker
machine es muy simple
Orquestadores que trabajan con
Docker.
Orquestadores que trabajan con
Docker.
● OpenNebula Docker Driver y Datastore
– ONEDock es un conjunto de extensiones para OpenNebula
que permite usar contenedores Docker como si fueran MV
ligeras.
– Docker se configura para que actúe como un hipervisor, de
manera que se comporta como KVM por ejemplo.
– La idea subyacente es que cuando a OpenNebula se le pide
una MV, desplegará un container Docker en su lugar.
– El usuario dispondrá de una IP para gestionar el contenedor.
Integración contínua
● Definición: La integración continua (continuous
integration en inglés) es un modelo informático
propuesto inicialmente por Martin Fowler que
consiste en hacer integraciones automáticas de un
proyecto lo más a menudo posible [..] (compilación
y ejecución de pruebas de todo un proyecto)
● El proceso suele ser: cada cierto tiempo (horas),
apoyado en Git, Subversion,ejecutar pruebas y
generar informes
Integración contínua
● Contras a la CI basada en Docker
– Aproximación relativamente nueva (surgió en el
2013)
– Sustentada sobre conceptos de virtualización
basada de contenedor, en lugar de un modelo
de hipervisor, sólidamente consolidado y
aprobado por la industria IT como estándar
– Incluso el formato de contenedor es diferente de
otras alternativas como Virtuozzo / openvz
Integración contínua
● Pros:
– Docker está muy orientado a procesos de entrega de software.
– Favorece el trabajo sostenido hacia el modelo
DevOps => Despliegue Contínuo.
– Cómodo para desarrolladores y para administradores de
sistema
– Proporciona capacidades para entregas de software
complejas con unas herramientas sencillas
– Proporciona fácilmente entornos idóneos y rápidamente
provisionables a los Desarrolladores... y mucho más.
Integración contínua
● Developer:
– ¿Necesitas un entorno específico para trabajar?
Busca en DockerHub y móntatelo tú mismo.
– ¿necesitas adaptarlo? Construye tu propia imagen
– ¿Necesitas distribuirlo y desplegarlo en otro entorno
(PREPRO, PRO), y el entorno es COMPLEJO?
● Usa un Dockerfile más un [Link] (para FIG) o un
[Link] (para Docker Compose).
– ¿Quieres almacenar imágenes en un registro interno,
y no en DockerHub? Instálate un registro privado.
Integración contínua
● Sysadmin
– ¿Frustrado con entregas de software cuyos manuales
contienen textos con tareas que deberían ser
automatizables y reproducibles sin errores de
interpretación? Pasa a modelos Dockerfile/Docker
Compose u Orquestados.
– Si Dockerfile genera problemas de despliegue, se devuelve
a Desarrollo. Se puede trabajar conjuntamente con
desarrollo porque ambos grupos de técnicos observan un
mismo modelo para entenderse.
– Se reducen las fricciones
Integración contínua
● Casos de éxito
– Battlefy: Docker + Jenkins
● Construye y sube imágenes Docker antes de desplegarlas
en AWS Elastic Beanstalk
● Comienzan con una petición en Github, lo enlazan a un
ticket JIRA
● Los resultados se envían a un equipo que lleva el código a
AWS S3 donde se usan Docker containers para construir un
entorno de preproducción.
● Después de unos tests, Jenkins es capaz de automatizar la
entrega a PRODUCCIÓN.
Integración contínua
● Casos de éxito (II)
– [Link]: creadores de IronMQ, un sistema de encolado de
mensajes. Y IronWorker una herramienta de procesado
de tareas asíncrono
● IronWorker tiene 15 stacks de imágenes Docker en
almacenamiento en bloque (cabinas de fibra) con
empaquetado de código de usuario en cada nuevo contenedor,
que ejecuta el proceso y después destruye el contenedor.
● [Link] trabajan en un contexto de microservicios que no está
disponible en entornos de producción al uso
● Utilizan software de orquestación
Integración contínua
● Casos de éxito (III) SPOTIFY
– Spotify tiene cientos de contenedores ofreciendo
servicio en producción
– Tiene un servicio monetizado, y confían en docker.
– Han creado su propio sistema de orquestación:
HELIOS. Es simple, aunque adolece de falta de
límites en los contenedores (CPU, memoria...)
– Su integración contínua y de despliegue es muy
intensiva.
– A veces complementan despliegue de
configuraciones con puppet.
Integración contínua
● Caso de FRACASO
– XMLDirector: es una plataforma XML gestor
de contenidos y de flujos de trabajo.
– Andreas Jung (líder de proyecto) quiso
colocar bases de datos de tipo XML en
contenedores.
– Midió que los builds normales tardaban de 5 a
10 veces más que con la shell. Algunos
procesos requirieron reiniciar Docker.
– “Docker es un lío, pero la idea es buena”
Integración contínua
● Caso a imitar: IIIEPE (Instituto de Investigación,
Innovación y Estudios de Posgrado para la
Educación, México)
1)Usan varios sites con Drupal, PHP y [Link]
2)Todo desarrollador usa Docker para crear la aplicación
3)La instancia Gitlab (que tiene una herramienta de
despliegue y de integración contínua) tiene configurado
WebHooks, con lo que cuando se da un “push” al
proyecto, ordena a Jenkins que ejecute una tarea
Integración contínua
● Caso a imitar: IIIEPE (II)
4) Cada tarea jenkins clona el último código de
gitlab, ejecuta tests, se loga en el registro
privado Docker, construye una nueva imagen
con la última versión y la sube al registry.
5)Finalmente, Maestro-NG (software de
orquestación) despliega la nueva versión de la
imagen.
6)El balanceador detecta el cambio y recarga la
nueva configuración.
¿Cómo triunfar implantando
Docker en producción?
● Salesforce:
– Empresa que ha creado un CRM con más de
100.000 clientes
– Ha trabajado intensamente buscando un
modelo cuyo pilar sea docker, a través de
ensayo y error.
– Modelo plenamente exitoso con el esquema
siguiente:
¿Cómo triunfar implantando
Docker en producción?
Integración Contínua
● Conclusiones
– Docker ha llegado para quedarse.
– Es el futuro (y presente) de la CI y la CD.
– Muchas empresas están invirtiendo en ello.
– El escenario que terminará por implantarse
será sin duda, híbrido.
Integración contínua
● Esto es complicado...¿Qué escenario elijo?
– Docker Swarm: es el clustering nativo de Docker.
Bueno para empezar, junto con Consul/kubernetes
para discovery.
– Permite crear un pool de Docker Engines en un
único “Virtual Host”.
– Es habitual usar Jenkins y Git como herramientas
en las que apoyarnos para la CI
– Es un comienzo….
LAB
● LAB En linux (compose no disponible en
windows):
● [Link]