DE DESARROLLO A PRODUCCIN USANDO

DOCKER
 AGENDA
Quines somos?
Docker: introduccin
Consideraciones para trabajar con docker
Volmenes
Docker Compose
Docker en produccin
QUINES SOMOS?
LEANDRO DI TOMMASO
Fundador de Mikroways.
Docente en UNLP e Instructor
CCNA.
DevOp en CeSPI-UNLP.
Miembro del NOC de UNLP entre
2007 y 2012.
Miembro del NOC de INTA en 2012.
CHRISTIAN RODRIGUEZ
Docente en UNLP
Miembro del equipo de soporte
CeSPI-UNLP hasta 2006
Instructor
CCNA/RedHat/Solaris/IRIX
Coordinador del equipo de desarrollo
de software interno (UNLP)
perteneciente a CeSPI
Aplicando DevOps desde 2012
Coordino el rea de IT para los
desarrollos propios
 QU HACEMOS EN NUESTRO TRABAJO?
Desde nes de 2013, nos consolidamos como equipo de IT
para el rea de desarrollo.
Aplicando DevOps gestionamos:
58 VMs virtualizando con Proxmox y VMWare.
Ambientes automatizados con chef.
67 aplicaciones en ambiente de produccin.
55 aplicaciones en ambiente de pruebas.
Monitoreo y backups contemplados en la
automatizacin.
Ambientes idnticos en desarrollo y produccin:
basados en vagrant y chef.
 QU HACEMOS EN NUESTRO TRABAJO?
En 2016 formalizamos a Mikroways como una sociedad.
Trabajamos con DevOps (Chef y Docker).
Monitoreo inteligente (Estadsticas y logs).
Consultora.
Capacitaciones.
Cloud computing.
IoT.
Partners de Chef, Docker y Amazon.
DOCKER
INTRODUCCIN
 ANTECEDENTES
Antiguamente, transportar bienes tena muchos
problemas.
Diferentes tamaos, formas, resistencias, etc.
Capacidad de transporte reducida.
Difcil realizar un seguimiento.
Prdida parcial de mercadera.
Grandes costos.
 CONTENEDORES
Los contenedores solucionaron muchos problemas:
Un vendedor pone todos sus productos en un
contenedor y slo debe preocuparse por ese
contenedor.
Los productos nunca se manipulan individualmente.
Tamaos y formas estandarizadas, simpli ca toda la
cadena de transporte: el transporte slo debe llevar
contenedores.
CONTENEDORES
 QU ES DOCKER?
Contenedores de software.
Empaqueta aplicaciones en una unidad estndar de
intercambio.
nica pieza de software en un lesystem completo que
contiene todo lo necesario para ejecutar una aplicacin:
cdigo, libreras, herramientas, etc.
Garantiza que el software siempre correr de igual forma
sin importar su ambiente.
 POR QU DOCKER?
Diferencias entre el ambiente de desarrollo, testing y
produccin.
Instalacin de una aplicacin en diferentes plataformas.
Deploy de aplicaciones complejas.
Ejecucin de cdigo antiguo.
Simplicidad para escalar horizontalmente.
MATRIZ DEL INFIERNO
MATRIZ DEL INFIERNO
COMPARACIN CON MQUINAS VIRTUALES
 HISTORIA
Emerge como proyecto de SL en 2013.
Virtualizacin a nivel de sistema operativo.
Se basa en el uso de:
Cgroups para restringir recursos como cpu, memoria, IO,
red, etc.
Kernel namespaces permite aislar y virtualizar recursos
de una coleccin de procesos como por ejemplo: PID,
hostname, UID, acceso a la red, comunicacin entre
procesos, lesystem, etc.
Filesystem de unin como es el caso de AUFS,
OverlayFS, Btrfs, Device Mapper, ZFS, etc.
 HISTORIA
Con las caractersticas antes mencionadas se obtienen
contenedores independientes en una instancia Linux que
evita el overhead de manipular VMs.
Antes de la versin 0.9, Docker usaba LXC como base. A
partir de la 0.9 incorporaron libcontainer, eliminando la
dependencia de LXC dado que accede directamente al
kernel para manipular cgroups, namespaces, apparmor,
interfaces de red, etc.
 IMGENES Y CONTENEDORES
