2. Problemas con enfoques actuales
● Conflictos en librerías/aplicaciones: Servicio A requiere X 0.95,
servicio B requiere X 1.03, para que convivan en un mismo
hardware/vm hay que hacer trucos
● Implicaciones de seguridad de muchas aplicaciones conviviendo en
un mismo hardware/vm
● VMs cargan sistema completo, requieren uso extra de memoria, cpu,
disco, a veces bastante importante
● Cache de disco en VMs afecta overcommiting para otras VMs, pero
no tener cache de disco afecta negativamente performance
● Testing de aplicaciones implica replicación de máquinas completas.
Es “caro” tener para cada desarrollador un ambiente idéntico al de
producción. Desarrollo/testing/producción deberían ser lo mas
parecido posible
● Alta disponibilidad implica mover/cargar VMs completas por la red
● Costos extras (mas máquinas) en nubes si se quieren compartimentar
aplicaciones
● Algunos paquetes/versiones estan para una distribución y no para
otras. Instalarlos implica instalar de fuente o crear nueva vm/maquina
3. • "chroot en esteroides"
• aislacion de procesos del resto del sistema, su propia
red, procesos, usuarios, y filesystem
• cgroups para limitar uso de recursos del sistema
(cpu/red/disco/etc)
• Pueden usarse para levantar aplicaciones individuales
en sistemas restringidos, sin cargar sistemas
completos. Pueden verse como contenedores (de
puerto) que llevan dentro la aplicación independiente
completa.
• En linux: openvz, vserver, lmctfy, lxc
• Otros SO tienen conceptos similares: BSD Jails, Solaris
Zones
Containers
4. • Originalmente: Linux 3.8+, aufs, lxc y 64 bits. Ubuntu
12.04 y 13.04 eran las distribuciones oficiales, pero
corría en debian, suse, y muchos “clouds”
• En 0.7 soporto storage drivers, agregando device
mapper/btrfs/vfs. Se agrega RHEL 6.5 (y centos,
fedora, etc) que no tenía soporte aufs.
• En 0.8 “soporta” OS X, corriendo linux en una vm
liviana y comunicándose con el docker del vm
• En 0.9 agregaron soporte de drivers de ejecución,
podría andar con openvz, bsd jails, solaris zones,
chroot, qemu y otros. Y libcontainer, para hablar
directamente con el kernel, ya no es obligatorio lxc.
Docker: Requerimientos
5. Ejemplo de sesión manual
# docker pull base
# docker run -i -t base /bin/bash
root@15c0db264611:/# apt-get install memcached
root@15c0db264611:/# exit
# docker ps -a
ID IMAGE COMMAND CREATED STATUS PORTS
7717ce712162 base:latest /bin/bash 2 minutes ago Exit 0
# docker commit 7717ce712162 test/mcached
# docker run -d -p 11211 test/mcached memcached -u daemon
# docker ps
ID IMAGE COMMAND CREATED STATUS PORTS
66a2cbdda35d test/mcached:latest memcached -u daemon 3 minutes ago Up 3 minutes 49153->11211
6. Que paso en el disco?
base
7717ce712162
test/mcached
66a2cbdda35d
docker pull base
apt-get install memcached
docker run ...
Contenedores creados
fbc9c18e0ac8
aff8363240b1 apt-get install nginx
docker run -v ...
ed464b61c53d
docker run -v ...
27d06e9d3eea
vi nginx.conf
7. Docker builder
# Dockerfile para nginx + php-fpm
FROM ubuntu:12.10
RUN echo "deb http://archive.ubuntu.com/ubuntu precise main universe" >
/etc/apt/sources.list.d/precise.list && apt-get update
RUN apt-get install -y nginx php5-fpm php5-pgsql php5-curl php5-json php-apc
RUN echo "cgi.fix_pathinfo = 0;" >> /etc/php5/fpm/php.ini
RUN echo "daemon off;" >> /etc/nginx/nginx.conf
ADD ./nginx-site.conf /etc/nginx/sites-available/default
EXPOSE 80
CMD service php5-fpm start && nginx
docker build nginxphp/ (subdirectorio con archivo Dockerfile + extras)
Va a ejecutar paso por paso el script, y tirar a consola el id de la imagen generada, similar a receta de
puppet o vagrant
docker run -d -p 8080:80 -v=/sitios/nginxphp-www:/usr/share/nginx/www nginxphp
8. Repositorio central
• Almacen de imágenes ya hechas, base, ubuntu, centos,
logstash, mongodb, etc
• Motor de busqueda en http://index.docker.io
• comandos docker pull imágenes, login para
autenticación y push de imagenes, search para buscar
• APIs para acceder al index server (donde esta la
búsqueda, metadatos, usuarios, etc) y al registry server
(donde estan las imagenes)
• Se pueden tener repositorios internos
9. Administración avanzada
• Remote API: Escucha por defecto en puerto 4243,
invocaciones tipo POST /images/(nombre)/comando, con
librerías existentes para python, ruby, js, java, php, go
• Varias WebUI simples, p/ej en
https://github.com/crosbymichael/dockerui
• Integración con OpenStack. Empezó siendo driver de
Nova pero para la siguiente versión lo es de Heat, el
orquestador de servicios
• Integración con OpenShift de RedHat
• Flynn,Deis,Shipyard,CoreOS,Dokku, y muchos otros