aplicaciones en una unidad estándar de intercambio. Única pieza de software en un lesystem completo que contiene todo lo necesario para ejecutar una aplicación: código, librerías, herramientas, etc. Garantiza que el software siempre correrá de igual forma sin importar su ambiente.
entornos de desarrollo. Favorece las arquitecturas de microservicios. Diferencias entre el ambiente de desarrollo, testing y producción. Instalación de una aplicación en diferentes plataformas. Deploy de aplicaciones complejas. Ejecución de código antiguo. Escalamiento horizontal.
LOS CONTENEDORES Sistema Operativo recortado. Un único proceso corriendo: buena práctica. No utilizan manejadores de procesos tipo systemd. Red privada bridgeada en los contenedores. Si se quiere exponer un puerto se debe realizar explícitamente. El lesystem utiliza Union File System ( ). Basado en capas. Al eliminar un contenedor, su lesystem desaparece. UFS
UN CONTENEDOR Como los contenedores establecen una capa volátil por encima de la pila de capas de una imagen origen, una vez editado todo lo necesario en un contenedor, los cambios pueden comitirse en una imagen. $ docker run -it ubuntu:14.04 root@7c78d0a777df:/# apt-get update \ && apt-get install -y nginx && apt-get clean root@7c78d0a777df:/# exit
UN CONTENEDOR Veri camos el contenedor anterior CREAMOS LA IMAGEN CREAMOS LA IMAGEN A partir de ahora es posible utilizar la imagen chrodriguez/nginx:ubuntu-14.04 $ docker ps -a CONTAINER ID IMAGE COMMAND 7c78d0a777df ubuntu:14.04 "/bin/bash" $ docker commit 7c78d0a777df chrodriguez/nginx:ubuntu-14.04 $ docker run --rm -p 8080:80 chrodriguez/nginx:ubuntu-14.04 \ nginx -g "daemon off;"
Docker. Permite escribir instrucciones a ejecutar. Automatiza el proceso de la creación de imágenes. Permite repetir y modi car fácilmente una imagen. Generar de forma simple imágenes derivadas.
de Docker. Disponible en forma local o usar servicios en la nube: Instalación local: Acceso local para mayor velocidad de descarga. Imágenes privadas en un ambiente controlado y gestionado por la organización. Servicios en la nube: Generalmente las registries privadas tienen costo.
Plan pago para imágenes privadas. Soporta builds automáticos. Cuentas para organizaciones. Gratis para imágenes públicas o privadas. Soporta builds automáticos. Cuentas para organizaciones. Docker Hub Gitlab Registry
Los contenedores crean una capa con las diferencias correspondientes respecto de la imagen original. Entonces los contenedores deberían minimizar los cambios respecto de la imagen original. Optimizando el uso de espacio y evitando impactos de performance. Promoviendo la reusabilidad.
actualización de una aplicación, consiste en crear nuevas intancias y destruir las anteriores, en vez de actualizarlas sobre la instancia productiva. Una vez que una aplicación está corriendo, ¡evitamos tocarla! promoviendo así: Repetibilidad. Reducir costos de mantenimiento. Simpli car rollbacks.
aplicación 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 aplicación desde cero. El segundo punto lo resuelve fácilmente Docker.
las imágenes impactará en la performance de los contenedores que generarán grandes capas con datos dinámicos. Ante la actualización del contenedor, estos datos se perderán.
El tamaño es lo que crece el contenedor respecto de la imagen. El tamaño virtual es lo que ocupa el contenedor sumado al tamaño de la imagen. root@6ce39ac62830:/# dd if=/dev/zero of=/tmp/lala.img bs=1M count 10+0 records in 10+0 records out 10485760 bytes (10 MB, 10 MiB) copied, 0.0127865 s, 820 MB/s $ docker ps -s docker ps -s CONTAINER ID IMAGE .... SIZE 6ce39ac62830 ubuntu:16.04 .... 10.5MB (virtual 13 $ docker diff 6ce39ac62830 C /tmp A /tmp/lala.img A /tmp/prueba
destruirlos y volverlos a iniciar con una mínima con guración. Evitar paquetes innecesarios: las imágenes no deben incluir paquetes que no se utilicen. Un proceso por contenedor: en la mayoría de los casos, se debe correr un proceso por contenedor. La (in)necesidad de ssh: acceder a un contenedor es algo que debemos evitar.
un sistema de archivos de unión (UFS). Pueden compartirse y reusarse entre contenedores. Los cambios se hacen directamente en el volumen. La información del volumen no se incluye en la imagen. Persisten aún cuando se eliminen todos los contenedores que los usan. Pueden quedar volúmenes sin referenciar.
anónimo o nombrado, la información que exista en el punto de montaje se copia al volumen. Con volúmenes desde el SO host o desde otro contenedor, se oculta la información que exista en el punto de montaje. Correspondencia con el comando mount.
-v /prueba ubuntu:16.04 /bin/bash root@a9c1a6e6c0ea:/# ls /prueba/ root@a9c1a6e6c0ea:/# echo "Prueba" > /prueba/archivo root@a9c1a6e6c0ea:/# exit $ docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS a9c1a6e6c0ea ubuntu "/bin/bash" 2 minutes ago Exited (0) A $ docker volume ls DRIVER VOLUME NAME local e9c7022b8c7bec55891ca44b8c40de1e5f41cf0fe9505a334bca0 $ ls /var/lib/docker/volumes/e9c7022b8c7bec55891ca44b8c40de1e5f41 archivo
ubuntu /bin/bash root@7def6f99f957:/# ls /prueba/ root@7def6f99f957:/# echo "Prueba" > /opt/archivo root@7def6f99f957:/# exit $ docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS 7def6f99f957 ubuntu "/bin/bash" 2 minutes ago Exited (0) $ docker volume ls DRIVER VOLUME NAME local test $ ls /var/lib/docker/volumes/test/_data archivo
permite correr aplicaciones compuestas por múltiples contenedores. La arquitectura se de ne y con gura en un archivo de texto ( ). Simple e intuitivo. Se vale de un comando para: Iniciar, detener y reconstruir servicios. Ver el estado de los servicios, los logs, etc. YAML
versiones mayores diferentes, la 1, la 2 y la 3. Entre la 1 y la 2 no son compatibles entre sí, entre la 2 y la 3 comparten estructura, pero se quitan algunas opciones en la 3. Veremos la sintaxis de la versión 3.
a crear un archivo llamado docker- compose.yml. De niremos allí la arquitectura de la aplicación. Nos valdremos del comando docker-compose para levantar Wordpress e interactuar con los contenedores generados.
del versionado de código, se realizan varios merge a la rama principal, generalmente master. Integración continua. Correr tests antes de cada merge. Revisión de código: simple con ujos propuestos por GitHub/Gitlab a través PR/MR.
su nombre será X.Y.Z. Según el lenguaje, será necesario compilar y subir el binario a un repositorio: o . Con docker es el momento de crear una imagen docker y subirla a la registry Si automatizamos estas tareas estamos implementando Artifactory Nexus entrega continua
un despliegue de cero que una actualización Existe estrategias de actualización: Esta tarea es complicada si se realiza manual Sobre todo con aplicaciones que escalan horizontalmente Docker es una gran simpli cación a este problema Canary deployment Blue Green deployment
Linux corre el servicio de Docker. Los contenedores pueden iniciarse automáticamente durante el booteo usando: Manejadores de procesos: , o , etc A través de políticas de reinicio (Docker >= 1.2). upstart systemd supervisor
Docker Engine de tal forma de poder utilizarlos para correr contenedores. Estos nodos pueden usar SO muy pequeños (~ 50MB) dado que su única razón de ser es la de proveer un kernel con docker engine:
Diseño descentralizado. Servicios, pods o stacks en vez de contenedores. Posibilidad de escalar. Conciliación para alcanzar el estado deseado. Service discovery. Load balancing. Actualizaciones en caliente.
se inicia cada contenedor. Asociado al scheduler trabajan los health checks que garantizan la conciliación de un estado deseado: que haya N contenedores para el servicio X. La distribución mágica del scheduler complica el manejo de volúmenes. Los volúmenes pertenecen a un nodo. Si el nodo cambia, se pierden los datos.
Docker. Incluye una API que permite administrar el cluster. Utilidades de línea de comandos. Soporta múltiples plataformas de clustering para Docker: Cattle Kubernetes Swarm Apache Mesos Windows
readme, corremos: Notar que pasamos 2 docker-compose.yml En esta modalidad podemos trabajar sin instalar nada en nuestra PC, editando el archivo php de la raíz del proyecto cd docker docker-compose -p demo-lb-dev \ -f docker-compose.yml -f docker-compose.dev.yml up
con el siguiente docker- compose.yml Con guraremos el load balancer a partir del label seteado rancher-cli utiliza variables de ambiente que lo con guran version: '2' services: web: image: registry.gitlab.com/chrodriguez/demo-lb:0.0.1 labels: application: demo-lb $ rancher up
Y BACKUPS Las bases de datos pueden dockerizarse o no Los backups deben hacerse sólo de los volúmenes En mi caso, es una excelente alternativa Backupeando la base de datos de rancher, podemos recuperar nuestra infra completa rsnapshot
chrodriguez
yuki_ink
cyberagentdevelopers
wa6sn
kenjikondobai
negi111111
smt7174
ryomrt
mikit
oracle4engineer
niwatakeru
rrreeeyyy
chriscoyier
bryan
scottboms
danielanewman
eileencodes
mraible
maggiecrowley
lauravandoore
addyosmani
marktimemedia
iamctodd