Imagen:
Filesystem y parmetros para utilizarla.
No cambia nunca y no tiene estados.
Contenedor:
Instancia de una imagen (resultado de ejecutarla).
Tiene una capa de RW voltil.
IMGENES Y CONTENEDORES
IMGENES Y CONTENEDORES
IMGENES Y CONTENEDORES
IMGENES Y CONTENEDORES
INSTALACIN DE DOCKER
Docker puede instalarse en:
Linux.
MacOS.
Windows.
 INSTALACIN DE DOCKER EN LINUX
Requisitos:
Sistema de 64 bits.
Kernel 3.10 o superior.
Existen binarios para la mayora de las distribuciones.
INSTALACIN DE DOCKER EN WINDOWS/MACOS
Usando Docker Toolbox.
Utiliza Docker Machine (no nativo).
Windows 7/MacOS 10.8 o superior
Docker for (Windows/Mac):
Corre una aplicacin nativa usando (Hyper-V/xhyve para
virtualizar la Docker Engine).
Windows 10/MacOS 10.10.3 o superior.
 COMANDOS BSICOS
#Msusados
dockerrun
dockerps
dockerbuild
dockerimages
dockerlogs
dockerinspect
dockervolume

#Otroscomandoscomunes
dockercommit
dockerpull
dockerpush
dockertag
 NUESTRO PRIMER CONTENEDOR
$dockerrunitubuntu: 16.04/bin/bash
Unabletofindimage 'ubuntu:16.04'locally
16.04:Pullingfromlibrary/ubuntu

6bbedd9b76a4:Pullcomplete
fc19d60a83f1:Pullcomplete
de413bb911fd:Pullcomplete
2879a7ad3144:Pullcomplete
668604fde02e:Pullcomplete
Digest:sha256: 2d44ae143feeb36f4c898d32ed2ab2dffeb3a573d2d8928646dfc9cb7deb1315
Status:Downloadednewerimage forubuntu:16.04

root@99a3403db59a:/#cat/etc/issue
Ubuntu16.04.1LTS\n\l
 DOCKERFILE
Archivo de texto plano para crear imgenes de Docker.
Permite escribir instrucciones a ejecutar.
Automatiza el proceso de la creacin de imgenes.
Permite repetir y modi car fcilmente una imagen.
Generar de forma simple imgenes derivadas.
 DOCKERFILE
FROMubuntu:16.04
MAINTAINERLeandroDiTommaso

#InstalarNginxyconfigurarunapginapersonalizada
RUNaptgetupdate&&aptgetinstallynginx
RUNmkdir/var/www/html/ejemplo
RUNecho"<html><h1>NginxenDocker</h1></html>" >/var/www/html/ejemplo/index.h

EXPOSE80
CMD["nginx","g","daemonoff"]
 NUESTRA PRIMER IMAGEN
$dockerbuildtleoditommaso/nginx: 1.0.0.
SendingbuildcontexttoDockerdaemon 2.048kB
Step1:FROMubuntu:16.04
16.04:Pullingfromlibrary/ubuntu
6bbedd9b76a4:Alreadyexists
fc19d60a83f1:Alreadyexists
de413bb911fd:Alreadyexists
2879a7ad3144:Alreadyexists
668604fde02e:Alreadyexists
Digest:sha256: 2d44ae143feeb36f4c898d32ed2ab2dffeb3a573d2d8928646dfc9cb7deb1315
Status:Downloadednewerimage forubuntu:16.04
>f753707788c5
Step2:MAINTAINERLeandroDiTommaso
>Running inf93e6923c21e
>a1144bb80b28
Removingintermediatecontainerf93e6923c21e
Step3:RUNaptgetupdate&&aptgetinstallynginx
>Running in489697f5e5d5
 NUESTRA PRIMER IMAGEN
$dockerrundp80:80leoditommaso/nginx: 1.0.0
 LA REGISTRY
Servicio para almacenar y distribuir imgenes de Docker.
Open source (Licencia Apache).
Instalacin privada
Acceso local para mayor velocidad de descarga.
Imgenes en un ambiente controlado y gestionado por la
organizacin.
Servicio en la nube (Docker Hub).
Libre de mantenimiento.
 DOCKER HUB
