Post on 12-Apr-2017
Usando
Profundizando en contenedoresJulio 2015
Conceptos sobre Docker
Modelos de aislación de aplicación
Kernel
ProcesosNetwork
IPC
Filesystem Global
Imágen R/OFilesystemContenedor
FilesystemChroot
ProcesosNetwork
IPC
ProcesosNetwork
IPC
FS R/W
Hardware
Hardware Emulado
Kernel VM
ProcesosNetwork
IPC
FilesystemVM
Nativo Chroot Container Docker VM
+
Que agregó Docker a Contenedores
Union fs, imágen read-only + filesystem escribible (CoW)
Imágenes fáciles de generar, derivar de otras, compartir y versionar
Orientado a correr programas individuales, no sistemas
Interface CLI intuitiva y simple, API REST, ejecutable sin dependencias
Red por defecto
enmascaramiento de acceso a red
exposición explícita de puertos
Ecosistema y comunidad muy activos
Docker FilesystemPotencialmente muchas capasImagen sólo lecturaSe pueden compartir imágenes (registry)Contenedor escribible asociadoVolúmenes sin versionado
Diferentes FS baseAUFS (union fs, CoW de archivos)Device Mapper (ThinP, CoW de bloques)BtrFS (subvolumes, snapshots)Mas a futuro (ZFS, OverlayFS, etc)Depende de distribución/disponibilidadComparación en Project Atomic
ImágenesObtención/Creacióndocker pull/run de Docker Hub, o
Docker registry propiodocker commit contenedor->imagendocker export -> .tgz -> docker importCrearlas a partir de Dockerfiles
Pueden tener capas a su vez“Herencia” entre capas ya creadasCapas “padre” están 1 sola vez en
disco/cacheApuntar a menor tamaño busybox<alpine
<debian<ubuntu
Ubuntu 14.04 +npm +aplicación 1
+jvm
+aplicación 3
+aplicación 2
+memcache
CentOS 6
+jboss
+ruby 1.9.1
+ruby 2.1.4
+aplicación 4
+aplicación 5
Que se define en este ejemplo?Imagen base (con versión)Variables de entorno para construcciónComandos a ejecutar en construcciónArchivos a agregarVolúmenes del contenedorPuertos que se exponenComando que se ejecuta por defectoCada línea operativa agrega capa, usar
volúmenes para directorios transitorios
DockerfilesFROM ubuntu:trusty
ENV DEBIAN_FRONTEND noninteractiveRUN apt-get update && \ apt-get -yq install mysql-server-5.6
ADD my.cnf /etc/mysql/conf.d/my.cnfADD run.sh /run.sh
VOLUME ["/etc/mysql", "/var/lib/mysql"]EXPOSE 3306
CMD ["/run.sh"]
docker build <directorio del dockerfile> --tag mysql
Volúmenesdocker run … \-v /opt/c/mysql1data:/var/lib/mysql ....Directorio del disco -> directorio del contenedor
docker run … \--volumes-from contenedor1 …Usa volúmenes de otro contenedor(contenedor1 no tiene porque estar corriendo)
FilesystemContenedor
/opt/c/mysql1data/var/lib/mysql
Contenedor Contenedor1
/var/lib/mysql /var/lib/mysql
Usos: backups, crons, transporte, área de compartición entre varios contenedores, captura de logs, persistir datos en SAN/NFS, filesystems distribuidos, etc
NetworkingModo bridge (net=bridge/defecto)
Crea bridge docker0Contenedores en subnet
detrás del bridgePuertos expuestos
enmascarados en eth0
172.17.0.2 172.17.0.3
172.17.42.1
200.40.133.133
contenedor 1
eth0
docker0
contenedor 2
Modo host (net=host)Usa la red del hostPublica directamente servicios en la misma interfaz de red
Modo none (net=none)No configura la redÚtil para configurar red por nuestros propios medios
después, o usos que no requieren red
Modo container (net=container_id)Similar a modo host, pero usa la red de otro contenedor,
previamente creado, en vez de la del host
“eth0”
Enlaces entre contenedores
Contenedor1docker run -p <puerto> --name Contenedor1 ...
Dockerfile EXPOSE <puerto>
Contenedor2
docker run --link Contenedor1 ...
● <puerto> es accesible directamente● variables de entorno que dicen puerto/ip● /etc/hosts contiene Contenedor1
Contenedores “embajador” sirven de puente para enlazar contenedores entre distintos servidores físicos/VMs
Contenedor1 Contenedor2Embajador1 Embajador2
Agrupando contenedores
wordpress: image: wordpress links: - db:mysql ports: - 8080:80
db: image: mariadb environment: MYSQL_ROOT_PASSWORD: example
● Trata varios contenedores como una unidad
● Define cómo se construye/obtiene c/u
● Define puertos y volúmenes compartidos
● Permite definir variables de entorno, como se ve el grupo desde afuera
● archivo de definición yaml
Docker-compose
Algunas herramientas para redesdocker-machine
Prepara máquinas/vms para correr dockerdocker-swarm/fleet/etc
distribuye contenedores entre máquinasConsul
directorio dinámico de serviciosKubernetes
Ejecución de grupos de contenedores en clúster
Donde correrlos?Cluster
MesosphereRedHat OpenshiftOpenstack/MagnumAmazon ECSGoogle Compute engineIBM BluemixPAAS varios (Flynn, Deis,
etc)etc
MaquinaCualquier linux con kernel
reciente correDistribuciones orientadas a
contenedoresCoreOSRancherAtomic OSUbuntu SnappyVMWare PhotonIntel ClearLinux
Estrategias de uso
Que debería tener un contenedor?
imagen
conf datos
● Inmutable● En repositorio privado/público● Dockerfile para crearla● Versionada● aplicación sigue 12factor.net
● Pasada x entorno/ etcd/ volúmenes/ línea de comando
● Depende/informa de contexto
● Dónde están mis datos?
● Debug info?● Claves/certs
● En volúmenes● Distintos sets de datos● Accesible desde distintos
procesos/contenedores● Respaldos/crons trabajan fuera
de este contenedor
Contenedor ideal
Backups
imagen
conf datos
● Definido en Dockerfile● Respaldado en repositorio ● Solo cuando se (re)construye
● Versionado en git
● Sólo cuando hay cambios de configuración
● Lo que importa respaldar o distribuir
● En volúmenes
Reuso de imágenes
Webserver
DBAplicación
Webserver
DB
Patrones para imágenes reusables
● Misma distribución base
● Mismas herramientas base
● Bibliotecas comunes
● muchos daemons? runit/ monit/
supervisord/ etc
● usuarios estandarizados
Continuous Delivery
Configuración/Datos pueden variar dependiendo del contextoDesarrollo
Testing QA Staging Producción
Imagen se mantiene inmutable en todo el proceso UsuariosRouter
Las etapas pueden correr en distintos equipos físicos, uso de registry para transporte
Escalamiento vertical
VM compartida
VM dedicada
Servidor(es) dedicado
Cloud de bajos recursos
Cloud de altos recursos
La aplicación no cambia por mucho que el ambiente donde corre si lo hace
Hardware/ambientes existentes se puede reusar o compartir con otras aplicaciones al no estar atados unos con otros
docker run -v /server/datos --name datacontainer1 tianon/true /bin/true
Contenedores de datos
Server
Backup
Reportes
cron
shell
125 bytes
● No depende de donde queda en host● Permisos/uid/gid consistentes● No tienen que estar corriendo un
proceso para usarse
inicialización
Data container
NO usar como VMs
Monitoreo● No correr agente● /sys/fs/cgroup para métricas● Monitorear aplicación/puertos● Sysdig
Logs● Montar /dev/log como volumen y usarlo desde otro
contenedor con (r)syslog (syslog-docker) ● docker logs muestra stdout/stderr de lo que corre
dentro
Acceso a contenedor en ejecución● No correr sshd en contenedor● Usar docker exec para shell/comando● Usar volúmenes para archivos que
tengan que ser accedidos por otros procesos/contenedores (cron, backup)
Invocación● Se pueden crear y descartar muy rápido● Eficientes en memoria, pueden quedar
cargados y enviarles tráfico desde balanceador cuando se precisen
● Fácil iterar con ellos● Persistencia vía volúmenes
Adopción gradualConvivencia con HW/SW existenteImplementación de nuevos serviciosNecesidad de correr apps que requieren librerías/
dependencias diferentes/ conflictivas con lo instaladoAgilizar desarrollo/ testing/ QAReplicación sistemas/ servicios para testear cambios/
configuraciones
Implica cambio de mentalidad, no forzar si no se entiende
Pequeña escalaPruebas limpias de software/serviciosAislación de aplicaciones en escritorioAlternativa a manejo de paquetesInstalación simple de sistemas complejosReplicación ambientes de producciónEntornos rápidos de otras distribuciones
Alternativas a Docker
Otros enfoquesCBSD, Jetpack (para FreeBSD, Jails+imágenes)Joyent Triton (containers docker/linux en SmartOS)Ubuntu LXD (Hypervisor orientado a contenedores)CoreOS Rocket (Reemplazo de docker, más modular)Hyper.sh (carga imágenes docker como vm)cargo (uso de imágenes docker en lxc)kernels livianos para VMs (unikernels, rumpkernels)pullcontainer (chroots usando imágenes docker)systemd (está adoptando mucha tecnología de contenedores)
Sitios de interés
Documentación oficial https://docs.docker.com/
Tutorial https://www.docker.com/tryit/
Blog de JPetazzoni http://jpetazzo.github.io/
The Docker Bookhttp://www.dockerbook.com
Awesome dockerhttps://github.com/veggiemonk/awesome-docker
Docker cheat sheethttps://github.com/wsargent/docker-cheat-sheet
Docker resourceshttps://github.com/hangyan/docker-resources