Gratis para imgenes pblicas.
Soporta builds automticos (desde Github/Bitbucket).
Cuentas para organizaciones.
Plan pago para imgenes privadas.
https://hub.docker.com
CONSIDERACIONES PARA
TRABAJAR CON DOCKER
 INTRODUCCIN
Ya sabemos que:
Las imgenes Docker son inmutables.
Los contenedores crean una capa con las diferencias
correspondientes respecto de la imagen original.
Entonces los contenedores deberan minimizar los cambios
respecto de la imagen original.
Optimizando el uso de espacio y evitando impactos de
performance.
Promoviendo la reusabilidad.
 INMUTABILIDAD EN LA INFRAESTRUCTURA
Desplegar una actualizacin de una aplicacin, consiste en
crear nuevas intancias y destruir las anteriores, en vez de
actualizarlas sobre la instancia productiva.
Una vez que una aplicacin est corriendo, evitamos
tocarla! promoviendo as:
Repetibilidad.
Reducir costos de mantenimiento.
Simpli car rollbacks.
 INMUTABILIDAD EN LA INFRAESTRUCTURA
Para lograr este tipo de inmutabilidad deben cumplirse los
siguientes requerimientos:
La aplicacin debe ser stateless. Su estado debe
almacenarse en un servicio por fuera del alcance de la
infraestructura inmutable.
Existe un template y/o conjunto de instrucciones que
permiten desplegar una instancia de la aplicacin desde
cero.
El segundo punto lo resuelve fcilmente docker
 QU ES DINMICO ENTONCES?
La creacin de las imgenes debe conocer bien el dominio
para identi car las partes que son dinmicas:
Archivos que se generan por la aplicacin.
Uploads desde la aplicacin.
Logs.
Spool.
 CMO VERIFICAR SI MIS CONTENEDORES
CRECEN?
Un mal diseo de las imgenes impactar en la performance
de los contenedores que generarn grandes capas con datos
dinmicos.
Ante la actualizacin del contenedor, estos datos se perdern.
 EL SIGUIENTE COMANDO PERMITE VERIFICAR
ESTO
$dockerpss

CONTAINERIDIMAGE.....SIZE
0d5c12033ee3nginx..... 2B(virtual182.8MB)

El tamao es lo que crece el contenedor respecto de la imagen. El tamao virtual es lo que ocupa el
contenedor sumado al tamao de la imagen.
 BUENAS PRCTICAS
Los contenedores deben ser efmeros: pararlos,
destruirlos y volverlos a iniciar con una mnima
con guracin.
Evitar paquetes innecesarios: las imgenes no deben
incluir paquetes que no se utilicen.
Un proceso por contenedor: en la mayora de los casos, se
debe correr un proceso por contenedor. Desacoplar
aplicaciones en mltiples contenedores hace mucho ms
simple el escalamiento horizontal y reuso de contenedores.
La (in)necesidad de ssh: acceder a un contenedor es algo
que debemos evitar. En trminos de infraestructura
inmutable, el servicio no debera considerar SSH.
VOLMENES
CMO GUARDO LA INFORMACIN?
Los contenedores son voltiles e inmutables.
Debemos preservar la informacin importante.
Dnde?
En volmenes de datos.
 CARACTERSTICAS DE LOS VOLMENES
No utilizan un sistema de archivos de unin (UFS).
Pueden compartirse y reusarse entre contenedores.
Los cambios se hacen directamente en el volumen.
La informacin del volumen no se incluye en la imagen.
Persisten an cuando se eliminen todos los contenedores
que los usan.
Pueden quedar volmenes sin referenciar.
TIPOS DE VOLMENES
Volmenes annimos.
Volmenes nombrados.
Volmenes desde el SO host.
 TIPOS DE VOLMENES
Al crear un volmen annimo o nombrado, la informacin
que exista en el punto de montaje se copia al volumen.
Con volmenes desde el SO host o desde otro contenedor,
se oculta la informacin que exista en el punto de montaje.
Correspondencia con el comando mount.
 ANALIZANDO LOS VOLMENES
Al iniciar un contenedor, la opcin -v permite indicar qu
volumen utilizar. El siguiente ejemplo de ne tres volmenes:
uno annimo, uno nombrado y uno desde el SO host:
$dockerrunit\
v/usr/local #anonimo
vtestvolume:/testvolume #nombrado
v/tmp:/tmp #SOhost
ubuntubash

Inspeccionando los volmenes vemos:

$dockervolumels
DRIVERVOLUMENAME
locale9c7022b8c7bec55891ca44b8c40de1e5f41cf0fe9505a334bca06a484a5ff1f
localtestvolume
DOCKER COMPOSE
 QU ES DOCKER COMPOSE?
Herramienta que permite levantar aplicaciones
compuestas por mltiples contenedores.
La arquitectura se de ne y con gura en un archivo de texto
(YAML).
Simple e intuitivo.
Se vale de un comando para:
Iniciar, detener y reconstruir servicios.
Ver el estado de los servicios, los logs, etc.
VERSIONES DE DOCKER COMPOSE
Hay dos versiones diferentes, la 1 y la 2.
No son compatibles entre s.
Pequeos cambios en el archivo de texto.
Veremos la sintaxis de la versin 2.
 DOCKER COMPOSE: EJEMPLO
Instalacin de Wordpress.
Vamos a crear un archivo llamado docker-compose.yml.
De niremos all la arquitectura de la aplicacin.
Nos valdremos del comando docker-compose para
levantar Wordpress e interactuar con los contenedores
generados.
 LEVANTANDO UN WORDPRESS
version:'2'

services:
db:
image:mysql: 5.7
volumes:
"dbdata:/var/lib/mysql"
restart:always
environment:
MYSQL_ROOT_PASSWORD:wordpress
MYSQL_DATABASE:wordpress
MYSQL_USER:wordpress
MYSQL_PASSWORD:wordpress

wordpress:
depends_on:
db
image:wordpress:latest
 LEVANTANDO UN WORDPRESS
$dockercomposeup d
Creatingnetwork "wordpress_default" withthedefaultdriver
Creatingvolume "wordpress_dbdata" withdefaultdriver
Creatingwordpress_db_1
Creatingwordpress_wordpress_1

$dockercomposeps
NameCommandStatePorts

wordpress_db_1dockerentrypoint.shmysqldUp 3306/tcp
wordpress_wordpress_1/entrypoint.shapache2for...Up 0.0.0.0:
 LEVANTANDO UN WORDPRESS

$dockercomposelogs f
wordpress_1| 127.0.0.1[16/Nov/2016:17:56:39+0000]"GET/HTTP/1.1"
wordpress_1| 127.0.0.1[16/Nov/2016:17:56:39+0000]"GET/wpadmin/insta
wordpress_1| 127.0.0.1[16/Nov/2016:17:56:41+0000]"GET/favicon.icoHT
DOCKER EN PRODUCCIN
 LOS DISTINTOS ESQUEMAS
Usando Docker para iniciar servicios de forma aislada.
Usando un cluster de docker.
 DOCKER STANDALONE
Cada servidor Linux corre el servicio de Docker en forma
aislada.
Los contenedores pueden iniciarse automticamente
durante el booteo usando:
Manejadores de procesos como upstart, systemd o
supervisor.
A travs de polticas de reinicio (Docker >= 1.2).
 A TRAVS DE MANEJADORES DE PROCESOS
Dado que Docker no setea polticas de reinicio por defecto,
cuando un servicio iniciado con Docker termina, no se toma
ninguna accin.
Las polticas de reinicio podran con ictuar con los manejadores de procesos.

INTEGRACIN CON LOS MANEJADORES DE PROCESOS

Cuando un contenedor ya corre como esperamos, entonces
podemos attacharlo a un manejador de procesos para que
l lo maneje.
Corriendo docker start -a Docker attachar al
contenedor corriendo (o iniciar si no est corriendo)
reenviando las seales al manejador de procesos.
 EJEMPLOS
Para entender los siguientes ejemplos veremos qu hace:
docker start -a
#Iniciamosuncontenedornginxdaemonizadoynombrado:
dockerrundname=nginx_dockerp 9090:80nginx

#Elcontenedoryaatiendeenelpuerto9090:
curlhttp://localhost: 9090

#Usandodockerstartparaattacharalcontenedornombrado
dockerstartanginx_docker
Ctrl+C#envalasealSIGTERMalproceso.Muereelcontenedor
#elcomandocurlyanoesexitoso

#Usandonuevamentedockerstart
dockerstartanginx_docker#reiniciaelservicio
 EJEMPLO UPSTART
Un contenedor que inicia Redis.
description"Rediscontainer"
author"Me"
startonfilesystemandstarteddocker
stoponrunlevel[! 2345]
respawn
script
/usr/bin/dockerstart aredis_server
endscript
 EJEMPLO SYSTEMD
[Unit]
Description=Rediscontainer
Requires=docker.service
After=docker.service

[Service]
Restart=always
ExecStart=/usr/bin/dockerstart aredis_server
ExecStop=/usr/bin/dockerstopt 2redis_server

[Install]
WantedBy=default.target

docker stop -t TIME enva la seal SIGTERM y luego del tiempo especi cado enva SIGKILL
 POLTICAS DE REINICIO
Si no queremos utilizar manejadores de procesos, entonces
podemos emplear las polticas de reinicio.
Estas polticas permiten especi car cmo un contenedor
debera o no ser reiniciado cuando termina.
 POLTICAS DE REINICIO
no: no iniciar el contenedor cuando termina. Valor por
defecto.
on-failure:[max]: reiniciar solo si el contenedor termina
con exit status diferente a cero. Limitar opcionalmente los
reintentos de reinicio.
always: siempre reiniciar el contenedor. Adems el
contenedor se iniciar cuando inicia el daemon Docker.
unless-stopped: idem anterior, salvo que en un reinicio del
servicio Docker considera si previamente fue detenido.
 EJEMPLO DE POLTICA DE REINICIO
#Iniciamosninxconrestartpolicyalways
dockerrundrestart=alwaysname=nginx_dockerp 9090:80nginx

#Verificamoslacantidaddereinicios:
dockerinspect f"{{.RestartCount}}" nginx_docker

#Matamosabruptamenteelcontenedor
dockerexecnginx_dockerkillQUIT 1

#Verificamoslacantidaddereinicios:
dockerinspect f"{{.RestartCount}}" nginx_docker

nginx recibe la seal QUIT para nalizar el proceso

https://www.nginx.com/resources/wiki/start/topics/tutorials/commandline/
 CLUSTERS DOCKER
La idea detrs de los clusters Docker es la de disponer de
nodos Linux con el Docker Engine de tal forma de poder
utilizarlos para correr contenedores.
Estos Linux deben ser muy pequeos dado que su nica
razn de ser es la de proveer un kernel, no utilidades.
Seran como equipos fsicos pertenecientes a un pool de
hardware disponible en un virtualizador como XEN o
VMWare.
LOS CLUSTERS MS CONOCIDOS

Swarm

Rancher

Kubernetes

Apache Mesos
CARACTERSTICAS DE TODOS LOS CLUSTERS
Diseo descentralizado.
Servicios, pods o stacks en vez de contenedores.
Posibilidad de escalar.
Conciliacin para alcanzar el estado deseado.
Service discovery.
Load balancing.
Actualizaciones en caliente.
 CONSIDERACIONES
El scheduler es el encargado de determinar donde se inicia
cada contenedor.
Asociado al scheduler trabajan los health checks que
garantizan la conciliacin de un estado deseado: que hayan
N contenedores para el servicio X.
La distribucin mgica del scheduler complica el manejo de
volmenes.
Los volmenes pertenecen a un nodo.
Si el nodo cambia, se pierden los datos.
 VOLMENES DISTRIBUIDOS
Necesidad de compartir datos entre los nodos del cluster.
Aparecen diferentes implementaciones de volmenes
compartidos. Las ms populares son:
Convoy
Flocker
EJEMPLO RANCHER
PREGUNTAS?
Y SI LAS PREGUNTAS SURGEN MS TARDE...
Leandro Di Tommaso
leandro.ditommaso@mikroways.net
https://github.com/leoditommaso
Christian Rodriguez
christian.rodriguez@mikroways.net
https://github.com/chrodriguez
GRACIAS!